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.
