Burnout in Scrum and how we dealt with it
Inception
“I bring you tidings of great joy”
Much touted as panacea at first, Scrum has fast become the de facto standard of operation in Software Development, regardless of the industry or vertical.
As it turns out, it is really hard to run pure Scrum.
And with many leaders pushing hard for some form of implementation anyway, companies end up with some bastardized variant of Scrum. Agile coaches might grin and bear it for now, perhaps as a first step towards the ideal. And perhaps there should be another iteration of evolution for the next sprint. That’s what retrospectives are for, isn’t it?
Isn’t it?
“Give an inch and they’ll take a mile”
So we kick the bucket of changes down the road. But deadlines don’t shift. And the first attempt is now our constant reality. Management would hold aloft this model of Scrum we built so far and proudly acclaim that this is our way of doing Scrum.
Maybe it is not quite Kejserens nye klæder. Still, it is hard to criticize the emperor’s new clothes when he pays your wages.
“My glass is half full”
Let us assume that we made a great first attempt and it is actually fairly close to ideal. The model works. And yes, each sprint builds our confidence.
So why does it feel repetitive?
We change up the retrospectives and introduce some fun. But it does not rid us of the niggling feeling that we are forever in some routine.
Hypothesis
“Quod Erat Demonstrandum”
I argue that the very nature of Scrum and the pressures of delivery in Software Development lends itself to a practical implementation of controlled crunch.
Crunch is endemic. Certainly in game development. So while it gets us results in the short term, we just cannot rely on such a method for sustainable practice.
“Cure sometimes, treat often, comfort always”
The root cause is clearly an imperfect application of Scrum, and the violation of one or more Agile Principles.
But I have no solution for that. There are far too many permutations and considerations for the failure of Scrum to take root in any one organization.
Instead, like a doctor who treats symptoms, I offer the following conjecture: give variety to your teams.
Specifically, rotating teams across development and production support.
Anecdote
I worked at a firm where we did a transition from LEAN to Scrum. Due to the strong Agile foundation, the transformation was swift and the results were quick to bear fruit. Within sprints, we established a predictive cadence, found an uncanny adherence to projected velocity and uplifted morale for all 6 development teams.
It turned out that this was not to last.
Within 3 months, we started to see burnout in our developers. Scrum turned out to be amazing for new feature development, and by incorporating the experience of limited scope from our LEAN days, we pushed to production very often.
These pressures existed before the days of continuous delivery, Kubernetes and immutable infrastructure. The result was a heavy responsibility shared across DevOps and Development. Our feature teams supported the push to production in real-time, and if it took an hour or six, well, the entire team was on standby, checking and re-checking.
Band-Aid Solution
As part of the senior technical team, we took note of the consequences and re-evaluated our approach while bearing in mind the commit dates from Product.
The solution we came up with, was simple:
1) Production Support will implement Kanban
2) Feature Development will continue using Scrum
3) Every sprint, a Feature Development team takes over from Production Support
So at any time, there were 5 teams doing Feature Development and 1 team on Production Support (PS). Every sprint (which was a week), we rotated a team in for PS.
Within 3 sprints, we had feedback from the teams who underwent the rotation. PS was not everyone’s favorite activity but it did turn out to give the team a break. There was no deadline to deliver in Kanban, just a priority and swarming, the latter which actually attributed to deeper, more fundamental solutions rather than a cobbled together patch.
We let the experiment run for 3 months. Then it stuck as practice.
For the remainder of my tenure, this model ran well.
Thinking back, I would not say that Kanban solved Scrum, was superior, or vice versa. Rather, I think the change in going from one process to the other, broke the drudgery of routine. So while I prescribe this approach as a household remedy for your organization, I do not expect it to be a cure-all.
After all, there is no panacea.
