October 25, 2025 • 44 mins
In this episode, we explore the growing issue of Agile burnout — when teams lose their spark and the work begins to feel like just another mundane task. We unpack why this happens, how organizations contribute to it, and what leaders can do to bring energy and balance back to their teams. Tune in for real talk about sustainable agility and keeping the heart of Agile alive.
Join Shawna Cullinan, Jörg Pietruszka, Diana Larsen, Sheila Eckert, Sheila McGrath, April Mills, Hendrik Esser, Ray Arell, and all the callers to the monthly live event as we explore this topic. For details on the next live event or how to support our show, please visit acnpodcast.org.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Ray Arell (00:31):
Good morning and good evening everyone.
Welcome to the Agile CommunityNetwork.
This is episode 106.
Today we're gonna talk aboutdealing with agile burnout.
Just as a reminder, we arecommunity supported.
Please, if you have a chance,go up to acnpodcast.org and look
at our sponsors, reach out tothem, become members, whatever
(00:53):
it takes to thank them for theircontributions that make this
show possible.
And also the individualcontributors that go up to New
Agility and give us donations.
That helps us to pay for thewebinar system and all the other
things we need throughout theyear.
Speaking of that, we are cominginto the next year.
This is the second to the lastsession before 2026, which is
(01:16):
bizarre to think about that weonly have one more show beyond
this one left before the newyear.
If you go up there and take alook again on cnpodcast.org, we
could use your financialsupport.
We do have some doubt cominginto next year on what we are
expecting, and in order tocontinue to bring the show, we
do need your help.
I'm joined every month by someco-hosts that have been with me
(01:40):
for a long period of time.
Shauna, Diana, Jorg, SheilaEckhart, Sheila McGrath, April
Mills, and Hendrick here to getthe conversation going along
with all the people who callinto our Monthly Live event.
The goal is to hear from allperspectives.
If you're new to Agile or ifyou've been doing Agile for a
long period of time, all ofthose perspectives, we want to
(02:01):
hear those.
Be a part of the community, bea part of the conversation.
Dealing with agile burnout.
I was talking with a couple ofpeople about a month ago, and
they were dealing with the issuethat their team was not feeling
it any longer.
They weren't feeling the agilevibe.
They felt like they were juststepping in, and every day
(02:25):
seemed like the same old thing.
The pressure of delivery, theywere dealing with some breakdown
in the system with poorlyformatted backlogs.
The priority of things werechanging so rapidly, which by
the way, priority changing is apart of the nature of Agile.
One of the reasons why we haveiterative development is that we
(02:48):
sometimes need to changebecause the customers decide
that this might not be the rightpath.
If you amp that up, where itdoesn't seem like there's a
rhyme or reason for that changegrounded in customer need, and
it just seems like you'redeveloping things that nobody
seems to want.
That really starts to drag downteam morale.
Also, sometimes the ceremoniesthat we do, for example,
(03:12):
retrospectives, when you doretrospectives and put in a
whole bunch of things that needto be fixed and none of that
stuff gets fixed, that alsoleads to burnout.
So you find that even thoughthat you're going through,
you're not really leading thechange in the organization at
all.
It just feels stagnant.
The lack of stability can leadto the burnout of our
(03:33):
developers.
And there's a lot of differentways that this can be fixed.
This is where I want to hearyour guys' perspective.
But from my view, I think thatthere's always needs to be
somewhat somewhat of a refreshon Agile's core purpose.
Why are we doing Agile withinthe organization?
What are those values andprinciples that we want to
(03:54):
embrace?
And how do we accomplish thosewith the types of ceremonies and
tools that we have?
Needless to say that over timewe overcomplicate things.
It's human nature, I think,sometimes when we start putting
in processes, but we don't takethem out when we don't need them
(04:14):
anymore.
Also the sustainable pace.
I remember a sprint review onetime when we were doing Scrum
and we were at like sprint 70 orsomething.
And there's a point where teamsover time will lose stability.
The sustainable pace falls off.
There's real work to get theteam back into hitting the pace
(04:35):
again.
I'm curious, how do you createthat sustainable pace within
your organization?
And then just reconnecting withthe purpose itself.
Why are we developing thisproduct?
What where are those customersand what are the customers
giving us feedback on?
Nothing recharges a team betterthan hearing great things from
(04:55):
the customers.
And even sometimes hearing notsuch good things.
It's a way of stepping up andsaying, okay, here's the things
that we need to go work on.
So the questions for today, areyou seeing Agile burnout?
Have you seen it within yourorganizations or organizations
that you go in and help coach?
What are the signs that youlook at when say, okay, oh, this
(05:16):
team seems like it needs somehelp because they are hitting
that burnout situation?
What steps would you take tofix it?
What are the types of methodsor things that you would do as a
coach, manager?
I'm curious to hear what youwould do.
So to kick us off, Diana, doyou want to take a stab at this?
Diana Larsen (05:35):
Yes, of course.
And you brought upretrospectives as a major
contributor to burnout.
I do think that frustration ofholding a meeting, having some
conversations about all thethings that are wrong, and then
either not identifying anythingto fix or identifying something
(05:57):
to improve, and then seeing nofollow-through on it, or the
having no plan forfollow-through on it, or maybe
it's outside of your control, isfrustrating for the whole team.
I've seen retrospectives thatend up just being a list of
here's the things we learned andhere's the things we'd like to
(06:17):
change, or that we think weshould do differently.
Nothing further than that.
You end up with two lists, andthat seems like a big waste of
time to the team and to me.
Then there are the ones wherethey actually pick something to
move forward on, but there's noplan for moving it forward.
No team member steps forward tosay, I'd really like to own
(06:39):
this for us for this next sprintand see if we can't make some
improvement on it.
There's a lot of ways in whichthat gets stalled or stuck and
is frustrating and feels like awaste of time.
Anytime we feel like we'redoing something that's wasting
time, that's the path to burnoutthat really does move us in the
(07:01):
wrong direction, really.
One thing, one thing I want tomention is that Esther Derby and
David Horowitz and I havewritten a second edition to the
Agile Retrospectives book.
Please look for that becausethis is one of the issues we
have addressed that wasn'taddressed on the first edition.
(07:21):
And I'm going to also drop alink in the chat to an activity
called Circles and Soup.
It's in the second edition ofthe book, and you can find it in
other places on the web aswell.
This activity helps the teamidentify the source of their
difficulties and where thosemight come from.
(07:44):
Are they in the team's control?
Are they things the teamdoesn't control but might be
able to influence?
And are they things that arecompletely outside of what the
team can move on their own, givesuggestions about improvements
you can do wherever you start onthat?
And the recommendation isalways start with things that
(08:07):
are in the team's control.
And that they feel enthusiasmfor fixing.
So that's one part of it.
But I think the retrospectivealso is a great place to bring
up other signs of burnout thatyou're seeing in your team.
Here are some other things thatwe are feeling frustrated
(08:29):
about.
Here are some other things thatseem to be holding us back.
All those things that make usfeel like we're trying to move
forward and being blocked.
So making sure that you'reidentifying impediments when
they come up and so on.
But I definitely see Agileburnout on Teams all the time.
(08:53):
Another big source of it iswhen it's a scrum team and there
is a scrum master, and thatscrum master is also supposed to
act as the product owner.
They've got a doubleassignment, or vice versa.
(09:14):
They're the product owner andthey're also supposed to have as
a scrum master.
And what happens is that thatthose two roles have competing
goals.
Often things that the scrummaster should could be doing get
pushed to the side to add moreon the product owner side, or
(09:35):
vice versa.
And that creates confusion inthe team and gets in the way of
the team being able to do whatthey need to do.
So that's that's another thingto bring up in a retrospective
and talk about how can you, howcan the is that within the
team's control to make anadjustment?
(09:55):
Or is there some other partythey need to influence to say,
this way of organizing this teamis not working?
What can we do to fix it?
A lot of it has to do withhaving a team that has
psychological safety so that youcan bring up the fact that
we're beginning to feel burnedout, we're beginning the
(10:17):
frustration levels are gettingreally high in our team, and we
need to do something about it,or we're going to be broken.
Those are the top of my headcomments to make about it.
Ray Arell (10:29):
Do you all see not just the shared role with the
product owner and the scrummaster, but also where a
developer is not in just oneteam, they might be in multiple
teams.
Diana Larsen (10:38):
That's the multi-team assignments that you
know where you that kind ofmulticastking across work roles
is just all kinds of researchthat says why that I can't put
my hand on any of it right now,but there's a lot of it.
If you are assigned more than60% to a project, that's the
(11:01):
project that's going to getpretty much 100% of your
attention.
If you're assigned 30%, 30%,and 40%, there's so much waste
in the shift of focus that itimpacts anybody's ability to
perform well.
That builds in a lot of wasteinto the system.
(11:22):
However, somebody is beingsplit across teams, it it's a
problem.
Ray Arell (11:28):
Yeah.
I appreciate that.
I see all of those things, andthank you for those good
suggestions, especially the Ineed to get the next revision of
your book because I do want toread that section.
Scott, what do you have onthis?
Caller 1 (11:41):
I was running retrospectives with my team,
using ideas boards every twoweeks.
And the team wasn't reallyburnt out, but I looked at
myself in the mirror one daywhen I'm like, I'm being lazy.
This could be better.
I need to be better.
I bought Diana's book andstarted offering the team
different formats.
Then I started researchingactivities like journey lines
(12:05):
and moving motivators to keepthings fresh and offer new
things to the team.
The thing that I liked aboutdifferent retrospectives is it
asked the same kinds ofquestions but in different ways.
So it got the team thinking alittle bit differently about the
system that they worked inevery retrospective.
And it kept things fresh.
The other thing that I'vealways talked to the team about
(12:26):
is, especially in theretrospectives, inspecting and
adapting, continuous improvementand finding things that we can
iterate on to make things bettertomorrow than they were today.
Hopefully, if things aregetting better, teams are
feeling good about themselves,right?
Even looking at things likeyour definition done in team
agreements, not getting lazywith those as a scrum master or
(12:47):
a coach and being like, hey,look, every quarter at least we
got to, or somebody new joinsthe team, we got to look at
these things on a continualbasis and update them so they
don't get stale.
As things get stale in routine,that's when burnout starts.
I also like to review thehistory because when you work on
lots of small iterations tomake things better, teams
(13:10):
quickly forget they've doneanything and think they haven't
done anything.
So I like to take them back andsay, hey, six months ago, this
is where we were.
And over the last six months,we've improved this.
We've iterated on them, we'veimproved that, all towards
making life better for ourselvesso that we can offer more
quality in a more timely fashionto our customers.
(13:32):
Many times you're like, oh, Ididn't even think about that.
And the other thing too issometimes just have some fun.
I have in the past playedcahoots with a team every
sprint, take an hour out of asprint and play, do something
that's not work-related to tryto keep things light and
introduce some things thataren't just pounding away at
(13:54):
what's wrong.
Ray Arell (13:55):
I like all the suggestions and especially just
going off and having fun withthe team.
I think sometimes when we lookat the daunting backlogs, we we
don't realize that we begin toslow down.
And in order to speed back up,we might just need to take a
break.
So that's thank you for allthose suggestions.
Jorg Pietruszka (14:18):
Yeah, multiple thoughts on this.
Sometimes it's as was mentionedalready by Scott, a bit it's a
bit of if you're doing the samething over and over again.
People feel that the energy putinto them as support or
anything is missing.
Grab the opportunities to dosomething different.
Especially now with Christmastime, instead of looking back
(14:41):
and improving, look forward andask what's the best improvement
we need to scale that mountainthat's ahead of us.
Or when the product owner isnot present at the retrospective
and is welcome, use that totalk about his contribution and
make it a recognition of hiscontribution to the team, what's
good.
You can then add improvementsto make his life easier or
(15:05):
whatever.
So that that's definitely onething.
And then looking from thepersonal point of view for
satisfaction with what you'redoing, you need some kind of
autonomy.
If you're not in control ofyour fate as a team, that's the
first thing to change, then youneed mastery, which means you
still want to improve on thetechnical side.
(15:27):
If you're doing everything thesame way every day and there's
no new technical challenge,that's as damaging as you can't
do your work because you don'thave the knowledge.
So that you you might need toadd some diverging
responsibility, differentperspective on the technical
side as well.
And then last but not least,there's purpose.
(15:49):
Bring in people to the team whotell them why their work
matters, for whom it matters andwhat the contribution is.
Do it as often as possible andas emotional as possible.
And that's one thing that I useto detect if a change is
definitely needed.
That's if emotions helps out ofthe team.
If there's no laughing, joking,or even frustration, then
(16:15):
something is definitely amissbecause we we're not
automatants, we're not justdoing our work going home.
We are spending a lot of timewith all those people.
So there needs to be a bit ofhuman element there as well.
In my very first company, theappraiser question that was to
be asked, among five others, areally significant one, brings
(16:35):
humor to the team.
And everybody needed to provideexamples, how they positively
did this because this is soenergizing and so positive.
That's my last tip.
I think I picked it up fromDarius, maybe he's here.
It's the happiness meter thatask people how happy do you feel
about the job, about the teamperformance, how willing are you
(16:56):
to work just on a scale of oneto five.
If that degrades, then it's awarning sign that something
might be wrong.
And it's a great conversationenhancer if you have trust in
the team, because then peopleand I've happy to say I had that
happen, step on and say, I'mreally feeling bad this week for
(17:18):
that and that reason.
So bear with me if I'm notreally constructive today.
And as long as they deal likethis with such a situation, it's
really helpful.
If they keep it to themselves,it's dangerous.
Ray Arell (17:31):
Those are good points.
What are some examples of newtechnical challenges that you
deal with?
Jorg Pietruszka (17:37):
For my people doing really low-level software
on controllers, it's reallygetting all that data used
somehow so they can play andthey are not challenged directly
for the direct work becausethey still need to make these
devices work in a ratherconstraint-specified form.
But learning from what they doand how the things work to
(17:59):
improve it is something wherethey can be really creative and
have a Hoi Rika moment just togive an example.
Ray Arell (18:08):
Also, one of the other things on sustaining work,
where you just have to sustainthe product.
I've seen companies thatthey'll just create a team that
does the sustaining work, andthen there's other teams that do
all the new cool stuff.
Do you not recommend creatingthe sustaining team?
Does that work shared witheveryone?
Jorg Pietruszka (18:27):
Yeah, I believe in what you do your own.
Normally, if you know there's ateam that will iron out the
last bug, you will leave muchworse things behind, unless you
have a really high respect.
There are some situations whereyou get a lot of stuff incoming
to have it pre-sorted by peoplejust learning the system.
So as a transitionary state, itcan be very helpful.
(18:51):
As a stable state, fixing otherpeople's stuff is a is a skill
and a capability.
So if you have people whoreally excel in this, that might
be something but you need tohire for and build a team and
praise it.
And they probably then need tobe the service organization's
(19:11):
technical backbone.
So they're no longer really inresearch and development.
But in another role, businesssustainability would probably be
a thing to really value whatthey do, but don't get low-paid
people to fix the bugs of thehigh-paid people.
That I think is ratherdisrespectful, especially for
(19:31):
their learning, because you byconstruct of the teams don't
want to elevate them to the nextlevel, which is probably rather
stupid.
Ray Arell (19:41):
I appreciate that.
Kyle.
Or I may not be pronouncingKyle.
You did great.
Okay.
Caller 2 (19:49):
It's smoke Hill, but it's pronounced Kyle.
Any of our German friends mightknow much exactly how it's
pronounced.
I just wanted to share a coupleof things on this topic.
I've presented a number oftimes locally in my area around
this issue.
One of the things that I don'toften hear other people share is
focusing on, for lack of abetter term, the scope of the
retro.
A lot of times we get into aretrospective meeting and we're
(20:12):
focused on the last break.
But teams have issues that areoutside of the work of the last
two weeks.
Occasionally I'll have aretrospective where we cover
either a longer period of timeor focus on a specific area of
the work that we're doing.
One of my favorite ones is justto ask the team if you had a
magic wand and could fixanything about the organization,
(20:34):
what would that be?
We talk about that.
One of my favorite examples isto share that my organization,
the team really wanted us toimprove the development
environment.
But in order to do that, it'san organizational-wide problem.
And so we set off afteridentifying that as the key
problem and we worked at it forabout a year.
After about a year, everybodywas on board and we upgraded the
(20:56):
development environments.
Everything went smooth.
The team was really energized,but uh so that's one of the
things we focus on.
One of the things I've done toenergize team members is to loan
a team member out.
Sometimes there's another teamyou're familiar with, and
they're struggling with and theycan use a boost.
And you loan that team memberout maybe for a sprint, but
usually I try something a littlebulker.
(21:17):
The team member has to be onboard with this.
By doing that, they getexposure to different ways of
working.
When they come back to yourteam, they come back with new
ideas, which can be energizing.
Loaning a team member out maynot work in every situation or
for every organization.
That's just another way to keepthings fresh and keep momentum
going and getting new and freshideas coming back to the team.
And now in your role, what doyou do?
(21:39):
I'm an agile coach.
I've been an agile projectmanager, agile scrum master, but
most recently just an agilecoach organization called
NellNAT, which does do the loanservicing pressing.
Ray Arell (21:51):
Do you find that for your own coaching, rotation is
also important?
Caller 2 (21:56):
Yeah, in fact, one of the things that we and I was I
was on a team with two otherpeople, one of the things that
we do is set a limit on thecoaching engagement we're
working on.
When that limit gets hit, weget together a team and say,
okay, should we still work withthis team or do is it time to
change things up?
We have goals for everything.
When those goals come out forteam, maybe you're gonna finish
(22:18):
that coaching relationshipbecause the team's passed what
they needed to do for.
Or maybe you're gonna shiftthem to another coach because
that coach brings you.
Ray Arell (22:26):
Yeah, no, I love that because I do believe it's the
same thing with like leadership,any type of leadership, knowing
what your skills are andknowing that you might not be
the right person to fix thatissue or to help.
An important part of coachingis understanding that I'm not
the right person to work onthis, but I know the person.
And we let's get them in.
Caller 2 (22:47):
Yeah, I think burnout's about the rut, a lot
of times.
You're just in a rut.
And identifying what that rutis probably the best first out
and trying to make thingscrashy.
Ray Arell (22:57):
Tully agree.
Yeah.
Sheila, what do you have onthis?
Sheila McGrath (23:02):
I think most of the teams I've worked with have
been working with other teamsthat were not agile at all.
So some of it is the challengeof finding a way that doesn't
interfere with the team's goals.
A lot of times it's teachingthem how to interact with these
teams themselves rather thanhaving to escalate everything to
(23:25):
management, understanding whatthe other team's priorities are
requires some conversationswithin the team and with
management to figure out how towork more effectively.
Another thing that I keeprunning across is it used to be
that you'd have a scarceresource in somebody who knew
old mainframe systems that youhad to interface with.
(23:46):
But now there's so many newtools out there that you wind up
with someone or two people whohave the expertise in a newer
tool, and they get spread acrossevery project there is.
And there isn't really any wayto avoid that until you get
other people up to speed.
One of the tricks is to getmanagement to allow time for
(24:09):
knowledge sharing that's notspecifically project related.
That can be very motivational.
Another thing that keepshappening every place I've been
is meeting burnout.
You need to have some period oftime blocked off where you say,
no meetings in this time frameunless someone on the team
(24:31):
schedules it themselves.
It can't be something organizedbetween teams or by management
to give them some focus time toactually work.
The other thing that I seehappen is people sometimes
estimate higher consistently.
(24:52):
Like they try to estimate threetimes the amount of time that
they're actually going to needbecause they know management's
gonna cut whatever they're givenand say you have to deliver by
this date, whether it makes anysense or not.
And trying to get management,especially product management,
to listen.
If you want a product that'sviable, you really have to give
(25:16):
us time to develop it if it'ssomething new.
If it's just little tweaks andbells and whistles, then maybe
that'll work.
But if you're really bringingsomething new to market, you
really have to not try todictate the time frame, which is
really hard when you're tryingto organize marketing campaigns
(25:37):
and make sure that customer careis ready, to not be able to
plan way in advance and justsay, okay, in six months we're
going to do this and make it animmovable date where you're
going to bring something outthat nobody's going to be proud
of if you're not careful.
That's really a mindset thatyou have to change with
management, internal to ITmanagement, but also at the
(25:59):
enterprise level, you need tomake sure that the enterprise
understands what agility means.
Those are the things I thinkabout.
Ray Arell (26:08):
So I'm curious along the line of deadlines.
To me, deadlines exactly as theword says, it's a deadline.
If we don't get it out there bythis date, we won't have a
product we won't eat.
How do you push back on that?
How do you discover whether thetime frame is arbitrary or made
up?
How do you combat that withinorganizations?
Sheila McGrath (26:33):
Sometimes it's not movable.
If it's something likeregulatory deadlines, you must
have this in place becausethere's a rule that takes effect
then.
Or you have a product that'sgoing to hit this condition, and
the development to support theproduct kept getting stuck in
the backlog and wasn't gettingdone.
(26:54):
And now you have a deadline.
In one case, someone high up inthe organization had gone out
and said, by this date, we willhave this product on the market.
And it was a new product withnew functionality, different
than anything they had donebefore.
Now the credibility of theorganization is on the line
because somebody spoke about itpublicly before they asked if it
(27:17):
could be done.
And that can turn into a deathmarch where you have to say,
okay, you said that we must haveit by this date.
Therefore, you must supportgiving us the resources to get
it done by this date.
Can you even find the people todo it if there truly is an
immovable date?
Sometimes you can, sometimesyou can't.
And then you have to set up howare we going to triage the
(27:40):
problems that we're going tohave because we didn't have
adequate time.
And what are we going to do tofix it?
How are we going to prioritizewhen we know we're going to have
more problems than we wouldlike and the product's not going
to be as clean as we would wantit to be.
And then you just have toeducate management about what
it's going to look like whenthey're going to get customers
(28:01):
complaining that problemswouldn't have been there if
they'd allowed us more time todevelop.
Ray Arell (28:06):
And that's the quality triangle, right?
Quality cost and time.
Something's got to give one wayor another.
One of the ways I deal with itis that the data is showing us
that we're not going to hitthat.
We need to reduce scope.
What I find a lot of times isthe must-haves.
A lot of these things are notmust-haves.
They were just someone had awhim that they thought that was
(28:28):
going to look good on a sheet orbecause the competitor had it,
but no one uses it.
So that's always a challenge.
Let's see, Isin, what do youhave on this topic?
Caller 3 (28:37):
Yes.
So for me, it's the one of thebiggest thing is the team
dynamics that I've seen to causeburnouts.
If you have a bunch of peopleworking together that don't gel,
have different approach tothings, it can lead to very
difficult conversations.
And I think Agile justbasically put that under the
microscope just because itrequires a lot of collaboration
and teamwork.
(28:58):
It turns what could be minorissues into a bigger problem if
people have to interact everyday and don't get along.
To me, one of the examples, forexample, the sustaining
engineering guy was brought upearlier.
I've I've was VP of engineeringfor a while.
Big, I don't know, agile guyfrom the VP level, from the
engineering side.
Trying to build the sustainingengineering team, I had to
(29:21):
basically ask the question whowants to be on that team.
Sometimes it worked out well.
Sometimes you have people thatwant to run it the same way it
runs for new features using thesame processes that cause issues
with the team members.
I think this is one of the bigones I had to keep an eye on,
evaluate the teams, see how wellthey're doing as a unit and how
(29:42):
they could improve, helpingthem either to improve or change
if needed.
Ray Arell (29:46):
What's your role in your company?
Caller 3 (29:48):
I'm a co-founder for a small startup, two people, but
I ran the engineering for 10years before that.
Ray Arell (29:55):
Okay.
I'm curious.
I've seen a downturn ininvestments of training people
post-COVID.
A lot of companies are saying,if you're going to go learn
that, go learn it yourself.
We're not going to make thatinvestment.
Do you think that's a badchoice by companies not to make
those investments?
Caller 3 (30:12):
I just came from a VP of engineering group where they
were talking about AI and howthey approached their teams
about encouraging their teams touse it.
I asked Do you guys train themon how to use AI?
How does it help a juniorengineer to a senior engineer?
All looked at me like notreally.
I'm finding that to be less andless, and I don't know if AI is
causing some of these issues,but for some reason there's not
(30:35):
a lot of investment in thatarea, money-wise or effort-wise
by leaders.
Ray Arell (30:40):
Yeah, I think it's a dangerous if you get to go to an
external class someplace.
That's one way of combatingburnout because you're learning
a new skill.
The AI stuff, I think you'reright.
You hear it on YouTube all thetime.
They call the AI slop of peoplejust producing something but
(31:01):
have the AI just do it.
I know some people in DevOpsorganizations who are doing
nothing more than having to gofix AI code because that's all
the junior developer checked in.
They just got the result fromthe AI system.
They didn't do any refactoringthemselves.
They don't even understand thecode.
And yeah, I think that's a hugechallenge.
So tell us just a little bit, aplug for your business.
(31:23):
What's your founder?
Congratulations.
What are you, what do you whatare you going to do?
Caller 3 (31:30):
I'm building an AI-powered agent for agile and
delivery coaching.
Our goal is to help agilecoaches scale in organizations.
What I've seen, and I'm prettysure a lot of you guys have seen
it, is teams or companies hirevery little number of coaches
compared to the numbers teamsthat they want covered.
We're hoping that the AI couldhelp get them the visibility,
(31:51):
help them push.
Like one of our first virtualbuilding is helping the team to
prep and run stand-ups and givethem coaching after.
Look at the data they need tocover about the risk, anything
that they have.
And then when they have theconversation, try to give them
feedback on how the conversationwent and what they should have
covered better or not.
Ray Arell (32:11):
Oh well, interesting.
As long as it doesn't replaceagile coaches, I'm on board with
it.
Caller 3 (32:17):
It is definitely one of my mission is not to do that,
but in instead to help themcover.
Because I don't believe anagile coach could be at every
stand-up, at every planning,every meeting that the team is
having.
And they could actually coachus to coach them and they could
be part of the conversation.
Ray Arell (32:32):
Thank you for that.
April, congratulations on yourkeynote.
April Mills (32:38):
Thank you.
It was a great time at thesoftware quality conference in
Portland last week.
Ray Arell (32:44):
What do you have on this subject?
April Mills (32:47):
I've been focusing a lot lately on the environment
the teams are in and the thingsthat the teams are running into
outside of the developmentprocesses.
One of the things that oftenwears out teams, it's the lack
of the tools or resources orinformation they have.
The reason they strugglewithout standard tools is
(33:10):
because of the largerorganizational bureaucracy.
I've been focusing on how tohelp bureaucracy hack, as I call
it, to help get the teams whatthey needed to be effective.
I think one of the cruelestthings I've seen over the decade
I've been in this agile spaceis the mounting expectations on
(33:32):
teams and the decline intraining, the decline in
training investment, the declinein infrastructure investment,
with those mountingexpectations.
I'm trying to focus a lot onhow to help burnout by how to
help teams understand how theycan hack the bureaucracy to get
the training, the infrastructurethey need, how to help leaders
(33:55):
understand that just asking theteams to go faster and hoping
that AI will somehow fix thethings they've been avoiding all
these years is not the path tosustainable, high-quality
products and services.
Ray Arell (34:12):
Give me some examples of the unhealthiness of the
bureaucracies that need to behacked.
April Mills (34:18):
I think there's a great example of many teams in
an infrastructure which is notmodern.
Let's say the contrast point iswhat developers at Amazon can
do in terms of A-B testing orchecking in their code.
You'll find teams contrastedagainst, say, an Amazon delivery
(34:39):
schedule, but they're operatingwithout that infrastructure.
When they bring that up, theconversation is usually we have
to wait till the next budgetcycle, or we have to wait until
the next CIO onboards, or wehave to give it another quarter.
Teams are often left to go backto their work and wait.
(35:01):
Bureaucracy hacking might be tosay, okay, at the pace we're
currently going, we will catchup to the current state of the
industry in 50 years.
Are we comfortable with that?
If not, what can we do to carveout an investment here out of
budget cycle?
Or an allowance for this teamto either use a new tool that
(35:24):
actually works versus getting itbedded for the enterprise or
other small carve-outs thatmight turn into larger
system-wide changes, but smallinvestments are small carve-outs
so the teams can win versusbeing set up to lose slowly,
which leads to burnout.
Ray Arell (35:45):
Bureaucracies fight back, right?
If you push them, they push youback.
I'm curious what the mainin-road would be for doing some
of that work.
Beyond budgeting has been inexistence for decades, but it
doesn't get into the system, atleast US businesses.
April Mills (36:02):
Yes.
Rather than pushing against thebureaucracy because you will
lose, what I like to do is makestone soup.
Do you bring what you've got tothe table and ask a person in
that bureaucracy, hey, I'mlooking for a small partnership
with you.
If I bring my team willing totry new things, can you bring a
(36:25):
leftover portion of yourdevelopment budget to give us
some training?
I'm not asking for a whole newprogram to level up all
developers, but what could I doto partner with you so we could
get maybe these five into thisclass or get access to this
content?
Or can we be the test team forthis new tool within the
(36:49):
enterprise?
So you go looking to partnerand parlay versus attack and
defeat.
Ray Arell (36:57):
Okay.
April Mills (37:04):
And that's what we've seen with most successful
agile implementations that didsustain people saying, I'm
choosing to be agile.
How can I carve out a space foragility even in a rigid
bureaucracy?
And then how can I parlay thatbit of space for more and more
so that I can deliver at thepace I want to in a way which
(37:26):
makes me proud and energetic?
Caller 4 (37:28):
Jeffrey, what do you have on this?
Hello.
This has been a greatconversation so far.
I had the question and then itwas answered.
We've been talking from theperspective of the dev teams.
As any good agile person knows,we take the perspective of the
team.
But when it comes to burnout,my observations more with the
actual agile coach, scrummaster, the agile project
(37:53):
manager, the program manager.
And it's it's what we wasreally just was discussed
earlier about how do you infectchange.
When we go in these retros,you're asking someone else to
change, you're adding more totheir plate.
And then it's trapped almostlike two weeks later, why didn't
this change?
That's not exactly howorganizational change happens.
(38:16):
I find my fellow coworkers inthat space trying to physically
push through changes, buggingthe senior leadership with all
the complaints the team has, andjust trying to help the team,
but not being strategic at all.
In my experience, the bestpeople in Agile know how to
(38:36):
influence people.
They know how to influence thedecision makers.
They know how to focus on theone or two things that will have
the greatest impact rather thanfight 50 battles.
You're going to be so worn outand burnt out that you're not
going to be able to fight thebattles that you can win, that
you find value in.
(38:56):
So I find sometimes people inthe change influence
organizational world fight toomany battles rather than focus
on one or two and seeing thatout to completion.
Ray Arell (39:11):
I agree with you.
I've always had the philosophydon't take on the biggest,
ugliest thing first.
Take the thing that you canchange today and celebrate that.
Thank you for that advice.
Your hand went up.
What do you have?
Jorg Pietruszka (39:22):
Yeah, just to pick this question up because
it's highly interesting.
My first advice to any productowner, Scrum Master, coach,
don't distance yourself from theteam.
Be somehow part of it.
The closer the better.
You need to be vulnerable.
If the team sees that you areactually contributing a lot, and
(39:44):
I've seen a lot of productowners who are not telling the
team what they are doing inparallel to the work for the
team.
The team thinks they are justdoing these few stories for us
and they're not doing anythingelse in the rest of the day.
And that is really toxicbecause there's no appreciation.
But if you go in and say, I'veactually had a long discussion
(40:05):
with management, the outcome isI didn't move a step, I'm really
frustrated today.
Then people probably come upwith other ideas to solve the
problem.
You're no longer alone.
What really helps is if you'reworking with more than one team,
there's normally one team thatyou get more energy from, and uh
most likely they need yoursupport less than the others.
(40:28):
So keep the time with themreally precious and go there if
you have a hard time.
Enjoy the wins.
Go where the wins are.
That really gives you energy toa huge proportion.
And the the best thing is justbe as human as you can.
It invites a lot of help.
Ray Arell (40:44):
I like that.
But real quick, we have a fewminutes left.
Karen posted what what's yourown elevator pitch to IT
management in order to besuccessful with business
agility.
Any of the panelists want totake a stab at that?
April Mills (41:02):
I'll start.
I think so often inbureaucracies and corporate IT
tends towards bureaucracy, thatthe prioritization of what
matters most gets confused.
Managing to their budget,complying with some internal
decision about something getsoften in the way of delivering
(41:26):
greater value to the customer atthe lowest possible production
cost.
And so it's really key to notemphasize a change you want in
terms of team preference, but interms of impact on delivering
to the customer in the best way.
Ray Arell (41:43):
I agree with that.
I think it's the most importantthing.
How does this affect thebusiness's bottom line?
Sometimes agile teams aretalking points and velocities.
At the end of the day, it's thebusiness value that we've
delivered.
Changing the focus of theorganization to be more value
delivery focused versus a datehitting focus is one of the
(42:05):
biggest key factors to it.
And the other thing isexperimentation.
Sometimes we want to try this,and these are the parameters we
are looking at.
If it's successful, then we aregoing to scale it.
That also helps managementsometimes understand that it's
not going to be something thatwe're going to pull up all the
floorboards and not getsomething delivered.
(42:26):
We are at the top of the hour,and I'm getting sad now because
we have one more recordingsession left for the year.
That's going to be on Friday,November 28th.
I hope everyone can make it.
Aside from this, I want to letpeople know that I just accepted
a volunteer position as thesponsor chair for Agile Open
(42:47):
Northwest.
That's going to be happening in2026.
And I'm looking for sponsors.
And if you have any interest ingetting your company name and
backing support for this greatevent, it's one of the oldest
agile events that's out there.
Please contact me through NewAgility and let's get something
(43:09):
going on that because one of thethings I found with like these
nonprofit organizations sinceCOVID, I'm surprised that the
quality conference that Aprilspoke at used to be thousands of
people.
Now it's hundreds.
I want to see these events growback again, especially when
these nonprofit organizationsare focused on helping us.
Now we need to help thembecause it is all about
community.
So with that, I hope you guysall have a tremendous month.
Good morning and good evening everyone.
Welcome to the Agile CommunityNetwork.
This is episode 106.
Today we're gonna talk aboutdealing with agile burnout.
Just as a reminder, we arecommunity supported.
Please, if you have a chance,go up to acnpodcast.org and look
at our sponsors, reach out tothem, become members, whatever
(00:53):
it takes to thank them for theircontributions that make this
show possible.
And also the individualcontributors that go up to New
Agility and give us donations.
That helps us to pay for thewebinar system and all the other
things we need throughout theyear.
Speaking of that, we are cominginto the next year.
This is the second to the lastsession before 2026, which is
(01:16):
bizarre to think about that weonly have one more show beyond
this one left before the newyear.
If you go up there and take alook again on cnpodcast.org, we
could use your financialsupport.
We do have some doubt cominginto next year on what we are
expecting, and in order tocontinue to bring the show, we
do need your help.
I'm joined every month by someco-hosts that have been with me
(01:40):
for a long period of time.
Shauna, Diana, Jorg, SheilaEckhart, Sheila McGrath, April
Mills, and Hendrick here to getthe conversation going along
with all the people who callinto our Monthly Live event.
The goal is to hear from allperspectives.
If you're new to Agile or ifyou've been doing Agile for a
long period of time, all ofthose perspectives, we want to
(02:01):
hear those.
Be a part of the community, bea part of the conversation.
Dealing with agile burnout.
I was talking with a couple ofpeople about a month ago, and
they were dealing with the issuethat their team was not feeling
it any longer.
They weren't feeling the agilevibe.
They felt like they were juststepping in, and every day
(02:25):
seemed like the same old thing.
The pressure of delivery, theywere dealing with some breakdown
in the system with poorlyformatted backlogs.
The priority of things werechanging so rapidly, which by
the way, priority changing is apart of the nature of Agile.
One of the reasons why we haveiterative development is that we
(02:48):
sometimes need to changebecause the customers decide
that this might not be the rightpath.
If you amp that up, where itdoesn't seem like there's a
rhyme or reason for that changegrounded in customer need, and
it just seems like you'redeveloping things that nobody
seems to want.
That really starts to drag downteam morale.
Also, sometimes the ceremoniesthat we do, for example,
(03:12):
retrospectives, when you doretrospectives and put in a
whole bunch of things that needto be fixed and none of that
stuff gets fixed, that alsoleads to burnout.
So you find that even thoughthat you're going through,
you're not really leading thechange in the organization at
all.
It just feels stagnant.
The lack of stability can leadto the burnout of our
(03:33):
developers.
And there's a lot of differentways that this can be fixed.
This is where I want to hearyour guys' perspective.
But from my view, I think thatthere's always needs to be
somewhat somewhat of a refreshon Agile's core purpose.
Why are we doing Agile withinthe organization?
What are those values andprinciples that we want to
(03:54):
embrace?
And how do we accomplish thosewith the types of ceremonies and
tools that we have?
Needless to say that over timewe overcomplicate things.
It's human nature, I think,sometimes when we start putting
in processes, but we don't takethem out when we don't need them
(04:14):
anymore.
Also the sustainable pace.
I remember a sprint review onetime when we were doing Scrum
and we were at like sprint 70 orsomething.
And there's a point where teamsover time will lose stability.
The sustainable pace falls off.
There's real work to get theteam back into hitting the pace
(04:35):
again.
I'm curious, how do you createthat sustainable pace within
your organization?
And then just reconnecting withthe purpose itself.
Why are we developing thisproduct?
What where are those customersand what are the customers
giving us feedback on?
Nothing recharges a team betterthan hearing great things from
(04:55):
the customers.
And even sometimes hearing notsuch good things.
It's a way of stepping up andsaying, okay, here's the things
that we need to go work on.
So the questions for today, areyou seeing Agile burnout?
Have you seen it within yourorganizations or organizations
that you go in and help coach?
What are the signs that youlook at when say, okay, oh, this
(05:16):
team seems like it needs somehelp because they are hitting
that burnout situation?
What steps would you take tofix it?
What are the types of methodsor things that you would do as a
coach, manager?
I'm curious to hear what youwould do.
So to kick us off, Diana, doyou want to take a stab at this?
Diana Larsen (05:35):
Yes, of course.
And you brought upretrospectives as a major
contributor to burnout.
I do think that frustration ofholding a meeting, having some
conversations about all thethings that are wrong, and then
either not identifying anythingto fix or identifying something
(05:57):
to improve, and then seeing nofollow-through on it, or the
having no plan forfollow-through on it, or maybe
it's outside of your control, isfrustrating for the whole team.
I've seen retrospectives thatend up just being a list of
here's the things we learned andhere's the things we'd like to
(06:17):
change, or that we think weshould do differently.
Nothing further than that.
You end up with two lists, andthat seems like a big waste of
time to the team and to me.
Then there are the ones wherethey actually pick something to
move forward on, but there's noplan for moving it forward.
No team member steps forward tosay, I'd really like to own
(06:39):
this for us for this next sprintand see if we can't make some
improvement on it.
There's a lot of ways in whichthat gets stalled or stuck and
is frustrating and feels like awaste of time.
Anytime we feel like we'redoing something that's wasting
time, that's the path to burnoutthat really does move us in the
(07:01):
wrong direction, really.
One thing, one thing I want tomention is that Esther Derby and
David Horowitz and I havewritten a second edition to the
Agile Retrospectives book.
Please look for that becausethis is one of the issues we
have addressed that wasn'taddressed on the first edition.
(07:21):
And I'm going to also drop alink in the chat to an activity
called Circles and Soup.
It's in the second edition ofthe book, and you can find it in
other places on the web aswell.
This activity helps the teamidentify the source of their
difficulties and where thosemight come from.
(07:44):
Are they in the team's control?
Are they things the teamdoesn't control but might be
able to influence?
And are they things that arecompletely outside of what the
team can move on their own, givesuggestions about improvements
you can do wherever you start onthat?
And the recommendation isalways start with things that
(08:07):
are in the team's control.
And that they feel enthusiasmfor fixing.
So that's one part of it.
But I think the retrospectivealso is a great place to bring
up other signs of burnout thatyou're seeing in your team.
Here are some other things thatwe are feeling frustrated
(08:29):
about.
Here are some other things thatseem to be holding us back.
All those things that make usfeel like we're trying to move
forward and being blocked.
So making sure that you'reidentifying impediments when
they come up and so on.
But I definitely see Agileburnout on Teams all the time.
(08:53):
Another big source of it iswhen it's a scrum team and there
is a scrum master, and thatscrum master is also supposed to
act as the product owner.
They've got a doubleassignment, or vice versa.
(09:14):
They're the product owner andthey're also supposed to have as
a scrum master.
And what happens is that thatthose two roles have competing
goals.
Often things that the scrummaster should could be doing get
pushed to the side to add moreon the product owner side, or
(09:35):
vice versa.
And that creates confusion inthe team and gets in the way of
the team being able to do whatthey need to do.
So that's that's another thingto bring up in a retrospective
and talk about how can you, howcan the is that within the
team's control to make anadjustment?
(09:55):
Or is there some other partythey need to influence to say,
this way of organizing this teamis not working?
What can we do to fix it?
A lot of it has to do withhaving a team that has
psychological safety so that youcan bring up the fact that
we're beginning to feel burnedout, we're beginning the
(10:17):
frustration levels are gettingreally high in our team, and we
need to do something about it,or we're going to be broken.
Those are the top of my headcomments to make about it.
Ray Arell (10:29):
Do you all see not just the shared role with the
product owner and the scrummaster, but also where a
developer is not in just oneteam, they might be in multiple
teams.
Diana Larsen (10:38):
That's the multi-team assignments that you
know where you that kind ofmulticastking across work roles
is just all kinds of researchthat says why that I can't put
my hand on any of it right now,but there's a lot of it.
If you are assigned more than60% to a project, that's the
(11:01):
project that's going to getpretty much 100% of your
attention.
If you're assigned 30%, 30%,and 40%, there's so much waste
in the shift of focus that itimpacts anybody's ability to
perform well.
That builds in a lot of wasteinto the system.
(11:22):
However, somebody is beingsplit across teams, it it's a
problem.
Ray Arell (11:28):
Yeah.
I appreciate that.
I see all of those things, andthank you for those good
suggestions, especially the Ineed to get the next revision of
your book because I do want toread that section.
Scott, what do you have onthis?
Caller 1 (11:41):
I was running retrospectives with my team,
using ideas boards every twoweeks.
And the team wasn't reallyburnt out, but I looked at
myself in the mirror one daywhen I'm like, I'm being lazy.
This could be better.
I need to be better.
I bought Diana's book andstarted offering the team
different formats.
Then I started researchingactivities like journey lines
(12:05):
and moving motivators to keepthings fresh and offer new
things to the team.
The thing that I liked aboutdifferent retrospectives is it
asked the same kinds ofquestions but in different ways.
So it got the team thinking alittle bit differently about the
system that they worked inevery retrospective.
And it kept things fresh.
The other thing that I'vealways talked to the team about
(12:26):
is, especially in theretrospectives, inspecting and
adapting, continuous improvementand finding things that we can
iterate on to make things bettertomorrow than they were today.
Hopefully, if things aregetting better, teams are
feeling good about themselves,right?
Even looking at things likeyour definition done in team
agreements, not getting lazywith those as a scrum master or
(12:47):
a coach and being like, hey,look, every quarter at least we
got to, or somebody new joinsthe team, we got to look at
these things on a continualbasis and update them so they
don't get stale.
As things get stale in routine,that's when burnout starts.
I also like to review thehistory because when you work on
lots of small iterations tomake things better, teams
(13:10):
quickly forget they've doneanything and think they haven't
done anything.
So I like to take them back andsay, hey, six months ago, this
is where we were.
And over the last six months,we've improved this.
We've iterated on them, we'veimproved that, all towards
making life better for ourselvesso that we can offer more
quality in a more timely fashionto our customers.
(13:32):
Many times you're like, oh, Ididn't even think about that.
And the other thing too issometimes just have some fun.
I have in the past playedcahoots with a team every
sprint, take an hour out of asprint and play, do something
that's not work-related to tryto keep things light and
introduce some things thataren't just pounding away at
(13:54):
what's wrong.
Ray Arell (13:55):
I like all the suggestions and especially just
going off and having fun withthe team.
I think sometimes when we lookat the daunting backlogs, we we
don't realize that we begin toslow down.
And in order to speed back up,we might just need to take a
break.
So that's thank you for allthose suggestions.
Jorg Pietruszka (14:18):
Yeah, multiple thoughts on this.
Sometimes it's as was mentionedalready by Scott, a bit it's a
bit of if you're doing the samething over and over again.
People feel that the energy putinto them as support or
anything is missing.
Grab the opportunities to dosomething different.
Especially now with Christmastime, instead of looking back
(14:41):
and improving, look forward andask what's the best improvement
we need to scale that mountainthat's ahead of us.
Or when the product owner isnot present at the retrospective
and is welcome, use that totalk about his contribution and
make it a recognition of hiscontribution to the team, what's
good.
You can then add improvementsto make his life easier or
(15:05):
whatever.
So that that's definitely onething.
And then looking from thepersonal point of view for
satisfaction with what you'redoing, you need some kind of
autonomy.
If you're not in control ofyour fate as a team, that's the
first thing to change, then youneed mastery, which means you
still want to improve on thetechnical side.
(15:27):
If you're doing everything thesame way every day and there's
no new technical challenge,that's as damaging as you can't
do your work because you don'thave the knowledge.
So that you you might need toadd some diverging
responsibility, differentperspective on the technical
side as well.
And then last but not least,there's purpose.
(15:49):
Bring in people to the team whotell them why their work
matters, for whom it matters andwhat the contribution is.
Do it as often as possible andas emotional as possible.
And that's one thing that I useto detect if a change is
definitely needed.
That's if emotions helps out ofthe team.
If there's no laughing, joking,or even frustration, then
(16:15):
something is definitely amissbecause we we're not
automatants, we're not justdoing our work going home.
We are spending a lot of timewith all those people.
So there needs to be a bit ofhuman element there as well.
In my very first company, theappraiser question that was to
be asked, among five others, areally significant one, brings
(16:35):
humor to the team.
And everybody needed to provideexamples, how they positively
did this because this is soenergizing and so positive.
That's my last tip.
I think I picked it up fromDarius, maybe he's here.
It's the happiness meter thatask people how happy do you feel
about the job, about the teamperformance, how willing are you
(16:56):
to work just on a scale of oneto five.
If that degrades, then it's awarning sign that something
might be wrong.
And it's a great conversationenhancer if you have trust in
the team, because then peopleand I've happy to say I had that
happen, step on and say, I'mreally feeling bad this week for
(17:18):
that and that reason.
So bear with me if I'm notreally constructive today.
And as long as they deal likethis with such a situation, it's
really helpful.
If they keep it to themselves,it's dangerous.
Ray Arell (17:31):
Those are good points.
What are some examples of newtechnical challenges that you
deal with?
Jorg Pietruszka (17:37):
For my people doing really low-level software
on controllers, it's reallygetting all that data used
somehow so they can play andthey are not challenged directly
for the direct work becausethey still need to make these
devices work in a ratherconstraint-specified form.
But learning from what they doand how the things work to
(17:59):
improve it is something wherethey can be really creative and
have a Hoi Rika moment just togive an example.
Ray Arell (18:08):
Also, one of the other things on sustaining work,
where you just have to sustainthe product.
I've seen companies thatthey'll just create a team that
does the sustaining work, andthen there's other teams that do
all the new cool stuff.
Do you not recommend creatingthe sustaining team?
Does that work shared witheveryone?
Jorg Pietruszka (18:27):
Yeah, I believe in what you do your own.
Normally, if you know there's ateam that will iron out the
last bug, you will leave muchworse things behind, unless you
have a really high respect.
There are some situations whereyou get a lot of stuff incoming
to have it pre-sorted by peoplejust learning the system.
So as a transitionary state, itcan be very helpful.
(18:51):
As a stable state, fixing otherpeople's stuff is a is a skill
and a capability.
So if you have people whoreally excel in this, that might
be something but you need tohire for and build a team and
praise it.
And they probably then need tobe the service organization's
(19:11):
technical backbone.
So they're no longer really inresearch and development.
But in another role, businesssustainability would probably be
a thing to really value whatthey do, but don't get low-paid
people to fix the bugs of thehigh-paid people.
That I think is ratherdisrespectful, especially for
(19:31):
their learning, because you byconstruct of the teams don't
want to elevate them to the nextlevel, which is probably rather
stupid.
Ray Arell (19:41):
I appreciate that.
Kyle.
Or I may not be pronouncingKyle.
You did great.
Okay.
Caller 2 (19:49):
It's smoke Hill, but it's pronounced Kyle.
Any of our German friends mightknow much exactly how it's
pronounced.
I just wanted to share a coupleof things on this topic.
I've presented a number oftimes locally in my area around
this issue.
One of the things that I don'toften hear other people share is
focusing on, for lack of abetter term, the scope of the
retro.
A lot of times we get into aretrospective meeting and we're
(20:12):
focused on the last break.
But teams have issues that areoutside of the work of the last
two weeks.
Occasionally I'll have aretrospective where we cover
either a longer period of timeor focus on a specific area of
the work that we're doing.
One of my favorite ones is justto ask the team if you had a
magic wand and could fixanything about the organization,
(20:34):
what would that be?
We talk about that.
One of my favorite examples isto share that my organization,
the team really wanted us toimprove the development
environment.
But in order to do that, it'san organizational-wide problem.
And so we set off afteridentifying that as the key
problem and we worked at it forabout a year.
After about a year, everybodywas on board and we upgraded the
(20:56):
development environments.
Everything went smooth.
The team was really energized,but uh so that's one of the
things we focus on.
One of the things I've done toenergize team members is to loan
a team member out.
Sometimes there's another teamyou're familiar with, and
they're struggling with and theycan use a boost.
And you loan that team memberout maybe for a sprint, but
usually I try something a littlebulker.
(21:17):
The team member has to be onboard with this.
By doing that, they getexposure to different ways of
working.
When they come back to yourteam, they come back with new
ideas, which can be energizing.
Loaning a team member out maynot work in every situation or
for every organization.
That's just another way to keepthings fresh and keep momentum
going and getting new and freshideas coming back to the team.
And now in your role, what doyou do?
(21:39):
I'm an agile coach.
I've been an agile projectmanager, agile scrum master, but
most recently just an agilecoach organization called
NellNAT, which does do the loanservicing pressing.
Ray Arell (21:51):
Do you find that for your own coaching, rotation is
also important?
Caller 2 (21:56):
Yeah, in fact, one of the things that we and I was I
was on a team with two otherpeople, one of the things that
we do is set a limit on thecoaching engagement we're
working on.
When that limit gets hit, weget together a team and say,
okay, should we still work withthis team or do is it time to
change things up?
We have goals for everything.
When those goals come out forteam, maybe you're gonna finish
(22:18):
that coaching relationshipbecause the team's passed what
they needed to do for.
Or maybe you're gonna shiftthem to another coach because
that coach brings you.
Ray Arell (22:26):
Yeah, no, I love that because I do believe it's the
same thing with like leadership,any type of leadership, knowing
what your skills are andknowing that you might not be
the right person to fix thatissue or to help.
An important part of coachingis understanding that I'm not
the right person to work onthis, but I know the person.
And we let's get them in.
Caller 2 (22:47):
Yeah, I think burnout's about the rut, a lot
of times.
You're just in a rut.
And identifying what that rutis probably the best first out
and trying to make thingscrashy.
Ray Arell (22:57):
Tully agree.
Yeah.
Sheila, what do you have onthis?
Sheila McGrath (23:02):
I think most of the teams I've worked with have
been working with other teamsthat were not agile at all.
So some of it is the challengeof finding a way that doesn't
interfere with the team's goals.
A lot of times it's teachingthem how to interact with these
teams themselves rather thanhaving to escalate everything to
(23:25):
management, understanding whatthe other team's priorities are
requires some conversationswithin the team and with
management to figure out how towork more effectively.
Another thing that I keeprunning across is it used to be
that you'd have a scarceresource in somebody who knew
old mainframe systems that youhad to interface with.
(23:46):
But now there's so many newtools out there that you wind up
with someone or two people whohave the expertise in a newer
tool, and they get spread acrossevery project there is.
And there isn't really any wayto avoid that until you get
other people up to speed.
One of the tricks is to getmanagement to allow time for
(24:09):
knowledge sharing that's notspecifically project related.
That can be very motivational.
Another thing that keepshappening every place I've been
is meeting burnout.
You need to have some period oftime blocked off where you say,
no meetings in this time frameunless someone on the team
(24:31):
schedules it themselves.
It can't be something organizedbetween teams or by management
to give them some focus time toactually work.
The other thing that I seehappen is people sometimes
estimate higher consistently.
(24:52):
Like they try to estimate threetimes the amount of time that
they're actually going to needbecause they know management's
gonna cut whatever they're givenand say you have to deliver by
this date, whether it makes anysense or not.
And trying to get management,especially product management,
to listen.
If you want a product that'sviable, you really have to give
(25:16):
us time to develop it if it'ssomething new.
If it's just little tweaks andbells and whistles, then maybe
that'll work.
But if you're really bringingsomething new to market, you
really have to not try todictate the time frame, which is
really hard when you're tryingto organize marketing campaigns
(25:37):
and make sure that customer careis ready, to not be able to
plan way in advance and justsay, okay, in six months we're
going to do this and make it animmovable date where you're
going to bring something outthat nobody's going to be proud
of if you're not careful.
That's really a mindset thatyou have to change with
management, internal to ITmanagement, but also at the
(25:59):
enterprise level, you need tomake sure that the enterprise
understands what agility means.
Those are the things I thinkabout.
Ray Arell (26:08):
So I'm curious along the line of deadlines.
To me, deadlines exactly as theword says, it's a deadline.
If we don't get it out there bythis date, we won't have a
product we won't eat.
How do you push back on that?
How do you discover whether thetime frame is arbitrary or made
up?
How do you combat that withinorganizations?
Sheila McGrath (26:33):
Sometimes it's not movable.
If it's something likeregulatory deadlines, you must
have this in place becausethere's a rule that takes effect
then.
Or you have a product that'sgoing to hit this condition, and
the development to support theproduct kept getting stuck in
the backlog and wasn't gettingdone.
(26:54):
And now you have a deadline.
In one case, someone high up inthe organization had gone out
and said, by this date, we willhave this product on the market.
And it was a new product withnew functionality, different
than anything they had donebefore.
Now the credibility of theorganization is on the line
because somebody spoke about itpublicly before they asked if it
(27:17):
could be done.
And that can turn into a deathmarch where you have to say,
okay, you said that we must haveit by this date.
Therefore, you must supportgiving us the resources to get
it done by this date.
Can you even find the people todo it if there truly is an
immovable date?
Sometimes you can, sometimesyou can't.
And then you have to set up howare we going to triage the
(27:40):
problems that we're going tohave because we didn't have
adequate time.
And what are we going to do tofix it?
How are we going to prioritizewhen we know we're going to have
more problems than we wouldlike and the product's not going
to be as clean as we would wantit to be.
And then you just have toeducate management about what
it's going to look like whenthey're going to get customers
(28:01):
complaining that problemswouldn't have been there if
they'd allowed us more time todevelop.
Ray Arell (28:06):
And that's the quality triangle, right?
Quality cost and time.
Something's got to give one wayor another.
One of the ways I deal with itis that the data is showing us
that we're not going to hitthat.
We need to reduce scope.
What I find a lot of times isthe must-haves.
A lot of these things are notmust-haves.
They were just someone had awhim that they thought that was
(28:28):
going to look good on a sheet orbecause the competitor had it,
but no one uses it.
So that's always a challenge.
Let's see, Isin, what do youhave on this topic?
Caller 3 (28:37):
Yes.
So for me, it's the one of thebiggest thing is the team
dynamics that I've seen to causeburnouts.
If you have a bunch of peopleworking together that don't gel,
have different approach tothings, it can lead to very
difficult conversations.
And I think Agile justbasically put that under the
microscope just because itrequires a lot of collaboration
and teamwork.
(28:58):
It turns what could be minorissues into a bigger problem if
people have to interact everyday and don't get along.
To me, one of the examples, forexample, the sustaining
engineering guy was brought upearlier.
I've I've was VP of engineeringfor a while.
Big, I don't know, agile guyfrom the VP level, from the
engineering side.
Trying to build the sustainingengineering team, I had to
(29:21):
basically ask the question whowants to be on that team.
Sometimes it worked out well.
Sometimes you have people thatwant to run it the same way it
runs for new features using thesame processes that cause issues
with the team members.
I think this is one of the bigones I had to keep an eye on,
evaluate the teams, see how wellthey're doing as a unit and how
(29:42):
they could improve, helpingthem either to improve or change
if needed.
Ray Arell (29:46):
What's your role in your company?
Caller 3 (29:48):
I'm a co-founder for a small startup, two people, but
I ran the engineering for 10years before that.
Ray Arell (29:55):
Okay.
I'm curious.
I've seen a downturn ininvestments of training people
post-COVID.
A lot of companies are saying,if you're going to go learn
that, go learn it yourself.
We're not going to make thatinvestment.
Do you think that's a badchoice by companies not to make
those investments?
Caller 3 (30:12):
I just came from a VP of engineering group where they
were talking about AI and howthey approached their teams
about encouraging their teams touse it.
I asked Do you guys train themon how to use AI?
How does it help a juniorengineer to a senior engineer?
All looked at me like notreally.
I'm finding that to be less andless, and I don't know if AI is
causing some of these issues,but for some reason there's not
(30:35):
a lot of investment in thatarea, money-wise or effort-wise
by leaders.
Ray Arell (30:40):
Yeah, I think it's a dangerous if you get to go to an
external class someplace.
That's one way of combatingburnout because you're learning
a new skill.
The AI stuff, I think you'reright.
You hear it on YouTube all thetime.
They call the AI slop of peoplejust producing something but
(31:01):
have the AI just do it.
I know some people in DevOpsorganizations who are doing
nothing more than having to gofix AI code because that's all
the junior developer checked in.
They just got the result fromthe AI system.
They didn't do any refactoringthemselves.
They don't even understand thecode.
And yeah, I think that's a hugechallenge.
So tell us just a little bit, aplug for your business.
(31:23):
What's your founder?
Congratulations.
What are you, what do you whatare you going to do?
Caller 3 (31:30):
I'm building an AI-powered agent for agile and
delivery coaching.
Our goal is to help agilecoaches scale in organizations.
What I've seen, and I'm prettysure a lot of you guys have seen
it, is teams or companies hirevery little number of coaches
compared to the numbers teamsthat they want covered.
We're hoping that the AI couldhelp get them the visibility,
(31:51):
help them push.
Like one of our first virtualbuilding is helping the team to
prep and run stand-ups and givethem coaching after.
Look at the data they need tocover about the risk, anything
that they have.
And then when they have theconversation, try to give them
feedback on how the conversationwent and what they should have
covered better or not.
Ray Arell (32:11):
Oh well, interesting.
As long as it doesn't replaceagile coaches, I'm on board with
it.
Caller 3 (32:17):
It is definitely one of my mission is not to do that,
but in instead to help themcover.
Because I don't believe anagile coach could be at every
stand-up, at every planning,every meeting that the team is
having.
And they could actually coachus to coach them and they could
be part of the conversation.
Ray Arell (32:32):
Thank you for that.
April, congratulations on yourkeynote.
April Mills (32:38):
Thank you.
It was a great time at thesoftware quality conference in
Portland last week.
Ray Arell (32:44):
What do you have on this subject?
April Mills (32:47):
I've been focusing a lot lately on the environment
the teams are in and the thingsthat the teams are running into
outside of the developmentprocesses.
One of the things that oftenwears out teams, it's the lack
of the tools or resources orinformation they have.
The reason they strugglewithout standard tools is
(33:10):
because of the largerorganizational bureaucracy.
I've been focusing on how tohelp bureaucracy hack, as I call
it, to help get the teams whatthey needed to be effective.
I think one of the cruelestthings I've seen over the decade
I've been in this agile spaceis the mounting expectations on
(33:32):
teams and the decline intraining, the decline in
training investment, the declinein infrastructure investment,
with those mountingexpectations.
I'm trying to focus a lot onhow to help burnout by how to
help teams understand how theycan hack the bureaucracy to get
the training, the infrastructurethey need, how to help leaders
(33:55):
understand that just asking theteams to go faster and hoping
that AI will somehow fix thethings they've been avoiding all
these years is not the path tosustainable, high-quality
products and services.
Ray Arell (34:12):
Give me some examples of the unhealthiness of the
bureaucracies that need to behacked.
April Mills (34:18):
I think there's a great example of many teams in
an infrastructure which is notmodern.
Let's say the contrast point iswhat developers at Amazon can
do in terms of A-B testing orchecking in their code.
You'll find teams contrastedagainst, say, an Amazon delivery
(34:39):
schedule, but they're operatingwithout that infrastructure.
When they bring that up, theconversation is usually we have
to wait till the next budgetcycle, or we have to wait until
the next CIO onboards, or wehave to give it another quarter.
Teams are often left to go backto their work and wait.
(35:01):
Bureaucracy hacking might be tosay, okay, at the pace we're
currently going, we will catchup to the current state of the
industry in 50 years.
Are we comfortable with that?
If not, what can we do to carveout an investment here out of
budget cycle?
Or an allowance for this teamto either use a new tool that
(35:24):
actually works versus getting itbedded for the enterprise or
other small carve-outs thatmight turn into larger
system-wide changes, but smallinvestments are small carve-outs
so the teams can win versusbeing set up to lose slowly,
which leads to burnout.
Ray Arell (35:45):
Bureaucracies fight back, right?
If you push them, they push youback.
I'm curious what the mainin-road would be for doing some
of that work.
Beyond budgeting has been inexistence for decades, but it
doesn't get into the system, atleast US businesses.
April Mills (36:02):
Yes.
Rather than pushing against thebureaucracy because you will
lose, what I like to do is makestone soup.
Do you bring what you've got tothe table and ask a person in
that bureaucracy, hey, I'mlooking for a small partnership
with you.
If I bring my team willing totry new things, can you bring a
(36:25):
leftover portion of yourdevelopment budget to give us
some training?
I'm not asking for a whole newprogram to level up all
developers, but what could I doto partner with you so we could
get maybe these five into thisclass or get access to this
content?
Or can we be the test team forthis new tool within the
(36:49):
enterprise?
So you go looking to partnerand parlay versus attack and
defeat.
Ray Arell (36:57):
Okay.
April Mills (37:04):
And that's what we've seen with most successful
agile implementations that didsustain people saying, I'm
choosing to be agile.
How can I carve out a space foragility even in a rigid
bureaucracy?
And then how can I parlay thatbit of space for more and more
so that I can deliver at thepace I want to in a way which
(37:26):
makes me proud and energetic?
Caller 4 (37:28):
Jeffrey, what do you have on this?
Hello.
This has been a greatconversation so far.
I had the question and then itwas answered.
We've been talking from theperspective of the dev teams.
As any good agile person knows,we take the perspective of the
team.
But when it comes to burnout,my observations more with the
actual agile coach, scrummaster, the agile project
(37:53):
manager, the program manager.
And it's it's what we wasreally just was discussed
earlier about how do you infectchange.
When we go in these retros,you're asking someone else to
change, you're adding more totheir plate.
And then it's trapped almostlike two weeks later, why didn't
this change?
That's not exactly howorganizational change happens.
(38:16):
I find my fellow coworkers inthat space trying to physically
push through changes, buggingthe senior leadership with all
the complaints the team has, andjust trying to help the team,
but not being strategic at all.
In my experience, the bestpeople in Agile know how to
(38:36):
influence people.
They know how to influence thedecision makers.
They know how to focus on theone or two things that will have
the greatest impact rather thanfight 50 battles.
You're going to be so worn outand burnt out that you're not
going to be able to fight thebattles that you can win, that
you find value in.
(38:56):
So I find sometimes people inthe change influence
organizational world fight toomany battles rather than focus
on one or two and seeing thatout to completion.
Ray Arell (39:11):
I agree with you.
I've always had the philosophydon't take on the biggest,
ugliest thing first.
Take the thing that you canchange today and celebrate that.
Thank you for that advice.
Your hand went up.
What do you have?
Jorg Pietruszka (39:22):
Yeah, just to pick this question up because
it's highly interesting.
My first advice to any productowner, Scrum Master, coach,
don't distance yourself from theteam.
Be somehow part of it.
The closer the better.
You need to be vulnerable.
If the team sees that you areactually contributing a lot, and
(39:44):
I've seen a lot of productowners who are not telling the
team what they are doing inparallel to the work for the
team.
The team thinks they are justdoing these few stories for us
and they're not doing anythingelse in the rest of the day.
And that is really toxicbecause there's no appreciation.
But if you go in and say, I'veactually had a long discussion
(40:05):
with management, the outcome isI didn't move a step, I'm really
frustrated today.
Then people probably come upwith other ideas to solve the
problem.
You're no longer alone.
What really helps is if you'reworking with more than one team,
there's normally one team thatyou get more energy from, and uh
most likely they need yoursupport less than the others.
(40:28):
So keep the time with themreally precious and go there if
you have a hard time.
Enjoy the wins.
Go where the wins are.
That really gives you energy toa huge proportion.
And the the best thing is justbe as human as you can.
It invites a lot of help.
Ray Arell (40:44):
I like that.
But real quick, we have a fewminutes left.
Karen posted what what's yourown elevator pitch to IT
management in order to besuccessful with business
agility.
Any of the panelists want totake a stab at that?
April Mills (41:02):
I'll start.
I think so often inbureaucracies and corporate IT
tends towards bureaucracy, thatthe prioritization of what
matters most gets confused.
Managing to their budget,complying with some internal
decision about something getsoften in the way of delivering
(41:26):
greater value to the customer atthe lowest possible production
cost.
And so it's really key to notemphasize a change you want in
terms of team preference, but interms of impact on delivering
to the customer in the best way.
Ray Arell (41:43):
I agree with that.
I think it's the most importantthing.
How does this affect thebusiness's bottom line?
Sometimes agile teams aretalking points and velocities.
At the end of the day, it's thebusiness value that we've
delivered.
Changing the focus of theorganization to be more value
delivery focused versus a datehitting focus is one of the
(42:05):
biggest key factors to it.
And the other thing isexperimentation.
Sometimes we want to try this,and these are the parameters we
are looking at.
If it's successful, then we aregoing to scale it.
That also helps managementsometimes understand that it's
not going to be something thatwe're going to pull up all the
floorboards and not getsomething delivered.
(42:26):
We are at the top of the hour,and I'm getting sad now because
we have one more recordingsession left for the year.
That's going to be on Friday,November 28th.
I hope everyone can make it.
Aside from this, I want to letpeople know that I just accepted
a volunteer position as thesponsor chair for Agile Open
(42:47):
Northwest.
That's going to be happening in2026.
And I'm looking for sponsors.
And if you have any interest ingetting your company name and
backing support for this greatevent, it's one of the oldest
agile events that's out there.
Please contact me through NewAgility and let's get something
(43:09):
going on that because one of thethings I found with like these
nonprofit organizations sinceCOVID, I'm surprised that the
quality conference that Aprilspoke at used to be thousands of
people.
Now it's hundreds.
I want to see these events growback again, especially when
these nonprofit organizationsare focused on helping us.
Now we need to help thembecause it is all about
community.
So with that, I hope you guysall have a tremendous month.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
Crime Junkie
Does hearing about a true crime case always leave you scouring the internet for the truth behind the story? Dive into your next mystery with Crime Junkie. Every Monday, join your host Ashley Flowers as she unravels all the details of infamous and underreported true crime cases with her best friend Brit Prawat. From cold cases to missing persons and heroes in our community who seek justice, Crime Junkie is your destination for theories and stories you won’t hear anywhere else. Whether you're a seasoned true crime enthusiast or new to the genre, you'll find yourself on the edge of your seat awaiting a new episode every Monday. If you can never get enough true crime... Congratulations, you’ve found your people. Follow to join a community of Crime Junkies! Crime Junkie is presented by audiochuck Media Company.