Are we solving the real problem?

Saturday, October 14, 2006

Iteration Planning

Another agile experience....


At "Company X" each project has:

- 1 PM (manages resourcing and release plan, but very hands-off, may be managing many projects)
- 1 BA (the customer)
- 1 Tech Analyst (reports to Technology but liaises very closely with the BA, is the conduit to the BA)
- 1 Lead Developer (manages the iteration)
- n Developers (liaise closely with Tech Analyst)
- 4 QA (report to the business)
- n TechOps (for deployment)
- n DevSupport (for fixing bugs after deployment)
- 1 Architect (adhoc basis - most developers are very senior so no strong requirement for a dedicated Architect)

No fancy software to manage the agile process. At most the PM uses Excel to manage resources.

There is very little emphasis on Velocity here. Rather, more focus on the release plan. Most projects have 2 wks bug fix. A developer must only work on 1 story at a time.

The amount of emphasis on TDD here is amazing...huge! And that shows. Company X has excellent systems in place to manage customers and to register customers. If the systems were rubbish then Company X would not be 3rd in the market. Actually one of the main reasons Company Y have purchased Company X is because they want to draw on the quality of systems and processes inside Company X.

Prior to iterations starting, a Planning Game is held where estimates are taken on stories (from the group). The stories then feed into the iteration. The regularity of this is usually up to the discresion of the TA. The Release Plan is always kept in mind, any movement outside the Release Plan is treated as a CR. The BA sits in to clarify the stories; the TA leads the Planning Game. The PM is not present. Stories are documented by the TA prior to the Game and are a word doc of 1-2 pgs. The Story card is written up by the lead developer and the estimate is written on the card, the card is pinned up on the radiator board.

Showcases are performed weekly by the lead developer and one other senior developer. This provides good feedback, both ways. CRs are created by this process.

Pairing is done here. We have 6 pairing stations. We swap about every 2 days.\n

Risk cards are also a big thing here and are pinned up on the radiator board.

They also do Retrospectives after the completion of each project. What have we done badly, done well, how can we improve?

Good article here.



Digg!

No comments: