Project management methods typically do not take this creative nature of sw development into account, they assume a straightforward model using known solutions. The methods assume it's like building a house, the same way as building another house, just built. While building such a replica house, a management method of tasks and timeframes might be suitable. For sw, these methods could be applied for duplication of already written sw, but they would have little, if anything, to do with sw development. It would be convenient for management if sw development could be managed as a set of tasks with known costs and pre-determined QualityAttributes, but that is simply not the Case.

In addition to sw development being a creative Process, there is the fact that what customers and other Stakeholders want and need, they don't normally know up front; nor do they know how to express them. Even if they did know, their needs and wants change quickly.

So sw developers were historically “managed” with methods that ignore this dynamic Quality environment. With rigid, top-down, frozen Requirements, they planned everything in detail first, and then went and coded it afterwards from the specifications. Failure projects were the norm (as they still are with agile) and frustration was high among developers. Out of this frustration among developers, Agile methods became popular. Agile methods were developed by developers, not by management, marketing, nor finance experts.

Most developers I come across, that are working in an Agile development environment are fairly happy with the Process; but there are many serious challenges with Agile. Not all parties are happy with Agile, the popular Agile methods are not necessarily suitable to all situations, many faults with sw development are not fixed with Agile.

In this blog series that will be written in 7 parts, or blogposts, I will highlight 7 major challenges and hint as to what needs to be done to rectify them. Most writings on Agile, talk about its glory, here I will write about the faults: faults that are so serious, that if not rectified will ensure that your favorite Agile method will become last year's fad.

Disclaimer:
I generally like Agile, Scrum and XP a lot. I am a personal friend with Jeff Sutherland, have had a private very enjoyable dinner with Kent Beck and his family, I am a personal friend with Craig Larman, and I know Alistair Cockburn and Mike Cohn. It is with great respect for these, and other Agile people that I write this blog series. They have made huge contributions in the forward movement of the awareness of Agile sw development.

Agile & me:
Having grown up with the grandfather of Agile, Tom Gilb. I have been teaching and literally fighting the established waterfall based methods my whole career. I remember some 16 years ago, teaching and coaching 1 week value delivery cycles to the likes of Ericsson. At the time people thought we were crazy. The Agile community did not exist yet, not even the word Agile. We were more or less alone with the message of short delivery cycles. An article we (I co-authored) wrote for an internal company magazine was censored by the company’s method owners (Tom & I nicknamed them the waterfall mafia). They had no arguments against our Agile message, but they had the power. We were 20 years ahead of our time (Tom even more). As you might see, I’m born into Agile, but there is trouble ahead, the Agile community needs to wake up … (read on)