My My, Hey Hey (Out Of The Blue)
My my, hey hey
Rock and roll is here to stay
It's better to burn out
Than to fade away
My my, hey hey.
--Neil Young
One of the core principles of agility is the notion of “sustainable pace”. It originated in the Extreme Programming community. Initially, in v1 of the XP book, it was defined or framed by the principle of a 40 hour work week.
I vividly recall managers at the time railing (no ruby intended) against the notion as a clear example that these agile maniacs were out of touch with business reality, out of control, and looking for an easy road at work. What could possibly be next—working from home?
In the second edition of XP, Kent Beck softened the message a bit and dropped the (n) hours recommendation. Nonetheless and thankfully, the notion of sustainable pace has remained as one of the core agile principles. Although there does appear to be an increasing de-emphasis of it within today’s agile teams.
Back to the Title Question
Can agile teams, solid agile teams who are high-performing for that matter, can they “burnout”? I believe the answer is yes. In fact, I’ve seen the phenomenon occur quite frequently. One example are teams who schedule their sprints sequentially or back-to-back, without a pause or break. For example, every other Monday they’re starting a sprint and every other Friday they’re closing a sprint, with not a break in between and for months (or a year or more) on end.
I often see these teams simply needing a break of some sort, but they’ve succumbed to the tyranny of agile iterations and don’t think it’s possible to “take a break”. Another driver is they’re too focused on reducing lean waste, and again, they look at any down time or slack time as being wasteful.
Somehow I think we’ve overly focused on iteratively being agile and on reducing waste that we’ve forgotten that we’re dealing with people in our teams. And people can get exhausted and often can use a break to recharge their batteries. Back to the Neil Young lyric, I don’t think it’s better to burn out, especially not in a continuous improvement and delivery model.
“Burn Out” Indicators
Next I want to share thoughts around burnout indicators. At the same time, I want to remain cautious in giving you a definitive list of indicators, as everything should be interpreted in the context of your culture and team dynamics. But knowing what to look for is often helpful in catching early stage burnout before it becomes systemic. Here are a few signs of burnout:
- Excessive overtime; becoming the norm with long term duration;
- Rising mistakes: bugs, poor design choices, and hurried implementations;
- Rising temperatures, increasing levels of team stress and conflict;
- Lack of humor / fun, team is too focused and lost any playfulness;
- Lack of refactoring or quality investments;
- Excessive negotiation (or avoidance) of your Done-Ness, rushing at the ends of Sprints;
- Excessive time-off, high levels of team stress seeping into home;
- Not taking time off / not taking or cancelling vacations;
- Increased paranoia; “they” are after us, we have no choice;
- Lack of transparency, honesty, openness, and continuous improvement.
Of course you don’t want to overreact. Hard work, dedication, and engagement are hallmarks of healthy agile teams AND there is certainly “normal and healthy” stress within teams. But here I’m looking beyond healthy reactions and I think you’ll be able to tell the difference.
7 Ideas for Possible “Refreshments”
So if you are suffering from burnout, what are some helpful techniques to refresh and recharge your teams? This is simply a starter list of ideas for you to try or use to brainstorm your own refreshments:
Ask them
My first response would be to ask your teams? Ask how they’re feeling and whether they need a break of some sort. Also, set the stage so that it’s “ok” for the team to ask for a break without feeling wasteful or unprofessional or guilty. Gather their response and sort through what options you might have to support their ideas. There’s nothing better than showing you care, are listening, and are willing to take action on team feedback.
Plan @ 80%
In waterfall teams it’s a fairly common practice to plan teams at 100% of their available time. Sure, you may allocate time for meetings and other diversions, but of the remaining time, you invest it at 100%. I’m going to recommend something you might struggle with, but so be it. Whatever your work capacity is for each individual, ask them to plan their effort at 80% of it no matter what. Not as some vacation factor, but as a slack factor to allow time for simply thinking, considering creative solutions, and to breath a bit. How they use the 20% is totally up to each individual and nobody micromanages it or tries to reduce it under any circumstances. Last time I checked, these are your trusted knowledge workers—so allow them so flex.
Pair more
Pairing can often defuse the pressure on each individual team member. By definition, the pair is sharing workload challenges and more used to asking for help from others. They become more focused on the work and delivering high quality features, rather than the false focus of keeping team members at 100% efficiency. I’m talking about comfortable, non-forced pairing here; as it makes sense within the teams’ Sprint Goals and backlog.
Another byproduct of pairing is reducing single points of knowledge or skill within the team. This allows for more flexibility in the team’s ability to meet the business’ demands and reduces individual stress for key team members.
Plan for a break
I’m, fairly fond of injecting “breaks” within my organizational release tempo. I usually like planning for a “break” during the interval between releases. Yes, I actually will pad time between releases, normally a week or so. Part of the week is for supporting the release. Part is for planning the next release. And a significant part is decompressing and personal time for the teams. Normally, I’ll leave it in each team’s hands to figure out how they’ll make the transition from one release to the next. But they need to factor in some break time for recharging their batteries.
Allow the team to work on their interests
Technical teams are often driven incredibly hard to deliver what the “customer needs”. I sometimes refer to this as feature-itis or 100% feature syndrome. It’s not necessarily bad if done infrequently. But in excess, the team may be unable to complete things that they feel are equally important, for example, extending infrastructure, fixing bugs, or fine-tuning some environmental tooling. I think excellent Product Owners learn how to feed their teams a balance of work—some of which is interesting to them. Allowing the team to occasionally work or immerse on what they want or what they think is important can often help recharge their batteries.
Focus
There can be a tremendous amount of wasted time surrounding the activities of an agile team. This can then lead to stress as a result of trying to compensate for the waste. Reducing meetings, actively facilitating meetings, allowing for more working from home, have the team work in a common space, etc. are ways to increase their focus. Also, don’t be afraid to let folks work alone. The majority of software folks are introverts—so they need some private time for increased productivity, creativity, and ideation. Point being, don’t force too much collaboration.
Go have fun
Get out of the office and do something that the team enjoys; either as a team OR as individuals. I’ve seen some teams focus on gathering together for fun. I’ve also seen teams who realize the commitment folks make to work and go off to spend some special time with their families. And sometimes there’s a combination of the two. As an agile leader, I’ve often provided funds to the team to support whatever activity(s) they come up with. My only stipulation is for them to have fun and get some decompression time.
Wrapping Up
I believe there is a lot of burnout within agile teams today. I think teams are being worked too hard and have too little buffer or slack time to recharge their batteries and their brains. This was true in waterfall teams and led to the coining the term Death March and the associated working patterns of failed projects.
I’m not implying that agile teams should take it easy or not work hard. I actually think that “Agile done well” is a very intense working pattern. Excellent agile teams can even burn out while working consistent “40 hour weeks”, so the hours aren’t the only determinant.
I’ve mentioned the term “slack” several times in this article. I use it with Tom DeMarco in mind and his exploration of slack in the book Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. The book does a great job of making the argument for allowing/encouraging some “white space” in your organization and team’s time.
What I hope I’ve inspired you to do is be aware of burnout within your agile teams. Look for the indicators and ask your teams about it. Show a willingness to slow down to go faster and to take the occasional break. Sure, you’ll need to trust that your team won’t take advantage of it. But why wouldn’t you trust those wonderful folks you hired anyway?
As always, thanks for listening,
Bob.