Objections to Agile development – level 300

Whether you love or hate Agile development methodologies, you need to read a whitepaper by Jim Highsmith entitled “Objections to Agile Development”.

Jim addresses objections that stakeholders make to Agile development. The categories are:

Buyer reality

Bad or no design

Doesn’t work with our business partners

No documentation

For each of the objections above, Jim does a fine job of explaining why these objections are unfounded. I’ll address the “no documentation” bullet from my own experience, but please read the whitepaper as well. I’ve battled many objections to Agile at a previous job.

If you’ve ever created design documentation (UML diagram, etc), you know that it is out of date as soon as it’s printed. Developers make design decisions throughout the coding process (Coding is design, and Jack Reeves take). It takes a lot of time to keep a design document current, and it just never happens. Design documents get created; they are shown to management; they look pretty, and they are plain wrong. They never describe the actual structure of the system. A manager may like them, but they are looking at a picture, not the actual system. The actual system ends up structured in a different way, but the manager doesn’t know. The manager isn’t reading the code. The manager goes on in ignorant bliss with a picture of something that doesn’t exist. Arguements can be made about how the process is “supposed” to work, but there’s also reality.

The time for documentation is when the project is finished, and it’s time for it to be mothballed. This is when documentation should be created for maintainers who may come later. The system has stopped changing and is actually in a state where it can be documented. This is maintenance documentation.

Throughout the project, the code and tests should be the documentation for the code. This is the only thing that is guaranteed to remain current. Developers should be able to look at the structure of the system in the IDE and understand it. The whole solution layout also has documentation qualities.

I’d be interested in finding out if anyone has created a design document before the system was created where the document actually stayed current and meaningful.

JH 3:38 am on July 27, 2005

I think that there are at least two significant difficulties with agile that causes it to fail in many cases.

1. It comes off, when described in “boot camps” delivered to early-adopting larger businesses, as a “developer methodology”. It is often being presented to management who are generally non-developers. Developers tend to be easily sold on this methodology as they are generally looking for something to address the issues of poor project management in their traditional methodology. Though it is often confused that documentation and other artifacts is not a requirement of agile, the delivery of those artifacts is most definitely something that can be done within this delivery model when desired by the customer.

2. Because it is in relative infancy, those that are attempting to manage the project (PM’s or “Iteration Managers”) are often very weak in addressing concerns about the methodology brought up by customers. This weakness tends to lend itself to customers distrusting what they decided they would go for during the boot camp introduction. It then becomes very easy to lapse back into the ol’ stand-by methodologies that the company has been used to in the past. Sometimes it is even the case that the poor project managers from other methodologies are now giving agile a try and proving that they are equally poor at delivering software under the agile methodology.

My experience has shown me that poor project management (by whom ever is running to project), regardless of the delivery model, has been the major contributor to project downfall. In the end, customers of custom software projects need to understand that the product being developed _is_ the livelyhood of their business and that they didn’t develop their method of delivering goods or services to the public between May and October of one calendar year.

The value of the project (from both developers and customers) comes when customers acknowledge that those developing the product for them are respecting the complexities and unique nature of their business and are as unwilling to sacrifice quality, just as the customer does in their business. This seems to be the point that project managers need to be able to deliver to customers, regardless of the delivery methodology, and have been failing to sucessfully do so for years. If this problem can be solved, any methodology would be seen as successful by customers and more projects would be successful as any artifacts or deliverables can be worked in to any methodology.
Jeffrey Palermo 3:34 pm on July 27, 2005

That’s a very good point. You must have a capable project manager as well.

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Objections to Agile development – level 300

Related