In this episode of the Scrum.org Community Podcast, guest host Lindsay Velecina welcomes Professional Scrum Trainer Simon Reindl to answer listener questions from his recent webinar, “How do the Scrum Accountabilities Work at Scale – Practical Steps for Delivery.”
Drawing on years of hands-on experience, Simon breaks down Scaled Scrum and portfolio management, explores how many Scrum Masters you really need, and offers guidance on applying frameworks like Nexus, Scrum at Scale, and even SAFe with intention—not dogma.
From structuring teams to improving flow and making value measurable, Simon shares practical insights to help organizations scale Scrum without losing sight of what really matters: delivering value through empowered teams and continuous learning.
Key Topics:
- Scaled Scrum and Portfolio Management
- How many Scrum Masters? It depends.
- Value Stream Mapping to uncover flow and bottlenecks
- Using metrics that matter (hint: it’s not velocity)
- The art of being a persistent (and sometimes annoying) Scrum Master
Whether you're scaling up or just getting started, this conversation will help you do it with clarity and purpose.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Lindsay Velecina (00:00):
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode. Okay, welcome to thescrum.org community podcast.
This is Lindsay bellascinahere@scrum.org and I am here
(00:26):
with PST. Simon reindell toaddress some open questions from
an early April webinar. How dothe scrum accountabilities work
at scale, practical steps fordelivery. So in this webinar,
Simon talked about scalingthrough the lens of the scrum
master product owner, developersand leadership, and also related
(00:48):
scaling to product portfoliomanagement. So welcome to the
podcast, Simon. Thanks
Simon Reindl (00:53):
for having me. I appreciate the opportunity to
answer some questions thatpopped up in the webinar.
Lindsay Velecina (00:58):
Yeah, there were some really great
questions, and I'm glad we couldtake the time to get these
addressed. So do you want to goahead and introduce yourself and
then maybe set the stage alittle bit for the Q and A
Simon Reindl (01:10):
Sure? Thank you so everyone. My name is Simon
reindell. I'm an Australianbased in the UK. Being a
professional scrum trainer,since 2010 I've had the honor to
perform all the accountabilitiesin Scrum, and I've worked in
some significant scalingsituations as well, and I work
from startups through tomultinationals, so I've seen a
(01:34):
lot of this stuff in my years.
During the webinar, I was tryingto really focus on the
difference between scaled Scrum,where you have many teams
working on a product, andportfolio, which is many teams
working on many products, right?
And I think it's important todistinguish between the two. And
(01:57):
the fundamental thing withscaling is we're still trying to
build an increment right scale.
Scrum is still scrum scaled.
Agile is still focusing ondelivering stuff. And so when
we're getting together andtalking about this, we're
talking about dependencies,integration and any impediments.
So if we can communicate thatstuff and resolve it quickly,
then we can deliver as a group.
Yeah, that makes a lot of sense.
(02:22):
So that's basically the lensthat I'm looking for that and
you know, the webcast is upthere on the scrum.org website
if you want to go back and havea look
Lindsay Velecina (02:32):
at it, yeah, and I'm including the link for
that in the show notes as well.
For anyone who's just tuning inand listening to this week's
episode, you can go back andwatch the webinar. So we had
quite a few open questions atthe end of the webinar, where we
had our Q and A session. Sowe're going to use this time to
get through the rest of thequestions that we didn't have
(02:54):
time for. So this I have themkind of organized into different
categories. So we're going tofocus first on agile frameworks
and scaling, and then we'll moveinto a few other topics. So in
this first one and the Nexusframework, there's only one
scrum master for many teams.
(03:17):
Does it work based on yourexperience?
Simon Reindl (03:21):
Yes and no, and it depends upon the capability and
capacity of the teams. Now, ifthe teams are really used to
doing Scrum, and they're reallycomfortable using Scrum, and
they don't require as much focusand effort off the Scrum Master,
it can work. So it's thatclassic, it depends. And I have
(03:43):
to say, for just about every oneof these scaling answers, yeah,
Lindsay Velecina (03:46):
I was just going to say, I think a lot, I
think all these questions thatwe're going through are going to
be kind of that it dependsanswer. So,
Simon Reindl (03:56):
yeah, context is king, right? Yes. When if
there's a lot going on, if theteams need help, as well as
there's challenges gettingthings integrated, you it is, I
would say it's more common tohave many Scrum Masters, like a
scrum master feature the teams,and one of them being the Nexus.
(04:18):
Scrum Master is probably morecommon than having one scrum
master for many teams.
Lindsay Velecina (04:23):
Okay, thank you. All right. So this is
another It depends. But what isthe ideal team size for a scrum
team when scaling? So maybe, ifyou want to share, like, some of
the things that you've seen withthis, because I know it depends
on the organization and theteam. Yeah. So
Simon Reindl (04:42):
I really want to channel my inner Ken as small as
possible and no bigger. That's avery zen like Ken answer. What
have I seen? I've seen teams ofsix being able to deliver a
workable increment. I've alsoseen. Seen a team of 15 where
they needed that number ofpeople because they needed that
(05:05):
mixture of skills to be able tocreate a an integrated
increment. I've also seen areally phenomenal group where
they would dynamically re teamevery sprint planning so they'd
have a look at what was going onduring that sprint, and they
(05:25):
would divvy themselves up intotwo or three teams,
Unknown (05:29):
right? And just track
Simon Reindl (05:33):
on with the work.
So my preference is to keepthose Scrum teams around the 10,
the magic number of 10. It'sjust the whole communication,
the focus. Now, when we scaleyou'll probably get used to
working with a group that islarger than that, and there's a
magic number of around 80 peoplethat you can maintain
(05:56):
professional relationships withand understand what's going on
and working together. Butthere's a reason sports teams
are stable, right? Americanfootball is an interesting one,
because the squads in that areso huge, yeah, talking, you
know, 5060, I think they canmaintain that network, and
(06:18):
people can step in and out ofthe tanks, but Right? So the
like, the exam answer is roughly10. The real life answer is
whatever works for you. I thinkthis is really important. When
we get to scaling, don't get sohung up on the framework or the
theory that you don't inspectand adapt and
Lindsay Velecina (06:40):
just figure it out, right? Awesome. Thank you.
All right, so what are yourthoughts on toolkits such as
disciplined agile and theCynefin framework to understand
and address the complexity andscaled Scrum?
Simon Reindl (06:56):
I love Cynefin.
Dave Snowden has done somereally good work there. And if
you have the opportunity to useestuarine mapping, it's a great
way of understanding what'sgoing on in your situation,
using the Cynefin framework tohelp understand your problem
space, really looking out forthose liminal areas between
(07:16):
zones. Awesome, disciplinedagile, like you know, is, I
don't think there's, there's nobad framework, right? And the
whole point of discipline Agileis a way of putting all the bits
together so that organizationscould deliver and one of the
great things that disciplinedagile was highlighting early
(07:37):
doors. Use the process, right?
Don't give lip service to it.
Don't do Agile theater, likefocus on it, ship stuff, close
the feedback loop and learn. SoI don't think there is a bad
framework or a bad model, if ithelps you deliver, right? Are
(07:57):
you connected to your customer?
Are you getting stuff done? Youclosing the feedback loop now
you improving anything thathelps you do that good, anything
that detracts from that bad?
Lindsay Velecina (08:11):
Awesome. Thank you. That makes a lot of sense.
So this next one here, so as itis a general, skilled agile
topic. Can you please give anexample and or scenario of when
to use, safe versus Nexus versusScrum, at scale versus Spotify,
(08:33):
all of them being scaled agileframeworks?
Simon Reindl (08:36):
Yeah. Okay. So first of all, I think there's a
link we need to put in the shownotes. I'll tackle the Spotify
one first. When most people saythey're using the Spotify model,
typically, they're referring toa blog article that Henrik
niburg published back in 2012right? And like, that's, that's
(08:57):
the seminal article aboutscaling, which is a snapshot
that he wrote with Spotify Agilecoach at the time of how a
particular group was working. Mynormal annoying question is,
people say, Oh, we're using theSpotify model. And you go,
Great. Are you a Swedish musicstreaming company in 2012 people
(09:17):
go, No. And I'm like, why areyou using their custom built
scaling framework? Because theydon't work like that anymore. I
think so, without trying to betoo flippant, but the whole idea
of guilds tribes communicatingthose patterns, so I think that
whole squad guild tribe model isa great naming convention and
(09:43):
way of communicating crossskills, right, right? So, if it
works great, but really Spotify,understood that when it comes to
scaling, you have to find yourown patterns and structure.
Messages to help yourorganization and your contextual
problem, and so blindly copyingsomeone else's pattern that
(10:08):
they've iterated on for them isusually dangerous,
Lindsay Velecina (10:12):
right? Because it was for them, it wasn't for
you, yeah,
Simon Reindl (10:15):
and it was also a snapshot, like at the time of
recording, it's 25 right? 2025,so it's 13 years ago. They have
changed since then. So if, whyare you taking the old model
like that's a 13 year old that'sa decade old model longer. So
use some languages. Use it as aninspiration for you to create
(10:38):
your own scaling framework.
Awesome, but don't just blindlycopy it. To be honest. That goes
with every other scalingframework included the beloved
Nexus from scrum.org, likethose. Don't blindly implement
it. Use it as a baseline. Ithink scaling frame,
Lindsay Velecina (10:55):
it's a framework. It's not something
that you take carbon copy andthey were just doing this, yeah,
Simon Reindl (11:04):
so I think this, the frameworks are a lot like
scales out of music. Like welearn scales so that we know
where the notes are, and then wecan use them to create music.
But just playing scales atpeople, it's not going to be a
really good concert. All right,so Nexus. Where's Nexus? Really
cool. It's really cool when youhave got a few teams that need
(11:25):
to work together, and you wantto start out doing that, so that
will scale. That'll scale toteams and teams of teams. It's
my personally preferred startingpoint for scaling, because it's
the lightest weight of thelight, right? Scrum at scale,
from Jeff Sutherland and ScrumInc, it's great because it
(11:47):
starts really describingpatterns to get your leadership
to engage. So it talks aboutorganizational change patterns
and organizational design, whichyou've got to get into when you
get into scaling and gettingyour organization to truly be
agile. So it's beautiful forthat you can add elements of
(12:08):
Scrum at scale on top of Nexus,
Unknown (12:12):
so that it's
Simon Reindl (12:13):
great, so that the you can mix it all together. And
that's the thing, like you canmix and match Safe is a
contentious topic. Some peoplelove it. Some people love to
hate it. The thing safe istypically for very large
organizations trying to be moreagile. I think it is a good
(12:35):
stepping stone to get people toconsider of how the feedback
loops work. One of my concernswhen you look at safe is it's
still quite top down, so thefeedback loops aren't as built
in. One of the contentiouspoints is a safe scrum master
(12:56):
and product owner does not equala scrum guide scrum master or
product owner, so be careful ofthat. So when we look at the
safe stuff is different. I knowyou've all done some good stuff
about Scrum and safe and thatthat's all available on the
scrum.or Yep, website. There
Lindsay Velecina (13:11):
was a there was a webinar a few weeks back
that he did on that so, and apodcast as well, I think, yeah.
So
Simon Reindl (13:21):
I'm going to defer to yuvals experience on that,
but it's a starting point. But Ireckon if your organization is
still using safe by the book,after a couple of years, you
probably haven't got the joke.
You're probably doing a bit ofagile theater at that point, and
you've just embedded stuff youhaven't iterated and learned. So
I think that that covers themall, doesn't it?
Lindsay Velecina (13:43):
Yeah, I think so that that was that was great,
great compare and contrast
Simon Reindl (13:51):
there, but take your pick, pick one. Start
there, change it.
Lindsay Velecina (13:57):
Yep, all right, so we're going to shift
gears a little bit for thesenext couple of questions. So
organizational agility anddecision making. So this person
wrote in my company keeps sayingthey are an agile enabled
company, but at the same time,decision making happens at top
(14:19):
management, where the result ofthe decision is shared, not the
input and process of thedecision making. These result in
people doing the work and notunderstanding the decision being
made in this session. Agilescaling needs to needs
information to flow accuratelyand freely within the
(14:40):
organization, so that thedecision making is understood by
the people who are doing thework. What first step can I try
to suggest to my organization totruly be an agile enabled
company, especially regardinginformation flow within the
organization? The big question,
Simon Reindl (14:58):
it's huge and.
It's so typical, right? And thefirst step is having doing some
investigation and finding outwhether the top management
believe they're communicatingsome of the some of the biggest
challenges we have as people, iswhen what we think is going on
(15:20):
is not what the other personthinks is going on. And so we
really need to tap into thestance that Stephanie and I
wrote about and in our bookmastering professional scrum
curiosity with positive intent.
So just like go up the foodchain and go, Hey, do you? Do
(15:42):
you? What do you think you'recommunicating? This is what
we're seeing. So that's thefirst thing. We've got to close
the loop. That's great advice.
You got to walk the talk aswell. So you've got to
communicate. You have to overcommunicate. And this is why I
love the work of Jocko will Nickand Leif Babbage in Extreme
Ownership dichotomy ofleadership, that whole thing
that we have to lead down, leadup, lead sideways. We everybody
(16:05):
needs to be a leader. So you gotto lead up. So you need to let
the people above you know thatthat communication is missing
some of the loop, you know, somethat high fidelity thing is
starting to lose a bit. So maybeyou just need to say, we'd like
to understand the reasoningbehind it. Yeah. The other thing
(16:27):
you could do, and this is wherenumbers, numbers are great. Love
numbers. Bit of empiricism. Getsome EBM going on. How long does
it take a message to flow fromthe top to the bottom, yeah. How
long does it take a message toflow from the bottom to the top?
If we did some math on it,what's the hang time for a
(16:51):
decision? Like, if you have togo up to get a decision, is
there lag to get the decisionmade. Turn it into numbers,
right? Because, if you've got,let's say your particular scrum
team, the average scrum teamcosts 70k a sprint, a two week
sprint, and let's say it takestwo weeks to get a decision.
(17:13):
Well, the cost of delay in thatinstance is 70k right? What
about if we got 10 teams? It'snow three quarters of a million.
Now, if you start bandingnumbers around like that, most
of the leadership will startpaying attention, because who
wouldn't like three quarters ofa million more money in the bank
account? I know I would.
Unknown (17:38):
So powerful metrics,
Simon Reindl (17:40):
money, money talks. You know, it's the golden
the golden rule of business.
Whoever's got the gold makes therules. So what we need to do is
to start talking about thatstuff. So to be agile enabled,
what we're trying to do is getthat information flow. We're
trying to create that space oftrust and communication and
empowerment. How can we starthaving scaling events where you
(18:03):
get better representation,better communication? I think
small steps,
Lindsay Velecina (18:12):
that's a good place to start. I think Awesome.
Thank you. Simon. All right, sowe're going to shift gears again
to portfolio and value streams.
So about portfolio level, what'syour opinion on using Value
Stream Mapping? Somebody asked,
Simon Reindl (18:29):
yeah, just do it.
Value Stream Mapping is awesome.
Do it in the team. Do it aportfolio. Try and understand
where the flow is, where youlock up, where's your decision
latency. Make sure, when you doit, you get a representative
sample the number of times I'vedone it. And the people on the
(18:50):
left think they're overcommunicating all the way
through, and the people on theright going, How come nobody
tells us everything, and we'regetting surprised and ambushed
all the time. And the people onthe left go, oh, but we tell you
it's like, man, no, you don't.
So having representatives ofeach of the different teams and
silos, you can see where thehandoffs and the lag is and the
die is. Value Stream Mapping isawesome. I love it.
Lindsay Velecina (19:15):
Okay, all right, so we're gonna refer to
one of the slides that were inyour presentation. So we'll jog
our memories. So question to theslide about the product owner
practices. What if the productowner is the CPO product VP or
portfolio lead, like Dave Westhad suggested in one of his
(19:39):
previous webinars recently, if aproduct owner is that high in
the hierarchy, then are theymore responsible for leading and
not driving product value? No,
Unknown (19:55):
flat, no. Right? Yeah.
Do.
Lindsay Velecina (20:00):
Their product owner? Yeah, it all goes back to
the accountability.
Simon Reindl (20:04):
It's the accountability the product
owner. Product Owner is a valueMaximizer. In fact, I would say
if they're a CPO product VP orportfolio lead, they're even
more on the hook because it'smore money. So if we go back to
that 70k team, let's say they'vegot 10 teams at 700k every two
weeks, they they better beshipping 700k worth of value
(20:28):
every two weeks, otherwise yourcompany will go broke. I don't
know any organization that canafford to hemorrhage that sort
of money.
Unknown (20:37):
So they are leading,
Simon Reindl (20:41):
and they are leading a product group who
should be delivering multiplefactors of value so many, many
moons ago, when I was working infinancial industry, they used to
say each engineering team neededto return 20 to one so for each
pound invested in theengineering team, we needed to
(21:05):
return 20 pounds worth of valueto basically make the company
more valuable. If your productowner at portfolio level or
product level at senior levels,if they are not using really
clear, evidence based managementvalue metrics. How are they
(21:26):
navigating and steering thatgroup? So I would suggest
they're even more accountablefor values because it's more
money. Yep, that makes a lot ofsense.
Lindsay Velecina (21:41):
All right, before I ask you this next
question, so I'm not going tocut this out. Is Art, what is
that average? Agile releasetrain. Agile train, it's a safe
term, okay, yeah, okay, allright, agile release train, so
I'll say that for the firstreference.
(22:11):
All right, okay, so this nextone, our portfolio manager is
only accountable for our agilerelease train while business
value is delivered in cross A RT teams value streams, really we
are not aligned that way, andour OKRs are for a r t only not
(22:33):
delivering value. How can I makeimprovements that are within my
control? How would you handlethis? And then in parentheses,
leaders are not agile or scrumtrained.
Simon Reindl (22:48):
Interesting. I think this is a wonderful
opportunity. Okay, there you'rein that that situation. Have you
ever seen Band of Brothers? Thestory about there's a wonderful
scene in band of brothers whenthey're about to go into
Bastogne, and the paratroopersare going in and the regular
(23:11):
infantry are coming out, and oneof the Champs mentions to the
commander. He said, Oh, what areyou doing? You're going to go in
there and you're going to besurrounded. And you said, Son,
we're paratroopers. We're meantto be surrounded. You're in that
situation, in this where yourleadership don't understand the
(23:32):
process they're trying toimplement. What is in your
control is educating yourleadership. So you need to start
finding ways to influence themand help them understand these
concepts of fast feedback loops,these concepts of cross
functional teams. Now we'retalking about cross functional
trains, because what you've gotis a disconnect here. So if your
(23:57):
OKRs are for your your train andthey don't, and the only way of
delivering value is acrosstrains. You've basically got
useless metrics. I don't carehow many revs your engines doing
if you haven't connected it tothe wheels, and this is one of
(24:21):
the dangerous things. You canmeasure everything, and it tells
you nothing,
Unknown (24:25):
right?
Simon Reindl (24:26):
So, how would I handle this? The pending on my
remit, and this is where, in thepresentation, I offered people a
model where it said, purpose,constraints, trust. It was a
simple Bullseye model. We've gotto start off with purpose. You
need to determine what yourconstraints or boundaries are,
what's in your gift. Now, themore trust we build up with our
(24:52):
leadership, with our peers, thelooser the constraints will
become. So you need todemonstrate your competence of
what. You're doing, so that yourportfolio manager will then
support you, and your discussionyour leaders will support you,
and you can then be listened toand trusted. Because if you're
not trusted, it doesn't reallymatter what you say, they'll
(25:13):
just go either they're justmaking noise. You have to be
careful about this, and it tookme a few years to realize this.
And people don't listenlogically. People listen
emotionally. And so if youapproach your senior leadership
and go, You guys haven't got aclue, that's not going to get
(25:35):
you anywhere. Whereas if youapproach like and you see this
when big ships come into harbor.
Tugboats come alongside them fora reason. There's no way a
tugboat can push against theship, but it can go along and
nudge aside. You need to buildpartnerships. You need to build
relationships. You need to growyour trust. You need to help
people understand that and thinkabout what's an experiment you
(25:56):
can run. Is it possible to bringin a metric across release
trains, try and explain it insuch a ways. Where can you
measure your customer value andyour customer impact, helping
leadership understand trueevidence based management
metrics? What is it that yourproduct is really needing? Is it
customer satisfaction? Is itmarket reach? What's the magic
(26:18):
number? How are you matchingwhatever that magic number is?
Go up and lead the put the dotsdown so that the leaders can
connect the dot and then own thedecision to try and experiment.
So love it got to be careful.
Yeah, because you're callingsomeone else's baby ugly at this
(26:40):
point, yep.
Lindsay Velecina (26:43):
All right, so next we're going to dive into
roles and career paths. So sothis person wrote in Please,
Your opinion is important as abusiness analyst, is it better
to go into the scrum master orproduct owner accountability? We
know that it depends. But goahead,
Simon Reindl (27:03):
which one do you want to do? It's as simple as
that. You know doesn't reallymatter. You know, you could be a
great scrum master. You could bea great product owner. The
choice is the one which youprefer. Why not give each them a
go? If you can, because if youspend some time in either role,
(27:23):
is going to help you be moreempathic when you inhabit the
other role, right? Oraccountability, oops, use the
role word that only changed fiveyears ago. Okay, still gets me.
Yeah. So when we're consideringour key our careers, think about
where you want to be, one year,three years, five years, what's
Unknown (27:47):
going to get you there and
Simon Reindl (27:50):
a little bit of time in each role. And I would
suggest, perhaps, unless you'vetried either of those
accountabilities, it's going tobe hard to make a choice. And
the thing is, no choicesforever. So you could give a
role a go for a year or so, andthen change on if you don't like
(28:11):
it, if you love it, just leaninto it. Sometimes we don't
know, we don't know the suitfits until we try it on, right?
Lindsay Velecina (28:20):
I like that advice. All right, so this
person wrote in today, I was inan interview for a role of an
agile project lead, where therole was supposed to be a
combined role of a scrum master,a project manager, and at the
same time having one on oneswith team members and conducting
(28:42):
performance reviews, even if itis a flat structure
organization. This sounds to melike a line manager role at the
same time. I guess thatcombining three roles is too
much. They're probably savingmoney and too much
responsibility for one person.
What do you think? Yeah,
Simon Reindl (29:02):
like Run DMC said it's tricky, tricky, tricky.
That That sounds quite busy.
There is like having one to onewith team members and
performance review. That's clearline management stuff and
project managers, their style ofoperation is orthogonal to that
(29:23):
of a scrum master. A scrummaster should be asking, not
telling. Project managers oftentell, don't ask. But really,
really good project managersoften act like Scrum Masters and
empower their people. So goingback to the bulls way, model of
purpose, constraints, trust.
Unknown (29:45):
You could form this.
You need to get really good atdelegating. You can delegate a
lot of this stuff, right?
Remember, a scrum Master's dutyof care is to reveal, not
resolve.
Simon Reindl (30:01):
So what you can then look at is you're the Agile
Project Lead great cultivatesomeone else, to people to be
Scrum Masters, to people to beproject managers, and depending
how big the team is, mentorpeople to get really good at
conducting performance reviews.
What about helping the team selfmanage their performance
(30:24):
reviews? Change the culture, mixit up. The only constraint I'm
hearing is that that stuff's gotto get done. Wouldn't it be
great if you created triads sothat each group of three people
had to conduct mutualperformance reviews of each
other. Yeah, and your your dutyof care is to coach it like just
(30:45):
find different ways, novel waysof doing it and leading projects
for external clients. I'mconfused like, if you're an
agile project lead, why are youbehaving differently with
external clients? Yeah, guessingyou're a consultancy or
something here, have a look atthe contract. See if the
contract can be written in amore agile way. Look at lean
(31:07):
agile procurement. There's awhole bunch of ways of building
contracts and collaboratively.
Look for the win, win with theclient, and start doing Agile
like change the interface withthe clients.
Lindsay Velecina (31:21):
Awesome. Thank you, Simon, make the job that
you want to do? Yeah, it couldbe a really great opportunity.
Yeah, great. So these lastcouple questions are scrumm and
agile practices questions alittle more general. So when
there is a different opinionbetween the product owner and
(31:41):
the scrum master about animportant change to make on the
objective of the product whoseopinion should prevail?
Simon Reindl (31:50):
Product Owner next, right? Let's open and shut
that's like smack it out of thepark. The the scrum master is
about the process Exactly. Now,if you'd said product owner and
developers, I'd say aconversation. This is one of the
things that is so challenging. AScrum Master is a true leader
(32:15):
that serves their focus is onhelping everybody understand and
execute on the process, notabout the product that is the
product owner. The scrum mastershould be supporting the product
owner making the decisions, nottrying to second guess or
influence that opinion. Butthat's nice. Keep it to
(32:37):
yourself, let the product ownermake the call.
Lindsay Velecina (32:42):
All right, so this next one. So what's the
best way to report on progress?
Because business, the business,doesn't understand velocity, and
then in parentheses, does notreally, for example, I've been
questioned velocity in the lastsprint was 25 why was it 20 for
this sprint?
Simon Reindl (33:05):
My team wasn't sleeping. Just that the US. I
think that's the user story, thePBI. Okay, I was wondering.
Yeah, that's my guess. Okay, sothe, this is a classic one.
Lindsay, this is nonsense.
Metrics, right? Velocity is atool for the team to understand
(33:29):
throughput. What's the best wayto report on progress a done
increment. That's it. This iswhat we have done. What about
PBI count? What it's also smellslike to me is the business
doesn't understand throughputthe business. The thing is that
product backlog items can bevariable in size. Now you should
(33:51):
be doing a few PBIS a sprint,like if you're only doing one
PBI sprint, I'd suggest you'reprobably not refining enough. So
I'd try and break them down alittle bit smaller, take smaller
mouthfuls, bite sized chunks.
You know, what's the best way ofreporting or demonstrating
progress, value delivered? Havea look at some evidence based
(34:14):
management metrics. Is yourcustomer satisfaction going up?
Have you generated more revenuefor the organization. Are you
releasing more frequently iscalls to the Support, Support
Center or call center droppingwhatever it is. Find metrics
that really matter, not somearbitrary one. You know, because
(34:40):
velocity is so easy to gain.
It's, it's a, it's useful toolfor to help the team understand
things, but it's not really forbroader consumption, right?
Okay, do, do I really care howmany beers you drink on the
weekend? No, that's your job,right? Whatever. Well, did you
have a good weekend that. At us.
(35:00):
Yeah, you might have said 00,beers, excellent. Did you have a
good weekend? Yes, fantastic.
You might even say, I don't likebeer even better. Did you have a
good weekend? That's theoutcome,
Lindsay Velecina (35:12):
right? Helping your outcomes is key. Yeah.
Simon Reindl (35:15):
So that was a very waffly answer. So look at
outcomes, not nonsense metrics.
Lindsay Velecina (35:21):
Awesome. Thank you. All right, so we have one
more question here, the scrummaster focused question. So you
pointed out that the scrummaster should push gently and
humbly. On the other hand, I'veheard that at the scrum master
you should also be uncomfortableand sometimes annoying. Do you
think these go well together.
What would you encounter if youheard something like this?
Simon Reindl (35:44):
Oh, yes, then, yeah, that's the thing is, if
you push gently and happilyconsistently for long enough, it
gets annoying,
Unknown (35:56):
um, go.
You know, constantly just,I have,
Simon Reindl (36:05):
I have an adult son, like he's still a teenager,
but he's technically an adultnow, and I am constantly pushing
gently and sometimes not toohumbly. You know, have you
thought about this or that? Youknow, at work, there's constant
times where we need to befocused on getting rid of
(36:28):
impediments, making thingsfaster, reducing cost of delay,
solving things and sometimes therepetitious asking right makes
it uncomfortable and annoying,because having that that truth
shoved in your face morefrequently can be quite tough.
Yep. So I think the two
Lindsay Velecina (36:50):
persistence is important, though. So yeah, just
gotta keep pushing, even if it'sgently and annoying,
Simon Reindl (36:59):
it's, it's, the practice, right? It's that doing
things daily, where it becomesit's a practice for a reason.
So, yeah, I do think that gentlyhumbly as well as uncomfortable
and occasionally annoying. I dothink it fits.
Unknown (37:20):
The interesting
Simon Reindl (37:21):
thing is the leaning into that curiosity with
positive intent. If people sayto you, hey, I find this
annoying, it's like, what aboutit makes it annoying for you.
Why are you finding it annoying?
Because typically, the thetruths that are most salient to
us are often the mostuncomfortable, right? You know,
the things that that otherpeople do that annoys us the
(37:44):
most are often the habits thatwe've got, yep, and the reason
it burns us up is like, geez, Ido that. I don't like doing
that, but it winds me up aswell. So, yeah, so I think that
they do relate.
Lindsay Velecina (38:01):
Awesome. Thank you. All right. So this was
great. Thank you so much fortaking the time to answer the
rest of our audience'squestions. Is there any final
piece of advice you want toleave people
Simon Reindl (38:12):
with? Just to reiterate the one of the key
points of scaling, you're goingto have to figure it out when it
comes to scaling, all bets areoff. Doesn't like I said at the
top. It doesn't matter whichframework you start with, you're
going to have to customize itand
Unknown (38:27):
tweak it right? It doesn't just come in a box. No.
Simon Reindl (38:31):
You know, we can't cookie cutter scaling, otherwise
every organization to beperfect. But what we do need to
do is do it experimentally. Doit, try and get short feedback
loops and just be comfortablechanging and mixing things up.
Unknown (38:48):
And, you know, get better, right? And it's the
goal, yeah, and
Simon Reindl (38:54):
don't confuse simple with easy. Just because,
you know, Scrum looks simple,but doesn't mean it's easy.
Exactly,
Lindsay Velecina (39:04):
All right, awesome. Well, thank you Simon
for taking the time. And in theshow notes, you'll see the link
to Simon's webinar and hisprofile and how to get in touch
with him and all that stuff. Andstay tuned for future episodes
of the scrum.org communitypodcast. And thank you, everyone
and Scrum on you.
Music. Welcome to the scrum.org community
(00:04):
podcast, a podcast from the homeof Scrum. In this podcast, we
feature professional scrumtrainers and other scrum
practitioners sharing theirstories and experiences to help
learn from the experience ofothers. We hope you enjoy this
episode. Okay, welcome to thescrum.org community podcast.
This is Lindsay bellascinahere@scrum.org and I am here
(00:26):
with PST. Simon reindell toaddress some open questions from
an early April webinar. How dothe scrum accountabilities work
at scale, practical steps fordelivery. So in this webinar,
Simon talked about scalingthrough the lens of the scrum
master product owner, developersand leadership, and also related
(00:48):
scaling to product portfoliomanagement. So welcome to the
podcast, Simon. Thanks
Simon Reindl (00:53):
for having me. I appreciate the opportunity to
answer some questions thatpopped up in the webinar.
Lindsay Velecina (00:58):
Yeah, there were some really great
questions, and I'm glad we couldtake the time to get these
addressed. So do you want to goahead and introduce yourself and
then maybe set the stage alittle bit for the Q and A
Simon Reindl (01:10):
Sure? Thank you so everyone. My name is Simon
reindell. I'm an Australianbased in the UK. Being a
professional scrum trainer,since 2010 I've had the honor to
perform all the accountabilitiesin Scrum, and I've worked in
some significant scalingsituations as well, and I work
from startups through tomultinationals, so I've seen a
(01:34):
lot of this stuff in my years.
During the webinar, I was tryingto really focus on the
difference between scaled Scrum,where you have many teams
working on a product, andportfolio, which is many teams
working on many products, right?
And I think it's important todistinguish between the two. And
(01:57):
the fundamental thing withscaling is we're still trying to
build an increment right scale.
Scrum is still scrum scaled.
Agile is still focusing ondelivering stuff. And so when
we're getting together andtalking about this, we're
talking about dependencies,integration and any impediments.
So if we can communicate thatstuff and resolve it quickly,
then we can deliver as a group.
Yeah, that makes a lot of sense.
(02:22):
So that's basically the lensthat I'm looking for that and
you know, the webcast is upthere on the scrum.org website
if you want to go back and havea look
Lindsay Velecina (02:32):
at it, yeah, and I'm including the link for
that in the show notes as well.
For anyone who's just tuning inand listening to this week's
episode, you can go back andwatch the webinar. So we had
quite a few open questions atthe end of the webinar, where we
had our Q and A session. Sowe're going to use this time to
get through the rest of thequestions that we didn't have
(02:54):
time for. So this I have themkind of organized into different
categories. So we're going tofocus first on agile frameworks
and scaling, and then we'll moveinto a few other topics. So in
this first one and the Nexusframework, there's only one
scrum master for many teams.
(03:17):
Does it work based on yourexperience?
Simon Reindl (03:21):
Yes and no, and it depends upon the capability and
capacity of the teams. Now, ifthe teams are really used to
doing Scrum, and they're reallycomfortable using Scrum, and
they don't require as much focusand effort off the Scrum Master,
it can work. So it's thatclassic, it depends. And I have
(03:43):
to say, for just about every oneof these scaling answers, yeah,
Lindsay Velecina (03:46):
I was just going to say, I think a lot, I
think all these questions thatwe're going through are going to
be kind of that it dependsanswer. So,
Simon Reindl (03:56):
yeah, context is king, right? Yes. When if
there's a lot going on, if theteams need help, as well as
there's challenges gettingthings integrated, you it is, I
would say it's more common tohave many Scrum Masters, like a
scrum master feature the teams,and one of them being the Nexus.
(04:18):
Scrum Master is probably morecommon than having one scrum
master for many teams.
Lindsay Velecina (04:23):
Okay, thank you. All right. So this is
another It depends. But what isthe ideal team size for a scrum
team when scaling? So maybe, ifyou want to share, like, some of
the things that you've seen withthis, because I know it depends
on the organization and theteam. Yeah. So
Simon Reindl (04:42):
I really want to channel my inner Ken as small as
possible and no bigger. That's avery zen like Ken answer. What
have I seen? I've seen teams ofsix being able to deliver a
workable increment. I've alsoseen. Seen a team of 15 where
they needed that number ofpeople because they needed that
(05:05):
mixture of skills to be able tocreate a an integrated
increment. I've also seen areally phenomenal group where
they would dynamically re teamevery sprint planning so they'd
have a look at what was going onduring that sprint, and they
(05:25):
would divvy themselves up intotwo or three teams,
Unknown (05:29):
right? And just track
Simon Reindl (05:33):
on with the work.
So my preference is to keepthose Scrum teams around the 10,
the magic number of 10. It'sjust the whole communication,
the focus. Now, when we scaleyou'll probably get used to
working with a group that islarger than that, and there's a
magic number of around 80 peoplethat you can maintain
(05:56):
professional relationships withand understand what's going on
and working together. Butthere's a reason sports teams
are stable, right? Americanfootball is an interesting one,
because the squads in that areso huge, yeah, talking, you
know, 5060, I think they canmaintain that network, and
(06:18):
people can step in and out ofthe tanks, but Right? So the
like, the exam answer is roughly10. The real life answer is
whatever works for you. I thinkthis is really important. When
we get to scaling, don't get sohung up on the framework or the
theory that you don't inspectand adapt and
Lindsay Velecina (06:40):
just figure it out, right? Awesome. Thank you.
All right, so what are yourthoughts on toolkits such as
disciplined agile and theCynefin framework to understand
and address the complexity andscaled Scrum?
Simon Reindl (06:56):
I love Cynefin.
Dave Snowden has done somereally good work there. And if
you have the opportunity to useestuarine mapping, it's a great
way of understanding what'sgoing on in your situation,
using the Cynefin framework tohelp understand your problem
space, really looking out forthose liminal areas between
(07:16):
zones. Awesome, disciplinedagile, like you know, is, I
don't think there's, there's nobad framework, right? And the
whole point of discipline Agileis a way of putting all the bits
together so that organizationscould deliver and one of the
great things that disciplinedagile was highlighting early
(07:37):
doors. Use the process, right?
Don't give lip service to it.
Don't do Agile theater, likefocus on it, ship stuff, close
the feedback loop and learn. SoI don't think there is a bad
framework or a bad model, if ithelps you deliver, right? Are
(07:57):
you connected to your customer?
Are you getting stuff done? Youclosing the feedback loop now
you improving anything thathelps you do that good, anything
that detracts from that bad?
Lindsay Velecina (08:11):
Awesome. Thank you. That makes a lot of sense.
So this next one here, so as itis a general, skilled agile
topic. Can you please give anexample and or scenario of when
to use, safe versus Nexus versusScrum, at scale versus Spotify,
(08:33):
all of them being scaled agileframeworks?
Simon Reindl (08:36):
Yeah. Okay. So first of all, I think there's a
link we need to put in the shownotes. I'll tackle the Spotify
one first. When most people saythey're using the Spotify model,
typically, they're referring toa blog article that Henrik
niburg published back in 2012right? And like, that's, that's
(08:57):
the seminal article aboutscaling, which is a snapshot
that he wrote with Spotify Agilecoach at the time of how a
particular group was working. Mynormal annoying question is,
people say, Oh, we're using theSpotify model. And you go,
Great. Are you a Swedish musicstreaming company in 2012 people
(09:17):
go, No. And I'm like, why areyou using their custom built
scaling framework? Because theydon't work like that anymore. I
think so, without trying to betoo flippant, but the whole idea
of guilds tribes communicatingthose patterns, so I think that
whole squad guild tribe model isa great naming convention and
(09:43):
way of communicating crossskills, right, right? So, if it
works great, but really Spotify,understood that when it comes to
scaling, you have to find yourown patterns and structure.
Messages to help yourorganization and your contextual
problem, and so blindly copyingsomeone else's pattern that
(10:08):
they've iterated on for them isusually dangerous,
Lindsay Velecina (10:12):
right? Because it was for them, it wasn't for
you, yeah,
Simon Reindl (10:15):
and it was also a snapshot, like at the time of
recording, it's 25 right? 2025,so it's 13 years ago. They have
changed since then. So if, whyare you taking the old model
like that's a 13 year old that'sa decade old model longer. So
use some languages. Use it as aninspiration for you to create
(10:38):
your own scaling framework.
Awesome, but don't just blindlycopy it. To be honest. That goes
with every other scalingframework included the beloved
Nexus from scrum.org, likethose. Don't blindly implement
it. Use it as a baseline. Ithink scaling frame,
Lindsay Velecina (10:55):
it's a framework. It's not something
that you take carbon copy andthey were just doing this, yeah,
Simon Reindl (11:04):
so I think this, the frameworks are a lot like
scales out of music. Like welearn scales so that we know
where the notes are, and then wecan use them to create music.
But just playing scales atpeople, it's not going to be a
really good concert. All right,so Nexus. Where's Nexus? Really
cool. It's really cool when youhave got a few teams that need
(11:25):
to work together, and you wantto start out doing that, so that
will scale. That'll scale toteams and teams of teams. It's
my personally preferred startingpoint for scaling, because it's
the lightest weight of thelight, right? Scrum at scale,
from Jeff Sutherland and ScrumInc, it's great because it
(11:47):
starts really describingpatterns to get your leadership
to engage. So it talks aboutorganizational change patterns
and organizational design, whichyou've got to get into when you
get into scaling and gettingyour organization to truly be
agile. So it's beautiful forthat you can add elements of
(12:08):
Scrum at scale on top of Nexus,
Unknown (12:12):
so that it's
Simon Reindl (12:13):
great, so that the you can mix it all together. And
that's the thing, like you canmix and match Safe is a
contentious topic. Some peoplelove it. Some people love to
hate it. The thing safe istypically for very large
organizations trying to be moreagile. I think it is a good
(12:35):
stepping stone to get people toconsider of how the feedback
loops work. One of my concernswhen you look at safe is it's
still quite top down, so thefeedback loops aren't as built
in. One of the contentiouspoints is a safe scrum master
(12:56):
and product owner does not equala scrum guide scrum master or
product owner, so be careful ofthat. So when we look at the
safe stuff is different. I knowyou've all done some good stuff
about Scrum and safe and thatthat's all available on the
scrum.or Yep, website. There
Lindsay Velecina (13:11):
was a there was a webinar a few weeks back
that he did on that so, and apodcast as well, I think, yeah.
So
Simon Reindl (13:21):
I'm going to defer to yuvals experience on that,
but it's a starting point. But Ireckon if your organization is
still using safe by the book,after a couple of years, you
probably haven't got the joke.
You're probably doing a bit ofagile theater at that point, and
you've just embedded stuff youhaven't iterated and learned. So
I think that that covers themall, doesn't it?
Lindsay Velecina (13:43):
Yeah, I think so that that was that was great,
great compare and contrast
Simon Reindl (13:51):
there, but take your pick, pick one. Start
there, change it.
Lindsay Velecina (13:57):
Yep, all right, so we're going to shift
gears a little bit for thesenext couple of questions. So
organizational agility anddecision making. So this person
wrote in my company keeps sayingthey are an agile enabled
company, but at the same time,decision making happens at top
(14:19):
management, where the result ofthe decision is shared, not the
input and process of thedecision making. These result in
people doing the work and notunderstanding the decision being
made in this session. Agilescaling needs to needs
information to flow accuratelyand freely within the
(14:40):
organization, so that thedecision making is understood by
the people who are doing thework. What first step can I try
to suggest to my organization totruly be an agile enabled
company, especially regardinginformation flow within the
organization? The big question,
Simon Reindl (14:58):
it's huge and.
It's so typical, right? And thefirst step is having doing some
investigation and finding outwhether the top management
believe they're communicatingsome of the some of the biggest
challenges we have as people, iswhen what we think is going on
(15:20):
is not what the other personthinks is going on. And so we
really need to tap into thestance that Stephanie and I
wrote about and in our bookmastering professional scrum
curiosity with positive intent.
So just like go up the foodchain and go, Hey, do you? Do
(15:42):
you? What do you think you'recommunicating? This is what
we're seeing. So that's thefirst thing. We've got to close
the loop. That's great advice.
You got to walk the talk aswell. So you've got to
communicate. You have to overcommunicate. And this is why I
love the work of Jocko will Nickand Leif Babbage in Extreme
Ownership dichotomy ofleadership, that whole thing
that we have to lead down, leadup, lead sideways. We everybody
(16:05):
needs to be a leader. So you gotto lead up. So you need to let
the people above you know thatthat communication is missing
some of the loop, you know, somethat high fidelity thing is
starting to lose a bit. So maybeyou just need to say, we'd like
to understand the reasoningbehind it. Yeah. The other thing
(16:27):
you could do, and this is wherenumbers, numbers are great. Love
numbers. Bit of empiricism. Getsome EBM going on. How long does
it take a message to flow fromthe top to the bottom, yeah. How
long does it take a message toflow from the bottom to the top?
If we did some math on it,what's the hang time for a
(16:51):
decision? Like, if you have togo up to get a decision, is
there lag to get the decisionmade. Turn it into numbers,
right? Because, if you've got,let's say your particular scrum
team, the average scrum teamcosts 70k a sprint, a two week
sprint, and let's say it takestwo weeks to get a decision.
(17:13):
Well, the cost of delay in thatinstance is 70k right? What
about if we got 10 teams? It'snow three quarters of a million.
Now, if you start bandingnumbers around like that, most
of the leadership will startpaying attention, because who
wouldn't like three quarters ofa million more money in the bank
account? I know I would.
Unknown (17:38):
So powerful metrics,
Simon Reindl (17:40):
money, money talks. You know, it's the golden
the golden rule of business.
Whoever's got the gold makes therules. So what we need to do is
to start talking about thatstuff. So to be agile enabled,
what we're trying to do is getthat information flow. We're
trying to create that space oftrust and communication and
empowerment. How can we starthaving scaling events where you
(18:03):
get better representation,better communication? I think
small steps,
Lindsay Velecina (18:12):
that's a good place to start. I think Awesome.
Thank you. Simon. All right, sowe're going to shift gears again
to portfolio and value streams.
So about portfolio level, what'syour opinion on using Value
Stream Mapping? Somebody asked,
Simon Reindl (18:29):
yeah, just do it.
Value Stream Mapping is awesome.
Do it in the team. Do it aportfolio. Try and understand
where the flow is, where youlock up, where's your decision
latency. Make sure, when you doit, you get a representative
sample the number of times I'vedone it. And the people on the
(18:50):
left think they're overcommunicating all the way
through, and the people on theright going, How come nobody
tells us everything, and we'regetting surprised and ambushed
all the time. And the people onthe left go, oh, but we tell you
it's like, man, no, you don't.
So having representatives ofeach of the different teams and
silos, you can see where thehandoffs and the lag is and the
die is. Value Stream Mapping isawesome. I love it.
Lindsay Velecina (19:15):
Okay, all right, so we're gonna refer to
one of the slides that were inyour presentation. So we'll jog
our memories. So question to theslide about the product owner
practices. What if the productowner is the CPO product VP or
portfolio lead, like Dave Westhad suggested in one of his
(19:39):
previous webinars recently, if aproduct owner is that high in
the hierarchy, then are theymore responsible for leading and
not driving product value? No,
Unknown (19:55):
flat, no. Right? Yeah.
Do.
Lindsay Velecina (20:00):
Their product owner? Yeah, it all goes back to
the accountability.
Simon Reindl (20:04):
It's the accountability the product
owner. Product Owner is a valueMaximizer. In fact, I would say
if they're a CPO product VP orportfolio lead, they're even
more on the hook because it'smore money. So if we go back to
that 70k team, let's say they'vegot 10 teams at 700k every two
weeks, they they better beshipping 700k worth of value
(20:28):
every two weeks, otherwise yourcompany will go broke. I don't
know any organization that canafford to hemorrhage that sort
of money.
Unknown (20:37):
So they are leading,
Simon Reindl (20:41):
and they are leading a product group who
should be delivering multiplefactors of value so many, many
moons ago, when I was working infinancial industry, they used to
say each engineering team neededto return 20 to one so for each
pound invested in theengineering team, we needed to
(21:05):
return 20 pounds worth of valueto basically make the company
more valuable. If your productowner at portfolio level or
product level at senior levels,if they are not using really
clear, evidence based managementvalue metrics. How are they
(21:26):
navigating and steering thatgroup? So I would suggest
they're even more accountablefor values because it's more
money. Yep, that makes a lot ofsense.
Lindsay Velecina (21:41):
All right, before I ask you this next
question, so I'm not going tocut this out. Is Art, what is
that average? Agile releasetrain. Agile train, it's a safe
term, okay, yeah, okay, allright, agile release train, so
I'll say that for the firstreference.
(22:11):
All right, okay, so this nextone, our portfolio manager is
only accountable for our agilerelease train while business
value is delivered in cross A RT teams value streams, really we
are not aligned that way, andour OKRs are for a r t only not
(22:33):
delivering value. How can I makeimprovements that are within my
control? How would you handlethis? And then in parentheses,
leaders are not agile or scrumtrained.
Simon Reindl (22:48):
Interesting. I think this is a wonderful
opportunity. Okay, there you'rein that that situation. Have you
ever seen Band of Brothers? Thestory about there's a wonderful
scene in band of brothers whenthey're about to go into
Bastogne, and the paratroopersare going in and the regular
(23:11):
infantry are coming out, and oneof the Champs mentions to the
commander. He said, Oh, what areyou doing? You're going to go in
there and you're going to besurrounded. And you said, Son,
we're paratroopers. We're meantto be surrounded. You're in that
situation, in this where yourleadership don't understand the
(23:32):
process they're trying toimplement. What is in your
control is educating yourleadership. So you need to start
finding ways to influence themand help them understand these
concepts of fast feedback loops,these concepts of cross
functional teams. Now we'retalking about cross functional
trains, because what you've gotis a disconnect here. So if your
(23:57):
OKRs are for your your train andthey don't, and the only way of
delivering value is acrosstrains. You've basically got
useless metrics. I don't carehow many revs your engines doing
if you haven't connected it tothe wheels, and this is one of
(24:21):
the dangerous things. You canmeasure everything, and it tells
you nothing,
Unknown (24:25):
right?
Simon Reindl (24:26):
So, how would I handle this? The pending on my
remit, and this is where, in thepresentation, I offered people a
model where it said, purpose,constraints, trust. It was a
simple Bullseye model. We've gotto start off with purpose. You
need to determine what yourconstraints or boundaries are,
what's in your gift. Now, themore trust we build up with our
(24:52):
leadership, with our peers, thelooser the constraints will
become. So you need todemonstrate your competence of
what. You're doing, so that yourportfolio manager will then
support you, and your discussionyour leaders will support you,
and you can then be listened toand trusted. Because if you're
not trusted, it doesn't reallymatter what you say, they'll
(25:13):
just go either they're justmaking noise. You have to be
careful about this, and it tookme a few years to realize this.
And people don't listenlogically. People listen
emotionally. And so if youapproach your senior leadership
and go, You guys haven't got aclue, that's not going to get
(25:35):
you anywhere. Whereas if youapproach like and you see this
when big ships come into harbor.
Tugboats come alongside them fora reason. There's no way a
tugboat can push against theship, but it can go along and
nudge aside. You need to buildpartnerships. You need to build
relationships. You need to growyour trust. You need to help
people understand that and thinkabout what's an experiment you
(25:56):
can run. Is it possible to bringin a metric across release
trains, try and explain it insuch a ways. Where can you
measure your customer value andyour customer impact, helping
leadership understand trueevidence based management
metrics? What is it that yourproduct is really needing? Is it
customer satisfaction? Is itmarket reach? What's the magic
(26:18):
number? How are you matchingwhatever that magic number is?
Go up and lead the put the dotsdown so that the leaders can
connect the dot and then own thedecision to try and experiment.
So love it got to be careful.
Yeah, because you're callingsomeone else's baby ugly at this
(26:40):
point, yep.
Lindsay Velecina (26:43):
All right, so next we're going to dive into
roles and career paths. So sothis person wrote in Please,
Your opinion is important as abusiness analyst, is it better
to go into the scrum master orproduct owner accountability? We
know that it depends. But goahead,
Simon Reindl (27:03):
which one do you want to do? It's as simple as
that. You know doesn't reallymatter. You know, you could be a
great scrum master. You could bea great product owner. The
choice is the one which youprefer. Why not give each them a
go? If you can, because if youspend some time in either role,
(27:23):
is going to help you be moreempathic when you inhabit the
other role, right? Oraccountability, oops, use the
role word that only changed fiveyears ago. Okay, still gets me.
Yeah. So when we're consideringour key our careers, think about
where you want to be, one year,three years, five years, what's
Unknown (27:47):
going to get you there and
Simon Reindl (27:50):
a little bit of time in each role. And I would
suggest, perhaps, unless you'vetried either of those
accountabilities, it's going tobe hard to make a choice. And
the thing is, no choicesforever. So you could give a
role a go for a year or so, andthen change on if you don't like
(28:11):
it, if you love it, just leaninto it. Sometimes we don't
know, we don't know the suitfits until we try it on, right?
Lindsay Velecina (28:20):
I like that advice. All right, so this
person wrote in today, I was inan interview for a role of an
agile project lead, where therole was supposed to be a
combined role of a scrum master,a project manager, and at the
same time having one on oneswith team members and conducting
(28:42):
performance reviews, even if itis a flat structure
organization. This sounds to melike a line manager role at the
same time. I guess thatcombining three roles is too
much. They're probably savingmoney and too much
responsibility for one person.
What do you think? Yeah,
Simon Reindl (29:02):
like Run DMC said it's tricky, tricky, tricky.
That That sounds quite busy.
There is like having one to onewith team members and
performance review. That's clearline management stuff and
project managers, their style ofoperation is orthogonal to that
(29:23):
of a scrum master. A scrummaster should be asking, not
telling. Project managers oftentell, don't ask. But really,
really good project managersoften act like Scrum Masters and
empower their people. So goingback to the bulls way, model of
purpose, constraints, trust.
Unknown (29:45):
You could form this.
You need to get really good atdelegating. You can delegate a
lot of this stuff, right?
Remember, a scrum Master's dutyof care is to reveal, not
resolve.
Simon Reindl (30:01):
So what you can then look at is you're the Agile
Project Lead great cultivatesomeone else, to people to be
Scrum Masters, to people to beproject managers, and depending
how big the team is, mentorpeople to get really good at
conducting performance reviews.
What about helping the team selfmanage their performance
(30:24):
reviews? Change the culture, mixit up. The only constraint I'm
hearing is that that stuff's gotto get done. Wouldn't it be
great if you created triads sothat each group of three people
had to conduct mutualperformance reviews of each
other. Yeah, and your your dutyof care is to coach it like just
(30:45):
find different ways, novel waysof doing it and leading projects
for external clients. I'mconfused like, if you're an
agile project lead, why are youbehaving differently with
external clients? Yeah, guessingyou're a consultancy or
something here, have a look atthe contract. See if the
contract can be written in amore agile way. Look at lean
(31:07):
agile procurement. There's awhole bunch of ways of building
contracts and collaboratively.
Look for the win, win with theclient, and start doing Agile
like change the interface withthe clients.
Lindsay Velecina (31:21):
Awesome. Thank you, Simon, make the job that
you want to do? Yeah, it couldbe a really great opportunity.
Yeah, great. So these lastcouple questions are scrumm and
agile practices questions alittle more general. So when
there is a different opinionbetween the product owner and
(31:41):
the scrum master about animportant change to make on the
objective of the product whoseopinion should prevail?
Simon Reindl (31:50):
Product Owner next, right? Let's open and shut
that's like smack it out of thepark. The the scrum master is
about the process Exactly. Now,if you'd said product owner and
developers, I'd say aconversation. This is one of the
things that is so challenging. AScrum Master is a true leader
(32:15):
that serves their focus is onhelping everybody understand and
execute on the process, notabout the product that is the
product owner. The scrum mastershould be supporting the product
owner making the decisions, nottrying to second guess or
influence that opinion. Butthat's nice. Keep it to
(32:37):
yourself, let the product ownermake the call.
Lindsay Velecina (32:42):
All right, so this next one. So what's the
best way to report on progress?
Because business, the business,doesn't understand velocity, and
then in parentheses, does notreally, for example, I've been
questioned velocity in the lastsprint was 25 why was it 20 for
this sprint?
Simon Reindl (33:05):
My team wasn't sleeping. Just that the US. I
think that's the user story, thePBI. Okay, I was wondering.
Yeah, that's my guess. Okay, sothe, this is a classic one.
Lindsay, this is nonsense.
Metrics, right? Velocity is atool for the team to understand
(33:29):
throughput. What's the best wayto report on progress a done
increment. That's it. This iswhat we have done. What about
PBI count? What it's also smellslike to me is the business
doesn't understand throughputthe business. The thing is that
product backlog items can bevariable in size. Now you should
(33:51):
be doing a few PBIS a sprint,like if you're only doing one
PBI sprint, I'd suggest you'reprobably not refining enough. So
I'd try and break them down alittle bit smaller, take smaller
mouthfuls, bite sized chunks.
You know, what's the best way ofreporting or demonstrating
progress, value delivered? Havea look at some evidence based
(34:14):
management metrics. Is yourcustomer satisfaction going up?
Have you generated more revenuefor the organization. Are you
releasing more frequently iscalls to the Support, Support
Center or call center droppingwhatever it is. Find metrics
that really matter, not somearbitrary one. You know, because
(34:40):
velocity is so easy to gain.
It's, it's a, it's useful toolfor to help the team understand
things, but it's not really forbroader consumption, right?
Okay, do, do I really care howmany beers you drink on the
weekend? No, that's your job,right? Whatever. Well, did you
have a good weekend that. At us.
(35:00):
Yeah, you might have said 00,beers, excellent. Did you have a
good weekend? Yes, fantastic.
You might even say, I don't likebeer even better. Did you have a
good weekend? That's theoutcome,
Lindsay Velecina (35:12):
right? Helping your outcomes is key. Yeah.
Simon Reindl (35:15):
So that was a very waffly answer. So look at
outcomes, not nonsense metrics.
Lindsay Velecina (35:21):
Awesome. Thank you. All right, so we have one
more question here, the scrummaster focused question. So you
pointed out that the scrummaster should push gently and
humbly. On the other hand, I'veheard that at the scrum master
you should also be uncomfortableand sometimes annoying. Do you
think these go well together.
What would you encounter if youheard something like this?
Simon Reindl (35:44):
Oh, yes, then, yeah, that's the thing is, if
you push gently and happilyconsistently for long enough, it
gets annoying,
Unknown (35:56):
um, go.
You know, constantly just,I have,
Simon Reindl (36:05):
I have an adult son, like he's still a teenager,
but he's technically an adultnow, and I am constantly pushing
gently and sometimes not toohumbly. You know, have you
thought about this or that? Youknow, at work, there's constant
times where we need to befocused on getting rid of
(36:28):
impediments, making thingsfaster, reducing cost of delay,
solving things and sometimes therepetitious asking right makes
it uncomfortable and annoying,because having that that truth
shoved in your face morefrequently can be quite tough.
Yep. So I think the two
Lindsay Velecina (36:50):
persistence is important, though. So yeah, just
gotta keep pushing, even if it'sgently and annoying,
Simon Reindl (36:59):
it's, it's, the practice, right? It's that doing
things daily, where it becomesit's a practice for a reason.
So, yeah, I do think that gentlyhumbly as well as uncomfortable
and occasionally annoying. I dothink it fits.
Unknown (37:20):
The interesting
Simon Reindl (37:21):
thing is the leaning into that curiosity with
positive intent. If people sayto you, hey, I find this
annoying, it's like, what aboutit makes it annoying for you.
Why are you finding it annoying?
Because typically, the thetruths that are most salient to
us are often the mostuncomfortable, right? You know,
the things that that otherpeople do that annoys us the
(37:44):
most are often the habits thatwe've got, yep, and the reason
it burns us up is like, geez, Ido that. I don't like doing
that, but it winds me up aswell. So, yeah, so I think that
they do relate.
Lindsay Velecina (38:01):
Awesome. Thank you. All right. So this was
great. Thank you so much fortaking the time to answer the
rest of our audience'squestions. Is there any final
piece of advice you want toleave people
Simon Reindl (38:12):
with? Just to reiterate the one of the key
points of scaling, you're goingto have to figure it out when it
comes to scaling, all bets areoff. Doesn't like I said at the
top. It doesn't matter whichframework you start with, you're
going to have to customize itand
Unknown (38:27):
tweak it right? It doesn't just come in a box. No.
Simon Reindl (38:31):
You know, we can't cookie cutter scaling, otherwise
every organization to beperfect. But what we do need to
do is do it experimentally. Doit, try and get short feedback
loops and just be comfortablechanging and mixing things up.
Unknown (38:48):
And, you know, get better, right? And it's the
goal, yeah, and
Simon Reindl (38:54):
don't confuse simple with easy. Just because,
you know, Scrum looks simple,but doesn't mean it's easy.
Exactly,
Lindsay Velecina (39:04):
All right, awesome. Well, thank you Simon
for taking the time. And in theshow notes, you'll see the link
to Simon's webinar and hisprofile and how to get in touch
with him and all that stuff. Andstay tuned for future episodes
of the scrum.org communitypodcast. And thank you, everyone
and Scrum on you.
Popular Podcasts
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!
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.