So what’s in a name … ? Does it matter what you call your chunks of work ?

In many ways it doesn’t – different people use the terms inter-changeably. Sprint is specifically a Scrum term, XP tends to use Iteration, each different Agile approach has different ways of defining and using the terms. However the common ground is that they are regular, repeated timeboxes used to manage the work to be done so that there are regular checkpoints and feedback as part of the project process.

However there are some important differences between the processes of iterating versus incrementing.

Jeff Paton has posted a nice summary of the difference, along with some pictures that help to make it clear:

Iterating: Starting with an idea of what is wanted and refining that idea to get the desired result

Incrementing: Starting with a much more definite understanding and building piece by piece

Both still have the benefit of regular feedback and both can still deliver usable software at the end of the timebox. Incrementing is probably more useful when requirements are more stable or better understood, whilst iterating allows a more agile response to changing or unclear requirements. There’s no reason why a project can’t use both, at different times and for different features – in fact most projects probably should.

So – whatever you call your timebox periods, make sure you understand whether you want to iterate or increment.

Mark raised some very good points in his comment against my recent post on welcoming change in projects:

“One main barrier to these approaches being adopted in the past was the engagement/contract models that our clients dictated. If the project needs a fixed cost, you usually need a fixed set of requirements.”

So what to do ? Does this mean that an Agile approach can’t be used ?

Much of what makes up Agile development is simply sound development practices, but what specifically could we take from the Agile philosophy for use in a fixed price contract ?

Let’s look at a typical situation we encounter – responding to an RFP or other tender. The client has provided some overview of the goals, objectives and requirements, a target completion date and wants a fixed price quote.

1) Respond to the RFP in the best way that you can
You need to make (and document) assumptions, try and fill in the gaps, use your experience – anything you can do to improve your information. And you need to estimate the work. There are no silver bullets here, with Agile or anything else, you just have to do the best that you can. However, if you’re used to working Agile you’ll be used to identifying requirements and putting together good estimates fairly quickly – treat is just like a normal planning session (someone will have to pretend to be the customer !).

2) Plan to deliver business benefit early
This is core to an Agile approach in any case – “early and continuous delivery of valuable software” – but it also means that if something surfaces during the project that significantly affects your original estimates you’re in a better bargaining position. A client is much less likely to be concerned about a suggestion to drop some of the minor functionality if they can see a working solution that already implements their most important requirements.

3) Promote your Agile approach as a benefit as part of the proposal (and put your money where your mouth is)
The use of Agile processes is now widespread, almost mainstream, so is something that can add value to your proposal. Even if your client isn’t really aware of what Agile processes are all about tell them what you are offering – choice. The ability for them – the client – to have control over the process and end it at the end of the next iteration if they’re not happy. Or maybe even if they are – because they might by that stage have what they need to achieve the business benefits they are after.

4) Do the job better
In the worst case – even if the client is not interested in Agile processes or iterative development – you can still benefit from those processes as an external vendor / supplier. If your development processes are more efficient and more effective then you are going to be more competitive at proposal time, as well as more likely to deliver on time, on budget and to meet (or exceed) your client’s expectations.

As Mark also points out in his comment – things work better when you have “trusted partnering relationships where both parties are working for mutual benefit”. Or – as the Agile Manifesto puts it -“Customer collaboration over contract negotiation”.

The more you can demonstrate delivery of business value, the more you can develop trust. On the other hand, if you need to rely on the wording of a contract to protect your position then the project is already in trouble.