2 week sprints are boring.
Been there, done that. So many
teams starting out an agile project, especially in a team new to agile, select
the default 2 week sprints without really knowing why. Not that I’m against 2 week sprints, but the
biggest part of selecting a sprint time box is knowing why you are selecting
that, e.g. What is the value? (BTW, I
try at all costs to avoid 3, 4, 6 week sprints)
One of the big advantages of the practice of time boxing
feature work (sprints) is to have a clear end point that is not very far out,
so that we can see the finish line often (small batch sizes), and when we reach
it determine if we are still going the right direction (inspect and
adapt). Determining what this end point
should look like and how often we should inspect/adapt is a difficult skill to
obtain. We as humans are really, really
bad at predicting the future, and the farther out we go the worse we get at
it. Especially for a team new to this
practice.
My MO when coaching new agile teams is to encourage the team
to start with one week sprints. There is
often a lot of concern and push back from this, with the usual arguments “we
can’t get anything done in a week” or “it takes too long to deploy to do it
once a week”. The answer to those
concerns is that if you can’t do this in one week you won’t be any better at in
two weeks. These objections are always symptoms
of underlying problems, such as the deployment capability is not utilizing
continuous delivery practices. Getting a
team to work in smaller time boxes will force them to learn to work in smaller
increments, which is a core skill they need to obtain. Learning how to break up a story into the
smallest business value they can will strengthen the team’s ability to deploy
business value more often, striving towards a daily (or more frequent) change
to production.
In doing initial training I have sometimes put teams in a
one day sprint pattern. Start the day
out with deciding what we need to accomplish by COB that day, and set about
doing it. It becomes glaringly obvious
where the issues are in the code base, deployment, and product
vision/understanding as the team struggles to break down the features into something
tangible and deployable in one day.
Sticking with this results in, at a minimum, a team that understands how
granular we want to work, and usually provides a pretty good list of spikes to
resolve to improve the deployment process.
My motto has long been: if you can’t succeed with one week
sprints, you will be terrible at two week sprints. The problem is, the larger the time box the
more the weaknesses in the team and the process will be masked. Agile is very much about constantly
inspecting what we have done and adapting for what we still need to do. The larger the time box the less agile we
become. Try to succeed with one week (or
smaller!) sprints before moving on.
And, as always, if you want to change this practice make sure you understand what problem you are trying
to solve by making the change.