I find myself in yet another contract with a company that has recently switched to using an Agile methodology. I like Agile. I believe the methodologies that encompass Agile strongly support good software development, help minimize risk, and help to meet the needs of the customer quicker then a traditional waterfall approach.
The problem I am finding is that many companies do not understand Agile enough to utilize it correctly. There is a tendency to take bits and pieces of it, run with them to an extreme, and then get frustrated when they are not achieving results.
"Working software over comprehensive documentation"
The most common mistake I see is in the area of requirements. Managers, business people and sometimes even developers see the Agile Manifesto statement above and take it to mean 'No Requirements Necessary' and sketch out stories and tasks on their 3 x 5 index cards that don't provide enough information to allow for successful development of the software.
An example of this occurred on one of the projects with which I am currently involved. Requirements have been minimal to non-existent and we have been able to muddle through until recently because the types of things we were developing were simple enough that requirements really weren't necessary. (Creating and saving users, addresses, phone number, email addresses, etc.) As the project is progressing and the true business logic is starting to come in to play, writing a story that says "Create a Compliance Front End" simply doesn't cut it. When it was brought up during the iteration planning meeting that perhaps another meeting to actually gather the requirements to know how to create the aforementioned piece was probably necessary, one of the members of the team got visibly irritated and suggested that if we were going to do things by a waterfall approach then we should just give up agile.
Agile projects have requirements. In fact, they have just as many requirements as any other methodology. The difference is that there isn't a focus on documentation. The working software serves as proof that the requirements were met. However when things are complex, not understood or unclear, having meetings and team discussions to make sure all members of the team understand the business needs and goals is just as necessary under Agile as it is under any other approach. In fact, sometimes these meetings will develop documentation, usually informal, that summarize the meeting and makes certain that everyone left the meeting with the same understanding. It is impossible to develop successful software without knowing what you are trying to create!
The rant of the day,