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.

Comments

Hi Zach,

Great article, observant and reflective. Its conclusion was along similar lines of what Andrew and I were talking about yesterday, which I do appreciate. :)

I do have some feedback for you that's also related to your question to me about doing Scrum training for your vendor product owners. I suspect a conversation may work better, but I'll try to do that here.

There seems to be a misunderstanding of the Scrum Product Owner role. The traditional product owner would be whoever owns the site and initiates the project, in your case, the client. However, the Scrum Product Owner role represents stakeholder interest to the team and the team's interest to the stakeholders. The SPO gets requirements from stakeholders and prioritizes the product backlog accordingly. At the same time, SPO also has the responsibility to communicate to the stakeholders what can realistically be done by the team and what is not reasonable or possible.

So the Scrum Product Owner has to be an integral part of the team -- one of the "pigs" in the sense that SPO is one of the people who is actually doing the work. This is why I always stress to say Scrum Product Owner together as opposed to just saying product owner, because it is very easy to be misled by the terminology. The distinction is very, very important. The SPO (along with the ScrumMaster) are the servant leaders serving the team. It can't be someone on the client's side. They are the stakeholders.

So when product owners are referred to as clients or when you talked about the product owner being on the vendors side, that sets off all kinds of alarms in my head.

I'm not involved in what and how your team is engaging with your clients. Maybe this point has already been clarified in an earlier post, but from reading this particular post, it isn't clear to me what your team's role is. So it's hard for me to make any other comments. Perhaps what I'm saying here really doesn't make sense, which is why I think a conversation would be more helpful. I would love to hear about what your team does and how you operate.

By the way, I would be happy to do the training for the vendors, but I don't know that that will solve your problems. I would suggest that your team invests in someone on your team (ideally all of your team) to be educated more in Scrum to help your team be more effective using this approach.

Hope this helps.
Xinlei

Hi Xinlei, thank you so much for joining the conversation here, I really appreciate your voice and your expertise. Thanks for the invite to your Agile Discussions group, I'd like to start coming to that.

the Scrum Product Owner role represents stakeholder interest to the team and the team's interest to the stakeholders.

I think that this is true, to one degree or another, for our projects. However, Scrum is still pretty new to us as an organization, I don't have the luxury of standing in for the full development lifecycle of these projects. My involvement normally ends at vendor selection. Where our arrangement differs from what you describe above is that we don't really have SPOs. We have experienced managers of departments, centers, and institutes that are accomplished professionals, but new to web projects and new to scrum. They are normally empowered to represent all stakeholders --though we need to assure signoff at key juntures-- so they naturally do a good job or representing stakeholders interests to the team, BUT I'm not so sure that they can always represent the team's interest to the stakeholders. We do expect that the client|product owner will prioritize the backlog, etc.

So I think what we have here is about an 80% fit. What concerns me is that the remaining 20% is a significant gap that we should consider how to close. I know that some agencies will provide an analyst or "client advocate" role to teams that lack a true SPO, but this is far from universal.

Let's talk some more about this. I'd like to explain in greater detail where I see some potential hazards that we might come up with a way for pro-actively avoiding.