Sunday, March 06, 2005

SAD - Solitary Agile Develop(er|ment)

Part 3

Gather » Iterate » Repeat

This third installation looks at a strategy for gathering and managing the requirements of a project using SAD. If you read the back of any shampoo bottle, you'll see the instructions "Lather, Rinse, Repeat." In case you hadn't already figured it out, that is an effective way to wash your hair. In SAD, I propose a similar strategy, "Gather, Iterate, Repeat" to effectively analyze and implement the requirements of a complex system with vague or unclear requirements.


Gather
With constant feedback from he stakeholders and users, the developer can begin to formalize use cases or user stories. Doing so yields many benefits. First, the stakeholder can help to prioritize the features so the developer knows what they need most. Second, it forces the developer to focus on and contemplate the behavior of the system. Thirdly, the developer is human, and as such can forget or confuse the details. A written record gives the developer a written reference of the requirements for the system.


Iterate
Any agile software development methodology will strongly emphasize the notion of short iterations or cycles of analyzing, designing, implementing and testing your code. XP (The Bob Martin flavor) for example suggests 1 week iterations whereas Scrum and others might suggest 2 to 4 week iterations. In SAD, the actual duration of the iteration is left up to the developer. The only stipulation is that the iteration should be kept short.

Other than that, the iterations consist of analysis, design, testing, implementation, communication (with stakeholders and users) and releases. All of these except Releases are all done at the same time. Analysis is continuously integrated during design. Design is continuously modified during implementation. Implementation is analyzed and refactored after testing. Communication is done throughout to maintain the open nature of Agile development. The last part of the iteration is the release. Which may be as simple as a demo to a client, not necessarily a full production release.

Short iterations allow the lone developer to effectively manage releases, and the more releases the more feedback the developer will get from the stakeholders and users. These iterations can vary, there's no reason to spend one month on an iteration you feel only requires 1 week. Likewise, if an iteration is more complex it may require a full month to complete. However, iterations of more than 5 weeks start to become dangerous and more difficult to manage.
Repeat
Consider the following code:

...
LoneCoder geek = new LoneCoder();
while(1)
{
geek.GatherRequirements();
geek.Iterate();
}
...


Again, open and free communication with stakeholders and users is critical in this entire process. Often times, the customer doesn't really know what they want until they see a working prototype. So I encourage you to show them demos as much as possible, have them look over your user stories or use cases and ask them to rank them on a scale of 1 to 10. Put up a suggestion page on your website, where users can submit their feedback and request new features. After all, they are the ones who will use your software, and they have the most to gain from the features you implement.

3 Comments:

At March 12, 2005 2:13 PM, Anonymous Anonymous said...

All of the XP reading that I've done also points to 2-4 week iterations. Where did you read about XP and 1 week iterations? Anyway, interesting stuff. I was on my own the first 16 months of my company's life...a fun time but wish I had known about agile methods back then.

 
At March 12, 2005 2:13 PM, Anonymous Anonymous said...

All of the XP reading that I've done also points to 2-4 week iterations. Where did you read about XP and 1 week iterations? Anyway, interesting stuff. I was on my own the first 16 months of my company's life...a fun time but wish I had known about agile methods back then.

 
At March 20, 2005 10:46 AM, Blogger Ben said...

Joe,

The 1 week iteration I actually heard about from Bob Martin. If you ever have a chance to see one of his presentations, I highly recommend it, he is an excellent speaker. You are correct though, many books on XP favor a 2 - 4 week iteration. However, Kent Beck and Martin Fowler in their book "Planning Extreme Programming" leave it up to you to decide the actual iteration length.

To quote them from their book:

"Don't get too hung up about choosing the right iteration length. The world isn't going to end if you pick three-week iterations instead of two-week iterations. As long as you are prepared to be aware of the effects of iteration length, and prepared to experiment when you spot a problem, you can start most anywhere. So start with two-week iterations."

I would have to agree that the same applies in Solitary Agile development. The key is to pick the right lenght that works for you (and stick to it as much as possible).

 

Post a Comment

<< Home