Monday, 8 September 2008

Iterative and Agile - the Venn Diagram of truth

I'm seeing a bit of this lately:

"Iterative software development is Agile software development."

and I have to say that I disagree quite strongly. The Venn diagram actually looks more like this:


This post has been prompted by two things. First, a few weeks ago a SCRUMmer made some comments along the following lines:
  • "We don't allow changing the iteration plan once the iteration has begun" 
  • "All the requirements for the stories for the iteration must have been gathered before it starts."
  • "If the customer want something else, they have to wait for the next iteration"
And some articles/blogs about iteration lengths that jogged my memory about what I disagreed with. The root of my discomfort in equating iterative development to agile development is because

agile software development is a set of values, it is not a process. 

In fact, one of the core values of Agile development is to not value you process too much. There are some processes that try to embody Agile values, and they have different interpretations and practicalities around those values, but these processes are not what defines Agile development. 

Here's a reminder of what it means to be agile:
  • Individuals and interactions over processes and tools 
  • Working software over comprehensive documentation 
  • Customer collaboration over contract negotiation 
  • Responding to change over following a plan 
It's very possible to do iterative development without embodying any of these values. Treating each iteration like a waterfall with the usual waterfall suspects (requirements up front, little room for manoevering, opressive specification and documentation) is a case in point. And to me, valuing your plan over your customer by not responding to their needs is not Agile.

You are, of course, invited to disagree...

1 comment:

Immo H√ľneke said...

I think it's very valuable to point out the ways in which the practice of Scrum sometimes diverges from the agile ideal. However, Ken Schwaber had valid reasons to insist that scrum iterations are of constant duration and that the requirements of an iteration don't change once it has begun. If requirements are allowed to change at any time, the developers are on shifting sand, which diminishes their productivity and motivation. Experience shows that quite often, the customer changes his/her mind about a new feature or property of the system that suddenly seemed utterly essential. Deferring consideration of change requests to well-defined points in the lifecycle imposes some discipline and damps the customer's "mood swings". But Scrum has a get-out clause. If it is evident that the current iteration is heading in the wrong direction, then the team and customer can agree to terminate it immediately and instead start planning a new iteration.