The Agile Project Manager – Can Agile Teams get “Burned Out”?

The Agile Project Manager – Can Agile Teams get “Burned Out”?

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.

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.

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:

  1. Excessive overtime; becoming the norm with long
    term duration;
  2. Rising mistakes: bugs, poor design choices, and hurried
    implementations;
  3. Rising temperatures, increasing levels of team
    stress and conflict;
  4. Lack of humor / fun, team is too focused and
    lost any playfulness;
  5. Lack of refactoring or quality investments;
  6. Excessive negotiation (or avoidance) of your Done-Ness,
    rushing at the ends of Sprints;
  7. Excessive time-off, high levels of team stress
    seeping into home;
  8. Not taking time off / not taking or cancelling vacations;
  9. Increased paranoia; “they” are after us, we have
    no choice;
  10. 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.

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.

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.

Leave a Reply