November 8, 2024 • 41 mins
What if mastering the art of Agile could transform your team's dynamics and boost productivity? Join me to uncover the insights of Gary Evans, a seasoned Agile Coach, Scrum Master, and author of "The Effective Scrum Master." Gary shares his journey of over thirty years in Agile methodologies and reveals the inspiration behind his latest book, filling crucial gaps in current Scrum Master literature. Tune in to explore his unique perspective on the evolving role of a Scrum Master and grasp practical guidance on navigating technical challenges and resolving conflicts within teams.
Discover the intriguing personas that Gary introduces—the Sherpa, Shepherd, Sheepdog, and Diagnostician—which illuminate the multifaceted role of a Scrum Master. These personas serve as a framework for understanding the journey from novice to expert, driven by experience, experimentation, empathy, and empowerment. Gary underscores the importance of community, humility, and mentorship in the path to becoming an effective Scrum Master. Through personal anecdotes, he illustrates how nurturing leadership and fostering self-reliance can empower Agile teams to thrive.
Join the conversation as we dissect the balance of authority and empathy required to protect and nurture Agile teams effectively. Gary candidly shares experiences that echo familial protectiveness, such as defending teams against unreasonable demands while maintaining sustainable work practices. By embracing both the nurturing and protective qualities akin to a shepherd and sheepdog, Scrum Masters can ensure their team's well-being and productivity.
Connect with Gary on LinkedIn:
linkedin.com/in/gary-k-evans-72167
Check out Gary's Book, "The Effective Scrum Master":
https://www.amazon.com/dp/098830113X
Visit Gary's website and subscribe:
https://www.effectivescrummaster.com/
When in Columbia, SC visit Lake Murray and the South Carolina State Museum:
https://www.lakemurraycountry.com/
https://scmuseum.org/
Follow us on LinkedIn:
https://www.linkedin.com/company/the-agile-within
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Mark (00:06):
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Well, hey there, I hopeeveryone is having an absolutely
fantastic day today.
I'm Mark Metz, your host at theAgile Within, and I have a
guest today by the name of GaryEvans.
(00:49):
Gary, welcome to the show.
Gary (00:52):
Mark, thank you very much.
I appreciate what you'veoffered here.
Mark (00:57):
It's great.
So, gary, you and I have knowneach other for quite some time.
I was working as a developerand when I got in touch with you
and you were given sometraining classes, you and I have
kind of stayed in touch hereand there.
It kind of helps that we livein the same city, so we're
geographically close together,but it's good to have you here
(01:17):
on the show.
Gary (01:18):
Well, I appreciate that and I guess it is unusual to
have someone from the same cityin which you live.
But we have stayed in touch andI remember those days.
It was a lot of fun back thenand it was a lot of fun.
Mark (01:30):
So, gary, you and I both are located in Columbia, south
Carolina.
Not only that, but even closer,by the same suburb of the city.
So Irmo, south Carolina, is inthe northwest corner of Columbia
.
So, gary, as our normalicebreaker question, if I were
coming to Columbia for a day andhad never been there before,
(01:54):
what's one thing that you wouldsay that I couldn't miss doing?
Gary (01:58):
Well, that's interesting.
I don't get around much inColumbia but, however, if people
were coming here, I wouldreally recommend first that they
go to Lake Murray, which is oneof the largest man-made
reservoirs, if you will.
It's a huge lake, all kinds ofboating, sports and fishing and
all those types of things, andsecondly, we have a great museum
(02:21):
here.
The State Museum for SouthCarolina is located here in
Columbia, South Carolina, andkids love it and adults get a
big kick out of it.
It's really quite impressive.
So I cheated I gave you two.
Mark (02:36):
That's great.
Well, hopefully I won't get abill for the second one, so I
appreciate that.
Gary, I can attest that I loveLake Murray and also love going
to the museum.
Those are both great places togo.
Well, I want to introduce Garyto our audience here.
So Gary is an agile coach, ascrum master, a developer and an
(02:57):
author, and he has over fourdecades yes, four decades of
experience in softwaredevelopment and delivery, and
that includes three decadestotally dedicated to agile
methods.
So very, very happy to haveGary here and we're going to
talk a little bit about his bookthat he has released and it's
called the Effective ScrumMaster.
(03:18):
And, gary, I've been goingthrough this book and I found it
absolutely fascinating.
It's over 450 pages.
It's a book that you can use.
You can read from cover tocover and then, when it's done,
it's a great reference to fallback to where you have certain
situations may presentthemselves and you're like gosh,
I don't know, I haven't beenthrough this before.
(03:40):
I need some guidance.
You can just go straight to thebook, go to that chapter, and
Gary's got some great advice andsome steps to walk through for
that.
So, gary, this book, theEffective Scrum Master I want to
ask you first of all, based onthe title, is this exclusively
for Scrum Masters?
What?
Gary (03:58):
a great question.
The answer is no.
I focus on the Scrum Masterrole in the entire ecosystem of
an Agile team, and I have entirechapters, multiple chapters, on
the product owner role, as wellas the developer role that is
defined in the 2020 Scrum Guide,which includes not just
(04:20):
developers, but testers anddatabase analysts and all of
that.
So it's really not just for,but testers and database
analysts and all of that.
So it's really not just forScrum Masters, but I use that
role as the focus forunderstanding how the team
should be operating and how theScrum Master can help the entire
team, including helping theproduct owner write stories, and
perhaps we could cover thatlater.
Mark (04:41):
It's a very important topic, I would agree.
I want to know, gary, what wasyour inspiration for writing
this book, because, like I say,it's over 450 pages, so there's
lots of information in there.
Can you talk to us about whyyou wrote this book?
Gary (04:56):
That's interesting, I'll share with you.
The first two books that Iwrote are non-technical books.
I eased into those.
However, this one, I actuallyhad an epiphany.
I was reading another ScrumMaster book that came out a few
years ago and at the end of that, when I was finished reading it
, I said I could have writtenthis book.
And then it suddenly hit me Ishould have written this book
(05:21):
and at that point I committedthat I was going to take
everything that I had learnedover the previous multiple
decades of working with agileteams iterative development,
scrum, extreme programming,kanban all of this I was going
to put it together to share asmy legacy for our agile
community.
And really it came from readingthat one book, which is a pretty
(05:43):
decent book, but it left out somuch.
And so many of the Scrum Masterbooks talk about the soft
skills, but they don't get intoreally detailed issues of should
a Scrum Master be technical,should a Scrum Master not be
technical, how should they dealwith conflict when you have
somebody who cannot be saved andhow do you vote them off the
(06:06):
team All of these issues thatare really very sensitive.
They were missing from all ofthe Scrum Master books that I
read, so I decided to write myown.
That's how it happened.
Mark (06:18):
Well, I'm glad you did, because the way I look at it is
I look at the Scrum Guide thatis out there that the 2020 is
the latest version that KenSchwaber and Dr Sutherland wrote
, and it's absolutely fantastic,and it's only 13 pages, so it's
very digestible.
But the one thing is it's sobroad and so open.
(06:38):
I don't know where to start.
I don't have any guardrails.
The world was too big.
It was like I was a toddler andI was immediately given access
to the entire house.
I could approach the stairs, Icould go outside, I could open
cabinets that may have things inthere that could hurt me, and
(06:59):
really didn't have anyinformation that would help me
from doing things that wouldharm me, and so that's why I
like your book.
It really provides a lot ofcontext around the Scrum Guide
to help Scrum Masters andproduct owners and the
development team to guide them.
Gary (07:16):
You've touched on a topic that when I was at Bank of
America rolling out Agileworldwide for the bank, this
issue came up in our team.
Do we provide guard rails andguidance for new teams or do we
let them flounder until theyfinally figure out what to do?
And we had some spiriteddebates about that, and this
(07:36):
goes on even in the rest of thecorporate world.
The reason I wrote the book theway that I did I wanted to give
people guard rails and guidancewithout giving them an either
or.
I didn't want to say you haveto do it this way or you're
going to fail.
I wanted to give them contextand some starting points so that
they could understand oh, isthat how you run a refinement
(07:58):
session?
Oh, okay, now I understand whatmy goals are.
Because the Scrum Guide isextremely abstract.
It doesn't go into how you dothings.
It tells you what you need todo, but not how to do it.
I just wanted to comment onthat because that particular
question that you raised.
I've seen so many teams thathave been hurt by Scrum Masters
(08:19):
who didn't know where to startor, even worse, where to end.
Mark (08:24):
Scrum.
Gary (08:24):
Master didn't understand the limitations on his or her
scrum master role, and there aresome very distinct limitations,
but they're all context-based.
I just wanted to make thatcomment and that's why the book
is written the way that it is sowhen you say context-based,
that really means it depends.
It depends.
If you've got a new team ofnothing but introverts, you're
(08:55):
going to work with that teammuch differently than you will
with an experienced, mature teamof extroverts.
You've got to deal with thepeople first and the process
comes second.
And that doesn't come out ofthe Scrum Guide.
The Scrum Guide really doesn'ttalk about people.
Mark (09:07):
One of the sections in your book that I really liked
and I had this highlighted wasthat you have agility.
Not agile is the goal.
Talk to us about that, gary.
Gary (09:21):
Agile has become a commodity, mark.
You've seen this.
You've been doing this aboutfive, six years and you have
seen that agile has becomecommoditized.
We have certification millswhere people get a certification
after two days and they thinkthey can actually do something,
and they don't yet understandtheir inability to address some
(09:44):
of the nuances.
If we focus on agility, theability to pivot when we need to
, the ability to constantlyevaluate from a medical
perspective consider you'reworking with a patient who's
injured.
You want to constantly measuretheir vital signs and you will
then make, based on thoseconstant measurements along the
(10:04):
way, you will decide oh, theblood pressure is dropping, I
need to do something.
But you only know that afteryou've been working with that
patient for a while.
You need the ability to pivot,not to take something again
where I sound like I'm pickingon a scrum guy, not to take some
paragraph from the scrum guideand say that's the one true way
(10:33):
to do this.
There is a one true way.
In truth.
You don't have to do stand-upsto be agile.
You don't have to do stories tobe agile.
If we focus on agility, you caneven be agile in the sense of
embracing agility, even in awaterfall project, even be agile
in the sense of embracingagility, even in a waterfall
project, if you approach itcorrectly.
So these are often consideredto be similar because they have
the same root word, agile, butin terms of practice and
(10:54):
implementation they're reallyquite different.
Mark (10:57):
You mentioned.
Do you really have to even havea stand-up to be agile?
I had a team with a group ofpeople that worked really well
together.
They just really enjoyedworking with each other.
They understood each other,they knew how to challenge each
other.
And, gary, they wereessentially mob programming
(11:21):
eight hours a day.
They just enjoyed that style.
And so they challenged me andthey asked why do we need a
daily scrum or a standup ifwe're meeting eight hours a day?
And I had to.
I had to ask myself, well,what's the purpose of the of the
daily scrum, cause it's not toreport to me.
(11:42):
So I understand the daily scrumis for you, the team, so that
you are aligned.
If you feel like you're fullyaligned, then maybe we don't
need it after all, and that wasa lesson that was taught to me
that day.
Now I haven't coached a teamlike that since then, so that
was probably an exception to therule.
But that is to say that thisteam was very, very close,
(12:06):
working together and were ableto work out all those
dependencies, all those blockers.
They were able to do that inreal time, as opposed to waiting
to sync up at some point 24hours away from each other.
Gary (12:20):
That is such a great story because you responded to the
reality rather than aprescription.
You haven't had another teamlike that, meaning that all
teams are different and, as aScrum Master, we need to be
sensitive to those people.
Issues in the teams, becauseteams as a whole have
personality, in addition to thepersonality of the individuals.
(12:41):
The team often reflects theindividual personalities, but we
need to be sensitive to that.
In your situation, mark, Iwould bet that you sat back and
just monitored the Slack channelor the Microsoft Teams channel
and looked for anything thatmight require your intervention,
but otherwise you let the teamroll.
Mark (13:02):
I did.
I'll tell you another littlewrinkle that was interesting.
That taught me early in myscrum mastering career is that
this team worked well togetherbut they had one person from the
team leave and had a new personcome in are totally different.
(13:29):
When only just even a singleperson comes in and is
introduced to the team is atotally different dynamic and
that person actually did notlike that style of working
together.
They wanted to.
Can I have some alone time?
Can I just work independentlyon my own instead of having to
look over somebody else'sshoulder or have somebody look
over my shoulder?
So yeah, that was anotherchallenge that we had to go
through.
And how does the team respondto that?
How do we work together?
So, like you say, all teams aredifferent.
(13:52):
All teams are different.
You talk about personas ofscrum masters in your book.
Specifically, there are fourpersonas and I found this really
interesting and startedimmediately thinking about
situations in my own ScrumMastering that fall into these
categories.
For our listeners out there,can we walk through those
(14:12):
personas and maybe give us someexamples of when you have had to
exhibit those personas?
Gary (14:20):
Oh, absolutely, the personas are four additional
attributes of the Scrum Masterrole.
So let's go back to thetraditional language that you
hear in the Agile community whatis a Scrum Master supposed to
do?
And the answer, the defaultanswer for years, has been oh,
(14:40):
the Scrum Master is a servantleader to the team and secondly,
secondly, removes impedimentsthat the team cannot remove
themselves.
Okay, and a lot of people stopthere, and I stopped there for a
long time.
In fact, when I started as ascrum master kind of very much
by default, back in the dayswhen scrum was just coming out I
(15:04):
had no clue what it meant to bea servant leader and I
struggled and I struggled.
I actually wrote an articleyears ago called the 10 Scrum
Master Crimes, in which Idefined what a Scrum Master
should not do, so that I could,by contradiction, try to
understand what a Scrum Mastershould do, and it helped me, and
(15:26):
I think I have that up on myLinkedIn account, that
particular little article.
But then I began to understandthat the role of the scrum
master is much broader than that.
I admit I take a very expansiveview of the role of the scrum
master.
I've been doing this for 30years and I have learned by
(15:47):
mistakes and I've made sometremendous mistakes what I, as a
Scrum Master, really should doto help my team be successful.
So I came up with these fourpersonas.
They just emerged.
It was very much an emergentset of concepts.
The first is the Scum master isa Sherpa, which means an expert.
(16:09):
Just as the Sherpas on themountain climbing teams have to
know everything about themountains and the crevasses and
all of that, a scrum masterneeds to be an expert.
Now, immediately, that raisesthe question well, what if I'm a
brand new scrum master, how canI be an expert?
And the answer is you cannot.
But you're on the journey tobecome an expert through first
(16:30):
exposure and then experience,and that leads, thirdly, to
expertise, and all of thatthrough experimentation.
Those four words start with theletter E, so I call them the
four E's, but the Sherpa has tolearn and is on a journey to
become an expert.
The second persona is theshepherd and this is the guide.
(16:54):
And this again is difficult fora brand new and experienced
Scrum Master, because a guidehas to know the journey and be
able to guide other people,because the shepherd has been
there before.
So this is where working onmultiple projects in different
domains.
Business domains is so valuablerather than working in the same
(17:17):
domain for year after yearafter year, because you learn so
much in different businessdomains, whether it's medical,
commercial, government,education, all of these
different areas.
You're going to learn much moreabout what it means to guide
your team as they work in aparticular business domain and
in the process of scrum orKanban or any other homegrown
(17:39):
process that you might rise.
The third persona is thesheepdog and this, frankly, is
the most difficult.
For most people.
It doesn't matter whetherthey're scrum guides, the scrum
masters, or not.
The sheepdog is the protector.
This is difficult because itmeans that you often have to
engage and embrace conflict,that if there is a threat to the
(18:00):
team, the scrum master has tostep in.
That often can result in somephysical confrontation as well
verbal or physical confrontation, and I can share stories about
that in a moment if you wish.
And then the fourth is thediagnostician, and this is the
healer.
And this is where the scrummaster understands the pulse and
(18:21):
the vital signs of the team ina very quiet, from the back of
the room approach, understandingwhen things are becoming a
little turbulent and whenthey're ready to turn into
turmoil.
A little bit of diplomatic ballmay be able to smooth the
waters a little bit.
The diagnostician has to beable to understand, through
(18:43):
meaningful measurements of theteam, not individuals, what is
the nature of the team?
What are the vital signs of theteam?
Are they thrashing?
Is there resentment buildingamong any team members?
This is crucial, the resentmentissue which turns into anger
and then you've lost your teamat that point.
So those are the four personasand the reason I added those to
(19:05):
the book.
They actually are the centraltheme for the book and the role
of the Scrum Master.
I'm constantly referring it asI talk about my war stories.
I'm constantly explaining as aSherpa, you need to do this and
as a Shepherd you need to dothis, so that I can bring them
back to these four conceptualroles Again the Sherpa, the
(19:26):
Shepherd, the Sheepdog and theDiagnostician a much more
expansive view than what you getfrom just the Scrum Guide.
Do those resonate with you inyour experience?
Have you found those same fourpersonas necessary?
Mark (19:39):
Yeah, I was actually wanting to talk through each one
of those, if you don't mind,gary, because I had some
questions for you and just somepersonal experiences.
So, starting out with Sherpa,like you say, starting out as a
new Scrum Master, you're notgoing to be the expert, you're
not going to necessarily knoweverything and you honestly
(20:02):
never will know everything.
But one of the things that Iwant to bring out is the
community that's out there andthe willingness to help, in the
humbleness that's out there ofpeople saying I don't have this
figured out, I need some help inthis area, can somebody help me
?
And then others being willingto step in and share some
(20:25):
experiences and just for thegoodness of bringing forth help
within the community.
So that has been tremendous forme.
So it's one of the things thatI try to aspire to do is to find
a mentor and be a mentor.
So you're continually havingboth sides of that and because
that can be daunting, right thatyou're going to be a Sherpa for
(20:48):
a team with this communitybehind you.
What's your experience beenlike?
Gary (20:54):
We do have a very helpful community where people are
willing to sacrifice and helpand answer questions and offer
guidance in so many differentways.
The issue of the Sherpa,especially for new scrum masters
accept the fact that you arenot an expert but you want to be
, and you used a word that Iabsolutely loved and it's in the
(21:15):
book.
It should be the fifth Scrumvalue, and that word is humility
.
A new Scrum Master or a newdeveloper, anybody who wants to
learn, has to have a certainhumbleness, a certain sense of
humility, so that they're notafraid of asking questions,
Because unless you ask thequestions, you will not fill in
that area that you don'tunderstand.
(21:37):
From a short-paced perspective,it could be that you're new to
the Scrum Master role, butyou're very good in other areas.
For example, I actually becamea software architect role, but
you're very good in other areas.
For example, I actually becamea software architect.
That was my major role inobject-oriented development back
in the 1980s when Scrum wascoming out.
In the late 1980s, when I wasstarting my path, I was actually
(21:58):
an object-oriented softwarearchitect.
I had that expertise when Ibecame a Scrum Master to bring
that to my teams, but I had tobe very clear to them.
Okay, I'm taking off my scrummaster hat and I'm putting on my
software architect hat, so youguys don't get confused.
I'm not telling you what to doas a scrum master.
I will not tell you what to do.
But as a software architect,here's what I think we could do.
(22:22):
And so I had expertise in otherareas, and you need to bring
that expertise.
Whether you're new to the ScrumMaster role or a product owner
role or even a developer role,you bring some kind of expertise
with you and then you grow fromweakness into strength and
expertise in other areas.
Ultimately, the Sherpa role isone to which we all aspire, but
(22:45):
we may not be there yet.
Mark (22:47):
Talking about the shepherd role.
Tell me if you disagree withthis, gary.
Maybe you do, but the shepherdrole, that's one that's very
difficult to acquire or learn.
It's something that much moreis ingrained within you.
I'll just say from myexperience I feel like that is
one of my stronger attributes,because I believe I get DNA from
(23:11):
my mother.
She was a registered nurse for30 years before she retired.
How much more of a loving,caring person do you think you
can be than being a registerednurse?
It wasn't something that shewas doing for financial reasons.
It was because she felt likeshe had a higher calling to do
that, to serve people and tocare for them.
(23:33):
So that's one that I kind offeel like it's harder for you to
go in, and if you don't havethat shepherd type mindset,
maybe the role isn't quite rightfor you.
Gary (23:46):
Oh, you've touched on such a sensitive area there.
You're absolutely right.
Personality accounts for somuch in everything we do on our
teams and a lot of scrum mastersstruggle and, frankly, some of
them fail because they are notpeople, persons, they do not
want to guide, they want to bethe boss.
(24:06):
And those scrum masters lastabout two minutes under my
coaching Because then I try toteach them.
You need to suggest, you needto offer, you do not need to
dictate.
And it does require apersonality that, if I can use
(24:28):
the word the shepherd needs tobe a pastoral personality where
you really care about people.
And this is what's missing inthe Scrum world and in the Scrum
guide.
It does not emphasize thepeople skills.
The team should decideeverything.
Well, what if none of your teamare people people either?
(24:48):
If they're not people, personsright.
So, it's a very difficultquestion.
When I work with scrum mastersin my role as a coach, I am
almost always operating in myshepherd persona.
I have to guide the guides, togive them an example of how they
(25:10):
should be approaching andguiding their teams.
If I didn't do that, theywouldn't have a model to follow.
So it's something that I'veworked on for years and I'm
still trying to become better atit.
Mark (25:24):
Very well said.
So we move on to the sheepdog,and in your book you had a
couple of really interestingI'll just leave it at that
examples from your own, fromyour own life.
Talk to us, give us thoseexamples and tell us about what
you learned from those, becauseI really found them fascinating.
Gary (25:47):
Well, I appreciate that the book is filled with war
stories.
As you have seen, after 30years doing this, I have lots of
war stories and many, many ofthem are in the book.
To give concrete examples, withrespect to the sheepdog, one
example was to protect the teamfrom themselves, and I had two
(26:11):
developers who came to me oneday and they were quite
distraught that a new developerwas taking too much of their
time and needing too muchhand-holding.
And so they came into my littlecubicle and they expressed
their concern.
They did their redress ofgrievance.
The look on their face made itpretty clear what they wanted
(26:33):
and I said we need to figurethis out and solve this right
away.
Let's go do it.
So we walked down the hall andwe went into another cubicle
area where the new developer wassitting and I said I'll just
say Fred, fred, john and Mikehere have a concern.
John, mike, tell Fred what yourproblem is.
(26:55):
And those two guys, their facesjust dropped because they
thought I was going to do allthe work for them.
But I had to protect them byletting them solve their own
problem, and they did.
They explained to Fred that hewas taking too much of their
time and that they had otherthings they needed to do.
And Fred said I had no idea.
(27:16):
Sure, and I simply said to FredFred, you know how to do this
stuff, just hammer at it.
Don't bother these guys for awhile.
If you run into a real problem,come see me.
You know how to do this stuff,just hammer at it.
Don't bother these guys for awhile.
If you run into a real problem,come see me.
Well, fred turned out to be oneof the best developers on the
team, but I had to defuse whatcould have turned into extreme
resentment and then extremeresistance between Fred, mike
(27:40):
and whatever other name I takethere.
Mark (27:43):
I almost feel like in that situation, gary, that there was
some level of inspiration,empowerment, because you could
have gone into that situationvery much and had a very down
look on your face.
You could have been lookingover the and people can't see me
, but looking over the top ofyour glasses with your arms
(28:04):
folded and been like no, fred,we don't want to have this
conversation again now.
So that's one way that couldhave.
But you know me as far as myparenting style, as far as my
coaching style with that's me,because that never motivated me.
(28:25):
My parents didn't raise me thatway and whenever I had a coach
that had that sort of demeanorto them, I didn't respond well
to that.
But the coaches that I doremember were the ones that
believed in me and stood behindme and supported me, and that's
what I see in this lovelypicture that you've painted here
is, maybe Fred just neededsomebody to believe in him, to
(28:48):
give him some confidence.
How reassuring and howrewarding is that to see that
outcome.
Gary (28:54):
That particular episode was very rewarding.
As I said, Fred became one ofthe best developers on the team.
He just didn't understandbecause of some cultural
differences His name wasn'treally because of some cultural
differences, His name wasn'treally Fred Some cultural
differences that he needed to bemore self-reliant.
My role was to help the guysexplain on their own their own
(29:19):
concerns, bring their ownconcerns and issues to Fred so
that the three of them couldwork it out.
Because if I went in there,like you said, with my glasses
down and my arms folded, itwould not have been productive
because that would have beenbasically dictating rather than
nurturing those guys.
Which brings me to anothersheepdog story, which is quite
(29:40):
different.
Yep I had a small team and I wasin their cubicle area and the
product owner stormed in onemorning and he was lit up.
He started berating the team,complaining that something
wasn't working and that theyshould have figured it out, and
I just said stop right there,you don't talk to my team that
(30:02):
way.
And I used the word my teambecause that established right
away that I had authority.
I was assuming authority forthese developers and I said stop
right there.
He started to come towards themand I physically moved between
them and I was ready to engagein some very physical contact if
(30:23):
necessary.
Fortunately it didn't turn outthat way and later I learned the
real reason behind his angerand his volatility had to do
with a very tragic personalissue in his life and he
apologized and it was all good,but for those few moments it was
(30:44):
very intense.
Most people won't have to dealwith that kind of threat, but
this was a physical threatagainst my team members and I
had to make a decision years agoam I going to step in?
And since I come from a militaryfamily, my answer has always
been yes, I'm going to step in.
You don't mess with my teamsfamily.
My answer has always been yes,I'm going to step in, you don't
(31:05):
mess with my teams.
Now, not everybody's going tofeel that way, but you need to
at least consider how will Irespond to something like that?
How will I respond if a productowner suddenly starts
criticizing my team in a publicforum, or even in a private
forum?
Will I stand up for my team,because those guys saw that I
was willing to basically take apunch for them and, as I said,
(31:28):
fortunately it did not come tothat, which in a professional
environment it never should.
But this was extremely volatilefor an unknown reason and I had
to respond in the only way Iwas prepared to do so.
But that's a different kind ofsheepdog response, as you can
see.
Sometimes they're very simple,like Fred, the issue with Fred,
(31:51):
and sometimes they're muchdicier.
Mark (31:54):
I have a story that did not escalate to that point.
I've actually told it on thepodcast before.
So, listeners, if you've heardit, if you want to skip over,
maybe about a minute or so, youmay just want to go ahead and do
that.
But we were working withanother company.
Two companies werecollaborating together to create
a software product and theywere in different verticals, but
(32:18):
they were working on this oneproduct that supported both
companies.
And one of the senior managersthat was working on the other
company made the comment that healways expects 130% output from
the team, because the team willnever give you exactly what you
(32:38):
say, and by him asking for 130%what you say, and by him asking
for 130% when they came upshort, he would, in the end, get
100%.
And so my response to that wasif you want to deal with your
team members like that, that'syour prerogative because they
work for you.
But as far as me and my team,we're simply not going to
(33:01):
operate like that.
We're going to work on asustainable pace and we're going
to make sure that we havequality built in and we're not
going to burn out our team.
Be that as it may, and we kindof went our own, our own
directions because there was adifference of opinion, but as
far as my team that I wasrepresenting, I was not going to
(33:21):
let that influence come in andcreep into the team.
Gary (33:26):
You were a sheepdog for your team.
You protected them from thatoverload, and sometimes it's as
simple as saying no, which iswhat you did.
No, we're going to do this theway that we will, in an honest
manner, with integrity.
But no, we're not going tooverload ourselves, we're not
going to burn ourselves out andwe're not going to overload
ourselves.
We're not going to burnourselves out and we're not
going to sacrifice our quality.
(33:47):
Sometimes being a sheepdog isas simple as saying no, and
other times it requires a lotmore investment of personal
sacrifice.
But either way, if a scrummaster is not willing to
sacrifice, is totally passiveand has no skin in the game,
that person should not be inthat role.
Mark (34:07):
It's quite interesting, isn't it?
Because you have to be a peopleperson but at the same time,
you have to have a little bit ofan edge to you to be able to
push back and not just be anorder taker.
It's no different than I'm notsaying that being a scrum master
is like being a parent.
Our teams are not our children,but there are some lessons that
(34:27):
we can learn and as you'redealing with raising a child,
there is a level of love thatyou have for that child, for
them to see them grow up, to seethem be a productive member of
society and to be happy.
But that doesn't mean thatyou're just going to, like you
say, be passive and say, well,johnny didn't want to clean his
room today, so I guess he's notgoing to clean his room.
(34:49):
No, of course not.
You know what's best.
So you're guiding them to makesome tough decisions.
But at the same time yeah, Iwould hope those of us that are
good parents out there.
I feel like I'm a good parentbecause my wife and I are empty
nesters and our kids are doingwell out on their own now, so
proud to say that.
But I think there are somelessons that we can learn from,
(35:11):
from parenting, and it kind ofcomes down to that sheepdog
persona like you talked about.
Gary (35:16):
The sheep, the sheepdog, as well as the uh the shepherd,
because you're nurturing theshepherd with the pattern that
we need to.
We need to.
We need to have a soft side tous as scrum masters so that we
can shepherd our team andnurture them, but we also need
to be able to defend them, justas we would defend a family.
Now, in my book, I don'tmention the parenting metaphor
(35:40):
as part of the scrum master role, but you're exactly right, I've
always thought this way being ascrum master is very much a
parenting role in the sense notthat the team are children, but
that you're nurturing the team.
You're growing them as a team.
You're also trying to help themgrow individually as
individuals and the goals thatthey have.
(36:02):
I have a series of questionsthat I share in the book that I
ask when.
I have a series of questionsthat I share in the book that I
ask when I'm a scrum master.
I ask my team members aboutfive or six questions, a couple
of which are very, very personal, but I ask them what are your
professional goals, what areyour personal goals?
And I want them to share thosewith me because I may be able to
help them achieve those goals.
(36:23):
My goal, my role, is to nurturethem and help them grow, not
just professionally asdevelopers or product owners or
other drummasters, but also asindividuals.
And so the more I know about myown team and some of the
sensitive things like I actuallyask them do you have any health
issues or other issues that Ineed to be aware of that could
(36:45):
impact your work?
And I've had people tell me thatthey've.
I've had people with drugproblems, substance abuse
problems.
I've had people with healthproblems.
I've had people who are goingthrough divorces.
I've had people who are, whoare caring for ailing parents,
and I simply say, great, thisdoesn't go outside this room,
(37:07):
but if you're having an episodethat you're struggling with, we
need to work out a signal sothat you can give me that signal
, so that I can know I need togive you some space or I need to
come alongside you.
You let me know.
Nobody else on the team isgoing to know anything about
this, and I have done that foryears, just because if
(37:28):
somebody's hurting, I need toknow it, and if they're hurting
and they need to be left alone,I need to know that, and if
they're hurting and they want meto come alongside for a while I
need to know that and theneverything returns kind of to
normal.
But that relationship that I'vehad with some of my team
members has been so strong theyliterally are like family.
Mark (37:51):
So you're right, pastoral and parenting, and you don't get
that from just reading thescrum card.
Gary (38:00):
No, and you don't get it from just sitting through a
certification and you don't getit from just one project and one
team, and you don't get ittypically until you're probably
around 40-some years old either,maturity in which we accumulate
(38:22):
all of this life experience andwe begin to realize the things
that we thought were reallyimportant in our 20s and our 40s
.
They're not very important.
Other things are much moreimportant, and it's a process of
growth for ourselves as well.
Another kind of topic that Italk about in the book is the
(38:43):
Japanese martial art of Aikido,which has three levels of
mastery called Shu, ha and RiJapanese words.
Shu is the beginner level, andthis is where a new scrum master
starts, and anybody startinganything new is at the Shu level
, s-h-u and they need achecklist and they have to
follow the checklist becausethey don't know any better.
(39:04):
So these are the guidelinesthat we would give them, right
as a shepherd.
We would give them someguidance and some things Okay,
do these three things whenyou're doing a daily stand-up
and then later you can start tomodify that.
The next level is HA, h-a, andHA is where you still have a
checklist, but you're willing tochange the checklist, because
you're context-based at thatpoint rather than just scripted.
(39:26):
And after HA you move into thetranscendent level, which is the
RE, spelled R-I, and the RE isthe expert level.
And it's called thetranscendence level because now
you don't even, you simply throwaway the checklist because it's
in your head and you deal witheverything based upon total
context, and that can only comethrough this exposure,
(39:49):
experience and experimentationleading to expertise.
I have a lot of people skills inthe book.
I have a lot of technicalskills in the book as well, so
this is a great discussion.
If people want to get in touchwith me or learn more about some
of the things that I writeabout, I have a website that is
just coming up now that peoplecan go to and they can register
(40:14):
for notifications.
The website is calledeffectivescrummastercom and it
will be evolving over the nextseveral weeks.
That people are more thanwelcome to come there and maybe
we can start a conversation thatway.
Mark (40:29):
That's great.
Gary (40:29):
Thank you so much, Mark.
I've really enjoyed this.
Mark (40:32):
Yeah, gary, and I'm sure if anybody wants to reach out
with you via email or LinkedIn,we can put all those different
ways to connect with you in theshow notes of the podcast.
Gary (40:44):
I appreciate it.
Thank you so much.
I'm looking forward to maybetalking again.
Mark (40:48):
That sounds great.
Well, Gary, thank you so muchfor being a guest and for all of
you out there listening.
Thank you for tuning in.
This has been Mark and Garywith the agile within.
We'll see everybody next time.
Bye, y'all.
Thanks for joining us foranother episode of the Agile
(41:09):
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
word with your friends andcolleagues Until next time.
This has been your host, MarkMetz.
Welcome to the Agile Within.
I am your host, Mark Metz.
My mission for this podcast isto provide Agile insights into
human values and behaviorsthrough genuine connections.
My guests and I will sharereal-life stories from our Agile
journeys, triumphs, blundersand everything in between, as
(00:29):
well as the lessons that we havelearned.
So get pumped, get rocking.
The Agile Within starts now.
Well, hey there, I hopeeveryone is having an absolutely
fantastic day today.
I'm Mark Metz, your host at theAgile Within, and I have a
guest today by the name of GaryEvans.
(00:49):
Gary, welcome to the show.
Gary (00:52):
Mark, thank you very much.
I appreciate what you'veoffered here.
Mark (00:57):
It's great.
So, gary, you and I have knowneach other for quite some time.
I was working as a developerand when I got in touch with you
and you were given sometraining classes, you and I have
kind of stayed in touch hereand there.
It kind of helps that we livein the same city, so we're
geographically close together,but it's good to have you here
(01:17):
on the show.
Gary (01:18):
Well, I appreciate that and I guess it is unusual to
have someone from the same cityin which you live.
But we have stayed in touch andI remember those days.
It was a lot of fun back thenand it was a lot of fun.
Mark (01:30):
So, gary, you and I both are located in Columbia, south
Carolina.
Not only that, but even closer,by the same suburb of the city.
So Irmo, south Carolina, is inthe northwest corner of Columbia
.
So, gary, as our normalicebreaker question, if I were
coming to Columbia for a day andhad never been there before,
(01:54):
what's one thing that you wouldsay that I couldn't miss doing?
Gary (01:58):
Well, that's interesting.
I don't get around much inColumbia but, however, if people
were coming here, I wouldreally recommend first that they
go to Lake Murray, which is oneof the largest man-made
reservoirs, if you will.
It's a huge lake, all kinds ofboating, sports and fishing and
all those types of things, andsecondly, we have a great museum
(02:21):
here.
The State Museum for SouthCarolina is located here in
Columbia, South Carolina, andkids love it and adults get a
big kick out of it.
It's really quite impressive.
So I cheated I gave you two.
Mark (02:36):
That's great.
Well, hopefully I won't get abill for the second one, so I
appreciate that.
Gary, I can attest that I loveLake Murray and also love going
to the museum.
Those are both great places togo.
Well, I want to introduce Garyto our audience here.
So Gary is an agile coach, ascrum master, a developer and an
(02:57):
author, and he has over fourdecades yes, four decades of
experience in softwaredevelopment and delivery, and
that includes three decadestotally dedicated to agile
methods.
So very, very happy to haveGary here and we're going to
talk a little bit about his bookthat he has released and it's
called the Effective ScrumMaster.
(03:18):
And, gary, I've been goingthrough this book and I found it
absolutely fascinating.
It's over 450 pages.
It's a book that you can use.
You can read from cover tocover and then, when it's done,
it's a great reference to fallback to where you have certain
situations may presentthemselves and you're like gosh,
I don't know, I haven't beenthrough this before.
(03:40):
I need some guidance.
You can just go straight to thebook, go to that chapter, and
Gary's got some great advice andsome steps to walk through for
that.
So, gary, this book, theEffective Scrum Master I want to
ask you first of all, based onthe title, is this exclusively
for Scrum Masters?
What?
Gary (03:58):
a great question.
The answer is no.
I focus on the Scrum Masterrole in the entire ecosystem of
an Agile team, and I have entirechapters, multiple chapters, on
the product owner role, as wellas the developer role that is
defined in the 2020 Scrum Guide,which includes not just
(04:20):
developers, but testers anddatabase analysts and all of
that.
So it's really not just for,but testers and database
analysts and all of that.
So it's really not just forScrum Masters, but I use that
role as the focus forunderstanding how the team
should be operating and how theScrum Master can help the entire
team, including helping theproduct owner write stories, and
perhaps we could cover thatlater.
Mark (04:41):
It's a very important topic, I would agree.
I want to know, gary, what wasyour inspiration for writing
this book, because, like I say,it's over 450 pages, so there's
lots of information in there.
Can you talk to us about whyyou wrote this book?
Gary (04:56):
That's interesting, I'll share with you.
The first two books that Iwrote are non-technical books.
I eased into those.
However, this one, I actuallyhad an epiphany.
I was reading another ScrumMaster book that came out a few
years ago and at the end of that, when I was finished reading it
, I said I could have writtenthis book.
And then it suddenly hit me Ishould have written this book
(05:21):
and at that point I committedthat I was going to take
everything that I had learnedover the previous multiple
decades of working with agileteams iterative development,
scrum, extreme programming,kanban all of this I was going
to put it together to share asmy legacy for our agile
community.
And really it came from readingthat one book, which is a pretty
(05:43):
decent book, but it left out somuch.
And so many of the Scrum Masterbooks talk about the soft
skills, but they don't get intoreally detailed issues of should
a Scrum Master be technical,should a Scrum Master not be
technical, how should they dealwith conflict when you have
somebody who cannot be saved andhow do you vote them off the
(06:06):
team All of these issues thatare really very sensitive.
They were missing from all ofthe Scrum Master books that I
read, so I decided to write myown.
That's how it happened.
Mark (06:18):
Well, I'm glad you did, because the way I look at it is
I look at the Scrum Guide thatis out there that the 2020 is
the latest version that KenSchwaber and Dr Sutherland wrote
, and it's absolutely fantastic,and it's only 13 pages, so it's
very digestible.
But the one thing is it's sobroad and so open.
(06:38):
I don't know where to start.
I don't have any guardrails.
The world was too big.
It was like I was a toddler andI was immediately given access
to the entire house.
I could approach the stairs, Icould go outside, I could open
cabinets that may have things inthere that could hurt me, and
(06:59):
really didn't have anyinformation that would help me
from doing things that wouldharm me, and so that's why I
like your book.
It really provides a lot ofcontext around the Scrum Guide
to help Scrum Masters andproduct owners and the
development team to guide them.
Gary (07:16):
You've touched on a topic that when I was at Bank of
America rolling out Agileworldwide for the bank, this
issue came up in our team.
Do we provide guard rails andguidance for new teams or do we
let them flounder until theyfinally figure out what to do?
And we had some spiriteddebates about that, and this
(07:36):
goes on even in the rest of thecorporate world.
The reason I wrote the book theway that I did I wanted to give
people guard rails and guidancewithout giving them an either
or.
I didn't want to say you haveto do it this way or you're
going to fail.
I wanted to give them contextand some starting points so that
they could understand oh, isthat how you run a refinement
(07:58):
session?
Oh, okay, now I understand whatmy goals are.
Because the Scrum Guide isextremely abstract.
It doesn't go into how you dothings.
It tells you what you need todo, but not how to do it.
I just wanted to comment onthat because that particular
question that you raised.
I've seen so many teams thathave been hurt by Scrum Masters
(08:19):
who didn't know where to startor, even worse, where to end.
Mark (08:24):
Scrum.
Gary (08:24):
Master didn't understand the limitations on his or her
scrum master role, and there aresome very distinct limitations,
but they're all context-based.
I just wanted to make thatcomment and that's why the book
is written the way that it is sowhen you say context-based,
that really means it depends.
It depends.
If you've got a new team ofnothing but introverts, you're
(08:55):
going to work with that teammuch differently than you will
with an experienced, mature teamof extroverts.
You've got to deal with thepeople first and the process
comes second.
And that doesn't come out ofthe Scrum Guide.
The Scrum Guide really doesn'ttalk about people.
Mark (09:07):
One of the sections in your book that I really liked
and I had this highlighted wasthat you have agility.
Not agile is the goal.
Talk to us about that, gary.
Gary (09:21):
Agile has become a commodity, mark.
You've seen this.
You've been doing this aboutfive, six years and you have
seen that agile has becomecommoditized.
We have certification millswhere people get a certification
after two days and they thinkthey can actually do something,
and they don't yet understandtheir inability to address some
(09:44):
of the nuances.
If we focus on agility, theability to pivot when we need to
, the ability to constantlyevaluate from a medical
perspective consider you'reworking with a patient who's
injured.
You want to constantly measuretheir vital signs and you will
then make, based on thoseconstant measurements along the
(10:04):
way, you will decide oh, theblood pressure is dropping, I
need to do something.
But you only know that afteryou've been working with that
patient for a while.
You need the ability to pivot,not to take something again
where I sound like I'm pickingon a scrum guy, not to take some
paragraph from the scrum guideand say that's the one true way
(10:33):
to do this.
There is a one true way.
In truth.
You don't have to do stand-upsto be agile.
You don't have to do stories tobe agile.
If we focus on agility, you caneven be agile in the sense of
embracing agility, even in awaterfall project, even be agile
in the sense of embracingagility, even in a waterfall
project, if you approach itcorrectly.
So these are often consideredto be similar because they have
the same root word, agile, butin terms of practice and
(10:54):
implementation they're reallyquite different.
Mark (10:57):
You mentioned.
Do you really have to even havea stand-up to be agile?
I had a team with a group ofpeople that worked really well
together.
They just really enjoyedworking with each other.
They understood each other,they knew how to challenge each
other.
And, gary, they wereessentially mob programming
(11:21):
eight hours a day.
They just enjoyed that style.
And so they challenged me andthey asked why do we need a
daily scrum or a standup ifwe're meeting eight hours a day?
And I had to.
I had to ask myself, well,what's the purpose of the of the
daily scrum, cause it's not toreport to me.
(11:42):
So I understand the daily scrumis for you, the team, so that
you are aligned.
If you feel like you're fullyaligned, then maybe we don't
need it after all, and that wasa lesson that was taught to me
that day.
Now I haven't coached a teamlike that since then, so that
was probably an exception to therule.
But that is to say that thisteam was very, very close,
(12:06):
working together and were ableto work out all those
dependencies, all those blockers.
They were able to do that inreal time, as opposed to waiting
to sync up at some point 24hours away from each other.
Gary (12:20):
That is such a great story because you responded to the
reality rather than aprescription.
You haven't had another teamlike that, meaning that all
teams are different and, as aScrum Master, we need to be
sensitive to those people.
Issues in the teams, becauseteams as a whole have
personality, in addition to thepersonality of the individuals.
(12:41):
The team often reflects theindividual personalities, but we
need to be sensitive to that.
In your situation, mark, Iwould bet that you sat back and
just monitored the Slack channelor the Microsoft Teams channel
and looked for anything thatmight require your intervention,
but otherwise you let the teamroll.
Mark (13:02):
I did.
I'll tell you another littlewrinkle that was interesting.
That taught me early in myscrum mastering career is that
this team worked well togetherbut they had one person from the
team leave and had a new personcome in are totally different.
(13:29):
When only just even a singleperson comes in and is
introduced to the team is atotally different dynamic and
that person actually did notlike that style of working
together.
They wanted to.
Can I have some alone time?
Can I just work independentlyon my own instead of having to
look over somebody else'sshoulder or have somebody look
over my shoulder?
So yeah, that was anotherchallenge that we had to go
through.
And how does the team respondto that?
How do we work together?
So, like you say, all teams aredifferent.
(13:52):
All teams are different.
You talk about personas ofscrum masters in your book.
Specifically, there are fourpersonas and I found this really
interesting and startedimmediately thinking about
situations in my own ScrumMastering that fall into these
categories.
For our listeners out there,can we walk through those
(14:12):
personas and maybe give us someexamples of when you have had to
exhibit those personas?
Gary (14:20):
Oh, absolutely, the personas are four additional
attributes of the Scrum Masterrole.
So let's go back to thetraditional language that you
hear in the Agile community whatis a Scrum Master supposed to
do?
And the answer, the defaultanswer for years, has been oh,
(14:40):
the Scrum Master is a servantleader to the team and secondly,
secondly, removes impedimentsthat the team cannot remove
themselves.
Okay, and a lot of people stopthere, and I stopped there for a
long time.
In fact, when I started as ascrum master kind of very much
by default, back in the dayswhen scrum was just coming out I
(15:04):
had no clue what it meant to bea servant leader and I
struggled and I struggled.
I actually wrote an articleyears ago called the 10 Scrum
Master Crimes, in which Idefined what a Scrum Master
should not do, so that I could,by contradiction, try to
understand what a Scrum Mastershould do, and it helped me, and
(15:26):
I think I have that up on myLinkedIn account, that
particular little article.
But then I began to understandthat the role of the scrum
master is much broader than that.
I admit I take a very expansiveview of the role of the scrum
master.
I've been doing this for 30years and I have learned by
(15:47):
mistakes and I've made sometremendous mistakes what I, as a
Scrum Master, really should doto help my team be successful.
So I came up with these fourpersonas.
They just emerged.
It was very much an emergentset of concepts.
The first is the Scum master isa Sherpa, which means an expert.
(16:09):
Just as the Sherpas on themountain climbing teams have to
know everything about themountains and the crevasses and
all of that, a scrum masterneeds to be an expert.
Now, immediately, that raisesthe question well, what if I'm a
brand new scrum master, how canI be an expert?
And the answer is you cannot.
But you're on the journey tobecome an expert through first
(16:30):
exposure and then experience,and that leads, thirdly, to
expertise, and all of thatthrough experimentation.
Those four words start with theletter E, so I call them the
four E's, but the Sherpa has tolearn and is on a journey to
become an expert.
The second persona is theshepherd and this is the guide.
(16:54):
And this again is difficult fora brand new and experienced
Scrum Master, because a guidehas to know the journey and be
able to guide other people,because the shepherd has been
there before.
So this is where working onmultiple projects in different
domains.
Business domains is so valuablerather than working in the same
(17:17):
domain for year after yearafter year, because you learn so
much in different businessdomains, whether it's medical,
commercial, government,education, all of these
different areas.
You're going to learn much moreabout what it means to guide
your team as they work in aparticular business domain and
in the process of scrum orKanban or any other homegrown
(17:39):
process that you might rise.
The third persona is thesheepdog and this, frankly, is
the most difficult.
For most people.
It doesn't matter whetherthey're scrum guides, the scrum
masters, or not.
The sheepdog is the protector.
This is difficult because itmeans that you often have to
engage and embrace conflict,that if there is a threat to the
(18:00):
team, the scrum master has tostep in.
That often can result in somephysical confrontation as well
verbal or physical confrontation, and I can share stories about
that in a moment if you wish.
And then the fourth is thediagnostician, and this is the
healer.
And this is where the scrummaster understands the pulse and
(18:21):
the vital signs of the team ina very quiet, from the back of
the room approach, understandingwhen things are becoming a
little turbulent and whenthey're ready to turn into
turmoil.
A little bit of diplomatic ballmay be able to smooth the
waters a little bit.
The diagnostician has to beable to understand, through
(18:43):
meaningful measurements of theteam, not individuals, what is
the nature of the team?
What are the vital signs of theteam?
Are they thrashing?
Is there resentment buildingamong any team members?
This is crucial, the resentmentissue which turns into anger
and then you've lost your teamat that point.
So those are the four personasand the reason I added those to
(19:05):
the book.
They actually are the centraltheme for the book and the role
of the Scrum Master.
I'm constantly referring it asI talk about my war stories.
I'm constantly explaining as aSherpa, you need to do this and
as a Shepherd you need to dothis, so that I can bring them
back to these four conceptualroles Again the Sherpa, the
(19:26):
Shepherd, the Sheepdog and theDiagnostician a much more
expansive view than what you getfrom just the Scrum Guide.
Do those resonate with you inyour experience?
Have you found those same fourpersonas necessary?
Mark (19:39):
Yeah, I was actually wanting to talk through each one
of those, if you don't mind,gary, because I had some
questions for you and just somepersonal experiences.
So, starting out with Sherpa,like you say, starting out as a
new Scrum Master, you're notgoing to be the expert, you're
not going to necessarily knoweverything and you honestly
(20:02):
never will know everything.
But one of the things that Iwant to bring out is the
community that's out there andthe willingness to help, in the
humbleness that's out there ofpeople saying I don't have this
figured out, I need some help inthis area, can somebody help me
?
And then others being willingto step in and share some
(20:25):
experiences and just for thegoodness of bringing forth help
within the community.
So that has been tremendous forme.
So it's one of the things thatI try to aspire to do is to find
a mentor and be a mentor.
So you're continually havingboth sides of that and because
that can be daunting, right thatyou're going to be a Sherpa for
(20:48):
a team with this communitybehind you.
What's your experience beenlike?
Gary (20:54):
We do have a very helpful community where people are
willing to sacrifice and helpand answer questions and offer
guidance in so many differentways.
The issue of the Sherpa,especially for new scrum masters
accept the fact that you arenot an expert but you want to be
, and you used a word that Iabsolutely loved and it's in the
(21:15):
book.
It should be the fifth Scrumvalue, and that word is humility
.
A new Scrum Master or a newdeveloper, anybody who wants to
learn, has to have a certainhumbleness, a certain sense of
humility, so that they're notafraid of asking questions,
Because unless you ask thequestions, you will not fill in
that area that you don'tunderstand.
(21:37):
From a short-paced perspective,it could be that you're new to
the Scrum Master role, butyou're very good in other areas.
For example, I actually becamea software architect role, but
you're very good in other areas.
For example, I actually becamea software architect.
That was my major role inobject-oriented development back
in the 1980s when Scrum wascoming out.
In the late 1980s, when I wasstarting my path, I was actually
(21:58):
an object-oriented softwarearchitect.
I had that expertise when Ibecame a Scrum Master to bring
that to my teams, but I had tobe very clear to them.
Okay, I'm taking off my scrummaster hat and I'm putting on my
software architect hat, so youguys don't get confused.
I'm not telling you what to doas a scrum master.
I will not tell you what to do.
But as a software architect,here's what I think we could do.
(22:22):
And so I had expertise in otherareas, and you need to bring
that expertise.
Whether you're new to the ScrumMaster role or a product owner
role or even a developer role,you bring some kind of expertise
with you and then you grow fromweakness into strength and
expertise in other areas.
Ultimately, the Sherpa role isone to which we all aspire, but
(22:45):
we may not be there yet.
Mark (22:47):
Talking about the shepherd role.
Tell me if you disagree withthis, gary.
Maybe you do, but the shepherdrole, that's one that's very
difficult to acquire or learn.
It's something that much moreis ingrained within you.
I'll just say from myexperience I feel like that is
one of my stronger attributes,because I believe I get DNA from
(23:11):
my mother.
She was a registered nurse for30 years before she retired.
How much more of a loving,caring person do you think you
can be than being a registerednurse?
It wasn't something that shewas doing for financial reasons.
It was because she felt likeshe had a higher calling to do
that, to serve people and tocare for them.
(23:33):
So that's one that I kind offeel like it's harder for you to
go in, and if you don't havethat shepherd type mindset,
maybe the role isn't quite rightfor you.
Gary (23:46):
Oh, you've touched on such a sensitive area there.
You're absolutely right.
Personality accounts for somuch in everything we do on our
teams and a lot of scrum mastersstruggle and, frankly, some of
them fail because they are notpeople, persons, they do not
want to guide, they want to bethe boss.
(24:06):
And those scrum masters lastabout two minutes under my
coaching Because then I try toteach them.
You need to suggest, you needto offer, you do not need to
dictate.
And it does require apersonality that, if I can use
(24:28):
the word the shepherd needs tobe a pastoral personality where
you really care about people.
And this is what's missing inthe Scrum world and in the Scrum
guide.
It does not emphasize thepeople skills.
The team should decideeverything.
Well, what if none of your teamare people people either?
(24:48):
If they're not people, personsright.
So, it's a very difficultquestion.
When I work with scrum mastersin my role as a coach, I am
almost always operating in myshepherd persona.
I have to guide the guides, togive them an example of how they
(25:10):
should be approaching andguiding their teams.
If I didn't do that, theywouldn't have a model to follow.
So it's something that I'veworked on for years and I'm
still trying to become better atit.
Mark (25:24):
Very well said.
So we move on to the sheepdog,and in your book you had a
couple of really interestingI'll just leave it at that
examples from your own, fromyour own life.
Talk to us, give us thoseexamples and tell us about what
you learned from those, becauseI really found them fascinating.
Gary (25:47):
Well, I appreciate that the book is filled with war
stories.
As you have seen, after 30years doing this, I have lots of
war stories and many, many ofthem are in the book.
To give concrete examples, withrespect to the sheepdog, one
example was to protect the teamfrom themselves, and I had two
(26:11):
developers who came to me oneday and they were quite
distraught that a new developerwas taking too much of their
time and needing too muchhand-holding.
And so they came into my littlecubicle and they expressed
their concern.
They did their redress ofgrievance.
The look on their face made itpretty clear what they wanted
(26:33):
and I said we need to figurethis out and solve this right
away.
Let's go do it.
So we walked down the hall andwe went into another cubicle
area where the new developer wassitting and I said I'll just
say Fred, fred, john and Mikehere have a concern.
John, mike, tell Fred what yourproblem is.
(26:55):
And those two guys, their facesjust dropped because they
thought I was going to do allthe work for them.
But I had to protect them byletting them solve their own
problem, and they did.
They explained to Fred that hewas taking too much of their
time and that they had otherthings they needed to do.
And Fred said I had no idea.
(27:16):
Sure, and I simply said to FredFred, you know how to do this
stuff, just hammer at it.
Don't bother these guys for awhile.
If you run into a real problem,come see me.
You know how to do this stuff,just hammer at it.
Don't bother these guys for awhile.
If you run into a real problem,come see me.
Well, fred turned out to be oneof the best developers on the
team, but I had to defuse whatcould have turned into extreme
resentment and then extremeresistance between Fred, mike
(27:40):
and whatever other name I takethere.
Mark (27:43):
I almost feel like in that situation, gary, that there was
some level of inspiration,empowerment, because you could
have gone into that situationvery much and had a very down
look on your face.
You could have been lookingover the and people can't see me
, but looking over the top ofyour glasses with your arms
(28:04):
folded and been like no, fred,we don't want to have this
conversation again now.
So that's one way that couldhave.
But you know me as far as myparenting style, as far as my
coaching style with that's me,because that never motivated me.
(28:25):
My parents didn't raise me thatway and whenever I had a coach
that had that sort of demeanorto them, I didn't respond well
to that.
But the coaches that I doremember were the ones that
believed in me and stood behindme and supported me, and that's
what I see in this lovelypicture that you've painted here
is, maybe Fred just neededsomebody to believe in him, to
(28:48):
give him some confidence.
How reassuring and howrewarding is that to see that
outcome.
Gary (28:54):
That particular episode was very rewarding.
As I said, Fred became one ofthe best developers on the team.
He just didn't understandbecause of some cultural
differences His name wasn'treally because of some cultural
differences, His name wasn'treally Fred Some cultural
differences that he needed to bemore self-reliant.
My role was to help the guysexplain on their own their own
(29:19):
concerns, bring their ownconcerns and issues to Fred so
that the three of them couldwork it out.
Because if I went in there,like you said, with my glasses
down and my arms folded, itwould not have been productive
because that would have beenbasically dictating rather than
nurturing those guys.
Which brings me to anothersheepdog story, which is quite
(29:40):
different.
Yep I had a small team and I wasin their cubicle area and the
product owner stormed in onemorning and he was lit up.
He started berating the team,complaining that something
wasn't working and that theyshould have figured it out, and
I just said stop right there,you don't talk to my team that
(30:02):
way.
And I used the word my teambecause that established right
away that I had authority.
I was assuming authority forthese developers and I said stop
right there.
He started to come towards themand I physically moved between
them and I was ready to engagein some very physical contact if
(30:23):
necessary.
Fortunately it didn't turn outthat way and later I learned the
real reason behind his angerand his volatility had to do
with a very tragic personalissue in his life and he
apologized and it was all good,but for those few moments it was
(30:44):
very intense.
Most people won't have to dealwith that kind of threat, but
this was a physical threatagainst my team members and I
had to make a decision years agoam I going to step in?
And since I come from a militaryfamily, my answer has always
been yes, I'm going to step in.
You don't mess with my teamsfamily.
My answer has always been yes,I'm going to step in, you don't
(31:05):
mess with my teams.
Now, not everybody's going tofeel that way, but you need to
at least consider how will Irespond to something like that?
How will I respond if a productowner suddenly starts
criticizing my team in a publicforum, or even in a private
forum?
Will I stand up for my team,because those guys saw that I
was willing to basically take apunch for them and, as I said,
(31:28):
fortunately it did not come tothat, which in a professional
environment it never should.
But this was extremely volatilefor an unknown reason and I had
to respond in the only way Iwas prepared to do so.
But that's a different kind ofsheepdog response, as you can
see.
Sometimes they're very simple,like Fred, the issue with Fred,
(31:51):
and sometimes they're muchdicier.
Mark (31:54):
I have a story that did not escalate to that point.
I've actually told it on thepodcast before.
So, listeners, if you've heardit, if you want to skip over,
maybe about a minute or so, youmay just want to go ahead and do
that.
But we were working withanother company.
Two companies werecollaborating together to create
a software product and theywere in different verticals, but
(32:18):
they were working on this oneproduct that supported both
companies.
And one of the senior managersthat was working on the other
company made the comment that healways expects 130% output from
the team, because the team willnever give you exactly what you
(32:38):
say, and by him asking for 130%what you say, and by him asking
for 130% when they came upshort, he would, in the end, get
100%.
And so my response to that wasif you want to deal with your
team members like that, that'syour prerogative because they
work for you.
But as far as me and my team,we're simply not going to
(33:01):
operate like that.
We're going to work on asustainable pace and we're going
to make sure that we havequality built in and we're not
going to burn out our team.
Be that as it may, and we kindof went our own, our own
directions because there was adifference of opinion, but as
far as my team that I wasrepresenting, I was not going to
(33:21):
let that influence come in andcreep into the team.
Gary (33:26):
You were a sheepdog for your team.
You protected them from thatoverload, and sometimes it's as
simple as saying no, which iswhat you did.
No, we're going to do this theway that we will, in an honest
manner, with integrity.
But no, we're not going tooverload ourselves, we're not
going to burn ourselves out andwe're not going to overload
ourselves.
We're not going to burnourselves out and we're not
going to sacrifice our quality.
(33:47):
Sometimes being a sheepdog isas simple as saying no, and
other times it requires a lotmore investment of personal
sacrifice.
But either way, if a scrummaster is not willing to
sacrifice, is totally passiveand has no skin in the game,
that person should not be inthat role.
Mark (34:07):
It's quite interesting, isn't it?
Because you have to be a peopleperson but at the same time,
you have to have a little bit ofan edge to you to be able to
push back and not just be anorder taker.
It's no different than I'm notsaying that being a scrum master
is like being a parent.
Our teams are not our children,but there are some lessons that
(34:27):
we can learn and as you'redealing with raising a child,
there is a level of love thatyou have for that child, for
them to see them grow up, to seethem be a productive member of
society and to be happy.
But that doesn't mean thatyou're just going to, like you
say, be passive and say, well,johnny didn't want to clean his
room today, so I guess he's notgoing to clean his room.
(34:49):
No, of course not.
You know what's best.
So you're guiding them to makesome tough decisions.
But at the same time yeah, Iwould hope those of us that are
good parents out there.
I feel like I'm a good parentbecause my wife and I are empty
nesters and our kids are doingwell out on their own now, so
proud to say that.
But I think there are somelessons that we can learn from,
(35:11):
from parenting, and it kind ofcomes down to that sheepdog
persona like you talked about.
Gary (35:16):
The sheep, the sheepdog, as well as the uh the shepherd,
because you're nurturing theshepherd with the pattern that
we need to.
We need to.
We need to have a soft side tous as scrum masters so that we
can shepherd our team andnurture them, but we also need
to be able to defend them, justas we would defend a family.
Now, in my book, I don'tmention the parenting metaphor
(35:40):
as part of the scrum master role, but you're exactly right, I've
always thought this way being ascrum master is very much a
parenting role in the sense notthat the team are children, but
that you're nurturing the team.
You're growing them as a team.
You're also trying to help themgrow individually as
individuals and the goals thatthey have.
(36:02):
I have a series of questionsthat I share in the book that I
ask when.
I have a series of questionsthat I share in the book that I
ask when I'm a scrum master.
I ask my team members aboutfive or six questions, a couple
of which are very, very personal, but I ask them what are your
professional goals, what areyour personal goals?
And I want them to share thosewith me because I may be able to
help them achieve those goals.
(36:23):
My goal, my role, is to nurturethem and help them grow, not
just professionally asdevelopers or product owners or
other drummasters, but also asindividuals.
And so the more I know about myown team and some of the
sensitive things like I actuallyask them do you have any health
issues or other issues that Ineed to be aware of that could
(36:45):
impact your work?
And I've had people tell me thatthey've.
I've had people with drugproblems, substance abuse
problems.
I've had people with healthproblems.
I've had people who are goingthrough divorces.
I've had people who are, whoare caring for ailing parents,
and I simply say, great, thisdoesn't go outside this room,
(37:07):
but if you're having an episodethat you're struggling with, we
need to work out a signal sothat you can give me that signal
, so that I can know I need togive you some space or I need to
come alongside you.
You let me know.
Nobody else on the team isgoing to know anything about
this, and I have done that foryears, just because if
(37:28):
somebody's hurting, I need toknow it, and if they're hurting
and they need to be left alone,I need to know that, and if
they're hurting and they want meto come alongside for a while I
need to know that and theneverything returns kind of to
normal.
But that relationship that I'vehad with some of my team
members has been so strong theyliterally are like family.
Mark (37:51):
So you're right, pastoral and parenting, and you don't get
that from just reading thescrum card.
Gary (38:00):
No, and you don't get it from just sitting through a
certification and you don't getit from just one project and one
team, and you don't get ittypically until you're probably
around 40-some years old either,maturity in which we accumulate
(38:22):
all of this life experience andwe begin to realize the things
that we thought were reallyimportant in our 20s and our 40s
.
They're not very important.
Other things are much moreimportant, and it's a process of
growth for ourselves as well.
Another kind of topic that Italk about in the book is the
(38:43):
Japanese martial art of Aikido,which has three levels of
mastery called Shu, ha and RiJapanese words.
Shu is the beginner level, andthis is where a new scrum master
starts, and anybody startinganything new is at the Shu level
, s-h-u and they need achecklist and they have to
follow the checklist becausethey don't know any better.
(39:04):
So these are the guidelinesthat we would give them, right
as a shepherd.
We would give them someguidance and some things Okay,
do these three things whenyou're doing a daily stand-up
and then later you can start tomodify that.
The next level is HA, h-a, andHA is where you still have a
checklist, but you're willing tochange the checklist, because
you're context-based at thatpoint rather than just scripted.
(39:26):
And after HA you move into thetranscendent level, which is the
RE, spelled R-I, and the RE isthe expert level.
And it's called thetranscendence level because now
you don't even, you simply throwaway the checklist because it's
in your head and you deal witheverything based upon total
context, and that can only comethrough this exposure,
(39:49):
experience and experimentationleading to expertise.
I have a lot of people skills inthe book.
I have a lot of technicalskills in the book as well, so
this is a great discussion.
If people want to get in touchwith me or learn more about some
of the things that I writeabout, I have a website that is
just coming up now that peoplecan go to and they can register
(40:14):
for notifications.
The website is calledeffectivescrummastercom and it
will be evolving over the nextseveral weeks.
That people are more thanwelcome to come there and maybe
we can start a conversation thatway.
Mark (40:29):
That's great.
Gary (40:29):
Thank you so much, Mark.
I've really enjoyed this.
Mark (40:32):
Yeah, gary, and I'm sure if anybody wants to reach out
with you via email or LinkedIn,we can put all those different
ways to connect with you in theshow notes of the podcast.
Gary (40:44):
I appreciate it.
Thank you so much.
I'm looking forward to maybetalking again.
Mark (40:48):
That sounds great.
Well, Gary, thank you so muchfor being a guest and for all of
you out there listening.
Thank you for tuning in.
This has been Mark and Garywith the agile within.
We'll see everybody next time.
Bye, y'all.
Thanks for joining us foranother episode of the Agile
(41:09):
Within.
If you haven't already, pleasejoin our LinkedIn page to stay
in touch.
Just search for the AgileWithin and please spread the
word with your friends andcolleagues Until next time.
This has been your host, MarkMetz.
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.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!