Sunday, July 09, 2006

What’s so special about Agility?

Gosh, I was looking at all those individuals who have signed up at http://agilemanifesto.org/sign/display.cgi. Hey, if you think there is a different way, add a comment, I can’t be the only lone voice – can I?

So, the Agile Manifesto is based on a dozen ‘principles’. Let’s take a look and see. I’m concerned that the Agilites somehow think they are unique in their beliefs and that there is no other way in which quality software can be produced.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This is the fast food philosophy to software development – clearly the Agilites can produce you something quickly however it is unlikely to be something that will be of quality, will inspire you or satisfy you beyond you immediate needs. Many customers are looking for something that will be substantial beyond their immediate short-term gratification. It is arrogant to assume that all customers are motivated and share this priority. Clearly time to market is important, but slapping out versions of half-baked software is not always the answer.

I’m reminded of Fred Brook’s preface to chapter 2 of The Mythical Man Month, actually the chapter named after the book. He quotes from the menu of restaurant Anoine, New Orleans – ‘Good cooking takes time. If you are made to wait, it is to serve you better, and to please you’.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Have these guys never seen effective change management processes? Even ‘waterfall’ techniques can accommodate change late in development when an effective change management process is in operation. Further, the customer is given an informed choice based on an impact assessment (these are really cheap and easy to do) irrespective of the development stage. The Agilites would press ahead without any foresight – I know some customer’s who wouldn’t feel comfortable with that. Can you imagine the scenario – humm let’s try that idea out and see if it works? I’m not sure what impact it will have longer term but let’s give this a try? This is a rather speculative and potentially risky strategy at times don’t you think?

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Continuous integration is possible with an iterative architecture driven approach. I would have it no other way, daily builds once construction has started. It is just a question of when does construction start? Perhaps a little later than the Agilites would like.

4. Business people and developers must work together daily throughout the project.

Do the Agilites live in a different Universe? If the customer is paying, they’d sure like it for the business to talk to the developers. I’ve never seen this not happen – why is this exclusive to Agile development?

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Yep – done this, but not with Agile techniques. I’ve known developers wanting to defer their holidays because they could see the value of a plan based, architecture, design lead approach.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

True. But I hope they write it down – the mind is a fickle thing and miscommunication is easy. We can all speak the same words but mean totally different things.

7. Working software is the primary measure of progress.

Why? This is based on the premise that customer’s are not educated, or are to too stupid to understand that progress can be measured in other ways. If I’m having an extension added to my house I hardly expect the builders to turn up and start to dig the foundation and lay bricks until we’ve agreed the detailed blueprints. With an Agile approach they’d lay the foundations in the wrong place (costly to change) or build walls that would need to be knocked down. Why would a customer pay for an army of Agilites to start cutting code which will be wrong and require modification. Surely paying someone to think before that code is a far more prudent plan.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

What on earth does this mean? Can someone explain this principle, it seems to imply that sustainable progress is only unique to Agile approaches.

9. Continuous attention to technical excellence and good design enhances agility.

How is this possible – on the Agile projects that I have observed everyone is racing along so quickly that they don’t have time to think. Technical excellence is rarely achieved and poorly thought-out designs occur. Somehow there is an expectation that some combination of rudimentary code refactorings will salvage a poor design. This is rarely the case.

10. Simplicity--the art of maximizing the amount of work not done--is essential.

Yes I subscribe to the Ludwig Mies van der Rohe ‘less is more’ principle.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

What effective teams aren’t self-organising?

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Continue review is an excellent principle, but again this isn’t exclusive to Agile approaches.

2 comments:

Anonymous said...

well Angry, I have been working in the IT industry for over 30 years. I have seen it all, I think. Customers who want to leave all the details to you, the developer, and then reject what you do as not being what you want. Self-organising teams as a norm? Give me a break. If you mean that the project manager tells everyone what to do, and he is part of the team, therefore the team is self-organising, then yes, self-organising teams.

I am drawn very much to the Agile Manifesto because I have seen so many project failures due to almost every one of the anti-agile practices that are stated there. Heavy handed planning up-front, estimates made to satisfy the IT manager or the business manager, that become fixed price quotes without having any real validity, long and frustrating working days and weekends to meet unrealistic deadlines (the famous 'death march' syndrome), customer refusal to participate on the grounds that 'you're the expert, why ask me?', an adversorial approach with constant tension and friction between customer and developer, often caused by unrealistic promises made by salemen etc etc etc.

The one time that I was able to say that I had participated in a totally successful development was when I was allowed to use an agile, prototyping approach ... on time, at 50% of expected budget, and the system worked exactly as the client wanted on Day 1.

Sorry ... I think the Agile Manifesto is a coherent amalgam of good experience (or maybe all those bad experiences). My consultancy motto now is 'Agile Always'.

Anonymous said...

Hi Angry,

I agree with everything you have written. Most of the agile manifesto is not new to anyone doing modern iterative and incremental development.

Perhaps, however, it is a step in the right direction (albeit a small one) for those who previously have just been coding, coding, and coding.

I don't see how "the code is the only model" can scale though, and it seems rather silly to me to try to capture analysis and design in code.

For professional developers on serious projects there are, as you suggest, more mature approaches to most of the manifesto's key items.

Cheers,
Ashley Aitken.

PS Hi Roy!