Discuss Agilepublic

Agile Product Management

A place for product managers to learn and share tips on working with agile development teams

This is a public Discussion Area  publicRSS

Question

    Global alignment of sprint durations -...
    Question posted 3/4/08 by David Rodriguez , tagged Challenges, Process guidance
    1786 Views, 3 Comments
    Title:
    Global alignment of sprint durations - organization-wide
    Question:
    We're in the process of rolling our scrum across our organization and are running into a couple issues that are plaguing our progress.

    Today's biggest issue is this:  do all teams in an organization need to adhere to the same sprint duration, or is it ok to have different teams running at different intervals?

    Those of you who adhere to the same durations across your organizations:  why have you taken this approach and did you consider different intervals for different teams, or did you only consider running all teams at the same interval?

    Those of you who have different sprint durations for different teams:  why did you decide to allow your teams to have unique sprint durations, and what challenges have you had to overcome in adopting this approach?

    We have started our teams with two-week sprint intervals to begin with, and have mandate a three-sprint time limit to allowing any changes but have some teams who say they need longer intervals now in order to be successful.

    Any input is greatly appreciated.

    Dave

    Comments

    • posted 3/4/08 by Evan Campbell
      Hi Dave,

      Great question.  We get it all the time from our consulting customers. 
      Do they "need" to adhere to same sprint length?  No
      Is it much much easier to plan and manage work when they do?  Definitely

      While shorter is better, a two week iteration is a great compromise.  Generally four is too long for a variety of reasons (distinct beginning/middle/end feel, large WIP between empirical measures, higher risk w no feedback, etc).  Especially bad if PO isn't accepting stories until iteration end.

      Most teams begging for four week iterations have process and quality issues.  Like most things in lean and agile (eg; Continuous Integration) if something is painful it's a signal that you need to do it more often.  If your teams find iteration planning onerous, or find it hard to decompose stories small enough, or struggle to finish stories in two weeks with the definition of done met, or many of the other symptoms, they will ask for longer iterations in order to avoid that pain that shouldn't be there.  Increasing iteration length will actually exacerbate the problem rather than help and dramatically increase risk of undelivered stories and rework.  Dig deeper into the request (5 whys), treat the causal factor, and the symptoms will disappear while simultaneously improving quality and agility.

      Good luck and hang in there!

      Evan

      Reply to this Comment

      Attach File

    • posted 3/4/08 by Alex
      Most of the large-scale agile adoptions I've seen have faced this question.  In general, most seem to decide that it's easiest to align iterations, and most settle on a 2-week iteration.  Some thoughts:

      - Many agile coaches suggest that if a team is having trouble meeting iteration commitments, they should move to shorter iterations, not longer ones.
      - A short iteration forces the team (and product owner) to work hard on splitting their work into very small pieces of business value.  This is a difficult thing to do, especially for teams that aren't used to it.  Bill Wake's article, 20 Ways to Split Stories, can be a big help if your team is trying to learn this skill.
      - Aligning multiple teams isn't as hard as it seems.  We've had companies do it across business units with 500+ people.  Once you really make the decision to do it, and pick the start date for your first aligned iteration, teams can adapt quickly.
      - Having the whole company work on the same rhythm makes all kinds of planning easier.
      - If you choose a 2-week iteration, the teams that prefer 1-week iterations can easily fit in.

      Out of the 30 teams I've helped move to Agile, only 2 were unable to move to 1 or 2 week iterations.  Both had legacy mainframe applications with horrible architectural problems.  So unless you honestly have crippling architecture problems that put you in the 5th percentile, you can probably adapt to 2-week iterations.

      Reply to this Comment

      Attach File

    • posted 3/18/08 by Ronica
      Evan and Alex give some great comments about sprint length.

      I want to expand a little on the topic of alignment.

      As Evan and Alex mentioned, many organizations find it easier if all the teams are working on the same sprint schedule. That said, I've run across a couple of situations that were slightly different. In one, the teams within the same *program* are aligned, but teams in different programs might be on slightly different schedules. That different schedule isn't really a different sprint length--all are on two-week sprints--but the different programs have different start and end days, to accommodate some specifics regarding launch days.

      I worked with an organization in which several stakeholders had to work closely with several teams, and so having sprint planning days be the same for every team was a challenge. So, again, the sprint length was the same, but they staggered the days.

      Finally, I know of (but haven't worked with) organizations who have just one or two special teams who work on a different schedule. For example, an architecture team might work on month-long sprints while application teams work on 2-week sprints. Or, a legacy-system team might work on 3-week sprints while everyone else is working on 2-week sprints.

      In all these cases, there are very specific reasons for the off-set schedules. Before you accommodate different schedules, consider having the teams investigate the reasons they want longer sprint lengths.

      Reply to this Comment

      Attach File