AA216 - New Scrum Guide Expansion: Revolutionary Update or Unnecessary Complexity?

The Scrum community is buzzing about a new 55-page expansion to the Scrum Guide. Is this the depth practitioners have been asking for, or is it turning the lightweight framework into bloatware? 

In this episode, Enterprise Business Agility Coach Om Patel and Product Manager Brian Orlando critically examine the "DLC" that claims the original guide was "deliberately oversimplified." 

We explore new concepts like outcome vs output definitions of done, the "supporters" role, and the inclusion of complex frameworks like Cynefin.

Stick around as we debate whether these additions help teams navigate complexity or create more confusion, while highlighting crucial omissions around organizational structure and practical implementation guidance. 

#Scrum #Agile #ProductDevelopment

= = = = = = = = = = = =

LINKS

= = = = = = = = = = = = 

http://arguingagile.com

YouTube

https://www.youtube.com/@arguingagile

Spotify 

https://open.spotify.com/show/362QvYORmtZRKAeTAE57v3

Apple

https://podcasts.apple.com/us/podcast/agile-podcast/id1568557596

= = = = = = = = = = = =

Toronto Is My Beat (Music Sample)

By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)

CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Episode Transcript

(00:00):
What if I told you there wasa new ex new Scrum guide, DLC

(00:04):
that's a new expansion pack.
Ooh, tell me more.
55 pages, just short of25,000 words, that claims.
The original scrum guide was,deliberately oversimplified,
and it was done so formass adoption and now is
time for the real deal.
Nice.
Well, it's good to hearthat the new one is.
A little more elaborate,but four times the size

(00:26):
of the previous one.
How much would you pay for that?
Would you pay by the word itm?
Trying to, I wouldnot pay by the word if
there's like 25,000 words.
I'm trying to, I'mtrying to pitch you on my
Dickensian scrum guide.
Oh yeah, yeah.
That's what I'm tryingto pitch you on.
But that was a literaryjoke for two people.
critics mainly LinkedIninfluencers that I've read

(00:47):
will say that it turns thelightweight scrum framework
into blow wear, basically.
Not so lightweight.
So we're gonna find out today,we've parsed the document.
We've looked for thingsthat stick out to us.
We're gonna talk about thosetoday in our normal framework.
So there's a new DLC out.
We're looking into it today,and we're gonna find out
that it is it, is it thescrum guide that we always
needed but didn't deserve?
I always screw upthat Batman line.

(01:08):
Sorry.
Is it a scrum encyclopediainstead, or what is it?
or is it destroyingsimplicity, right.
And is the opposite.
We've broken up the guideinto 10 distinct points we're
gonna walk through in noparticular order, like the
right, they're all, they'reall good to talk about.
Normally on a podcast, we'll gothrough an ordering on this one.
They're all good to talk about.
So we didn't go through anykind of ordering exercise
like we normally would.

(01:29):
I think that's okay.
We're gonna try to.
Zip through theseas fast as possible.
Hopefully we will contain thispodcast to an hour because
this could be very dry stuff.
the first point isself-managing teams versus
individual self management.
So the, the scrum guidehas a distinction between
self-managing scrum teams.
They're not to be confused withindividual self-management.

(01:51):
Okay.
Scrum guide's on the screennow it says a self-managing
scrum team checks whetherthey are on track, takes
actions when they're not ontrack, decides how to work
resolves scrum conflict andfixes, problems with fixes,
problems in the scrum team.
That means that , generallymanagers, if they're part of
the landscape, do not tellthe Scrum team what to do or

(02:11):
decide which Scrum team memberneeds to be taken aside to fix
issues directly or indirectly.
If managers exist, it'sgenerally better They
demonstrate leadership.
Okay.
None of that is new so far.
Let me keep going.
Self-managing.
Scrum teams organized aroundvalue are critical for
creative problem solving andcapturing emergence reliance
on non self-managing Scrumteams hinders the ability

(02:34):
to deal with complexity.
Did I just read that right?
you did.
I think they're talking abouthaving autonomy at the team
level on what to work on andof course how to work on it.
And this is, again, Idon't feel this is new.
Oh, I see, so it's sayingnon self-managing scrum team.
So if you have non.
Self-managing scrum needs thatyou're just telling what to do,
then they're not gonna be ableto deal with complex problems.

(02:56):
Yeah okay.
I understand.
Yeah, I agree with you.
I don't think this is new.
Maybe it wasn'tstated like that.
Which also stated likethat I don't know if a
lot, it's not the best.
I don't know if a lot ofpeople are gonna get what
he's trying to Yeah, yeah.
Put across the table there.
It's not the bestway to, to phrase it.
Okay.
So, self-managing scrum teamsare not to be confused with
individual self-management.
It is the seamlessinterplay that allows

(03:17):
a great team to emerge.
The facilitation of teamautonomy and more efficient
decision making within anon-hierarchical structure
could help Scrum teamsimprove their self-management.
Did I say Dickensian atthe start of this podcast?
You, you did.
And listen this paragraph talksabout a term called individual
self-management, but itdoesn't, it's elaborate on that.

(03:39):
It just says.
Yeah.
This, this is not to be confusedwith individual self-management,
but that's the extent of it.
It doesn't really elaborateon it, and I feel like they're
missing a, a trick here.
They should, right?
Because individualself-management is how teams
can flourish as a team, right?
When everybody exhibitsthose behaviors of

(04:00):
individual self-management.
Alright.
There's 13 references in thedocument to self-management.
Two of them are in thesection we just read.
Let's look at whatthe other ones are.
So he's saying, he's sayingself-managing Scrum teams are
not gonna be confused withindividuals who can self-manage.
I'm guessing he's saying that'sdifferent from an individual
who can do complex things bythemselves, but not a whole team
that can do things by themselvesbecause 'cause our claim here

(04:22):
was the self-managing scrumteams not be, not to be confused
with individual self-management.
Right.
Yeah.
I think I'll read alittle bit more into that.
Even though, like you said, hedoesn't really specify it, or
they don't, I should say, soit's three people that were the
authors of this expansion pack.
Mm-hmm.
So one of the things I readinto it is individuals as

(04:43):
individuals can actuallyself-manage and, and, and do
the right thing But when youhave a bunch of them together,
there's some friction there.
Because you and I couldbe on a team, you say,
we need to do this thing.
I say we need to do that thing.
How do we reconcilethat as a team?
And they didn'tspecify any of this.
They didn't actuallygo into it in the whole

(05:04):
document that I could find.
But I do feel like that issomething that many teams do
struggle with especially whenyou have a team that's self
organizing, self-managing,but you have a tech lead
that is essentially dictating. To the rest of the team.
What they should be working on.
Because the same thing thathappens with the Scrum team
being dictated things to workon, happens with individuals.

(05:25):
So like I just, I basicallysee this statement.
I mean, a spoiler alert, there'sa lot of stuff in here that I'm
like, somebody did not get aneditor, or maybe there was an
editor in this document and theywere just like too scared to
suggest like, maybe we shouldcut that, because om wrote
that and he's really smart.
We shouldn't suggest cutting.
Right.
, I would've cut this outto be like, listen man,

(05:47):
everyone knows that.
Like there are people thatjust work by themselves.
Scrum doesn't change it.
There are some people thatare really smart individual
contributors that go anddo stuff on their own.
like I've been on teams whereyou have teams and then the
team lead is split acrossteams, but the team lead.
Is also like thearchitect, right?
Or in like largerorganization, we have like
a enterprise architector something like that.

(06:08):
Yeah.
But maybe they'reactually a good enterprise
architect, meaning theyactually work, right.
And don't just come downfrom the ivory tower with the
stone tablets of requirementsmaybe they're actually a
working individual contributorand someone who helps with
architectural concerns.
Basically integrationacross systems.
An individual, a single personis not gonna say, okay my team

(06:28):
is responsible for the videoupload functionality and your
team is responsible for allthe audio functionality, which
has to do with audio upload.
But maybe we share a mediaupload function, right?
That neither one ofour teams wholly owns.
But when we wanna modifyit, we have to get
this additional person.
To come in and sit with us.

(06:49):
But what this points outis like, well, you've got
individual contributors who aremotivated to take ownership of
problems, development problems.
Yeah.
And it's trying, like I, I,again, I'm just extrapolating
'cause I just don't thinkthis is a good listen, we are
all extrapolating 'cause itdoesn't have the detail here.
Right.
So you have yourown extrapolation.
You know, mine is along the samelines but slightly different

(07:10):
in that he's talking aboutindividual self-management.
Talking about people that arelike the lone wolf developers
saying I'm gonna go work onthis because I think that's
the right thing to do andI'm an expert at, yeah.
So I'm gonna go get itdone 'cause you're pricing
my contribution as, canhe finish or she finish
the work in the sprint.
Yeah, I can do this soyou're gonna have that.

(07:31):
And when you havemultiples of those on
your team, you basicallyhave a divergence, right?
Mm-hmm.
Of what people are working on.
And that doesn't really help.
Yeah.
Because you're not workingtowards a common product goal.
Yeah.
Or sprint goal in this case.
Okay.
Lemme throw rocks for a second.
If I were to rework thissection, what I would do is I
would start with the extremeownership version of it.

(07:52):
I would start with theextreme ownership version
of this and point out ifyour team is composed of
individuals who cannot takeownership or who cannot
self-manage their own stuff.
And then when they joina team that's supposed
to be a self-managingteam or a self-organizing
team, self-managing isthe term he's using.
So if they can't self-managethemselves, then when
they're part of a team thateveryone's meant to work

(08:13):
together and self-manageas a unit, as a group.
How are they gonnacontribute to that?
I would've used this as astepping stone to say at
first, let's make sure peoplecan self-organize themselves,
self-manage themselves,and then when they're part
of a larger body of folksworking on a shared problem,
it's a different problem.
Like, you can motivate andyou can figure out how to

(08:34):
take ownership of a problemand drive it to resolution.
And now you have to do thatand also communicate with
the people to your left andright, every step of the way.
Yeah.
but it's a building block ontop of a smaller skill that
I think is easier to master.
Hey, first, master this onething, pick a problem, get
as much help as you need.
We're not saying you have tosolve the problem alone, Let's

(08:54):
take that first step first, andthen the next step above that
is like, okay, now let's workon helping your buddy to your
left and your right, they'rehelping you or your problem.
Now we all help every eachother with all of our problems.
Now we have a pathtowards self-organization.
Whereas like if I justtake the section, I'm
like, okay, that's cool.
We should do that.
I believe you.
How?
Right?

(09:14):
Yeah draw me a roadmap.
'cause my team doesn'tknow how to do that.
I have a bunch of juniordevelopers or a bunch of people
who call themselves developers,but really are just marketers
who are using the AI tool.
Sorry, I got, oh, thatone hits close to home.
I was like, oh my goodness.
Oh, I've got a real team whodoesn't know how to do this.
Yeah.
They're learningfor the first time.
Yeah.
I think underneath all of thatis the ethos that if you have

(09:38):
individual contributors thatare just basically doing their
own thing what you don't haveor, or not, because they might
not feel empowered to act.
Well there's that too.
So there, there's.
Yeah.
So that, that's partof that first step.
The first step is like, hey,take ownership of it is like,
Hey, you own the whole thing.
Yeah.
And that goes back to theextreme ownership that
you mentioned, right?
yeah.
Absolutely.
Well, we do have peoplethat are doing their own

(09:58):
thing 'cause they believeit's the right thing to do.
Not only do you have thiskind of diversity of thought
and what the goal really is.
it becomes obfuscated.
What goal are wemarching toward?
But you also have this ideawhere people are gonna look
at other people that arestronger personalities.
And say they're doingtheir own thing.
This is obviouslywhat's expected of us.

(10:20):
And they'll hide behindthat and say, well, the
team's doing this, so I'mjust doing my own thing.
I'm just refactoring the librarycode or whatever it might be.
So this is reallynot a good thing.
I think coming back tothe whole point that they
mentioned here, they sayself-managing, but they don't
have any tips on how to improveindividual self-management.
Yeah.

(10:40):
They do have references,however, right.
Of the hundreds that point toin research papers perhaps yeah.
And I think the casual readerwho's interested in following
the expansion pack will behard pressed to get the value
out of this specific topic.
let's move on to the nextcategory, which is the
definition of outcome done.

(11:00):
Definition of outcome done.
And I think the pointhere is measuring value
versus measuring output.
I think that's what he'strying to get across.
I think you've nailed it.
So traditional measures ofdefinition of done are really
talking about the number ofitems you get to done right.
And this is going a littlebit beyond that saying.
Really it's about the outcomedelivered rather than the

(11:21):
number of features deliveredinto an environment production
or whatever it might be.
That's where thedistinction is drawn here.
I think a lot of it boilsdown to what is your goal?
Is your goal let's sayyou're sprinting and
what is your sprint goal?
Is your sprint goal tofinish all these features?
I can't tell you the numberof times I've seen teams
just simply list a collectionof features or stories that

(11:42):
they've committed to inthe sprint and say, this
is our goal and they'recompletely missing the point.
This is typically whatwe have a weak product
person in, in, in the team.
Yeah.
They don't reallylead with a goal.
So it's often when you seethis, it's always back to
front, meaning the teamcommits to a bunch of user
stories, pbis, whatever it is,and somebody looks at those

(12:04):
collectively and says, what's aholistic description of those?
And that's our goal.
That's back to front.
It should start with thegoal, and the question is
asked, what do we need todo to achieve this goal?
If this goal is too lofty, sowe can't deliver it in a sprint,
let's break it down and that'son the product owner to do that.
And oftentimes I see weakproduct ownership where

(12:25):
this doesn't happen.
so the commitment definitionof outcome done, let's see.
It's, so, are there anymore definition of output?
Done?
The definition of outcome done.
So there's two definitionsof done in here.
Oh boy.
Oh boy.
There's a definition ofoutcome done, and down here
under the increment is thedefinition of output done.

(12:46):
Let's read thedefinition of output.
Done.
Definition of outputdone every time.
I said it 15 times and nowit means, has no meaning.
The definition of outputdone is a commitment.
It formally describesthe quality measures that
express due diligence forthe increment, so it could
be delivered to stakeholders.
Woo.
Boy.
I'm gonna keep going.
I see your face.

(13:07):
I'm gonna keep, I see itoutta the corner of my eye.
Yeah.
Ignore me for a bit.
I'm gonna keep going.
Yeah, yeah, yeah.
The definition of outputdone typically includes
but is not limited toboth technical standards.
And this is how I know thedocument was not edited
this, but not limited to.
Both technical standardsand product qualities.
It scrum team.
Creates, if not provided bythe organization as a minimum.
There's multiple scrumteams of the same product.

(13:28):
They share, the samedefinition of output done.
So this is the definition ofdone now in the future, which
is different than the previousdefinition, which is the
definition of outcome done.
Definition of outcomedone is a commitment.
It describes the observableevidence, measures quantitative,
or qualitative requiredto demonstrate realized
benefit, often referredto as value validation.

(13:51):
Okay, I'm with them on this one.
I mean this whole thing couldhave been three sentences.
Sure.
It could be for theoverall product.
Or a specific goal.
It's often best to definethe measures of value
validation before realizationstarts, starts that.
Does that mean development?
Yeah.
Well, no, that means actualdelivery to the customer.
Okay.
Outcomes and relatedinterpretations and form future

(14:11):
adaptations ideally confirmingthe intended stakeholder impact.
Okay.
Favor, direct evidence overcircum circumstantial evidence.
For example, customer outcomescould focus on delivering
measurable value to customerssuch as increased customer
satisfaction, customer long-termcost reduction, or the number
of customer jobs addressed.

(14:32):
Product stakeholderoutcomes could connect
these behavioral changes toproduct performance metrics,
business stakeholder outcomes.
Compliance business,long-term risk reduction.
Risk re scrum teamoutcomes such as improved
technical capability.
Okay.
User experience, UX orcustomer experience, CX
debt is the sum of designand implementation choices.

(14:52):
Intentional or not, that makea product or service less
usable, enjoyable, or effective.
Okay.
That's, that's, thatis what, that is.
The, but that's just atextbook definition of it.
Recognizing, tracking, oraddressing the debt is essential
for delivering products thattruly meet the user needs.
I mean, I agree withthose statements, but
those are just statements.
They are just statements.
That description youjust read isn't all that

(15:14):
different than what was inthe original scrum guide.
Definition of done.
I feel like they've added aphrase there that kind of raises
eyebrows, at least for me.
Right.
Psychological flowor whatever it was.
Because you go back tothat, you'll see, I don't
know what that even meansin that last bullet.
See, scrum team outcomesas such as improved
technical capability.

(15:35):
Psychological flow.
Wait, wait, wait.
Oh, for example, scrum teamoutcomes such as improved
technical capability.
Psychological flow,that's a reference 70.
Let's go find outwhat 70 is The flow.
Flow, the psychology of optimalexperience . harper and Roe.
It is nine pages.
Mm-hmm.
Is there like a summaryor This is the summary.

(15:58):
This fascinating.
Book's all about happinessand how to find it.
Building Inner Harmony.
Our level of happinessultimately depends on how our
mind filters and interpretseveryday experiences.
Okay.
So look, I already got it.
I like it's CX basically.
I already got it.
and, but this is inwardfocus to the team.
Absolutely, so we're readingthis paper , let me show
everyone that we're readingthis., We've downloaded this

(16:20):
I think it's a book, butmaybe this is the, paper.
This fascinating book isall about happiness and
where to find it I thinkhe's talking about, this
book flow, the Psychologyof Optimal Experience.
But the reference is tothis paper about the book?
Yeah.
Okay.
So as you know, on thepodcast, we will go and
research the entire book andthe author find their house,

(16:40):
live there for a week, andthen do a podcast about it.
That makes a lot of sense to mebecause the, this last bullet
point, scrum, scrum teams out,scrum team outcomes such as
improved technical capability,tech, debt, ux or cx.
Like Yeah, of courseyou would reference the
and psychological flow.
So basically your, yourpsychological flow through

(17:01):
the application is like muchmore pleasant and pleasing.
It's an application you liketo use as opposed to, for
example, using other productsthe polar opposite is products
that we all are forced to usethat we like, find thoroughly,
like terrible as an experience.
I was gonna say JiraOh, yeah, yeah, yeah.

(17:21):
Jira too.
Yeah.
That's interesting.
So, psychological flowhere is referenced from the
perspective of the customer,those that are benefiting
from the work of Sprint.
Well, I think it could be ifit's technical debt or CX work.
It could be the team too.
I mean, the team might reallyenjoy internal customers.
The team might enjoy thatkind of stuff, you know.
So this was a minor changeyou're adding an extra term.
So it's not definitionof done anymore?

(17:42):
No.
It's outcome done.
Output done.
Okay.
And output done is reallyjust definition of done right.
And then all, all thedefinition goes to there.
And then this new outcomedone is a separate definition.
Yeah.
Which means it'sthat extra swim.
Oh no.
It's that extra column on theboard of saying like, did we
validate with the customer thatwhat we did actually solve the
problem that nobody does nobody.

(18:04):
They just get the item todone when it's dev done Right.
And test done right.
And that's it.
So yeah, absolutelyagree with that.
This is like that, Obama quoteof like, being a president
is like being the captain ofa big ship, being the person
steering a big container shipand like you can turn the wheel
but you're only allowed toturn the wheel a certain number
of degrees ' cause turningmore, might brake something.
Yeah.
And then like you don'tget to immediately see the

(18:25):
results of you're turningthe wheel like one degree.
You have to wait.
Yeah, for a while.
That's a great analogy.
I agree.
Like that, that's this, it'slike you can add definitions
here in the DLC or whatever,the main video game of Scrum,
I don't know if you're gonnaaffect that with this is like
the, the, the getting peopleto add another column and just
make that the way it is acrossthe board forever without

(18:46):
explicitly telling peoplethat's what they need to do.
If I wrote this, I would givepeople a graphical example
of like, this is what yourboard probably looks like
and it probably would looklike their board, right?
Especially if you're, if you'reJeff Sutherland or one of these
guys like you, you know what90% of people are showing.
Here's your to-do, doing,done or whatever to do
qa, you know development,doing development, done qa,

(19:08):
doing qa, done whatever.
You probably like.
Here's a half a dozentypical workflows of the
way people do Scrum, right.
And to all of these, you needto add a column at the end
after done that says, validatingwith the customer and then
after that, done, done, doneor whatever Val, value done.
Outcome done.
Outcome done.
Yeah.
So I would say on that, onthat front, maybe it would

(19:30):
be better to have a columnahead of done that says,
validating with the customerand then you're done once you
validate it with the customer.
Right now, the teams maybulk at that because the
lifecycle becomes longer.
Right.
But the overall impactof what you're delivering
is much more exacting.
You, you're actually gettingthose metrics back from the

(19:51):
customer and the signalsthat say we hit the mark
or we didn't hit the mark.
I might just have.
You know, doing, whichis all of those things
you described, right?
Development in progressQA in progress, et cetera.
And then validatingwith the customer.
Now, sometimes an item couldsit there for a while, right?
Because you don't haveaccess to the customer.
You can fix those thingsand then get to done.

(20:13):
Once you get to done.
It's like, okay, we've,we've actually confirmed with
the customer, they receivedthe value they were Hoping
to get out of this, right?
Also incidentally, doing it thatway gives us the opportunity
to get the feedback thatwe need from the customer.
Oh, I thought you were gonna,I thought you were gonna
go where I was gonna go.
Which is , like doing itthe way that I suggested,
which is also the waythat this document infers.

(20:35):
this document doesn't dictatehow you're gonna do things, but
it also doesn't get into thenitty gritty of helping teams.
The teams still have toextrapolate from this document
the best way to do it.
most teams I saywould extrapolate.
The way that I Yes, agreed.
Just suggested, agreed.
However, step into my office,the better way to do this
would be for that definitionof outcome done , that
column needs to come beforedevelopment starts working.

(20:57):
Oh, you have to define thedefinition way upfront.
I do agree with that it'sjust the validation of that.
Once you've done the work, , ifyou are not putting up silos
and your development teamtruly is self-organizing,
self-managing self, whateverterm you want to use in any
addition of scrum guide, likethe development team, this
shouldn't be the designer's job.

(21:18):
This shouldn't be theproduct manager's job.
This shouldn't beMarty Cagan's job.
This shouldn't beany of their jobs.
It should be.
The team's job to say like,are you sure doing this is
what the customer is, is what'sgonna solve their problem.
Right.
And , you can stub outsome stuff in Dev that's
just like front end.
You can do something quickin a day that maybe all that
code gets thrown away ornever gets promoted to the

(21:40):
next environment or whatever.
, Cool, you spent a day, tohave a live prototype to
get the customer on a call.
now you and I both know,the harder part of that
is getting a busy customerto dedicate their time.
Exactly.
That's hard, but if you'reusing a suite of software
and you have a whole team ofdevelopers in your corner you
will spare the time, right?
Yeah.
I, as a customer justsay, I can't imagine.
You probably can find in thatgroup some people that would

(22:02):
like spend 20 minutes Right.
to have their, theirparticular problem solved.
Yeah, I understand what it'strying to say, when I hear
the product management folkshammering the Scrum folks to
be like, there's no value inthat, or like, our problems are
not solved with any of that.
Like, this is the kind ofstuff it's like, you should
know before your, before yourdevelopment team is doing all

(22:23):
this work, you should knowthat this solves a problem.
I'm not saying that youdon't need the extra
column afterwards.
Definitely do that too.
Yeah.
I mean post-delivery telemetryis always a good thing.
But I agree.
Don't start work unless youknow what you're doing and
who you're doing it for andwhy those three questions.
there are problems thatI would pay to solve.
Right?
Right I will give you moneyand I'll break out my wallet

(22:44):
right now and give you cash.
If I can never have this problemagain, if it's that kind of
problem, I'll bring the team,we'll, we'll bring the brain
trust and we'll solve it.
But if I get in the room andthe customer's like, well I
don't really have budget and Idon't know, blah, blah, blah.
I'm like, Hey, man, likeyou should, like next,
listen, I was willing totake my time to do this.
That's my job in productmanagement, but next time you

(23:06):
tell me you got a great idea nowyou're a little more experienced
to understand they were justkind of they're a little
pulling your chain over here.
I don't blame customersfor doing that.
But I'll tell you this, right.
as a savvy product manager,one of the skill sets you
bring to the table is sortingout the wheat from the chef.
What I mean by thatis, looking at.
True needs and validatingthose versus the wishes,

(23:27):
the wants and the desires.
Anyone can tell you anythingfrom a customer perspective,
but do they truly need it?
How bad do they need it?
Are they willing to pay for it?
All of those things come intothe picture because you have an
opportunity cost to consider.
You're doing something'cause somebody told you
to do it and you could beworking on something else.
can I give you the mostboring pushback in the world?
Yeah, yeah, yeah.
the most boring pushback inthe world for this is but ohm.

(23:49):
Like any minute my developersspend not writing code.
that's overhead.
That distracts them fromproducing quality software.
Talking to people.
Yeah.
I, we have seen that.
people have told me that.
People have been verypassionate about that.
Absolutely.
Yeah.
They'll say thingslike this happens.
Typically when you have aPMO type of setup, they'll
say, we're paying thesedevelopers to write code we're

(24:11):
not paying them to talk tocustomers I mean, these are
all massive anti-patterns.
So what's interesting aboutthis point is in this expansion
of the Scrum guide, theyactually mentioned that one
of the objectives should be toreduce the distance between.
Product developers, whichis what they call developers
and testers, et cetera.
We used to be called developers,are now product developers

(24:32):
between them and stakeholders,which they're also changing
now to supporters, right?
So I think they're heading inthe right direction, but it
seems to me they seem to belike hinting at that, right?
Rather than saying, do this,there's no, there's no,
there's no direction hereother than suggestions.
And they'll hide behind that.
The fact that this is aframework adopted to your use.

(24:55):
Let's talk about supporters.
One of the things that theDLC ads is a supporter, is
a specific stakeholder type.
Supporters are supportingstakeholders and change agents,
supporters are supportingstakeholders and change agents.
Supporters are often part ofa powerful guiding coalition.
who inspire and removedemotivating factors supporters

(25:16):
support the Scrum team tothrive and influence the
organization's workflows,processes, and systems.
Supporters should participatewhen and where needed
and or as requested.
Value creation oftenrequires effective and
constructive collaborationwith other stakeholders.
Stakeholders are entity,individual or group
interested in, affectedby or impacting inputs,

(25:38):
activity or, or outcomes?
So this is the sameas they were before.
Okay.
Stakeholders, right.
But then supporters, I guess.
So I guess supportersare like managers.
People that like help the Scrumteam actively help depending on
the size of the organization.
Example, the supporters includeare not limited to colleagues.
That's terrible.
Colleagues.
Yeah, I know.
Delete that word.
Decision makers.
Okay.
Decision makers is,that's a good one.
Financial sponsors.

(25:59):
That's a good one.
Governance, oversight.
You know what I thinkabout governance managers,
which is what I said.
Subject MAs.
Okay.
SMEs.
Marketing, hr,finance, procurement.
So Alli Domains, basically.
Yeah.
Yeah.
Anybody that you need,that you really should
have on the Scrum team thatisn't on the Scrum team.
Yeah.
Yeah.
I wanna look at his 83and 71 reference before
we get outta this section.
83 is Kotter Leading Change.

(26:21):
We did a whole podcast on that.
I nailed it.
yeah, yeah.
So I think we, I think wegot a handle on supporters.
I think the advantage here isit acknowledges that like Scrum
doesn't just live by itself.
Like there are theseother people that have
control of finance and havecontrol of the, the say
on who goes on what teams.
And they, they have controlof like hiring authority
and stuff like that.
And those people are noton the Scrum team, right?

(26:42):
Like, theoretically theScrum team is self-managing.
They figure it all out.
But in reality.
You have supporters that aremeant to support the team.
So that that, that's a positiveto me that like, there is
some acknowledgement of that.
Yeah, I agree.
I also think that it's sortof antithetical to what
Sweiber said you don't needthis elaborate structure.
Right.
We need just enough structure.
Oh yeah, that's what itsays in the gate column too.

(27:04):
Yeah.
I mean, you are, you're right.
I mean, we don't need,like in a startup Oh yeah.
You don't need, youdon't have that.
Yeah.
You don't have it, and youdon't it, and you know what?
Somehow they're successful,somehow they figure it out.
Yeah.
Role proliferation and thecore of Scrum, I mean, the
core of Scrum is, simplicity.
I mean, it's a reallysimple framework.
the scrum guide itself,like not the DLC.
Hey, you're just abunch of people working

(27:25):
together and being cool.
I don't know how I feel aboutthis category, you know?
It goes against the principleof just enough structure.
So . The next point is theDLC states that a product
developer who is neitherwilling nor ready, nor able to
be a professional, should stepdown as a product developer.
They have this, this terminologyshould, should step down.

(27:46):
Let, let's searchfor, should step down.
Okay.
So I'm searching for, thewords should step down and
it's under product developer.
Okay.
Here, the product developeris an accountability.
It says, all productdevelopers together should
possess all the skillsneeded to create increments.
The combined skillset, oftenreferred to as cross-functional.
Okay.
Yeah.
So the, so this was developer,now it's a product developer.

(28:07):
'cause we throw productin front of it because
Marty Cagan wrote a book.
That's right.
He wrote several.
So now that we're all inthe same marketing page,
there's six references in thisdocument to should step down.
Okay.
And it says as a rule ofthumb, a product developer
who is neither willing norready, nor able to be a
professional, should stepdown as a product developer.

(28:28):
I am wondering why this is,why this is in here at all.
It's not needed I couldjust replace product.
Developer with a janitor.
Oh really?
Because you gottabe professional.
You are working.
Let me search, let mesearch for the other places.
Yeah.
Yeah.
So it says a product,product management skills.
A product owner who's neitherwilling, ready, nor able
to gain product managementskills should step down.

(28:50):
A scrum master who's neitherwilling, oh goodness me,
they sprinkled it acrossall the roles every night.
Product owner, productdeveloper, scrum master,
like they're all in here.
They should step down ifthey don't want do that job.
let's talk about elitistgatekeeping here.
Let's talk about working inthe worst work centers that
I've worked in where they'resaying like, well, Brian, if
you don't wanna work 65 hours aweek, then you should step down

(29:13):
because we got loads of peoplewilling to work 65 hours a week.
If you don't want to bea quote professional like
that, that's what, that'sthe way this sounds to me.
Yeah.
Yeah.
I can't disagree.
I think that's true.
That is exactly how it sounds.
But in that section, they'rekind of making things a little
more confusing in the productdeveloper section, right?
Because they're sayingthat at least one product

(29:35):
developer out of however manyyou have, should be human.
And they're saying that's withregards to the AI section.
Yeah.
Yeah, I think it is.
Yeah.
But they don't say it that way.
They just say itshould be human.
And then they say.
if they can't do all of thesethings and be professional,
they should step down.
And then they liberallysprinkle that across the whole
document saying whatever roleit is, insert your role here.

(29:57):
If you're not professionalor willing to, to gain
those skills, et cetera,you should step down.
I feel like that whole, all ofthose things are superfluous
because presumably you'regetting paid to do a job, right?
Yeah.
You bring certain skillsto the table, and if you
don't, you can learn those.
And if you're unwillingto learn them, you'll find
yourself looking for work again.
So I don't know how muchvalue that's really adding.

(30:19):
Right?
on the scale to addingvalue where like 10 is like
super valuable, somethingyou absolutely need and one
is like, Hey man, like Icould have skipped this and
saw a movie or whatever.
Like, this is solidly a zero.
What is the point of evensaying like, Hey man, you
should quit your job ifyou don't want to do this.
I feel like I'm beating itup pretty hard right now.
If I'm gonna take a stepback for a second and

(30:39):
really take a look at this.
He's saying, if you don't wannaplay the game by these rules,
you shouldn't play the game.
That's basicallywhat's going on here.
and my counterpoint to thatis this is not your problem
with Scrum like the problemwith Scrum is like working
in these, deciding thatyou're gonna scale something
that's failing already.
Yeah.
With all these managersthat are gonna tell you what

(31:00):
to do and like that you'renot changing the org co.
The problem is not atthe Scrum team level.
That's right.
The problem is well abovethe Scrum team level and
55 pages here doesn'thelp you with any of that.
And, this kind of , well,if you don't wanna work more
than 40 hours, then maybe youshould throw in the towel and
let somebody who like, okay.
All right, man.
I know.
I agree.
Listen, that there's noreference in this document

(31:22):
about one of the majorimpediments of adopting
agility in general, right?
Which is the organizationalstructure, the org structure.
It's not mentioned here at all.
Unless you can change that.
It doesn't matter If you doall of those other things,
they're not gonna work overall.
Right.
You won't have the impact.
There's 18 references toorganizational in this document.

(31:43):
We're gonna go throughevery one of 'em right now.
Sure.
For anybody who mightever read the comments.
Now let me welcome youto part of the Arguing
Agile podcast that we callBrian's being Pedantic.
And we're gonna go throughevery reference to the word
organizational in this document.
There are 18 of them.
2000 years later.
Anyway, I wanted to gothrough every single one of

(32:04):
those and what you've whatyou've uncovered is the fact
that they do not address.
Org structures in this document.
Right?
And that is one of the biggestimpediments to adopting agility.
You know, what we discusson the arguing Agile podcast
though in in arguing agilepodcasts that you can go
search for org structures.
That's right.
Hey, quick, quick, while,while the parents are away,

(32:25):
we'll save you some time.
Oh, I know we can talkabout arguing Agile 1 99.
This, that demingsprofound knowledge for
transforming organizations.
What else can we talk about?
We can talk about workstructure with stormy.
Yeah.
We can talk about arguingAgile 90 or culture.
We can talk aboutself-organization
when self-organizationgoes off the rails.

(32:45):
So arguing 1 21.
We can talk about arguing Agile.
67 is one we, apologies.
Teens apologies.
Yeah.
All of them.
All of them being better.
Then this referenceindeed in this document.
So I, I please listen to any ofthose of our podcasts and don't
go back beyond arguing Agile.
Sorry.

(33:05):
I was gonna say don't, don't gobefore 67 before I was editing
So another thing theyincorporate in this document
is the Cynefin framework.
Yeah.
It's a Welsh word.
Well, I'm done.
But anyway, like they pointto this popularized by the
Harvard Business Reviewarticle, A leaders framework
for decision making by DavisSnowden and Mary Boone in 2007.

(33:26):
Yeah.
Another framework insideof our framework, right?
Talking about complexity andhelping people understand the
different levels of complexity.
They basically regurgitatethe entire framework in here.
And I'm not going through itbecause people can read this.,
All they had to do is replaceall of that diatribe in there
with just the coning framework.

(33:47):
Diagram.
Which is a two by two, right?
Just tells you what's chaos,what's what, and, and it
just helps you organize whichapproach you're going to take
based on the circumstanceyou find yourself in.
Right?
I wish they had done that, andit would've spoken volumes more
than reading all of those words.
I'm hoping that Dave agreeswith me, Dave Snowden, who's

(34:07):
the, I guess the author of this,There you go.
people can see that.
So it's a two by two.
The top left is complex.
The top right is complicated.
The bottom left is chaotic, andthe bottom right is obvious.
It's a two by two, but there'san intersection of all of
those quadrants in the middle.
Where you reach disorder.
Okay so net net, the, the,the thesis here is if you're

(34:29):
in the complex quadrant.
Mm-hmm you are probing,sensing, and responding.
Mm-hmm.
Right on that diagramand so on and so forth.
For all of those quadrants,there is a, there is a
suggestion on how youshould handle that.
Mm-hmm and he's got anout, so to speak, in the
middle, which is where allof the quadrants intersect,
where you're in chaos.

(34:50):
And when you're in chaos,what should you do?
Right.
I don't think thereis a suggestion on
how you should behave.
The only thing that I couldsurmise from the little reading
that I've done is try and getyourself in one of the quadrants
if you're in that space, so youknow what to do in a known area,
rather than this abyss whereeverything's in chaos and you

(35:12):
really have nothing to go on.
I'm gonna go out on alimb and say, I hate this
inclusion and the reason,let me give you a reason
before you push back on me.
All right?
Yeah.
I hate this inclusionbecause this is like
academic theorizing.
I understand the reasonfor the framework.
Yeah.
I understand what it's tryingto do, but as a product
manager, I'm trying to get.
Leaders in the organizationto just look for evidence

(35:35):
that their idea isa good idea or not.
Like I, this is waypast that, you know?
Yeah.
Yeah.
So it's interesting to hear yousay that, A, as a person who's
interested in process and howorganizations navigate their way
through different environments.
I'm interested inthe canon framework.
I do think there's somevalue in exploring it, but

(35:57):
absolutely not needed as such.
Yeah.
And on a scale of justbuild it to needs a PhD
in systems theory, right?
How much theoretical frameworkdo practitioners need?
At some point you say, look, wedon't know what we don't know.
Can we just do some explorationto find out and move on rather
than theorize on these thingsand say, well, are we really in

(36:17):
this quadrant or that quadrant?
Because you're gonna get 10different answers based on,
I mean, you five people youask, you're also talking to
the guy that loves Deming.
And we did two podcasts, right?
Right.
We did two podcasts on twodifferent Deming books and,
and we took the time to,do you know what I mean?
To, to yeah.
To justify doingEnd Deming podcast.
So like, I, like I understandtheory of a systems and
also systems thinking.

(36:39):
And this is not that.
It, it isn't.
I agree.
Also from, from what whatI surmise, most teams don't
have the chops to understandand apply complexity
theory to begin with.
Right, right, right.
So take this forward.
It is, I mean, theyadded it in there.
Did they need to?
Probably not.
Yeah it's there.
I'd rather have that, thatdiagram of like, this is

(37:00):
what all y'all's boards looklike and like that this is
what they should look again,that diagram is value.
Because this wholesection takes up.
A page or two by itself.
Oh, it's more than that.
I, I would trade this out forlike a page of what y'all's
boards probably look like.
And this would bea good addition.
Yeah.
That you could really I,I mean, I, I don't know.
It's two diagrams.
Here's your, what your boardprobably looks like here.

(37:22):
Here's what you mightbenefit from, which is that
suggested extra lane inthere, or a column rather.
I mean also you'rehanding this over.
A lot of scrum teamsdon't have a scrum master.
They're just asking thedeveloper to play the role
part-time or whatever.
And the developer is gonna bringup this theoretical framework.
It's not gonna happenlike it's 55 pages.

(37:44):
They theoreticallythrew everything in the
kitchen sink in here.
They did that Theycould think of.
I just don't knowspeaking of overcomplicating,
let's talk about their,their division between
product thinking versusproject thinking.
This should be an easywin this category.
Yeah.
And this is, again, nota new concept, right?
That they'veintroduced here, right?
Right.
Everyone's known about this orthey should have, so I'm showing

(38:07):
on the screen what I'm reading.
In the product thinkingsection, it says people
consume products includingservices, not projects, people
consume products or services.
Mm-hmm.
A product is a conduit todeliver value, balancing
the short and long term.
This is why Scrum has a productowner, not a project owner.

(38:27):
Oh boy.
A bunch of people, likeI was gonna say, we lost PMs.
Now project managersproducts are long-term and
need to be taken care offor their entire existence,
whereas project is timebox and often leaves an
orphaned product behindonce a project is completed.
I mean, I like, I feel this wasa good inclusion to be honest.

(38:50):
I think so too, because ittalks about how the product
lifecycle is way beyondjust a project lifecycle.
Yes.
I think they should haveled with, led with this.
I think it should, this shouldhave been the opening paragraph.
It's like, all y'all thinkingyou can do this stuff, scrum.
What we're talking about, whatwe built as projects, right?
Y'all are wrong.
And, and that's, well especiallygiven the, the definition of

(39:12):
success for projects is waydifferent than definition of
success for products, right?
So product, let's talk aboutsustainable products, right?
Yeah.
they generate valuefor the users.
The users consume them.
You can pivot basedon the market need.
You can pivot based onwhat users are telling you.
You can change directionthat they're not fixed scope.
Fixed duration, fixed scope,. Fixed timeline, they align

(39:32):
with your business model.
They can change when yourbusiness model, if you have
a strategy pivot for yourbusiness, they can change.
You cut projects whenthis stuff happens.
Oh, This project isrunning too long.
Cut the funding off.
Cut it off.
I do like thisinclusion in here.
I think they could havespent more time here than
on the cynefin framework.
Right?
Oh boy.
Possibly.
Yeah.
But you know, the, the againston this is, well, at least

(39:55):
with the project, we know howmuch money we have to spend.
Sure.
We know roughly bywhen we should be done.
Mm-hmm whereas if you justthink about building a product
instead, we're gonna keep going.
We don't know whenwe'll be done.
Yeah.
We don't know howmuch money we have.
Keep going back to thewell for more money.
Yeah.
And end up with what theycall product theater.
Well, I mean, that's what MartyCagan calls product theater.

(40:16):
Like in you, you the thinkingand also the thinking
that inside of a productis just multiple projects
back to back to back.
And then the, that, thatthinking into like, oh, well
the Scrum team is just likea. Project delivery team
that delivers micro projectsinto whatever, like timeframe
buckets that are cut up.
Like even that is likeyou've already failed

(40:39):
when you're Absolutely.
It introduces a linearity right.
Which is not true in real life'cause you're always going back
and forth, so Yeah, absolutely.
So fund, fund the productand the product teams
don't fund projects.
Right, right.
The, the funding mechanism.
and in fact, in the otherthat we already talked, we
already finished talkingabout that category.

(41:00):
We was talking about thesupporters of your Scrum team
being financed, stuff like that.
I think they missed anopportunity to say like,
well, your finance person thatsupports your product team
should be part of your team.
Now maybe they don'thave anything to do.
Sprint over Sprint over sprint.
But they can come inand go as they need to.
Maybe you only need them liketwice a year but when they
come in, they need to explainto the team how finance works

(41:22):
and explain to the team whythings are wor oh here's your
funding in the last fiscal year.
I mean, you definitely need'em once a year when the
fiscal year rolls over.
It's probably a good ideato have a more frequent
than that, though, likemaybe every quarter to say,
here's how we're meteringagainst our, our march right.
You could extend the sameargument to other allied
domains like hr, for instance.

(41:43):
Right.
As you're right.
Sizing your team and you'reconstantly doing that.
well, definitely when we haveheadcount spots that are open.
Or not open.
Nobody got fired.
Nobody's being replaced,nobody's getting hired . but the
moment that one of those spotsis vacant on the team, yeah.
That person is now a regularpart of the team for as long
as that spot is open, untilthat spot gets taken away from
the team, or until that spotgets filled by a new hire.

(42:06):
Yeah.
Like that person, that personshould be part of the team.
And in this document,they don't, they don't
make that bold claim thatlike these supporters.
Are team members, theydon't even allude to that.
And that's a miss, I think.
Well, they make up a new, theymake up a new role rather.
Yeah.
But that's about it.
Right?
They don't say how they shouldbe involved in the team.
When you're at a startup,those people really are

(42:28):
team members for as longas you have that role open.
Sure.
For as long as you have financequestions, those people need
to be in constant contact.
Maybe you have to create adhoc meetings because they're
not just gonna show up everyday . How about a better way
of working would be to putyour arms around the whole
ownership of the problem.
Be like, Hey, we need your help.
Please join our standups.

(42:50):
Maybe we can help you.
You're not getting peopleapplying for the position.
Maybe we can tweak the resume.
We're not getting thequality candidates.
Maybe everyone on the team canreach out to people they've
worked with or whatever.
There are things that the teamcan do that you, by yourself as
a recruiter, finance, whatever,are limited when you're
leveraging the whole team.
So that like, there's afailing in here to be like,

(43:11):
Hey, scrum really does work.
I mean, it reallydoes work, right?
Mm-hmm.
Scrum really does work, butwhen you're trying to put
all these guardrails, silos,all that kind of stuff, like
you're really chipping awayat what makes Scrum work.
that should have beenthe executive overview,
of this document.
You should have been like,Hey, , there is no executive
overview that says here's a onepage summary of the 50 pages.

(43:31):
50 plus.
I mean, I shouldn'thave to tell.
That's not, I shouldn't haveto tell the crew that wrote
this, that executives, I'm notgonna read a 55 page document.
Exactly.
I agree.
.
The product thinkingsection, I think it's good.
I mean, I like this section.
I think this should havebeen the intro to the whole
document and the wholedocument should have been
framed around this, but alsolike , you guys miss the

(43:52):
market opportunity 'cause MartyCagan wrote a book about this.
He wrote several, actually.
Mm-hmm.
And now you're behind.
Alright, let's lookat emergent strategy.
So the guide, I mean, this isactually a pretty large section.
It is a very largesection, probably too
large on emergent strategy.
So it basically says strategyis not limited by scale.
It exists, it should beclearly articulated at the

(44:14):
corporate business unit orproduct level and remain
coherent and integratedacross all these levels.
I agree a hundred percent.
No, I agree so far.
Yeah.
Crucially, strategy shoulddistinguish between ends and
means ends meaning quantified.
Stakeholder valued outcomes andmeans meaning how you get there.
Initiatives and activities,Drawing and adapting.

(44:34):
Roger Martin's work.
I'm gonna assume this isthat is the Roger Martin.
I'm gonna assume 41 is how toplay . 41, let's go look at 41.
It takes you there.
Yeah.
Martin, A new way to think,your Guide to Superior
Management Effectiveness.
Well, this is not what Ithought it was gonna be.
No, but it is theRoger Martin, I think.

(44:55):
Yeah.
Roger Martin.
How, yeah.
How to win.
Yeah.
Play to Win.
Yeah.
This is the same one.
Yeah.
Playing to win.
We did a podcaston plane to win.
We did, we did.
Now you gotta look onwhich podcast it was.
Curtis was here, I think.
I don't think you were here.
So emergent strategy.
He says, for a situation whereexpertise alone is sufficient?
To ensure strategy is iterative,actionable, and value focused.

(45:17):
And he gives a big listOf things for a situation
where expertise is valuable,yet insufficient cause and
effect are only coherent inretrospect and uncertainty
needs to be embraced.
Scrum teams and stakeholdersneed to, and then he gives
a big list of things.
I understand what they're doinghere, but it seems, I don't
know, it's a bit misplaced.
it seems haphazardin its compilation.

(45:40):
You know, it seems likewhat they're saying is like.
Market conditions aremoving faster than you can
react, and your strategyneeds to be emergent.
Your strategy needs to basicallyfollow the users and follow
'em as closely as possible.
Which in principle is fine.
Yeah.
But I gotta say like, inactuality like strategy is
that thing your leadership teamdoes once a year at an offsite

(46:02):
that you are not invited to.
Yes.
Yes.
And questioning it is likenow you're you might as well
be like kicking their dog.
Yeah.
So I agree with that.
At the scrum team level,you're not invited and your
voice doesn't really carry.
Right.
The strategy's alreadydecided go work on it.
Well, let's pivot from thatbecause some people might
be like, oh, Brian, likeyou're the product manager.

(46:23):
You should be involved in thestrategy, don't play the victim.
Okay.
But , my executives aregonna say, well, Brian,
you're just, you're justshopping different strategies.
You're, you're testing 'em.
You, you have no plan.
You're just testing everythingand going, which, what?
Whichever the way the windblows, you're going that way.
And it, it seems likeyou have no plan.
No plan is your plan.

(46:44):
That's that's what my executiveswill come, that is a real
danger and they won't fund me.
They will not.
Yeah, they won't becausethey don't have confidence
in what you're Correct.
Bringing to the table e evenif, even if I will win, yeah.
Because you are actuallylooking for evidence, et
cetera so yeah, you win in theend, but yeah, right from the
get go, they won't fund you.
So I think there's a timehorizon to consider here.
The Scrum team's workingon something that's

(47:05):
emergent right now.
Off the top of the backlog,whereas strategy is decided
on a longer time horizon.
Mm-hmm , as a scrum team,you really don't have sway
there you're basically handeddown the strategy, right.
Possibly through multiplelayers to say, go work on
this, go deliver this so thisis little bit misplaced, I
feel like, in this documentwhat can the scrum team do?

(47:27):
You can't just go knock on thesenior leader's doors, right.
The C level and say, Hey,I'm gonna tell you what the
strategy should be, or let'sco-create the strategies.
Like nobody invites you in.
Yeah.
When, when you do that, wellthat, I mean this is, this
could be a very dense section.
Mm-hmm.
If it, if it is saying like,well you should go knock on
that leader's door, right?
And say, Hey listen,like this is not working.

(47:48):
Why don't we work together?
And I'll bring you some evidencesaying, why don't we lay out a
bunch of potential strategiesand then we'll make tests for
each strategy, and then we'lltest them against the market.
And now you're back in productdiscovery and I would argue.
Again, my role on the podcastas a product manager I would
argue I don't need this 55 pageDLC that I buy that adds like

(48:12):
this ridiculous quest that I'mnot even interested in doing.
I can read theMarty Cagan books.
I can go buy thatgame, you know?
Yeah.
and go play the whole gamewithout any DLC there, there's a
bunch of books written for this.
Okay.
I agree.
So I go back towhat I said earlier.
It's misplaced in thisdocument, at least because the
teams can't do much with it.
I want to go into theend of the podcast here

(48:32):
and talk about like.
Okay.
The, the expansion claims thatScrum is founded on empiricism
and emphasizes evidence-baseddecision making, right?
Yeah.
But also like empiricism, evenin the original Scrum guide.
And when you tack on productmanagement, like as a discipline
that's works with Scrum, likethat, the product owner is

(48:52):
like a delegation thereof,like empiricism gets diluted.
So in the original scrum guide,maybe not the latest one, I
think it's all in there though,but it was introduced some time
ago now, a few versions ago.
Empiricism in the formof tPI, transparency,
adaptation, inspection.
Inspection.
Not in that sequence.
Transparency.

(49:12):
You've gotta be able tosee what you're doing,
inspect it, and then adaptas needed so they had that in
there for some time ago now.
Which, which is sointeresting because that's,
that's just the OODA loop.
Like it is just a re So, whichis in, which is in the 55 pages.
Yeah, yeah, yeah.
They reference the oodleloop in the 55 pages.
Yeah, yeah, yeah.
It is exactly that.
It's, it's just a differentacronym, but I don't know.

(49:32):
So, the educated hunches, likethey, they reference educated
hunches in this document.
Yeah.
Like like, okay, I get it.
Like I, because we did apodcast with Alex where we
were talking about like, oh,well, is it, is it evidence
based or is it intuition based?
And they kind of infer that inhere is like, oh, it's educated
hunches to move you forward.

(49:53):
But I don't know.
there, there's a, like with55 pages, you would think the
clarity should come through.
I just don't think thatthe , I'm trying to give
the document a fair chance.
That's what I'm trying to do.
But at the same time, ifeverything is empirical in the
document, nothing is, nothinglike the term lose all meaning
everything's empirical, butyour hunches are empirical,
but your evidence is empirical,but you're not going out

(50:14):
on a limb in the document.
And you, and trying to likeseparate the mode one, mode
two, thinking of like, you'remaking snap judgments, but also
you're making judgment basedon evidence and experience.
Yeah.
So are you making, are youmaking snap judgments off of
experience and your feeling?
Are you making judgementsoff of well done

(50:34):
Experiments with evidence.
Yeah.
and those two thingslike it's just not laid
out very well in here.
Yeah, I know.
And so one of the thingsthat is in the against is
educated hunches are justlike it says here, just like
your opinion, man, right?
So you ask four people theiropinions on your educated
hunches and see how they land.
So what they could havedone here, just like we

(50:55):
talked about , the boards.
, Hey, like after you deliversomething and validate with a
customer, what they could havedone here is they could have
said every work item that youpick up, every swim lane that
cuts across all your steps ithas a verifiable hypothesis.
Right?
Mm-hmm.
And then we can measurethat statistically at the

(51:15):
end of the phase when wedeliver it with the customer,
We can measure that.
And they could have gone forwardreally taking empiricism and
making it the cornerstoneof Scrum to be like, Hey,
you need to change all yourwork items to comply with the
fundamentals of empiricism.
So your work item is, if wedo this, this is gonna happen.

(51:37):
Right?
And then the end is either acon, a confirmation or denial.
Refutation.
Yeah, refutation.
Yeah, refuting.
It's either true or false.
It's either true or false.
Yeah.
Your, your theory is eithertrue or false at the end,
and like the software mightbe good and they, but the
original empirical statement.
True or false, no matterhow the software turns out.

(51:57):
Yeah.
and it might be great software.
Turns out that ouroriginal theory is false,
but software is great.
Everyone loves it.
That could happen.
But there's learning in that.
That is not what's beingset up in this, in this
55 page 25,000 word setup.
It's like, well man, it'skinda like your opinion.
I don't know.
it's weird.
it's weird to be in likeempiricism should be a

(52:20):
cornerstone of Scrum.
Yes.
It's just weird.
It's like, is that gonna be,is trust your gut a thing?
is that what we're saying?
Because that, but I see you.
Yeah.
I see you going therefrustrated by that.
I see you, I see youfrustrated by that.
But.
I think you would agree with me.
Most development teams,when they launch off to
like spend a month workingon a feature, they're just

(52:41):
trusting their gut againstor they're just taking orders,
but Yeah, absolutely correct.
So I think there'slevels, right?
Development teams don'treally feel empowered
most of the time to say,Hey, this is our gut feel.
We're gonna do this.
Yeah, they're gonna do itbecause that's what the PO
or the product manager hasspecified they should do.
No, no, no.
But that's a cop out yes it is.
But, but that person could takeownership to be like, well,

(53:04):
it's my gut feeling, however,I'm gonna put it down on paper.
I'm gonna put it on the wall.
I'm gonna say, I think ifwe do X we'll get Y output.
And again, if you're testinghypothesis as you move along,
you can say, okay, the customersI've verified the with say
that the Z would be the output.
We're gonna do x. Put it onthe wall, we expect Z output.

(53:27):
And then just put that on thewall for everyone to see it,
they could have, if empiricismtruly is the core they could
have if, if it's a creamynouget core, they could have
peeled the chocolate layerback and be like, this is what
it should look like inside.
absolutely correct so thiscan actually in practice,
be implemented in the formof experiments as well.
You say, if we do this,we expect this to happen.

(53:49):
Let's try it out in thesmallest possible slice of work.
So we don't spend a lot of timetrying to learn from it and
go from there . I also thinka lot of times teams know that
something could be in our waythis isn't really the right
thing to do, but they don't.
They either they'renot empowered to or
they don't speak up.
you just pointed out I thinkwhat the core of what they

(54:09):
could have done here Yes.
Is yes.
They could have pointed outlike what's we are gonna take
on a feature and the featureis like a problem wrapped
in a solution statement.
We're gonna strip backthe solution until we
get to the problem.
And then we're gonnavalidate the problem.
Validate the problem.
And validate the problemmeans learning, right?
So we're gonna,we're gonna learn.
Until we come upwith a solution.

(54:30):
And then we're gonna implementa solution at the, like the
tiniest cross-functional,everything that's in here, and
then we're gonna validate thatactually solves a problem.
And then we're gonna go deepand we solve the whole problem.
Like they, they could havegone like, here's the steps.
Break your work item down.
Learn, learn, learn.
Implement, learn,implement, learn.
Solution.
Solution done.
Yeah, I agree.

(54:50):
That would've beenextremely helpful.
Not to harp on this, , becauseI brought it up 5,000 times
today, but they could havegraphically represented this.
Yeah, so like when you havea brick of text, they could
have been giving you somediagrams to be like, Hey,
here's the way you probablydo it now at the end you got
a radically different board.
I think I should do that.
That is so if they had donethat, that would've been

(55:12):
a good blueprint for teamsto follow, to work with
their leadership Right.
As well because they canactually illustrate the logic
behind it and it would, howhe arrived at a conclusion.
And it would've been great if.
The individual team boardsall rolled back up to
a strategy level board.
Unfortunately, most almsdon't really cater for that.
Also to your point aboutillustrating things with

(55:34):
diagrams, it's telling thatthis document has zero diagrams
none well, that's a problem.
If your framework needs 50pages and 25,000 words, words.
Yeah.
Yeah.
Yeah.
You're building the nextrational, unified process.
I feel what they're doinghere is they've watered down
the scrum guide for Maskassumption and now they're
wheeling back this, the market'sbeen segmented with product

(55:58):
management saying like, wedon't need these scrum people.
Like, they're losingmoney basically.
Their wallet's a little lighterthan it was five years ago.
Sure.
if the cynical part of meis being taken out of it, I
would say like 50% of what wetalked about today was , good
additions, but the bad partsthat were being added, , the
misses were, the additionsdidn't go deep enough and

(56:18):
, the parts where they missed,they really whiffed the ball.
I think what's happenedhere is in this so-called
expansion pack, what they'vedone is they've added quite
a bit of work from theoriginal scrum guide, which
is what about 13 pages?
Yeah.
12 or 13.
Yeah.
They've added that, and thenthey've elaborated on it.
They've changed somevernacular so developers

(56:39):
are no longer developers.
They're product developers.
Yeah.
And they've added some roleslike supporters, et cetera.
All of that could havebeen done in a page or two.
Literally in a page ortwo and they could have
just launched the newversion of the Scrum guide.
Scrum guide version2025 so it'll be now
what, 13 instead of 13?
It might be 14 or 15 pages.
Sure.
Not that much of an ad asopposed to this, I feel sorry

(57:02):
for somebody coming intothe field, 'cause I think
seasoned practitioners would,see through this, but yeah.
Somebody coming into thefield would have to read
the scrum guide as they sayhere, that you should do
And then read this and, and, andbe left to work out the pieces.
And that's a shame.
Yikes.
All right.
well if, if you have an opinionabout this new DLC pack or I

(57:23):
mean, if you're like me andyou don't wanna buy the DLC.
And you think the original gameshould include all this stuff.
Send me a comment and tellme I'm right or wrong.
Yeah, I would loveto hear from you.
Also, let us know what youwant us to talk about next.
And don't forgetlike, and subscribe