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.

My last post on Agile software development ended on one of the Agile Manifesto key principles – “Welcome changing requirements, even late in development.”

But surely that leads to chaos – how can we possibly build something if we’ve got a moving target ? It must make more sense to gather all the requirements from all the stakeholders, lock them down and then make sure we deliver …

Let’s explore that thought for a moment. It is conventional wisdom that defects are more expensive to fix the later thay are discovered. Requirements are gathered at the start so changing them down stream will be expensive – the further down stream the more expensive.

But what are the costs of not allowing requirements to change ? Even if the solution is delivered on time, on budget and meeting all requirements, research has shown that more than 60% of the functionality is rarely if ever used and only about 20% is used often. Why is this …

1. The requirements change: Business moves on, and the longer the project the more things change
2. People’s understanding of the requirements change: People aren’t very good at predicting what they want
3. People make up requirements: “This is my only chance so I’d better ask for everything I could possibly want”

But what if there was a way to change things ? What if a change to requirements could be made without the expense, or maybe even to save costs or increase benefits ?

The full principle from the manifesto is “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

Change happens. Projects are about making change. We can treat changes within our projects as an impediment that needs to be constrained or removed, or we can harness it.

The Agile Manifesto was released in 2001 with some theatre and not a little revolutionary symbolism. Whilst it was seen by many as being a radical departure from accepted software development “best practise” I remember being somewhat bemused at what all the fuss was about. Rather than being a radical departure, it seemed to describe a lot of what we were already doing.

So were we doing Scrum back in 2001 ? Or XP ? No. Although these methods (and others) had been developing for some years before the release of the manifesto, at that time they didn’t have widespread adoption or even awareness. But – at a time when projects around us were being cancelled, in some cases after years with no progress – we were writing good code, delivering quality systems that the users liked and getting things done. So were we “doing Agile” ?

Here are some of the principles we followed back then:

• Sit the development team together and as close as possible to the business
• Encourage regular informal interaction between the development team and business
• Recruit good people with a passion for what they do and trust them to do it
• Focus on the business benefit, not the technology
• Make sure it works, make Sure it works, make sure it Works

These principles evolved from experience – seeing what worked and what didn’t – and from an innate sense of what is ‘right’ both ethically and in terms of effectiveness. A lot of these could almost be taken directly from the Agile Manifesto and supporting principles which perhaps explains my initial response. So in that sense we were certainly in the spirit of Agile.

But there were a few significant concepts introduced with the Agile Manifesto that were not front of mind for us back then. One of these was “deliver early, deliver often” – an idea so mainstream now that it seems hard to conceive of a time when it wasn’t practised. Yet this more than anything has helped demolish the great dividing wall between technology and business, allowing people from the non-technology world to step into the development process and share control.

Fast Forward to today and what has changed at Shine ?

In some ways nothing at all – we still subscribe to the basic principles we were following in 2001 simply because they’re right and they work. We are still writing good code, delivering quality systems that the users like and getting things done. We’ve chosen not to standardise on a specific Agile methodology yet, but we have heavily borrowed from many and used ideas as appropriate to specific projects. We have used time boxed iterations, test driven development and continuous integration (amongst others) as techniques to help, particularly in order to “deliver early, deliver often”.

It is worth remembering that Agile software development is not XP or Scrum or AUP or any of the other many and varied methodologies. These are expressions and extensions of the underlying principles laid out in the Agile Manifesto. So perhaps Agile software development is more evolution than revolution, defined by a group of like minded people who stood up, looked around and recognised that some of the things people were doing actually made things better.

Or perhaps it is something more.

One of the other new ideas was to “Welcome changing requirements, even late in development”. This puts control of scope squarely back with the business – where it should be – but is arguably the greatest challenge to traditional software development approaches.

But that’s another story in itself so it will have to wait until next time.