Structure Work to Avoid Burnout

The Agile purist view is that sprints should all be the same length (known as “common cadence”). If a team tolerates common cadence well, there’s no reason to change it. Common cadence makes calculation of velocity and other aspects of sprint planning more straightforward.

However, a common complaint about Scrum implementations is that an endless succession of sprints leads to sprint fatigue or a feeling of being on the sprint hamster wheel. With Sequential development, there are natural troughs of work, particularly between disciplines, that balance the high-intensity periods. Continuous sprints leave no troughs for rest if every sprint is truly sprinting.

One antidote to sprint fatigue is to vary the lengths of the sprints occasionally. A systematic way to do this is to use a pattern of 6x2x1—6 sprints of 2 weeks plus 1 sprint of 1 week, a total of 13 weeks, which can be performed once per quarter. Alternatively, shorter sprints can be worked in after major releases, around holidays, or at other times when the team’s velocity probably wouldn’t be stable anyway. During the 1-week sprints, the team can work on infrastructure or tools, attend training or team-building events, have hack days, work on technical debt, concentrate on improvements that are too large to be worked into a regular sprint, or other similar work.

Varying sprint cadence supports the Agile notion of “sustainable pace.” Much of the Agile writing today interprets sustainable pace as “no evenings or weekends, ever.” I think this is simplistic and ignores differences in individuals’ work preferences. A steady 40 hours per week amounts to a sustainable pace for some people, but for others that amounts to a recipe for boredom. I personally have done much of my best work in burst mode—55 hours for a couple weeks, and then 30 hours for a couple weeks after that. The average might work out to about 40 hours per week, but individual weeks aren’t very close to 40 hours. The details that make up “sustainable pace” are not the same for everyone.

Other considerations

Non-project software development work

Not all software development work occurs in projects, even considering the many definitions described at the beginning of the chapter. Ad hoc, single-person software work is common in handling support tickets, production issues, patches, and so on.

This kind of work certainly qualifies as software development work, and it is also amenable to Agile practices. It can be made more efficient, higher quality, and more methodical through adoption of Agile practices such as Lean and Kanban. However, in my experience, organizations tend to struggle with this kind of work much less than they struggle with project-size software development work, so this course focuses on projects rather than ad hoc work streams.