Wednesday, 13 June 2007

Agile Methodologies & Scrum - Sprint Duration

At Cape Clear we practise Agile development and planning - we use Scrum to create a product backlog and have iterative development cycles, continuous build & test etc. While I love the visibility, control and feedback that the process gives us I have found that we needed to tweak it to work for us - This is the first of a sequence of posts which summarise how we have customised Scrum:

1. Iterations can be too short.

The general recommendation is that iterations should be as short as possible - we decided at the outset to try 4 week cycles however we subsequently moved to 6 week cycles. We did this for 2 main reasons:
  • The overhead of Scrum (1 day planning & 1 day review & retrospective) per team was too big. We run 2 separate teams - therefore the overhead on a 4 week iteration would be 3-4 days every 20 - which I think you will agree is not very desirable. Management (especially me!) found that the planning overhead very burdensome and the teams felt that they were only really hitting their stride when they had to stop and re-plan. So we changed it. There are times when the 6 week cycle is quite long - when an analysis task (we call this a SPIKE task) must be completed in one SPRINT in order to facilitate planning for a subsequent sprint. This can cause an undesirable sequential dependency which can be worked around by good ol' fashioned common sense if it causes a problem.
  • Our product stories tend to be quite complex - by this I mean that we are not building a web app in which the delivery framework is well understood and the functions discrete. We are building middleware infrastructure with deep dependency chains which straddle tools, runtime and management infrastructure. In order for each iteration to be "potentially releasable" (Ha Ha) - we wanted to be able to define stories at a product capability level, we did not want our stories to straddle multiple sprints if we could help it.
    We found that 6 weeks encompassed all but the most fiendish stories so we settled on this.
My recommendation therefore is to choose an iteration cycle to suit you and your team - don't be swayed by the purists who insist on bi-weekly iterations at the most - I suspect that this is good for simple or prototype developments - it is not good for product development.