In the second of the series examining the twelve principles of the Agile Manifesto we come to the thorny problem that is the bane of software development teams the world over, change. How should the team react to the news that the client has moved the goalposts off the field? And  during overtime! The Manifesto says that we should take this in stride, but should we? Some of us beg to disagree.

Principle #2 – Welcoming change
Principle #2 asks us to “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage”.

I am afraid that the ideals behind welcoming change are so badly expressed I can’t even countenance this principle as a rule. It might have lofty goals but to anyone outside the software development community they are being expressed in a nonsensical fashion. We are asked to welcome two of the most destructive elements of quality and value in almost any endeavour and to believe that this is somehow related to competitive advantage for our customers. If the first principle was hopelessly optimistic this one is so far out there that one would have to ask a software development team that genuinely worked to this principle what kind of happy pills they were on.

This principle is wrong from the first word – welcome. To welcome clearly implies that to receive changing requirements, no matter when they occur, is something that is of universal, positive benefit. Smile! Laugh! The six weeks that you spent busting a gut and burning the candle at both ends to deliver top class, robust software may be going down the toilet because the client changed his mind, but hey, that’s what we all wanted. We welcome change, right? Wrong! Here’s why it is wrong and if you can change the fundamental basis of this argument then I shall withdraw it.

Time is money and nothing takes no time. Anything that adds to the time that it takes to develop software also adds to the cost, whether you can charge for it or not. Changing requirements, particularly at late stages of development invariably add time; the later the change the smaller the chance of minimizing its impact. In order to ‘welcome’ changing requests, particularly late changing requests, everyone would somehow need to benefit from this. The client might benefit if the cost to them was zero, but then the development team suffers in comparison because they are now working for no reward. The development team might benefit if they charge the client for the additional work and inconvenience but then the client suffers. However we look at the scenario it does not deliver a zero sum game where nobody loses. We can all accept that we will lose out in a transaction but only a fool would welcome the fact.

The second principle asks us to welcome change precisely because the authors of the Agile manifesto’s principles knew how destructive changing requirements, and particularly late changing requirements, are to software development.  Why then would we be asked to welcome change? It makes no sense and things that make no sense cannot be principles.

Before I go on to explain what I believe this tenet of the manifesto evolved from and what I know it should say, I would like to finish taking exception to its wording.  We are supposed to accept that “Agile processes harness change”. This is meaningless verbiage of the type that campaigners for plain English frequently denounce. Nothing harnesses change. It is a meaningless expression because change, by definition, is not a force you can harness. You can adapt to change, you can welcome change (though not, I believe in the sense of the second principle), you can even instigate change, but you cannot harness it unless you are the Lord of Chaos.

Believe it or not, I still haven’t finished taking exception to the wording of this principle because I think that to then link Changing Requirements, Software Development and your customer’s Competitive Advantage is to make a connection so tenuous as to be fatuous.  I have worked in the software industry for nearly thirty years as a Programmer, PM, Technical Architect, Head of Engineering and CTO. In that time I have worked on projects for at least twenty global corporations, and I have never, ever seen a situation where the acceptance of a change to a client’s requirements could be said to confer competitive advantage on their business. All that can be said about these particular words in the manifesto is that the founding fathers of the Agile manifesto were not economists (I hope) and simply misused terminology. I think they were trying to say that the acceptance of a late change would be to the client’s benefit and maybe it is, although I have worked with many clients who quite frankly had no idea what they were letting themselves in for when they introduced a change late in the day and soon wished they hadn’t. Usually the client learns to deeply regret asking for late changes and wouldn’t have made the request had they known the detail of what it entailed. It would have been better to create a principle that said that Agile teams are responsible for educating the client about the cost of making changes, particularly late in the development cycle.

I said in my analysis of the first principle that “a principle is something that can be held up as true and not merely honest.” The truth that I believe the second principle to be based on is:

“We are all helplessly carried along by the tide of change. You can go with the flow or you can sink where you are but you cannot stem the tide.”

What this means for software development is that we must accept that our customers must react to change. As the customer might say - “Thank you very much for the software that you have designed and coded but I’d like to point out that my rival has come up with something new and I need to respond. I’m sorry if it is inconvenient for you but we live in the real world and change happens.” How the customer reacts is a matter for them and entails a complex range of possibilities that even the customer might not be sure is in their best interests. In the face of declining sales of toothpaste should Colgate change the images in their current online campaign to show people with worse teeth or should they widen the holes of toothpaste tubes by a fraction to compensate? Who knows? The board don’t and the Agile team responsible for maintaining the website hasn’t a clue either.

Here is my version of the second principle, which is all about change. I hope it serves you well.

“We cannot predict the timing, extent or nature of change because change is frequently foisted upon us. Successful teams will be those that learn to accept that change is an inevitable consequence of living. Those who recognise that this is a universal truth that applies to every third party that they interact with, will be those who fare best in the face of adverse circumstances caused by change.”

Following this principle, software development teams can develop rules and practices that help to minimize the impact of change. Agile incorporates a way of working that minimizes the impact of late changes. If your team doesn’t already use this methodology, now at least you know why Agile works the way it does in practice.

Trackback(0)

TrackBack URI for this entry

Comments (2)

...
written by dsikuade, March 07, 2011

The answer is 'yes' and I am really pleased that the principle works for you, I never doubted it would. I think you will find that the point I am trying to make is that the concept of 'welcoming change' only makes sense if you live in an agile world and are blessed with an insider's knowledge.

• 
• +1
• 
• 

...
written by Alan, March 07, 2011

Dele, have you ever lived on an Agile project?

To make my point, your comment about "The six weeks that you spent busting a gut and burning the candle at both ends to deliver top class, robust software may be going down the toilet because the client changed his mind, but hey, that’s what we all wanted." makes no sense to me.

An Agile team works at a sustainable pace and yes I have had the "requirements" change a month before funding ran out without issue. The key is to introduce change (which is inevitable) in ways that we can control (through regular iteration planning). I have seen this many times on Agile projects and it is not an "either/or" scenario (customer or development team winning) as you suggest, but both the development team and our customer have come out winning.

So for me, the second principle works just fine, it's simple and clear.

• 
• +0
• 
• 

Write comment

Show/hide comment form

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment Preview