It’s been more than 20 years since the Agile Manifesto was published. In the intervening years, the world of software development has changed significantly. Plenty of digital ink has been overflow:visibled arguing the merits and demerits of the various agile methodologies.
I’m not here to tell you whether to practice agile in your software development team. But if you do, I hope this series will give you some new ways to think about how you approach it, no matter your methodology of choice. The first two parts will cover specific practices you can employ, while the third and fourth will be about a practice you should try to quit.
In Part 1, I’ll discuss the concept of a “deload.” This is a common concept in weightlifting. When you deload, you take a scheduled reduction in your training load. This gives your body the additional rest needed to recover and avoid injury, fatigue, or strength plateaus. You don’t stop exercising entirely. You just take a step back from trying to reach your limits.
Sustained intense exercise also puts a heavy strain on the central nervous system and can be mentally fatiguing. So, a deload also gives your mind and nerves a chance to reset. I think it’s time we brought this concept into our software development practices.
There is no such thing as a deload in agile.
In software development, dominated by different agile methodologies, no such concept of a deload exists. In fact, two of the foundational principles from the Agile Manifesto are:
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
and
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Essentially, these suggest that your team never pause to recover while continually increasing your output. (It’s also possible to interpret these two principles as “keep output constant while continually reducing hours worked,” but we all know in practice that’s never going to fly with the client or management.)
Kanban sets maximum limits on Work In Progress, but it’s not ideal to work significantly less than the maximum.
In Scrum, teams measure velocity and use that to plan future sprints. It’s expected that the next sprint should achieve an equal or greater velocity than the sprints prior (or at least their average).
In Lean, basically anything that results in a delay in the software development process is considered wasteful and to be avoided. Etc.
When should you deload with agile?
For weight training, a typical cycle is three weeks of progressive lifting, followed by one week of reduced lifting (a deload). Some programs will go six to eight weeks before taking a deload week. There’s no right answer, and it depends a lot on the individual. However, it’s reasonable to spend anywhere from 10-25% of your training regimen in a deload cycle.
In Scrum, XP, and other methodologies, you’d use a defined iterative cycle such as a sprint. In that case, you can simply insert a “deload” week in between two cycles at whatever cadence your team feels is right. For example, if you’re running two-week sprints, you might include a deload week after every three sprints, so that the total cycle repeats every 7 weeks.
For Kanban or other methodologies that rely more on continuous delivery without defined cycles, simply add a deload week at any appropriate interval. You could even set your deload to a different length of time than a week. Perhaps you have a deload Wednesday through Friday at the end of every third week.
How do you deload with agile?
There are different ways to deload your weight training. You can keep the amount of weight you lift the same, but reduce the repetitions. Or you can keep repetitions the same but reduce the weight. Or you can change entirely the set of exercises you’re doing. Using a mix of these across several deload cycles is also an option.
Translating this to software development is pretty straightforward. You can “deload” your development cycle by reducing your planned velocity for the week, or maximum WIP.
You can choose to focus only on small, straightforward work: pull from a backlog of bugs, simple design tweaks, or documentation.
You could change your priorities and focus on work that’s viewed as less valuable, or a lower priority, but perhaps more fun/interesting than the primary tasks at hand. Maybe this is the perfect time to address some long-built-up technical debt.
The important point is to shift your team’s expectations about what work will be accomplished during the deload. You also give them a chance to take a step back from whatever pace you’ve been grinding away at.
Why you should deload with agile.
Writing complex software is challenging and mentally taxing. Humans aren’t robots, unceasingly cranking out quality work week after week, sprint after sprint, with no end. In “Extreme Programming,” Kent Beck even admits:
“Most programmers can’t pair for more than five or six hours in a day. After a week like that, they are ready for a relaxing weekend away from work.”
Of course, his assumption here is that they get a relaxing weekend away from work. For many, this isn’t the case. They’re lucky to even have a clear separation from work on the weekends to stress about their own lives. Vacations, holidays, and other paid time off can help provide a period of recovery. But, as we’ve seen from weightlifting, two weeks off once a year isn’t sufficient for your body to recover and progress.
These vacation breaks also tend not to be synchronous for a whole team. Adding regular deload intervals from the rigor of development gives your team a chance to recover in sync. That means you’re all fresh to tackle the next challenge together.
I’ve previously advocated for building inefficiency into your process. I think deload periods in Agile development are a great way to take advantage of this concept.
Read the complete series:
Rethinking Agile, Part 1 – Deload Periods
Rethinking Agile, Part 2 – The Stand Down Meeting
Rethinking Agile, Part 3: Stop Estimating Effort