Agile Development

I’ve recently been exposed to Agile Software Development. For years, I worked in a consulting practice where we were asked by clients to “estimate” how much time and money it would take to build “this application.”

Unfortunately, this is an impossible task. First, we never had a well-organized repository of past experiences that we could draw from to help us. Second, you just can’t know everything there is to know in software development up front. Things will change during the process of building the application. So, we would magically pull some numbers out of the air, pad them and then present a range to the client. Of course, we would tell them that a “Discovery Phase” would occur, after which we would have a more precise estimate.

Even if you conducted a thorough Discovery Phase, interviewed all the stake holders and all the users, you still will most likely not have all the information needed. There will always be things that weren’t thought of or things that become more or less of a priority.

So, in the end what happens is the project gets built, it may or may not meet all the needs of the client, and it most likely cost more than what was estimated at the outset.

The Agile process is designed to allow for this. It is based on the principal that it values:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I’m very new to this process, but here is a high-level overview as I understand it:

The decision is made to proceed with a software project. Of course, a lot goes into that decision, but we’ll assume that the company needs this project done.

So the first question is, what does the project do, and how difficult is it to build?

To define what the project does, User Stories are created. A user story is a description of what the software needs to do from a user’s perspective. There is not talk of specific technology here, just a description of what happens (similar to a use case). The user stories are defined by having as many users or stakeholders as possible meet to discuss the purpose and functionality of the software. Each user story is recorded on a note card.

Once the user stories are defined, a forecasting session is held to determine the effort required to build the software. At least two developers should attend the forecasting session. Each user story is reviewed, and the developers each assign a point value to the user story.

This point value (called a story point) is equal to one ideal engineering day. The more complex the user story the higher the point value (or, the more days it would take to build).

If the developers disagree on the point value, it is discussed until a consensus is made. The great thing about this forecasting session is that everybody is involved in forecasting the project. It is just someone pulling numbers out of the air; the users and stakeholders are all in the room and they are learning about the amount of effort required to build the software.

Once all the user stories are assigned a point value (and if a user story has a high point value, it is broken up into several smaller user stories), they are then assigned a priority.

Based on the prioritization of the user stories, work can begin. The project is broken up into iterations. Iterations are typically 1 or 2 week periods of time where a release is made. This allows the users or clients the ability to see what is being built, and to test it.

At the end of each iteration is a review of what has been accomplished, and a determination of what user stories will be attacked in the next iteration.

Just like forecasting the weather, it cannot be determined what will happen too far in the future. For this reason, the entire project is never “estimated.” We have an idea of how much time each user story might take, but as the project progresses, we may learn things that change that. Just like the weatherman changing a weekend forecast as the week progresses, the project manager is adjusting forecasts as the project progresses.

Of course, for this to work, a great deal of communication is required between the development staff, the project manager and the customers. But since, the project is being released in iterations that require acceptance testing before they are “complete,” the communication is inherent in the process.

There are several other advantages to using this process. Instead of taking hours and hours creating a large spec document that nobody will read, we are creating easy to read note card user stories. These are quickly created and everybody has feedback in their creation. Developers can spend their time writing code, and not writing documentation. The code should be well written in a way that describes itself. A large document that nobody will read is not necessary.

Over the next several months, I will be on a development team using this methodology. At first blush, it seems like a simple, logical methodology that allows everybody involved to be fully aware of what is being built and the effort required to build it.

Here are some books if you’re interested:
“User Stories Applied” by Mike Cohn
www.mountaingoatsoftware.com

“Lean Software Development” by Mary Poppendieck
http://www.poppendieck.com/