Monday, 23 February 2015

One week sprints could work for you - but probably won't.

I've been working using the Scrum methodology of agile, or some derivative of it, for many years now.  Over that period years I've worked at several different places who have all had a particular sprint length already established when I joined the team.

The one I enjoyed the most was the one-week sprint.  When you say this to people they usually balk, but the context for the one week sprint was just right.  Our product was single platform and we only interacted with people outside of the engineering team once a week in order to demo and plan for the following week.   The same day we would have our team retrospective and because it was Friday we'd either go to the pub or go home early.  Four solid days of development and one day off for admin type stuff, it worked really well and we were incredibly productive.

But the one week sprint can only work well if you have the right conditions:

  • The team can work in relative isolation with the scrum master as a conduit, getting answers to questions quickly.
  • The team feel empowered to make executive decisions.
  • Your team is single platform with little or no external dependencies.
  • Sprint starts on the Monday and finishes on the Friday.  
For me the one week sprint falls over pretty quickly when:
  • Your team is multi-platform.  For instance, developing mobile and server functionality concurrently.  The additional collaboration required means none of the devs can knuckle down and get work done.
  • Inter-team dependencies.  The more people you know, the more likely you are to get random interruptions, which break train of thought.
  • Your team is not co-located. If you have anyone that contributes to the sprint in different locations, then your ability to collaborate is severely hampered.  You'll use Skype, email, conference calls or some other tool and will then likely be asked why you're having so many meetings and using email to communicate.
  • Your scrum master is unable to to shield the team from distractions (for whatever reason).
  • You can't end your sprints on a Friday.  Stopping and starting during the middle of the week is counter productive for a couple of reasons.  Firstly, the Monday and Friday are natural delimiters for working.  If you have unfinished work on a Friday, devs will naturally ponder it, or at least feel a foreboding about it, over the weekend.  As a result they are not winding down and will burn out.  Secondly, having has the weekend to completely switch context Monday will naturally end up being a day of getting back up to speed.  Anecdotally, devs are most productive on Tuesdays and Wednesdays, maybe Thursdays.
  • Any of the above combined with an open plan office.  Open plan office is basically a forum for open discussion, people shouting across desks, people wandering around making noise and generally being distracting.  Give your devs a quiet area to work.  Joel Spolksy highlighted this about 15 years ago.  If you wonder why you see your devs working with headphones on "when they should be collaborating" this is why.

So I've been trying to work out how to determine the best sprint length, but there really isn't a formula.  That said, it is easy for me to say that unless your conditions are perfect, as described above, one week sprints aren't going to work for you. Personally, I would like 4 days of solid, relatively uninterrupted time to make quality progress. In this case, start with two week sprints.  This gives your devs time to work, but also builds in contingency for collaboration. Use retrospectives to let the team express their desire for shorter or longer sprints and listen to them.  Work around your engineers rather than forcing them to work around other parts of the team that are not actually producing something.

No comments: