Arguing Agile

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

• Brian Orlando • Season 1 • Episode 216

Share episode

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)

What if I told you there was a new ex new Scrum guide, DLC that's a new expansion pack. Ooh, tell me more. 55 pages, just short of 25,000 words, that claims. The original scrum guide was, deliberately oversimplified, and it was done so for mass adoption and now is time for the real deal. Nice. Well, it's good to hear that the new one is. A little more elaborate, but four times the size of the previous one. How much would you pay for that? Would you pay by the word itm? Trying to, I would not pay by the word if there's like 25,000 words. I'm trying to, I'm trying to pitch you on my Dickensian scrum guide. Oh yeah, yeah. That's what I'm trying to pitch you on. But that was a literary joke for two people. critics mainly LinkedIn influencers that I've read will say that it turns the lightweight 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 things that stick out to us. We're gonna talk about those today 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 the scrum guide that we always needed but didn't deserve? I always screw up that Batman line. Sorry. Is it a scrum encyclopedia instead, or what is it? or is it destroying simplicity, right. And is the opposite. We've broken up the guide into 10 distinct points we're gonna walk through in no particular order, like the right, they're all, they're all good to talk about. Normally on a podcast, we'll go through an ordering on this one. They're all good to talk about. So we didn't go through any kind of ordering exercise like we normally would. I think that's okay. We're gonna try to. Zip through these as fast as possible. Hopefully we will contain this podcast to an hour because this could be very dry stuff. the first point is self-managing teams versus individual self management. So the, the scrum guide has a distinction between self-managing scrum teams. They're not to be confused with individual self-management. Okay. Scrum guide's on the screen now it says a self-managing scrum team checks whether they are on track, takes actions when they're not on track, decides how to work resolves scrum conflict and fixes, problems with fixes, problems in the scrum team. That means that , generally managers, if they're part of the landscape, do not tell the Scrum team what to do or decide which Scrum team member needs to be taken aside to fix issues directly or indirectly. If managers exist, it's generally better They demonstrate leadership. Okay. None of that is new so far. Let me keep going. Self-managing. Scrum teams organized around value are critical for creative problem solving and capturing emergence reliance on non self-managing Scrum teams hinders the ability to deal with complexity. Did I just read that right? you did. I think they're talking about having autonomy at the team level on what to work on and of course how to work on it. And this is, again, I don't feel this is new. Oh, I see, so it's saying non self-managing scrum team. So if you have non. Self-managing scrum needs that you're just telling what to do, then they're not gonna be able to deal with complex problems. Yeah okay. I understand. Yeah, I agree with you. I don't think this is new. Maybe it wasn't stated like that. Which also stated like that I don't know if a lot, it's not the best. I don't know if a lot of people are gonna get what he's trying to Yeah, yeah. Put across the table there. It's not the best way to, to phrase it. Okay. So, self-managing scrum teams are not to be confused with individual self-management. It is the seamless interplay that allows a great team to emerge. The facilitation of team autonomy and more efficient decision making within a non-hierarchical structure could help Scrum teams improve their self-management. Did I say Dickensian at the start of this podcast? You, you did. And listen this paragraph talks about a term called individual self-management, but it doesn't, it's elaborate on that. It just says. Yeah. This, this is not to be confused with individual self-management, but that's the extent of it. It doesn't really elaborate on it, and I feel like they're missing a, a trick here. They should, right? Because individual self-management is how teams can flourish as a team, right? When everybody exhibits those behaviors of individual self-management. Alright. There's 13 references in the document to self-management. Two of them are in the section we just read. Let's look at what the other ones are. So he's saying, he's saying self-managing Scrum teams are not gonna be confused with individuals who can self-manage. I'm guessing he's saying that's different from an individual who can do complex things by themselves, but not a whole team that can do things by themselves because 'cause our claim here was the self-managing scrum teams not be, not to be confused with individual self-management. Right. Yeah. I think I'll read a little bit more into that. Even though, like you said, he doesn't really specify it, or they don't, I should say, so it's three people that were the authors of this expansion pack. Mm-hmm. So one of the things I read into it is individuals as individuals can actually self-manage and, and, and do the right thing But when you have a bunch of them together, there's some friction there. Because you and I could be on a team, you say, we need to do this thing. I say we need to do that thing. How do we reconcile that as a team? And they didn't specify any of this. They didn't actually go into it in the whole document that I could find. But I do feel like that is something that many teams do struggle with especially when you 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 that happens with the Scrum team being dictated things to work on, happens with individuals. So like I just, I basically see this statement. I mean, a spoiler alert, there's a lot of stuff in here that I'm like, somebody did not get an editor, or maybe there was an editor in this document and they were just like too scared to suggest like, maybe we should cut that, because om wrote that and he's really smart. We shouldn't suggest cutting. Right., I would've cut this out to be like, listen man, everyone knows that. Like there are people that just work by themselves. Scrum doesn't change it. There are some people that are really smart individual contributors that go and do stuff on their own. like I've been on teams where you have teams and then the team lead is split across teams, but the team lead. Is also like the architect, right? Or in like larger organization, we have like a enterprise architect or something like that. Yeah. But maybe they're actually a good enterprise architect, meaning they actually work, right. And don't just come down from the ivory tower with the stone tablets of requirements maybe they're actually a working individual contributor and someone who helps with architectural concerns. Basically integration across systems. An individual, a single person is not gonna say, okay my team is responsible for the video upload functionality and your team is responsible for all the audio functionality, which has to do with audio upload. But maybe we share a media upload function, right? That neither one of our teams wholly owns. But when we wanna modify it, we have to get this additional person. To come in and sit with us. But what this points out is like, well, you've got individual contributors who are motivated 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 think this is a good listen, we are all extrapolating 'cause it doesn't have the detail here. Right. So you have your own extrapolation. You know, mine is along the same lines but slightly different in that he's talking about individual self-management. Talking about people that are like the lone wolf developers saying I'm gonna go work on this because I think that's the right thing to do and I'm an expert at, yeah. So I'm gonna go get it done 'cause you're pricing my contribution as, can he finish or she finish the work in the sprint. Yeah, I can do this so you're gonna have that. And when you have multiples of those on your team, you basically have a divergence, right? Mm-hmm. Of what people are working on. And that doesn't really help. Yeah. Because you're not working towards a common product goal. Yeah. Or sprint goal in this case. Okay. Lemme throw rocks for a second. If I were to rework this section, what I would do is I would start with the extreme ownership version of it. I would start with the extreme ownership version of this and point out if your team is composed of individuals who cannot take ownership or who cannot self-manage their own stuff. And then when they join a team that's supposed to be a self-managing team or a self-organizing team, self-managing is the term he's using. So if they can't self-manage themselves, then when they're part of a team that everyone's meant to work together and self-manage as a unit, as a group. How are they gonna contribute to that? I would've used this as a stepping stone to say at first, let's make sure people can self-organize themselves, self-manage themselves, and then when they're part of a larger body of folks working on a shared problem, it's a different problem. Like, you can motivate and you can figure out how to take ownership of a problem and drive it to resolution. And now you have to do that and also communicate with the people to your left and right, every step of the way. Yeah. but it's a building block on top of a smaller skill that I think is easier to master. Hey, first, master this one thing, pick a problem, get as much help as you need. We're not saying you have to solve the problem alone, Let's take that first step first, and then the next step above that is like, okay, now let's work on helping your buddy to your left and your right, they're helping you or your problem. Now we all help every each other with all of our problems. Now we have a path towards self-organization. Whereas like if I just take the section, I'm like, okay, that's cool. We should do that. I believe you. How? Right? Yeah draw me a roadmap.'cause my team doesn't know how to do that. I have a bunch of junior developers or a bunch of people who call themselves developers, but really are just marketers who are using the AI tool. Sorry, I got, oh, that one hits close to home. I was like, oh my goodness. Oh, I've got a real team who doesn't know how to do this. Yeah. They're learning for the first time. Yeah. I think underneath all of that is the ethos that if you have individual contributors that are just basically doing their own thing what you don't have or, or not, because they might not feel empowered to act. Well there's that too. So there, there's. Yeah. So that, that's part of 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 the extreme ownership that you mentioned, right? yeah. Absolutely. Well, we do have people that are doing their own thing 'cause they believe it's the right thing to do. Not only do you have this kind of diversity of thought and what the goal really is. it becomes obfuscated. What goal are we marching toward? But you also have this idea where people are gonna look at other people that are stronger personalities. And say they're doing their own thing. This is obviously what's expected of us. And they'll hide behind that and say, well, the team's doing this, so I'm just doing my own thing. I'm just refactoring the library code or whatever it might be. So this is really not a good thing. I think coming back to the whole point that they mentioned here, they say self-managing, but they don't have any tips on how to improve individual self-management. Yeah. They do have references, however, right. Of the hundreds that point to in research papers perhaps yeah. And I think the casual reader who's interested in following the expansion pack will be hard pressed to get the value out of this specific topic. let's move on to the next category, which is the definition of outcome done. Definition of outcome done. And I think the point here is measuring value versus measuring output. I think that's what he's trying to get across. I think you've nailed it. So traditional measures of definition of done are really talking about the number of items you get to done right. And this is going a little bit beyond that saying. Really it's about the outcome delivered rather than the number of features delivered into an environment production or whatever it might be. That's where the distinction is drawn here. I think a lot of it boils down to what is your goal? Is your goal let's say you're sprinting and what is your sprint goal? Is your sprint goal to finish all these features? I can't tell you the number of times I've seen teams just simply list a collection of features or stories that they've committed to in the sprint and say, this is our goal and they're completely missing the point. This is typically what we have a weak product person in, in, in the team. Yeah. They don't really lead with a goal. So it's often when you see this, it's always back to front, meaning the team commits to a bunch of user stories, pbis, whatever it is, and somebody looks at those collectively and says, what's a holistic description of those? And that's our goal. That's back to front. It should start with the goal, and the question is asked, what do we need to do to achieve this goal? If this goal is too lofty, so we can't deliver it in a sprint, let's break it down and that's on the product owner to do that. And oftentimes I see weak product ownership where this doesn't happen. so the commitment definition of outcome done, let's see. It's, so, are there any more definition of output? Done? The definition of outcome done. So there's two definitions of done in here. Oh boy. Oh boy. There's a definition of outcome done, and down here under the increment is the definition of output done. Let's read the definition of output. Done. Definition of output done every time. I said it 15 times and now it means, has no meaning. The definition of output done is a commitment. It formally describes the quality measures that express due diligence for the increment, so it could be delivered to stakeholders. Woo. Boy. I'm gonna keep going. I see your face. I'm gonna keep, I see it outta the corner of my eye. Yeah. Ignore me for a bit. I'm gonna keep going. Yeah, yeah, yeah. The definition of output done typically includes but is not limited to both technical standards. And this is how I know the document was not edited this, but not limited to. Both technical standards and product qualities. It scrum team. Creates, if not provided by the organization as a minimum. There's multiple scrum teams of the same product. They share, the same definition of output done. So this is the definition of done now in the future, which is different than the previous definition, which is the definition of outcome done. Definition of outcome done is a commitment. It describes the observable evidence, measures quantitative, or qualitative required to demonstrate realized benefit, often referred to as value validation. Okay, I'm with them on this one. I mean this whole thing could have been three sentences. Sure. It could be for the overall product. Or a specific goal. It's often best to define the measures of value validation before realization starts, starts that. Does that mean development? Yeah. Well, no, that means actual delivery to the customer. Okay. Outcomes and related interpretations and form future adaptations ideally confirming the intended stakeholder impact. Okay. Favor, direct evidence over circum circumstantial evidence. For example, customer outcomes could focus on delivering measurable value to customers such as increased customer satisfaction, customer long-term cost reduction, or the number of customer jobs addressed. Product stakeholder outcomes could connect these behavioral changes to product performance metrics, business stakeholder outcomes. Compliance business, long-term risk reduction. Risk re scrum team outcomes such as improved technical capability. Okay. User experience, UX or customer experience, CX debt is the sum of design and implementation choices. Intentional or not, that make a product or service less usable, enjoyable, or effective. Okay. That's, that's, that is what, that is. The, but that's just a textbook definition of it. Recognizing, tracking, or addressing the debt is essential for delivering products that truly meet the user needs. I mean, I agree with those statements, but those are just statements. They are just statements. That description you just read isn't all that different than what was in the original scrum guide. Definition of done. I feel like they've added a phrase there that kind of raises eyebrows, at least for me. Right. Psychological flow or whatever it was. Because you go back to that, you'll see, I don't know what that even means in that last bullet. See, scrum team outcomes as such as improved technical capability. Psychological flow. Wait, wait, wait. Oh, for example, scrum team outcomes such as improved technical capability. Psychological flow, that's a reference 70. Let's go find out what 70 is The flow. Flow, the psychology of optimal experience . harper and Roe. It is nine pages. Mm-hmm. Is there like a summary or This is the summary. This fascinating. Book's all about happiness and how to find it. Building Inner Harmony. Our level of happiness ultimately depends on how our mind filters and interprets everyday experiences. Okay. So look, I already got it. I like it's CX basically. I already got it. and, but this is inward focus to the team. Absolutely, so we're reading this paper , let me show everyone that we're reading this., We've downloaded this I think it's a book, but maybe this is the, paper. This fascinating book is all about happiness and where to find it I think he's talking about, this book flow, the Psychology of Optimal Experience. But the reference is to this paper about the book? Yeah. Okay. So as you know, on the podcast, we will go and research the entire book and the author find their house, live there for a week, and then do a podcast about it. That makes a lot of sense to me because 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 course you would reference the and psychological flow. So basically your, your psychological flow through the application is like much more pleasant and pleasing. It's an application you like to use as opposed to, for example, using other products the polar opposite is products that we all are forced to use that we like, find thoroughly, like terrible as an experience. I was gonna say Jira Oh, yeah, yeah, yeah. Jira too. Yeah. That's interesting. So, psychological flow here is referenced from the perspective of the customer, those that are benefiting from the work of Sprint. Well, I think it could be if it's technical debt or CX work. It could be the team too. I mean, the team might really enjoy internal customers. The team might enjoy that kind of stuff, you know. So this was a minor change you're adding an extra term. So it's not definition of done anymore? No. It's outcome done. Output done. Okay. And output done is really just definition of done right. And then all, all the definition goes to there. And then this new outcome done is a separate definition. Yeah. Which means it's that extra swim. Oh no. It's that extra column on the board of saying like, did we validate with the customer that what we did actually solve the problem that nobody does nobody. They just get the item to done when it's dev done Right. And test done right. And that's it. So yeah, absolutely agree with that. This is like that, Obama quote of like, being a president is like being the captain of a big ship, being the person steering a big container ship and like you can turn the wheel but you're only allowed to turn the wheel a certain number of degrees ' cause turning more, might brake something. Yeah. And then like you don't get to immediately see the results of you're turning the 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's like you can add definitions here in the DLC or whatever, the main video game of Scrum, I don't know if you're gonna affect that with this is like the, the, the getting people to add another column and just make that the way it is across the board forever without explicitly telling people that's what they need to do. If I wrote this, I would give people a graphical example of like, this is what your board probably looks like and it probably would look like their board, right? Especially if you're, if you're Jeff Sutherland or one of these guys like you, you know what 90% of people are showing. Here's your to-do, doing, done or whatever to do qa, you know development, doing development, done qa, doing qa, done whatever. You probably like. Here's a half a dozen typical workflows of the way people do Scrum, right. And to all of these, you need to add a column at the end after done that says, validating with the customer and then after that, done, done, done or whatever Val, value done. Outcome done. Outcome done. Yeah. So I would say on that, on that front, maybe it would be better to have a column ahead of done that says, validating with the customer and then you're done once you validate it with the customer. Right now, the teams may bulk at that because the lifecycle becomes longer. Right. But the overall impact of what you're delivering is much more exacting. You, you're actually getting those metrics back from the customer and the signals that say we hit the mark or we didn't hit the mark. I might just have. You know, doing, which is all of those things you described, right? Development in progress QA in progress, et cetera. And then validating with the customer. Now, sometimes an item could sit there for a while, right? Because you don't have access to the customer. You can fix those things and then get to done. Once you get to done. It's like, okay, we've, we've actually confirmed with the customer, they received the value they were Hoping to get out of this, right? Also incidentally, doing it that way gives us the opportunity to get the feedback that we 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 it the way that I suggested, which is also the way that this document infers. this document doesn't dictate how you're gonna do things, but it also doesn't get into the nitty gritty of helping teams. The teams still have to extrapolate from this document the best way to do it. most teams I say would 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 definition of outcome done , that column needs to come before development starts working. Oh, you have to define the definition way upfront. I do agree with that it's just the validation of that. Once you've done the work, , if you are not putting up silos and your development team truly is self-organizing, self-managing self, whatever term you want to use in any addition of scrum guide, like the development team, this shouldn't be the designer's job. This shouldn't be the product manager's job. This shouldn't be Marty Cagan's job. This shouldn't be any 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's gonna solve their problem. Right. And , you can stub out some stuff in Dev that's just like front end. You can do something quick in a day that maybe all that code gets thrown away or never gets promoted to the next environment or whatever., Cool, you spent a day, to have 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 customer to dedicate their time. Exactly. That's hard, but if you're using a suite of software and you have a whole team of developers in your corner you will spare the time, right? Yeah. I, as a customer just say, I can't imagine. You probably can find in that group some people that would like spend 20 minutes Right. to have their, their particular problem solved. Yeah, I understand what it's trying to say, when I hear the product management folks hammering the Scrum folks to be like, there's no value in that, or like, our problems are not solved with any of that. Like, this is the kind of stuff it's like, you should know before your, before your development team is doing all this work, you should know that this solves a problem. I'm not saying that you don't need the extra column afterwards. Definitely do that too. Yeah. I mean post-delivery telemetry is always a good thing. But I agree. Don't start work unless you know what you're doing and who you're doing it for and why those three questions. there are problems that I would pay to solve. Right? Right I will give you money and I'll break out my wallet right now and give you cash. If I can never have this problem again, 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 and the customer's like, well I don't really have budget and I don't know, blah, blah, blah. I'm like, Hey, man, like you should, like next, listen, I was willing to take my time to do this. That's my job in product management, but next time you tell me you got a great idea now you're a little more experienced to understand they were just kind of they're a little pulling your chain over here. I don't blame customers for 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 sorting out the wheat from the chef. What I mean by that is, looking at. True needs and validating those versus the wishes, the wants and the desires. Anyone can tell you anything from 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 into the picture because you have an opportunity cost to consider. You're doing something'cause somebody told you to do it and you could be working on something else. can I give you the most boring pushback in the world? Yeah, yeah, yeah. the most boring pushback in the world for this is but ohm. Like any minute my developers spend not writing code. that's overhead. That distracts them from producing quality software. Talking to people. Yeah. I, we have seen that. people have told me that. People have been very passionate about that. Absolutely. Yeah. They'll say things like this happens. Typically when you have a PMO type of setup, they'll say, we're paying these developers to write code we're not paying them to talk to customers I mean, these are all massive anti-patterns. So what's interesting about this point is in this expansion of the Scrum guide, they actually mentioned that one of the objectives should be to reduce the distance between. Product developers, which is what they call developers and testers, et cetera. We used to be called developers, are now product developers between them and stakeholders, which they're also changing now to supporters, right? So I think they're heading in the right direction, but it seems to me they seem to be like hinting at that, right? Rather than saying, do this, there's no, there's no, there's no direction here other than suggestions. And they'll hide behind that. The fact that this is a framework adopted to your use. Let's talk about supporters. One of the things that the DLC ads is a supporter, is a specific stakeholder type. Supporters are supporting stakeholders and change agents, supporters are supporting stakeholders and change agents. Supporters are often part of a powerful guiding coalition. who inspire and remove demotivating factors supporters support the Scrum team to thrive and influence the organization's workflows, processes, and systems. Supporters should participate when and where needed and or as requested. Value creation often requires effective and constructive collaboration with other stakeholders. Stakeholders are entity, individual or group interested in, affected by or impacting inputs, activity or, or outcomes? So this is the same as they were before. Okay. Stakeholders, right. But then supporters, I guess. So I guess supporters are like managers. People that like help the Scrum team actively help depending on the size of the organization. Example, the supporters include are 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. That's a good one. Governance, oversight. You know what I think about 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 that isn't on the Scrum team. Yeah. Yeah. I wanna look at his 83 and 71 reference before we get outta this section. 83 is Kotter Leading Change. We did a whole podcast on that. I nailed it. yeah, yeah. So I think we, I think we got a handle on supporters. I think the advantage here is it acknowledges that like Scrum doesn't just live by itself. Like there are these other people that have control of finance and have control of the, the say on who goes on what teams. And they, they have control of like hiring authority and stuff like that. And those people are not on the Scrum team, right? Like, theoretically the Scrum team is self-managing. They figure it all out. But in reality. You have supporters that are meant to support the team. So that that, that's a positive to me that like, there is some acknowledgement of that. Yeah, I agree. I also think that it's sort of antithetical to what Sweiber said you don't need this elaborate structure. Right. We need just enough structure. Oh yeah, that's what it says in the gate column too. Yeah. I mean, you are, you're right. I mean, we don't need, like in a startup Oh yeah. You don't need, you don't have that. Yeah. You don't have it, and you don't it, and you know what? Somehow they're successful, somehow they figure it out. Yeah. Role proliferation and the core of Scrum, I mean, the core of Scrum is, simplicity. I mean, it's a really simple framework. the scrum guide itself, like not the DLC. Hey, you're just a bunch of people working together and being cool. I don't know how I feel about this category, you know? It goes against the principle of just enough structure. So . The next point is the DLC states that a product developer who is neither willing nor ready, nor able to be a professional, should step down as a product developer. They have this, this terminology should, should step down. Let, let's search for, should step down. Okay. So I'm searching for, the words should step down and it's under product developer. Okay. Here, the product developer is an accountability. It says, all product developers together should possess all the skills needed to create increments. The combined skillset, often referred to as cross-functional. Okay. Yeah. So the, so this was developer, now it's a product developer.'cause we throw product in front of it because Marty Cagan wrote a book. That's right. He wrote several. So now that we're all in the same marketing page, there's six references in this document to should step down. Okay. And it says as a rule of thumb, a product developer who is neither willing nor ready, nor able to be a professional, should step down as a product developer. I am wondering why this is, why this is in here at all. It's not needed I could just replace product. Developer with a janitor. Oh really? Because you gotta be professional. You are working. Let me search, let me search for the other places. Yeah. Yeah. So it says a product, product management skills. A product owner who's neither willing, ready, nor able to gain product management skills should step down. A scrum master who's neither willing, oh goodness me, they sprinkled it across all the roles every night. Product owner, product developer, scrum master, like they're all in here. They should step down if they don't want do that job. let's talk about elitist gatekeeping here. Let's talk about working in the worst work centers that I've worked in where they're saying like, well, Brian, if you don't wanna work 65 hours a week, then you should step down because we got loads of people willing to work 65 hours a week. If you don't want to be a quote professional like that, that's what, that's the 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're kind of making things a little more confusing in the product developer section, right? Because they're saying that at least one product developer out of however many you have, should be human. And they're saying that's with regards to the AI section. Yeah. Yeah, I think it is. Yeah. But they don't say it that way. They just say it should be human. And then they say. if they can't do all of these things and be professional, they should step down. And then they liberally sprinkle that across the whole document saying whatever role it is, insert your role here. If you're not professional or willing to, to gain those skills, et cetera, you should step down. I feel like that whole, all of those things are superfluous because presumably you're getting paid to do a job, right? Yeah. You bring certain skills to the table, and if you don't, you can learn those. And if you're unwilling to learn them, you'll find yourself looking for work again. So I don't know how much value that's really adding. Right? on the scale to adding value where like 10 is like super valuable, something you absolutely need and one is like, Hey man, like I could have skipped this and saw a movie or whatever. Like, this is solidly a zero. What is the point of even saying like, Hey man, you should quit your job if you don't want to do this. I feel like I'm beating it up pretty hard right now. If I'm gonna take a step back for a second and really take a look at this. He's saying, if you don't wanna play the game by these rules, you shouldn't play the game. That's basically what's going on here. and my counterpoint to that is this is not your problem with Scrum like the problem with Scrum is like working in these, deciding that you're gonna scale something that's failing already. Yeah. With all these managers that are gonna tell you what to do and like that you're not changing the org co. The problem is not at the Scrum team level. That's right. The problem is well above the Scrum team level and 55 pages here doesn't help you with any of that. And, this kind of , well, if you don't wanna work more than 40 hours, then maybe you should throw in the towel and let somebody who like, okay. All right, man. I know. I agree. Listen, that there's no reference in this document about one of the major impediments of adopting agility in general, right? Which is the organizational structure, the org structure. It's not mentioned here at all. Unless you can change that. It doesn't matter If you do all of those other things, they're not gonna work overall. Right. You won't have the impact. There's 18 references to organizational in this document. We're gonna go through every one of 'em right now. Sure. For anybody who might ever read the comments. Now let me welcome you to part of the Arguing Agile podcast that we call Brian's being Pedantic. And we're gonna go through every reference to the word organizational in this document. There are 18 of them. 2000 years later. Anyway, I wanted to go through every single one of those and what you've what you've uncovered is the fact that they do not address. Org structures in this document. Right? And that is one of the biggest impediments to adopting agility. You know, what we discuss on the arguing Agile podcast though in in arguing agile podcasts that you can go search for org structures. That's right. Hey, quick, quick, while, while the parents are away, we'll save you some time. Oh, I know we can talk about arguing Agile 1 99. This, that demings profound knowledge for transforming organizations. What else can we talk about? We can talk about work structure with stormy. Yeah. We can talk about arguing Agile 90 or culture. We can talk about self-organization when self-organization goes off the rails. 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 reference indeed in this document. So I, I please listen to any of those of our podcasts and don't go back beyond arguing Agile. Sorry. I was gonna say don't, don't go before 67 before I was editing So another thing they incorporate in this document is the Cynefin framework. Yeah. It's a Welsh word. Well, I'm done. But anyway, like they point to this popularized by the Harvard Business Review article, A leaders framework for decision making by Davis Snowden and Mary Boone in 2007. Yeah. Another framework inside of our framework, right? Talking about complexity and helping people understand the different levels of complexity. They basically regurgitate the entire framework in here. And I'm not going through it because people can read this., All they had to do is replace all of that diatribe in there with just the coning framework. Diagram. Which is a two by two, right? Just tells you what's chaos, what's what, and, and it just helps you organize which approach you're going to take based on the circumstance you find yourself in. Right? I wish they had done that, and it would've spoken volumes more than reading all of those words. I'm hoping that Dave agrees with me, Dave Snowden, who's 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, and the bottom right is obvious. It's a two by two, but there's an 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 in the complex quadrant. Mm-hmm you are probing, sensing, and responding. Mm-hmm. Right on that diagram and so on and so forth. For all of those quadrants, there is a, there is a suggestion on how you should handle that. Mm-hmm and he's got an out, so to speak, in the middle, which is where all of the quadrants intersect, where you're in chaos. And when you're in chaos, what should you do? Right. I don't think there is a suggestion on how you should behave. The only thing that I could surmise from the little reading that I've done is try and get yourself in one of the quadrants if you're in that space, so you know what to do in a known area, rather than this abyss where everything's in chaos and you really have nothing to go on. I'm gonna go out on a limb 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 inclusion because this is like academic theorizing. I understand the reason for the framework. Yeah. I understand what it's trying to do, but as a product manager, I'm trying to get. Leaders in the organization to just look for evidence that their idea is a good idea or not. Like I, this is way past that, you know? Yeah. Yeah. So it's interesting to hear you say that, A, as a person who's interested in process and how organizations navigate their way through different environments. I'm interested in the canon framework. I do think there's some value in exploring it, but absolutely not needed as such. Yeah. And on a scale of just build it to needs a PhD in systems theory, right? How much theoretical framework do practitioners need? At some point you say, look, we don't know what we don't know. Can we just do some exploration to find out and move on rather than theorize on these things and say, well, are we really in this quadrant or that quadrant? Because you're gonna get 10 different answers based on, I mean, you five people you ask, you're also talking to the guy that loves Deming. And we did two podcasts, right? Right. We did two podcasts on two different Deming books and, and we took the time to, do you know what I mean? To, to yeah. To justify doing End Deming podcast. So like, I, like I understand theory of a systems and also systems thinking. And this is not that. It, it isn't. I agree. Also from, from what what I surmise, most teams don't have the chops to understand and apply complexity theory to begin with. Right, right, right. So take this forward. It is, I mean, they added it in there. Did they need to? Probably not. Yeah it's there. I'd rather have that, that diagram of like, this is what all y'all's boards look like and like that this is what they should look again, that diagram is value. Because this whole section takes up. A page or two by itself. Oh, it's more than that. I, I would trade this out for like a page of what y'all's boards probably look like. And this would be a good addition. Yeah. That you could really I, I mean, I, I don't know. It's two diagrams. Here's your, what your board probably looks like here. Here's what you might benefit from, which is that suggested extra lane in there, or a column rather. I mean also you're handing this over. A lot of scrum teams don't have a scrum master. They're just asking the developer to play the role part-time or whatever. And the developer is gonna bring up this theoretical framework. It's not gonna happen like it's 55 pages. They theoretically threw everything in the kitchen sink in here. They did that They could think of. I just don't know speaking of overcomplicating, let's talk about their, their division between product thinking versus project thinking. This should be an easy win this category. Yeah. And this is, again, not a new concept, right? That they've introduced here, right? Right. Everyone's known about this or they should have, so I'm showing on the screen what I'm reading. In the product thinking section, it says people consume products including services, not projects, people consume products or services. Mm-hmm. A product is a conduit to deliver value, balancing the short and long term. This is why Scrum has a product owner, not a project owner. Oh boy. A bunch of people, like I was gonna say, we lost PMs. Now project managers products are long-term and need to be taken care of for their entire existence, whereas project is time box and often leaves an orphaned product behind once a project is completed. I mean, I like, I feel this was a good inclusion to be honest. I think so too, because it talks about how the product lifecycle is way beyond just a project lifecycle. Yes. I think they should have led with, led with this. I think it should, this should have been the opening paragraph. It's like, all y'all thinking you can do this stuff, scrum. What we're talking about, what we built as projects, right? Y'all are wrong. And, and that's, well especially given the, the definition of success for projects is way different than definition of success for products, right? So product, let's talk about sustainable products, right? Yeah. they generate value for the users. The users consume them. You can pivot based on the market need. You can pivot based on what users are telling you. You can change direction that they're not fixed scope. Fixed duration, fixed scope,. Fixed timeline, they align with your business model. They can change when your business model, if you have a strategy pivot for your business, they can change. You cut projects when this stuff happens. Oh, This project is running too long. Cut the funding off. Cut it off. I do like this inclusion in here. I think they could have spent more time here than on the cynefin framework. Right? Oh boy. Possibly. Yeah. But you know, the, the against on this is, well, at least with the project, we know how much money we have to spend. Sure. We know roughly by when we should be done. Mm-hmm whereas if you just think about building a product instead, we're gonna keep going. We don't know when we'll be done. Yeah. We don't know how much money we have. Keep going back to the well for more money. Yeah. And end up with what they call product theater. Well, I mean, that's what Marty Cagan calls product theater. Like in you, you the thinking and also the thinking that inside of a product is just multiple projects back to back to back. And then the, that, that thinking into like, oh, well the Scrum team is just like a. Project delivery team that delivers micro projects into whatever, like timeframe buckets that are cut up. Like even that is like you've already failed 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 product and the product teams don't fund projects. Right, right. The, the funding mechanism. and in fact, in the other that we already talked, we already finished talking about that category. We was talking about the supporters of your Scrum team being financed, stuff like that. I think they missed an opportunity to say like, well, your finance person that supports your product team should be part of your team. Now maybe they don't have anything to do. Sprint over Sprint over sprint. But they can come in and go as they need to. Maybe you only need them like twice a year but when they come in, they need to explain to the team how finance works and explain to the team why things 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 idea to have a more frequent than that, though, like maybe every quarter to say, here's how we're metering against our, our march right. You could extend the same argument to other allied domains like hr, for instance. Right. As you're right. Sizing your team and you're constantly doing that. well, definitely when we have headcount 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 spots is vacant on the team, yeah. That person is now a regular part of the team for as long as that spot is open, until that spot gets taken away from the team, or until that spot gets filled by a new hire. Yeah. Like that person, that person should be part of the team. And in this document, they don't, they don't make that bold claim that like these supporters. Are team members, they don't even allude to that. And that's a miss, I think. Well, they make up a new, they make up a new role rather. Yeah. But that's about it. Right? They don't say how they should be involved in the team. When you're at a startup, those people really are team members for as long as you have that role open. Sure. For as long as you have finance questions, those people need to be in constant contact. Maybe you have to create ad hoc meetings because they're not just gonna show up every day . How about a better way of working would be to put your arms around the whole ownership of the problem. Be like, Hey, we need your help. Please join our standups. Maybe we can help you. You're not getting people applying for the position. Maybe we can tweak the resume. We're not getting the quality candidates. Maybe everyone on the team can reach out to people they've worked with or whatever. There are things that the team can do that you, by yourself as a recruiter, finance, whatever, are limited when you're leveraging the whole team. So that like, there's a failing in here to be like, Hey, scrum really does work. I mean, it really does work, right? Mm-hmm. Scrum really does work, but when you're trying to put all these guardrails, silos, all that kind of stuff, like you're really chipping away at what makes Scrum work. that should have been the executive overview, of this document. You should have been like, Hey, , there is no executive overview that says here's a one page summary of the 50 pages. 50 plus. I mean, I shouldn't have to tell. That's not, I shouldn't have to tell the crew that wrote this, that executives, I'm not gonna read a 55 page document. Exactly. I agree.. The product thinking section, I think it's good. I mean, I like this section. I think this should have been the intro to the whole document and the whole document should have been framed around this, but also like , you guys miss the market opportunity 'cause Marty Cagan wrote a book about this. He wrote several, actually. Mm-hmm. And now you're behind. Alright, let's look at emergent strategy. So the guide, I mean, this is actually a pretty large section. It is a very large section, probably too large on emergent strategy. So it basically says strategy is not limited by scale. It exists, it should be clearly articulated at the corporate business unit or product level and remain coherent and integrated across all these levels. I agree a hundred percent. No, I agree so far. Yeah. Crucially, strategy should distinguish between ends and means ends meaning quantified. Stakeholder valued outcomes and means meaning how you get there. Initiatives and activities, Drawing and adapting. Roger Martin's work. I'm gonna assume this is that is the Roger Martin. I'm gonna assume 41 is how to play . 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 I thought it was gonna be. No, but it is the Roger Martin, I think. 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 podcast on plane to win. We did, we did. Now you gotta look on which podcast it was. Curtis was here, I think. I don't think you were here. So emergent strategy. He says, for a situation where expertise alone is sufficient? To ensure strategy is iterative, actionable, and value focused. And he gives a big list Of things for a situation where expertise is valuable, yet insufficient cause and effect are only coherent in retrospect and uncertainty needs to be embraced. Scrum teams and stakeholders need to, and then he gives a big list of things. I understand what they're doing here, but it seems, I don't know, it's a bit misplaced. it seems haphazard in its compilation. You know, it seems like what they're saying is like. Market conditions are moving faster than you can react, and your strategy needs to be emergent. Your strategy needs to basically follow the users and follow'em as closely as possible. Which in principle is fine. Yeah. But I gotta say like, in actuality like strategy is that thing your leadership team does once a year at an offsite that you are not invited to. Yes. Yes. And questioning it is like now 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 already decided go work on it. Well, let's pivot from that because some people might be like, oh, Brian, like you're the product manager. You should be involved in the strategy, don't play the victim. Okay. But , my executives are gonna say, well, Brian, you're just, you're just shopping different strategies. You're, you're testing 'em. You, you have no plan. You're just testing everything and going, which, what? Whichever the way the wind blows, you're going that way. And it, it seems like you have no plan. No plan is your plan. That's that's what my executives will come, that is a real danger and they won't fund me. They will not. Yeah, they won't because they don't have confidence in what you're Correct. Bringing to the table e even if, even if I will win, yeah. Because you are actually looking for evidence, et cetera so yeah, you win in the end, but yeah, right from the get go, they won't fund you. So I think there's a time horizon to consider here. The Scrum team's working on something that's 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 handed down the strategy, right. Possibly through multiple layers to say, go work on this, go deliver this so this is little bit misplaced, I feel like, in this document what can the scrum team do? You can't just go knock on the senior leader's doors, right. The C level and say, Hey, I'm gonna tell you what the strategy should be, or let's co-create the strategies. Like nobody invites you in. Yeah. When, when you do that, well that, 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. Why don't we work together? And I'll bring you some evidence saying, why don't we lay out a bunch of potential strategies and then we'll make tests for each strategy, and then we'll test them against the market. And now you're back in product discovery and I would argue. Again, my role on the podcast as a product manager I would argue I don't need this 55 page DLC that I buy that adds like this ridiculous quest that I'm not even interested in doing. I can read the Marty Cagan books. I can go buy that game, you know? Yeah. and go play the whole game without any DLC there, there's a bunch of books written for this. Okay. I agree. So I go back to what I said earlier. It's misplaced in this document, at least because the teams can't do much with it. I want to go into the end of the podcast here and talk about like. Okay. The, the expansion claims that Scrum is founded on empiricism and emphasizes evidence-based decision making, right? Yeah. But also like empiricism, even in the original Scrum guide. And when you tack on product management, like as a discipline that's works with Scrum, like that, the product owner is 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 form of tPI, transparency, adaptation, inspection. Inspection. Not in that sequence. Transparency. You've gotta be able to see what you're doing, inspect it, and then adapt as needed so they had that in there for some time ago now. Which, which is so interesting because that's, that's just the OODA loop. Like it is just a re So, which is in, which is in the 55 pages. Yeah, yeah, yeah. They reference the oodle loop in the 55 pages. Yeah, yeah, yeah. It is exactly that. It's, it's just a different acronym, but I don't know. So, the educated hunches, like they, they reference educated hunches in this document. Yeah. Like like, okay, I get it. Like I, because we did a podcast 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 in here is like, oh, it's educated hunches to move you forward. But I don't know. there, there's a, like with 55 pages, you would think the clarity should come through. I just don't think that the , I'm trying to give the document a fair chance. That's what I'm trying to do. But at the same time, if everything is empirical in the document, nothing is, nothing like the term lose all meaning everything's empirical, but your hunches are empirical, but your evidence is empirical, but you're not going out on a limb in the document. And you, and trying to like separate the mode one, mode two, thinking of like, you're making snap judgments, but also you're making judgment based on evidence and experience. Yeah. So are you making, are you making snap judgments off of experience and your feeling? Are you making judgements off of well done Experiments with evidence. Yeah. and those two things like it's just not laid out very well in here. Yeah, I know. And so one of the things that is in the against is educated hunches are just like it says here, just like your opinion, man, right? So you ask four people their opinions on your educated hunches and see how they land. So what they could have done here, just like we talked about , the boards., Hey, like after you deliver something and validate with a customer, what they could have done here is they could have said every work item that you pick up, every swim lane that cuts across all your steps it has a verifiable hypothesis. Right? Mm-hmm. And then we can measure that statistically at the end of the phase when we deliver it with the customer, We can measure that. And they could have gone forward really taking empiricism and making it the cornerstone of Scrum to be like, Hey, you need to change all your work items to comply with the fundamentals of empiricism. So your work item is, if we do this, this is gonna happen. Right? And then the end is either a con, 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 either true or false at the end, and like the software might be good and they, but the original empirical statement. True or false, no matter how the software turns out. Yeah. and it might be great software. Turns out that our original theory is false, but software is great. Everyone loves it. That could happen. But there's learning in that. That is not what's being set up in this, in this 55 page 25,000 word setup. It's like, well man, it's kinda like your opinion. I don't know. it's weird. it's weird to be in like empiricism should be a 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 there frustrated by that. I see you, I see you frustrated by that. But. I think you would agree with me. Most development teams, when they launch off to like spend a month working on a feature, they're just trusting their gut against or they're just taking orders, but Yeah, absolutely correct. So I think there's levels, right? Development teams don't really feel empowered most of the time to say, Hey, this is our gut feel. We're gonna do this. Yeah, they're gonna do it because that's what the PO or the product manager has specified they should do. No, no, no. But that's a cop out yes it is. But, but that person could take ownership to be like, well, 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 if we do X we'll get Y output. And again, if you're testing hypothesis as you move along, you can say, okay, the customers I've verified the with say that the Z would be the output. We're gonna do x. Put it on the wall, we expect Z output. And then just put that on the wall for everyone to see it, they could have, if empiricism truly is the core they could have if, if it's a creamy nouget core, they could have peeled the chocolate layer back and be like, this is what it should look like inside. absolutely correct so this can actually in practice, be implemented in the form of experiments as well. You say, if we do this, we expect this to happen. Let's try it out in the smallest possible slice of work. So we don't spend a lot of time trying to learn from it and go from there . I also think a lot of times teams know that something could be in our way this isn't really the right thing to do, but they don't. They either they're not empowered to or they don't speak up. you just pointed out I think what the core of what they could have done here Yes. Is yes. They could have pointed out like what's we are gonna take on a feature and the feature is like a problem wrapped in a solution statement. We're gonna strip back the solution until we get to the problem. And then we're gonna validate the problem. Validate the problem. And validate the problem means learning, right? So we're gonna, we're gonna learn. Until we come up with a solution. And then we're gonna implement a solution at the, like the tiniest cross-functional, everything that's in here, and then we're gonna validate that actually solves a problem. And then we're gonna go deep and we solve the whole problem. Like they, they could have gone like, here's the steps. Break your work item down. Learn, learn, learn. Implement, learn, implement, learn. Solution. Solution done. Yeah, I agree. That would've been extremely helpful. Not to harp on this, , because I brought it up 5,000 times today, but they could have graphically represented this. Yeah, so like when you have a brick of text, they could have been giving you some diagrams to be like, Hey, here's the way you probably do it now at the end you got a radically different board. I think I should do that. That is so if they had done that, that would've been a good blueprint for teams to follow, to work with their leadership Right. As well because they can actually illustrate the logic behind it and it would, how he arrived at a conclusion. And it would've been great if. The individual team boards all rolled back up to a strategy level board. Unfortunately, most alms don't really cater for that. Also to your point about illustrating things with diagrams, it's telling that this document has zero diagrams none well, that's a problem. If your framework needs 50 pages and 25,000 words, words. Yeah. Yeah. Yeah. You're building the next rational, unified process. I feel what they're doing here is they've watered down the scrum guide for Mask assumption and now they're wheeling back this, the market's been segmented with product management saying like, we don't need these scrum people. Like, they're losing money basically. Their wallet's a little lighter than it was five years ago. Sure. if the cynical part of me is being taken out of it, I would say like 50% of what we talked about today was , good additions, but the bad parts that were being added, , the misses were, the additions didn't go deep enough and, the parts where they missed, they really whiffed the ball. I think what's happened here is in this so-called expansion pack, what they've done is they've added quite a bit of work from the original scrum guide, which is what about 13 pages? Yeah. 12 or 13. Yeah. They've added that, and then they've elaborated on it. They've changed some vernacular so developers are no longer developers. They're product developers. Yeah. And they've added some roles like supporters, et cetera. All of that could have been done in a page or two. Literally in a page or two and they could have just launched the new version of the Scrum guide. Scrum guide version 2025 so it'll be now what, 13 instead of 13? It might be 14 or 15 pages. Sure. Not that much of an ad as opposed to this, I feel sorry for somebody coming into the field, 'cause I think seasoned practitioners would, see through this, but yeah. Somebody coming into the field would have to read the scrum guide as they say here, that you should do And then read this and, and, and be left to work out the pieces. And that's a shame. Yikes. All right. well if, if you have an opinion about this new DLC pack or I mean, if you're like me and you don't wanna buy the DLC. And you think the original game should include all this stuff. Send me a comment and tell me I'm right or wrong. Yeah, I would love to hear from you. Also, let us know what you want us to talk about next. And don't forget like, and subscribe