I want to share thoughts around burnout indicators. At the same time, I want to remain cautious in giving you a definitive list, as everything should be interpreted in the context of your culture and team dynamics. But knowing things to look for can be 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 definition of “done”, rushing at the ends of sprints
- Excessive time off, high levels of team stress seeping into home
- Not taking time off, not taking vacations (or cancelling them)
- Increased paranoia: “they” are after us, we have no choice but to work this way
- Lack of transparency, honesty, openness and continuous improvement
Of course you don’t want to over-react. 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.
Four Ideas for “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:
1. 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 “okay” for the team to ask for a break without feeling wasteful, unprofessional or guilty. Gather their responses 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 the team’s behalf. Then, based on feedback, give them a break.
2. 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 overall 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.
3. Plan for a break. I’m fond of injecting “breaks” within my organizational release tempo. I usually like planning for a “break” during the interval between release trains. 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.
4. 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-it is, 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.
There is far too much burnout within agile teams today, and it’s leading to shoddy work and poor results. 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 for and encouraging “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’ve hired, anyway?