Burnout and Disengagement on Agile Teams

An Agile approach to work—collaborating with a self-organizing team to complete meaningful increments of product on short cycles—has the potential to increase motivation and engagement. After all, all the factors are there: autonomy, mastery, and purpose. Or, at least, they should be.

The unfortunate reality, though, is that the autonomy, mastery, and purpose can get lost in the jargon and process. Sometimes, that’s just leaders cynically using the words without the content. But a lot of times, there’s an oversight, some missing skills, a structural issue that accidentally creates the conditions for burnout and disengagement.

In this episode, Richard digs into the causes and fixes for burnout and disengagement on Agile (or ostensibly Agile) teams. Agile teams should be the most motivating teams to be on—opportunity for autonomy, mastery, and purpose are built right in. But, too often, that’s not how it plays out. Tune in to learn how to avoid or address some common patterns that create burnout and disengagement.

Learn More

Episode transcription

Richard Lawrence

Welcome to the Humanizing Work Show!

I’m solo this week, as Peter’s out of town, and I want to talk a bit about burnout and disengagement on Agile (or ostensibly Agile) teams. Studies of workers more broadly that I’ve seen show something like 80% of workers report that they feel disengaged and demotivated.

There’s no study I know of that looks specifically at the Agile product development world, but I’ve heard plenty of stories from disengaged and burned out people in that space.

There are lots of reasons for burnout and disengagement. Sometimes they’re personal. Sometimes they’re related to the work or to the organization. But I’ve noticed that there are some patterns for how Agile (or would-be Agile) teams, in particular, can end up with the conditions for burnout and disengagement.

An Agile approach to work—collaborating with a self-organizing team to complete meaningful increments of product on short cycles—has the potential to increase motivation and engagement. All the factors are there: you have autonomy, mastery, and purpose. Or, at least, the factors should be there.

The unfortunate reality, though, is that autonomy, mastery, and purpose can get lost in the jargon and the process. Sometimes, that’s just leaders cynically using the words without the content. But a lot of times, there’s an oversight, maybe some missing skills, perhaps a structural issue that accidentally creates those conditions for burnout and disengagement.

In this episode, I’ll highlight five causes I’ve observed for burnout and disengagement on Agile teams—some patterns for how things can go wrong—and I’ll suggest some changes you can make to fix things if one of those sounds familiar.

Alright, in no particular order…

The first cause of burnout and disengagement I see on Agile teams is routine over commitment.

Over commitment kills mastery. When you have too much work to do and too little time to do it, you either don’t get the sense of progress that comes from getting things done or you have to cut corners to get things done. Either way, that undermines your sense of competence in your work. And when you’re overloaded, there’s no time for growth whether that’s via training or even just taking on a task that’s a bit of a stretch. So, a team who’s overcommitted will see their engagement naturally go down over time.

Making things even worse, that disengagement usually leads to a reduction in productivity and that doesn’t usually come with a reduction in workload, so the over commitment increases, and increase more.

So, what causes this?

Sometimes too much work is being assigned to teams.

But more often, Agile teams are, technically, pulling their own work, making their own commitments. So, the forces that lead to over commitment are more subtle. Here are a few that I’ve seen:

One is over-optimistic estimating. Teams commit to the amount of work they think they should be able to get done without paying attention to past performance.  Sometimes it even sounds like, “This sprint is going to be different.”

The fix there is to actually use your historical velocity, however you’re estimating, to predict the future. And if you’ve never finished something in the same sprint that you started it, your historical velocity is zero. So, the right move for a team like that who really have no idea how much they can get done, might be to work on one item at a time for a sprint to figure out the realistic minimum you can actually get done.

Another cause for over commitment is pressure on the team to take on more. This is different than just assigning a team too much work because the team still in a sense retains the authority to choose how much work they take in. But there may be a leader saying, “We have to get more done to hit our goals this quarter, or “We have to get this feature done because sales promised it to a key customer,” Sometimes, it’s not even that direct. The team might see how much pressure their product owner or manager is under and feel a sense of obligation to help them out. Or, even harder to diagnose…the pressure might be internal to the team. A sense that “We should be able to do more” or a past experience with getting pressured somewhere else that built a habit to overcommit.

Wherever it’s coming from, pressure to overcommit rarely produces the outcomes anybody wants. Certainly not over the medium- to long-term.

So, the fix is to explicitly relieve the pressure. I’ll coach product owners with teams who overcommit to encourage their teams to take on less and give themselves space to do it well.  They may something like, “We keep committing to ten backlog items in a sprint, and we’re struggling to get them done, and then putting things back on the backlog or carrying them over, you know, I’d be perfectly happy if we took on eight and did them really well instead of taking on ten and struggling.  So, it’s not pressure from me that should have you taking on ten.”

The second cause of burnout and disengagement I see is poorly run meetings. Most Agile methods have recurring coordination points and fairly often. In Scrum, for example, you’re going to be doing sprint planning, reviews, and retrospectives, as well as daily scrums. That’s 5-10% of your time in all-team meetings.

When those are facilitated well, it feels like you’re using the time together to do something that matters, and you’re getting it done efficiently. When they’re not facilitated well, that’s a lot of wasted time, and wasted time is demotivating.

The fix? Put some effort into making your meetings matter. We’ve done several past episodes on this, both about meetings in general and about each of the Scrum events. A whole team for an hour is expensive, and it’s not just the direct cost but also those downstream effects of the meeting whether good or bad.

The third cause of burnout and disengagement… Ineffective backlog refinement. I’ve said it on this show before: organizing work around small slices of value is the keystone habit that makes all the other Agile stuff work. If your backlog is a pile of tasks and components, you can keep busy, you can do some status reporting, but you’re not going to have the experience of collaborating to deliver value day after day.

Related to that is the fourth cause: Disconnection from a larger purpose. Even if your backlog is made up of small slices of value, if they don’t feel connected to something larger, you can end up feeling like your team is doing an endless parade of features with no larger, coherent point.

In both those cases, the fix is build a backlog where the items the teams works on day to day are small slices of value that roll up into larger features that have a meaningful impact that themselves roll up into a bigger purpose or vision. It’s possible for a team to have work from multiple demand sources mixed together on one backlog, so it doesn’t have to be one product, one larger purpose. But each small item should trace back to some larger goal. And everybody should be aligned about what it is. And that right there is gonna improve engagement.

Finally, the fifth cause for burnout and disengagement on so-called Agile teams is a team structure that makes delivering value in short cycles basically impossible. If you’re on a component team, and your completed work needs to get combined with three other teams’ completed work to be an actual increment of value, the long cycle time of finishing all those things and accumulating them, and the frequent rework that comes from later components rendering earlier components wrong in some way, it’s going to be demotivating.

It’s possible (I’ve seen it) to have a component team that’s motivating to be on, but that requires a really, really interesting technical problem or really high stakes for the quality of the component, because you’re optimizing for that.

In most cases, if your work is part of something that ultimately exists to provide value for users, working on a team that has all the skills to deliver that value is going to be more engaging. Not to mention the cycle time and feedback loops will get much shorter, creating a positive cycle of motivation, as you experience progress and results.

Now, a lot of times people stuck in the middle of an org structure made up of component teams don’t have the power to change it. For them, I give my usual advice about anybody in the middle of a system you can’t change, and that’s this: If you can’t fix it, make it more visible. [He repeats:] “If you can’t fix it, make it more visible.”  So the people who can fix it see what you see, and can consider that, and maybe do something about it. So, in this case, you might show the costs in cycle time and rework so the people who could change the structure see what you see.

Zooming out, from those specific causes, if you see issues with burnout and disengagement on your team, dig into the root causes. It’s usually a sign of something in the system that’s not working. So, motivation can be the canary in the coal mine for systemic issues, so build that, for example, into your retrospectives. And if you see a clear motivation issue, dedicate time to find out what’s behind it and make a change to do something about it.

Thanks for tuning in. See you next week!

Last updated