As mentioned previously, the Agile methodology is an iterative development process that is designed (in theory) to allow engineers to more accurately estimate their work and respond to unexpected changes.
Seventeen people went on a skiing trip and, by the end, decided they had figured out the proper way to develop software.
(This is not a joke)
At the end of their trip, they published The Agile Manifesto, explaining how to properly develop software.
For some reason, it became a buzzword in the industry and everyone had to “do Agile.”
(Though, more often than not, they aren’t actually “doing Agile”)
Be skeptical of anyone peddling manifestos.
crickets chirp in the background
It is difficult to gather requirements, because
In order to reduce the impact of our inability to gather accurate requirements, we will attempt to add continuous feedback to our development process.
We should start obtaining feedback as soon as possible.
In the Agile world, this means as soon as we have a minimum working product.
In order to ensure our ability to get continuous feedback, we must be able to deliver working releases of our product to the client.
To accomplish this, we will divide our work into small, “complete” subsets of functionality called “sprints.”
Sprints should be very limited in scope and should always result in working, buildable, and releasable code.
Ideally, your project should build without failure from the beginning and every single commit should do the same.
By limiting the scope of a sprint and by ensuring that our project always builds, we can more easily provide clients with regular, functioning builds to review and to use for providing feedback.
How do we create these sprints, though?
First, we want to gather general ideas about what the product should do.
Next, we should discuss what we think we understand about the project with the client. We should:
To help ensure that we don’t miss anything, we may want to brainstorm with the customer. No ideas should be off limits. The goal is to obtain the absolute ideal requirements assuming no limits.
Once we have gathered enough informtion from the client, we will create high level user stories to capture the requirements. These should be:
Once we have all of our user stories, we will estimate the level of effort required to implement each, then prioritize them (with the customer).
Then we simply select user stories from this list to fill the time period of our sprint (often a couple of weeks).
How, though, do we estimate the level of effort for our user stories?
We use planning poker.
All team members sit around a table with “poker cards.”
Each card has a time estimate written on it.
The team discusses a user story and everyone “plays” the amount of time they estimate the story will take.
If there is no consensus, then the team discusses their estimates and they play another round.
This is continued until a consensus is reached (or until everyone gets tired of arguing with the guy who refuses to change his mind).
Then, magically, the consensus opinion is an accurate estimate.
(This is not a joke)
Why might this not work?
When might it work?
It appears that many reports about the benefits of Agile development fall into one of two categories:
For everyone else, the studies that exist don’t seem to support the hype.