Friday, April 7, 2006

Agility...

The key practices of agile software development, known and followed are:
1. Face-to-face communication over documentation
2. Quick feedback from end users over project phases (as in waterfall)

Collective ownership, Pair Programming, use of whiteboard, paper, and most importantly the terrific visual representation of the project health and progress... the wall

For an agile team the wall is everything. The action of moving stories & bugs along the columns and the instant snapshot of the project health is fantastic. Here's how it works...

The process :
  1. The Business Analyst analyzes the requirement and writes a story and acceptance criteria
  2. The developers estimate a bunch of such stories in a planning game
  3. The developers (in pairs) then sign-up for a story each morning
  4. When the development is done, the story is tested for desired functionality by the analyst
  5. After the analyst has signed the story off, the tester picks it up
  6. The testers and devs play ping-pong for a while with the issues (bugs) raised by the former
  7. When the tester signs off the story, it's ready for the client to have a look at.
This procedure takes ideally about 3 days per story. The client can then look at the story and sign it off or (ask for some changes) !!!

The documentation per say in this complete procedure is an index card for writing the story, some more for the acceptance criteria and a few more for the bugs.

  • The client and the analyst discuss the requirements face to face probably using some paper to make rough screen sketches sometimes.
  • The analyst talks to the dev pair that signed for the card and describes the functionality.
  • The devs use whiteboards & pair rotation for design discussions, issues and knowledge sharing
  • The devs keep bugging the analyst all the time for clarifications
  • The tester talks to the devs about issues and only writes a bug on a card if it can't be resolved then and there.
For anyone roaming around, the color coded, columned wall with the stories and bugs gives a clear picture of the iteration health. And a team can easily setup the wall to show the project health coz it's the team that decides the color codes, the statuses (columns), etc on the wall.

It's the team that decides when to start the day, what coding conventions to follow, the core hours of work and it all works out so smoothly because the client is part of the team!!

Now how much better can it get?

1 comment: