In the last installments, I offered an alternative to Scrum backlogs and what it might look like. Today, you'll learn a better approach to iterative development than the infamous "Sprints."
What is a Sprint, anyway?
The official guide describes it rather briefly and in very vague terms.
In essence, it is a fixed period of arbitrary length, usually two weeks, that contains features and bug fixes that the team has decided to work on - with the blessing of the stakeholders.
Its goals are:
- ship software quickly - every two weeks, something new can potentially be released to customers,
- make a change to the scope possible - the stakeholders can change their minds every two weeks about what's important,
- protect the developers from outside interference - whatever the team works on during a sprint is that the team works on, with exceptions.
The underlying assumption is that the project's scope cannot be determined with sufficient accuracy up-front.
The problem with Sprints
Besides the terrible metaphor to start with?
That's the least of it, but unless there are fires to put down, I wouldn't want anyone on my team run around like crazy! That rarely helps.
When organizations deploy the Scrum process, they often spend little time customizing it to fit their:
- company culture,
- product development process,
- agility level (a Fortune 500 company moves at a different speed than a scrappy start-up)
Instead, they go with the defaults.
The default is two weeks, so two-week cycles it is.
The problem? Two weeks is seldom enough to produce anything that really moves the needle.
Remember that Scrum teams use backlogs, one-dimensional bucket lists of things to do. The problem starts there, as I argued last time. It only gets worse.
The team uses a vague estimation technique using arbitrary "points" (often directly translatable to person-hours in less enlightened environments), decides what they can fit into the two weeks, and off they go. Or, run.
Depending on how much they get punished for not delivering everything they promised to do at the end of the Sprint, they may eventually be very conservative in what they commit to next time.
Even in the best case, the incremental value-add of each Sprint is most often negligible. More complex features usually take two or more Sprints. That means arbitrarily breaking down the specification of a feature into bits that can be manufactured in 2 weeks or less.
I think the problem is becoming obvious by now.
What to do instead
The following is conditional on not using backlogs but rather living documents that have the important decisions fleshed out so that the team is left with only tactical decisions as they implement a feature.
We have established that two weeks is usually not enough to deliver meaningful work product. What is the optimal length, then?
I think 6-8 weeks should do depending on the team's maturity . The Shape-Up process by Basecamp advocates for 6 weeks. That sounds about right to me.
Smaller projects might require less than that, of course.
The benefits of a 6-8 cycle as opposed to a 2-week Sprint are an inverse of the problems of Sprints I outlined above:
- The team delivers something meaningful and visible at the end of the iteration.
- Since the strategic decisions are laid out before the work begins, the team has plenty of creative freedom to implement the strategy.
- There's no artificial rush; the team members can work at their best. At the same time, it's not 6 months, so there is not much room for slacking.
This should work equally well for product teams and client work. The distinction is barely important here except for negotiating the process with the client in the initial stage of the project.
Is it possible to do 6-week iterations and still use Scrum? In principle, why not?
However, I see no benefit of Scrum ceremonies for a mature team that can deliver impactful work on its own, given 6 weeks and a clear vision.
We'll speak about these next time.
photo credit: Annie Spratt