It’s one thing to read about agile in books. It’s another to see it working in practice. And it’s impressive!
I had the opportunity to take part in meetings with a team that applies agile methods: they’ve been doing this for years and their process is very mature. I was impressed with the discipline. The methods the team uses are agile in spirit and re-use some elements from scrum, extreme programming and lean.
They hold at least three types of meetings:
- stand-up (daily):
- quick status update by each pair
- decide the new pairs for the day
- quickly go over yesterday’s annoyances (written on a board)
- planning (every iteration): give a time estimate to each piece of work in the next iteration.
- retrospective (every two iterations): list what went well, what didn’t and what needs to change.
Six programmers work in pairs and interact with two business analysts. The pairs change every day.
The business analysts identify early little chunks of functionality called stories. Stories are small enough to be designed/coded/tested in less than two days and still provide business value. The BAs prepare a list of the stories that will make it into the next iteration. After discussion with the developers they assign a rough weight to each story. A story is weighted in relation to a “standard” story, which takes about 1.5 day for a pair to complete. A story with weight 1/3 takes a third of the time of a standard story. Later the devs will give a more precise estimate to the story during the planning meeting.
The most striking aspect of the approach is that the BAs write and complete the FIT tests before each iteration. That means even before the dev pair starts coding a story, there is already a FIT test for that story. Obviously at this stage the test fails because the solution does not yet exist. Then the job of the devs is to get the FIT tests to pass by actually coding the functionality (writing the unit-tests first and using TDD’s Fail>Pass>Refactor cycle). If the devs feel a need to change something to the FIT test itself, they discuss it with the BAs.
The dev pairs change every day and the new pairs are decided during the stand-up.
More about the planning meeting: before each new iteration the team meets to discuss the stories going into the next iteration. They sit around a table and go through the stack of stories one by one. It’s literally a stack of cards with a brief description of the story on it. Because the stories are very lightweight both in terms of functionality and coding complexity, you can get away with a very short description on the card. A few lines of handwritten text are enough to express what the story is about. No heavy specs documents: fine level story granularity + lots of team communication replace the need for detailed specs. The FIT tests and unit-tests capture the detailed specifications.
The process they use is self-evolving: once a month they hold a formal meeting called a retrospective. They discuss what went well, what didn’t and then fine-tune their methods.
The structure of the retrospective is straightforward: they write three lists of items on a board:
- GOOD
- BAD
- TODO
They also bring the board with last month’s TODOs to tick off those that were actually done and carry over the rest. Everyone sits around a table with tea, coffee and biscuits. Not surprisingly that meeting can get quite animated, especially given that those guys are not exactly the shy type. You can tell they’re used to doing that by the way they structure the discussions: list the items first on the board, close the list and then discuss the items one by one rather than dwell on the first items and run out of time.
