Geeks With Blogs
Wes Weeks

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,

Posted on Friday, September 9, 2005 12:23 PM | Back to top

Comments on this post: Agile Methodologies Still have requirements.

# re: Agile Methodologies Still have requirements.
Requesting Gravatar...
Well put.
Left by Jeremy on Sep 09, 2005 1:26 PM

# re: Agile Methodologies Still have requirements.
Requesting Gravatar...
So true.

In fact, most companies (even the big ones) fail on process methodology alltogether - regardless of whether it is Agile, CMMI, or any of the half-dozen major systems that have been invented for software and IT projects.

If IT managers and personnel were trained in the basics to begin with, and required to adhere to a uniform standard, there woould be a lot more synergy across groups/teams/products - and a lot more efficiency from the workers at every level.

Imagine a company that could take a technology worker from one dicision and transplant him (as part of an ERP solution) into another division's project -and the person could immediately be productive because they all understand intimately, and are actively using, a standard process methodology based upon an SDLC. 'Natch - that won't happen until SDLC eduction and practicum are adopted at the university and corporate levels, but it is every IT manager's wet dream.

I, too, am now on another contract with a client who, despite being a powerhouse, has zippo in terms of internal processes and standards. I have introduced a very streamlined SDLC and watered down Agile methodology because it was the only thing that I could advocate that would allow me to have a buffer between managers and technical resources/equipment/software.

Nice job on the critique.

Left by Christopher L. Hansen on Sep 09, 2005 1:53 PM

# re: Agile Methodologies Still have requirements.
Requesting Gravatar...
Check out...
For info on documentation and modeling with an Agile approach.

Left by Rajesh Duggal on Mar 16, 2006 7:08 AM

Your comment:
 (will show your gravatar)

Copyright © Wes Weeks | Powered by: