The first article in this series addressed how to fit sprints to business context, with the analogy that people naturally change their routines when they go on vacation, almost without thinking about it. This second installment will talk about intentionally bringing the breaks people take in personal life into software engineering schedules, in a way that makes teams more productive.
In a perfect world, software backlogs would be forever neatly groomed, maintained and prioritized. Features would always be delivered the right way, the first time. Long-term goals would be balanced with short-term goals. There would be no quick hacky fixes, and technical debt would not accumulate. Of course, nobody is perfect. These things don’t happen unless they get prioritized. But what if these things could occur without managers having to explicitly prioritize them? What if they passively became part of the process?
Sprints are a way of wrapping software delivery into predictable units. Sprints exist mostly for the business, not the programmer. There’s no reason why a programmer needs sprints for her own sake, other than to accomplish two things: establish a deadline, and ensure that work is adequately described and scoped into doable chunks no longer than two weeks long. Neither of those goals requires a sprint. So, sprints are a mechanism of control for the business. They help ensure that known chunks of software will be delivered (and evaluated) at short, predictable intervals, which is preferable to working on long and notoriously error-prone estimates and timelines.
If predictability is what the business values, then what does the programmer value? Anecdotally, there’s one job quality that comes up often when talking to experienced programmers, which is autonomy. Autonomy in terms of both what one focuses their efforts on, as well as how they manage their time. The business’ control mechanisms, then, are at odds with the desires of programmers. Considering that another top and growing concern of programmers is burnout, there has to be a compromise. Promoting autonomy and preventing burnout are key to maintaining employees’ happiness, sanity and ulitmately, productivity.
Consider balancing business and programmer needs by building a small gap of a day or two in-between sprints. If a sprint is typically ten working days, then a gap-enhanced sprint would be eight or nine days. A gap-enhanced sprint might start on a Monday and end Wednesday of the following week. That additional day or two (e.g. the final Thursday and Friday) can be designated for a number of rejuvenating and forward-looking activites:
- Reflecting on sprint demos, incorporating feedback into the sprint backlog
- Reflecting on retrospective next-steps, and incorporating them into team context and process
- Reporting out and up on accomplishments to stakeholders, beyond what occurs in Demos
- Long-term planning
- Personal or small-group projects for learning and R&D
- Training and professional development
- Workshops
- Writing blog posts or prepping conference talks to get the word out on the company’s work
- Paying down technical debt or doing work that scratches an itch
- Running a hackathon
- Team building
- Writing up personal accomplishments
- Team “Fixit” days
So many things are essential to keeping employees growing and happy, while also tending to the longer-term needs of the product and the business. Taking technical debt as an example, sprint gaps can keep this commonly deprioritized but highly important work from falling through the cracks. It’s generally hard to get technical debt on the backlog in the first place, and to convince stakeholders that technical debt tickets should be prioritized into a sprint. If this “unplanned work” is left to be done side-of-desk, it can bring unpredictability to sprints, because programmers will work on it whenever they can, sometimes to the detriment of the sprint. On the other hand, things will run more smoothly if the time between sprints is explicitly blessed to take care of all the seams and loose threads by which the business could unravel.
The mostly likely business objection to sprint gaps is that less work will fit in a slightly shorter sprint. There may be some truth to this, but given less time in a sprint, many teams will simply waste less time during a sprint. The adage known as Parkinson’s Law, tells us that “work expands so as to fill the time available for its completion.” In addition, given the extra time for employees to decompress (see especially the 2007 article from Google linked above), the difference in planned output is likely to be negligible. Also, the additional investment in technical debt, documentation, etc., is more likely than not to improve team velocity during sprints, which will be a net benefit to the business in the long run.
Despite all the possibilities listed above, some more structured, some less, engineering managers should be sure not to over-schedule the sprint gaps. If the goal is to balance control with autonomy, one should make the assumption that developers will focus on the right things to work on in their sprint gaps. For instance, on a team that I managed a few years ago, our developers had to split time across multiple projects, so they used their sprint gaps to perform self-directed maintenance and bug fixes on the projects that weren’t currently prioritized in a sprint. The developers chose their own gap priorities, and it made them happy, and it kept the clients happy, too.
Sprints are not the be-all and end-all. They are a way of time-boxing prioritized work. Give work a “weekend” gap to ensure the health of employees, products and culture. Your business will be better for it.
