The Commercialisation of Agile (or how I learned to stop worrying and love fixed price)

John Cornforth, Head of Consulting, Tier 2 Consulting

John CornforthI’ve recently been thinking a lot about the way Agile projects are approached commercially, and how hard, commercial realities can seem at odds with the seemingly light and fluffy ideals put forward in the Agile Manifesto.  The two main reasons why I’ve been thinking about it so much are a) it’s my job, and b) I’ve recently been asked to speak about this very subject.

At first glance, these two worlds seem diametrically opposed.  On the one hand, you have what I like to call the “Customer Charter”, which comprises the 2 basic questions any software delivery team has to answer:

  • How much will it cost?
  • When will I get it?

Contrast this with the values of the Agile Manifesto, which sound like the software development equivalent of holding hands and singing “We are the World”:

  • Individuals and interactions over processes and tools;
  • Working software over comprehensive documentation;
  • Customer collaboration over contract negotiation;
  • Responding to change over following a plan.

So, how do we reconcile the two?  In other words, how do we allow ourselves to run a project according to the Manifesto’s principles, while providing a credible response to the challenges of the Charter?

One answer lies in looking at the Charter itself: in particular, what it doesn’t contain.  In my experience at least, the actual functionality (i.e. the “What will I get?” question) is either absent or a distant second to the other questions.  Most, if not all, of the projects I have been involved with had some level of uncertainty associated with them: what I like to call a “requirements fog”.  Sometimes this fog is more of a light mist, and sometimes it’s thick pea soup.  In some cases, and continuing the food analogy, the project’s requirements are so vague that the business analyst’s job can be likened to “trying to nail blancmange to the ceiling”.

What we can be certain of is that, even if there appears to be no trace of fog at inception, it will descend at some point, and change will happen.  This change may be the result of a change in business rule or policy, an omission, or simply the customer having new ideas as a result of a demo or testing.  The only way we could realistically account for these at inception is to add the following questions to the charter:

  • What do you want?
  • What do you really want?
  • What do you really want, now that you’ve had a chance to play with it?

There is no way to answer these questions at inception, and we shouldn’t even try.  All we can do at inception is go with what we know, foggy or not.  In practical terms, this means producing a set of high-level estimates based on whatever requirements information is known or can be gleaned without resorting to a (potentially costly) requirements analysis exercise.  Having said this, I would generally go to the trouble of creating my own product backlog, separate to whatever requirements documentation may or may not have been provided by the customer.  This is good practice for the following reasons:

  • it’s a good discipline, forcing you to re-read, paraphrase, and potentially remove, join or split requirements;
  • it’s a good reference point to keep track of requirements during development;
  • it’s a great checklist for testing.

In the SCRUM world, the high-level estimates will give us an idea of how many development sprints are going to be required.  Sprints are, by definition, fixed cost, because they are a fixed period of time, so essentially we can present our fixed cost and defined timeframe to the customer right then and there.

The only thing that’s missing is the “what”, and this is where prioritisation of requirements is key.

Let’s assume we’re using the MoSCoW scale: we cannot have a product backlog with all Ms.  There has to be some wriggle room – some nice-to-have requirements which can potentially be dropped in the event that a new, high-priority requirement comes in, or some other unforeseen change occurs.

This approach ensures that the customer ultimately still gets the system they had envisaged, but perhaps minus some functionality.  More importantly, the decision to omit said functionality is the customer’s, not an arbitrary decision made by the developers because they simply ran out of time.

In terms of adhering to the Manifesto’s principles, we get a big tick for “individuals and interactions”, “customer collaboration” and “responding to change” without compromising the Charter: the “how much” and “when” remain the same – only the “what” has changed.

Now, as for the principle of “working software”, that’s a whole other blog…

Find out more about Tier 2 Consulting.