Skip to content Skip to navigation

Agile Developer, Waterfall Client

In my role as Web Strategist, I enjoy a privileged perspective on the state of the web industry in higher ed. I get an inside look into the new methodologies employed by some the best agencies in the business. Agile project management is a growing trend, and one that different vendors employ in different ways: some scrupulously follow the Scrum method and all of its rituals, while others prefer a “hybrid” approach. In this article I gather some of the lessons learned from some of the largest web development projects at Stanford over the past year, in the hopes of sharing them with others that are about to embark on their own projects.

What is Agile exactly? At its core, Agile project management means that work happens iteratively, and that the Product Owner (the client) has the ability to change directions, and doesn’t have to define everything in the beginning.

This all sounds pretty wonderful right? Well, it can be. At SWS we are using some Agile methods in our in-house development, as well as in vendor projects. This has been incredibly effective for our team, as Agile has the ability to stand up prototypes very quickly, and therefore at a reduced cost.  When the machine is working well, communication channels are established, and everyone knows their role, Agile can yield incredible results.

In other cases Agile doesn’t work very well, and it often comes down to the client, their culture, preferences, and customary way of working. On the vendor side it requires an expert PM and careful monitoring of budget burndown.  A lot of things have to go right. So, does Agile work for web projects at Stanford? Will it work for you? Maybe not. One important part of Agile development that takes some getting used to is that there may be no firm specification at the beginning--the requirements take shape over the course of the project, and can change based on evolving needs. At Stanford we typically do not use pure Agile for web projects, in part because of institutional preferences and ways of working.  Even when we engage in Agile methods (mostly we use Scrum), we have an endpoint in mind, and a set of requirements articulated at the end of a Discovery phase.

Minimum Viable Product

A key concept in Agile development is Minimum Viable Product (MVP -- the nature of which is pretty evident in its name).  MVP is a barebones version of the project, a prototype that includes all the must-have functionality.  If the Agile process has gone awry (due to miscommunication, excess communication, etc.), MVP is all we will have at the end of the project.  If the Agile project has gone well, we will have MVP very quickly, and many rounds of subsequent improvements. In a recent project with SWS, we engaged with a vendor in a T&M (Time and Materials) contract that spanned a maximum of 10 weeks.  The team was very efficient, with clearly defined roles; we got to a functional prototype in the very first sprint (!) and we essentially reached MVP in the very next sprint (in this case sprints were 1-week long).  
Bottom line: we achieved what we set out to do using only 20% of the allotted budget.

Ugly First, Pretty Later

A Minimum Viable Product is, well, minimal.  Agile focuses on building a rough version as fast as possible, and then adding more and more each sprint until we have a polished final product.  The website will be ugly for a while. This is normal. Your developer will be focused on the underlying content and data structures--content types, taxonomy, user roles and permissions--and pretty doesn’t usually make it into the first sprint.  It’s important to know that from the outset.

Working with a barebones prototype and incrementally improving it can be a challenging proposition for clients because it focuses on what’s under the hood first (which is harder to appreciate), and the visual layer comes into focus gradually. This is especially challenging when we need to communicate progress to higher level stakeholders--which we should always do.  For this reason, Waterfall methods, in which a discrete design phase precedes development, often make more sense for institutions like Stanford.  The challenge is to discern why Waterfall works better for client communication, and borrow what we need from it.

What Works for Stanford

Regardless of the project management methodology employed, getting stakeholders on board with the direction the project is taking --in particular the creative direction-- is vitally important.  Project leads (cf. Product Owner) are typically empowered to make all the decisions in the development of the project, and approve invoices, which can make it challenging to know exactly when we should check in with the higher level stakeholders on whose behalf we are acting. At minimum, I recommend that we seek signoff from stakeholders for visual design, which tends to be a component that generates a lot of feedback, and people tend to get more involved around page comps.  There are other key moments that might also be good to gather feedback (such as final wireframes, and style tiles) but comps should be shared at minimum … and here is where we can start to have problems with Agile.  

Agile projects might not even produce comps at all, and some shops have begun “prototyping in-browser” rather than wasting time with lo-fi wireframes or hi-fi HTML prototypes. For client communication and signoff, we need to take a page from the Waterfall playbook. Even if the developer is prototyping in-browser we still need some form of visual to share with stakeholders for their feedback.  In the event that your Agile process skipped these shareable artifacts, we still need to come up with something portable to circulate (likely via email).  A jpeg screenshot of the site (assuming that it has crossed the ugly->pretty threshold) will suffice. This may seem backwards to some, but experience shows that a jpeg comp is an important communication tool for Stanford clients (and I would wager for many other institutions and clients in other verticals as well).

Be Careful What You Ask For

The Product Owner of an Agile project is empowered to change or refine direction at the end of any given sprint (an intense period of concentrated work, usually 2 weeks in length). That is awesome. It’s also dangerous.  Most projects have fixed budgets, and we have to be very mindful that for every new feature that is added midstream--each sprint spent on researching the applicability of that new javascript library that didn’t exist at the start of the project--those are all billable hours, and we are choosing to give up something else as a result.  For this reason, Agile projects cannot be beholden to a specification that was minted at the outset.  Product Owners must know that they have to exercise their powers of prioritization judiciously.

Summary: Lessons Learned

  • Formal agreements, formal process structures are important.  Vendors that have well established PM structures and habits tend to be the most reliable on Agile projects.  However, if they use terms like “Agile-ish” or “hybrid agile” it doesn’t mean that they don’t know what they are doing. We have to dig deeper, there is no litmus test.
  • Stakeholder Signoff Plan. Have a plan for how you are going to communicate with stakeholders and keep them in the loop at an appropriate level.  Avoid design-by-committee. Luckily everyone thinks that is a bad idea … even committees.
  • RACI Responsibility Matrix. In a recent project SWS was able to hit the ground running because we drafted a formal responsibility matrix that eliminated the possibility that anyone wasn’t clear on who was doing what.
  • Fully sized and ready backlog. Scrum projects work by atomizing work into user stories that reside in a backlog, and are prioritized by the Product Owner.  If the stories in the backlog have not been properly “sized” by team consensus, you may have a problem on your hands. Insist on a “sized and ready backlog” if attempting Scrum with a new vendor.
  • T&M is okay so long as there are checkpoints, and only for trusted vendors
  • Burndown charts are an important way to make sure that we are not surprised by a budget shortfall.
  • Project Managers are the most valuable resource for overall success, and really great PMs are hard to come by. If you have one, hold on to them! The best ones not only keep everything moving smoothly, but also provide pushback to clients when needed. At Stanford we don’t like pushback, but we need it.  

So, is Agile right for Stanford? Yes.  Assuming that Stanford clients go into a vendor contract with a clear idea about what it means to be part of an Agile project, are fully cognizant of the hazards, are working with a trusted vendor, and have a plan for engaging stakeholders, Agile is an efficient, cost-effective, and fun way to work. It is also worth noting that the Waterfall method is still relevant, tried and true, and is proven to work well at Stanford, so not every project should use Agile.  We are fortunate to have a number of excellent web vendors that are sensitive to our needs as clients, and can adapt their process to help us build the next generation of web experiences for our users.