Thursday 10 May 2012

Sprint Length - the beating heart of the Agile process

I had a conversation yesterday about the length of sprints as there were a range of opinions in the room.  In my world, the two week sprint is ideal  (as opposed to the "Scrum" norm of four weeks) for five main reasons:
  • Its an appropriate amount of time for teams to be focussed internally on what they have been set to achieve.
  • From a higher managment perspective seeing progress every couple of weeks is nice, whereas something longer (like monthy) seems a bit too "admin" (akin to attending monthly sales report meetings) and a bit waterfall.
  • If all goes wrong and a sprint is wasted, managment can "swallow" losing two weeks of time, but longer is less aceptable "what do you mean we lost a month - this is supposed to be Agile?"
  • It gives an opportunity to review the supporting Agile processes (CI, TDD etc) regularly so that they can be tuned or re-engineered if there are problems, also there is more retrospective review as a whole.
  • Shorter sprints mean less work-in-progress at any one time so you have potentially less integration problems and less risk of regression test failure if CI processes are not mature.
Some organisations are pushing the bouandaries a bit and going for one week sprints.  In my mind if the organisation is "Agile-mature" so both the automated processes and the manual ones such as sprint planning can be slick and quick, then its perfectly do-able, but if many companies tried this I think they would find they are doing at least one full day of sprit prep and retrospective for every iteration, therefore losing at least 20% of the available coding time to the process.

The final point I would make on spint lengths is that whatever you do choose, don't change it for the sake of it.  There is little point playing a two week sprint, followed by a three week sprint, followed by a two and then a one as all it does is "upset" the rest of the organisation. "Is it sprint planning/show and tell this week?" - "no-idea, what was last week?".

So much that is external to the scrum teams needs to interact with the Agile process (Product owners, stakeholders, IT support, BAU, release managers etc) that they need the calendar to be constant so they can plan their workload.  A whole organisation adopting Agile should have the sprint length as the constant heartbeat in the middle of it that everyone can "hear" in the background.

No comments:

Post a Comment