Making Scrum work with fixed price projects.

There are a lot of articles and talks swimming about on the Internet warning you against using a waterfall approach to project management. I bet you’ve seen them. And due to this you may presume that there is an epidemic of misguided digital producers out there. Why aren’t they listening? Can they not see the light?

But has anyone ever actually found an agency that has specifically chosen not to adopt an agile approach? I haven’t. I’m pretty sure everyone’s on board and we left the station a few years ago. We’re no different. And if Agile thinking is our weapon of choice, the Scrum mindset is our ammo. The problem is that there are no textbook answers to many of the real world issues that crop up in an agency environment.

I do believe it is the best option we as digital agencies have to work with, but the fact it was never initially designed with the agency format in mind results in some common flaws that sometimes force us to stumble and trip back down the waterfall. The fundamental difference is that we are a service industry, not manufacturers.

Now sure, a big part of our job is producing great products for our clients and their customers, but that is not where it starts and ends. On a day-to-day basis it involves a lot more than that. We also want to make sure that:

  • Our clients are as involved in the design process as they wish to be.
  • They understand what they are getting, and how much it is going to cost them.
  • They know what to expect from us and when to expect it.
  • That their vision is achieved.
  • That we make them look good (and this can apply on a personal as well as a company-wide basis).
  • That they enjoy the process from start to finish. Or at least not hate it.

We don’t employ account managers at BLISS. It is our belief that the services described above are best achieved by having a direct open dialogue between clients and the project team. They (the project team) are, after all, generally the ones with the answers. This policy is helped by two strict operational rules:

  1. No knobheads. BLISS exclusively hire nice people.
  2. No bullshit. We endeavour to operate under total transparency.

Despite this, there are some fundamental Scrum principles that can make the process frustrating for the client. In general, this is because it is an unfamiliar way of working.

A lot of these problems can be avoided by outlining and justifying our approach very early on. Typically with the help of pretty pictures, and if absolutely necessary, interpretive dance. Indeed, this educational duty is a big part of the Project Manager’s job. But there are some stickier points that seem to cause discord time and time again.

So over the past few months I’ve pulled out my meditation mat (see ‘bottle of wine’) and had a good old contemplation on the matter. In a series of articles I’ll outline the questions we asked, and the answers we came up with. First up…

How do we make fixed price projects work without a fixed scope?

When we agree a project, the client often wants to know what they’re going to get, and how much it will cost. Cheeky, I know! But they are the customer after all, and we aim to please so we agree a set price fee. But we’re using Scrum right? And therefore we need to be flexible to change. So how do we balance our desired attitude with that fixed price and scope?

Firstly (or once the project has been agreed in principle at least), we create the first draft of our product backlog.

This product backlog is based on a balance of the client brief and our proposal, and it summarises the functional expectations of the project. We work through every item on the list, breaking it down if necessary and establishing an estimate for the effort required to complete it (at BLISS we use story points for this).

You may now be thinking that this sounds a little premature, and ordinarily you would be right. It certainly goes against Scrum’s principles to do so much prep work upfront, but then Scrum wasn’t really designed for us, remember? We still try to limit the work involved. We may make (and document) a number of assumptions, and we accept that we aren’t going to be as accurate at this point as we would like to be. Even so, we know that some (maybe a lot) of the effort put in to this process will be wasted. We just have to factor this spill into the cost of sale.

Once we have finished refining the product backlog, we can calculate the sum effort we believe will be required for the project. This not only helps us to establish a project cost, but also formulates part of the sale contract which goes a bit like like this:

You (the client) agree to pay us (the shit hot web designers) a bunch of money. And we (the shit hot web designers) agree to do a bunch of story points worth of work for you (the client). If nothing changes, then those story points will equate to this list of features.

So what happens when (not if) the scope changes? Early on (and again and again and again…) we show the client the product backlog (find a simple example here).  We point out the feature estimate column, and the cummalitive estimate column, and explain that anything below this line (the line where the cummulative estimate, is greater than the number of story points we agreed to sell them) is not going to be completed within the scope of this project. 

A simple example of a product backlog. Try adding or re-prioritising​ the backlog items, and editing the budget.

We can add items, and reorder items as much as we want, but those items that fall below the scope line are probably not going to be completed without an increase in budget. And if the client wants to get some of these additional features in, great. We’ll provide a cost for some additional development sprints and shift the scope line down a bunch of story-points. 

Simple as that.

Now I’m sure there are many other ways of dealing with this issue (see some further reading and references below), but in our experience, this approach makes for a much happier process all round. The client knows what they are getting at any given time, and has the flexibility to sacrifice some features in order to include others; we’re not wasting huge amounts of time scoping and negotiating change requests that we often know are never going to happen; and we all get to look smug when we hear a talk about how evil waterfall project management is.

Some of the other questions I’ll be looking at in this series of articles include 'when exactly do we design things?'; and 'what do we say when a client asks for a concrete completion date for their project?'.

Keep an eye out for them.

References and further reading

Appelo, Jurgen: “Fixed Price Contracts in Agile Projects”

Borja, Manuel: “An Approach for Scrum in a Fixed-Price Contracts World“

van Baarsen, Tim: “Lessons Learned How To Do Scrum In a Fixed Price Project”