Is scrum broken?

Read along you will

Murray: In this episode we discuss Ron Jeffries article. Can scrum be fixed? We talk about Ron’s concerns with the scrum industrial complex and developers issues with scrum. We talk about what we like and don’t like about scrum and how the gaps we’ve experienced can be overcome

Shane: Welcome to the No Nonsense Agile podcast. I’m Shane Gibson.

Murray: And I’m Murray Robinson. 

Shane: Hey Murray. How are you today?

Murray: I’m good. Thank you. 

Shane: Excellent. I think this week we are gonna talk about, is scrum broken?

Murray: Yes, is Scrum Broken. Ron Jeffries, who is one of the Agile manifesto authors wrote a article called Can scrum be fixed? Just recently. And I thought we should talk about it.

Shane: So do you wanna give us a bit of a summary of some of the key points Ron makes, and then maybe we can go through and pick them up one by one and have a chat about them. 

Murray: Yeah so he’s basically saying that for most people, agile is Scrum, whether we like it or not. And he sees a lot of problems with it. He’s previously written articles on Dark Scrum, which is about organizations using Scrum to oppress developers and make their life horrible. 

And he’s talked about imposition, which is scrum being forced on people, whether they like it or not. He says Scrum ignores developers, it does have a developer course, but he doesn’t think it’s very good. 

I don’t think he’s anti scrum, but he’s very concerned about it. And I have some things I like about Scrum and some things I don’t like, and I thought maybe we could talk about those. 

Shane: All right, let’s pick up that first one that you mentioned. So is scrum Agile or is Agile Scrum? So there is a lot of behavior I’ve seen where we interchange scrum and Agile as being exactly the same thing. For me, the Agile Manifesto gives us a good way of thinking about things. Scrum gives us some good practices and patterns that we can adopt if they work for us. When I’m working with a new team, I will typically introduce some of the Scrum practices first because in my experience working with them over many years, we seem to get better results by doing that first and trying to adopt some of the other agile practices, but I’ve always struggled with this idea that Agile is Scrum. Cuz for me, scrum is just a bunch of patterns that have value. But it’s not actually what you would define as agile.

Murray: Yes. I agree. This idea that Agile is Scrum is very common and most people I come across who are doing scrums think that they’re doing agile. But Ken and Jeff were just two out of, I think 14 people who developed the agile manifesto. And most of the people there were coming more from an xp object-oriented design and development approach. And so agile is a lot broader than Scrum . 

Shane: Yeah. I haven’t done a lot of XP or worked with teams who have, but he says in his blog, scrum, if you fuzz your eyes is like xp, except it forgets to mention how to actually do the work. Yeah. I’ve always found it interesting that, xp, which is my understanding being around longer than Scrum has didn’t become overly popular yet. Somehow Scrum did. And is that because there is less rules to follow, so therefore it’s easier to adopt? Or is it there was better branding done? Or is it just right time, right place? 

Murray: It’s because of the aggressive marketing and certification of Scrum that XP decided not to do. Scrum has developed a way for people to make money by spreading Scrum, so you can become a certified trainer and get people on your courses. And so all that money means that people have a strong incentive to spread it. Now, XP doesn’t have any of that. It doesn’t have certifications or courses. That is the main reason that XP has been forgotten and Scrum has triumphed. 

Shane: Wow. So what you’re saying is, if we wanted to make some money, we could start doing XP certification branded as Scrum 2.0 and would make a fortune. He uses a term scrum industrial complex or sick. So I’m guessing that’s a slightly negative view on the certification industry around scrum training. 

Murray: Yes. Martin Fowler talked about the agile industrial complex a few years ago and he’s just applying it to Scrum. So yes, , there is a industrial complex around it particularly around the Scrum alliance. And you might be aware that the founders have both had big fights with the Scrum alliance and split off into their own groups. Jeff has gone to scrum at scale and Ken has gone to scrum org. I have found people in the Scrum alliance to be very mixed . There’s people who are terrific, humble, friendly, cooperative, but there’s also leaders in that community who are arrogant and, guru like. Their way is the only way. There’s at least, one in each country who’s a leader who has that sort of approach. If you say anything critical about Scrum at all on LinkedIn , you’re gonna get a whole hoard of people coming and attacking you. And they’ll often make very personal remarks. I’ll call you an idiot or say you don’t know what you’re talking about, or you’re not actually doing Scrum. And there’ll be people who respond to this discussion in that same way. And I’d like those people just to remember that an attack on the person rather than argument is a logical fallacy that doesn’t prove or disprove an argument at all. 

Shane: Yeah, one of the signs that it’s not broken is that it’s very popular and there are a lot of passionate people that believe it solves some problems. So that’s a good thing. But you get people who all have different personality styles. You have servant leaders and you have people that like to be at the front. And it’s the same when you get things that are popular like this, you get people who are humble and people who are arrogant. 

So let’s go back to that certification. I believe training is a good thing. I believe that when teams are starting off and being introduced to some of the Scrum practices, that going on a two day course is a good thing. Going on something that and explains some of the concepts and gives them some practice and gives them the terminology and gives ’em that introduction that’s a good thing and we should encourage it.

Not a great fan of the fact that you get a certificate at the two day mark that somehow has gone from being a certificate of you just turned up and did the two days to some kind of certificate that you are, an experienced scrum master. And in the blog Ron talks about people who define themself as an agile coach often being a retrench management consultant or a project manager. Or I think you said somebody who looks after lawns.

Murray: Yeah, I remember that.

Shane: And so it’s one thing that I’ve always struggled with is the difference between a Scrum master and an agile coach. When people ask me, what I say is scrum Masters were the original Agile coaches. They were people who were experienced working with teams. Introducing these practices and helping them be successful. And then the advent of the two day certificate meant the people who were experienced had to differentiate themselves. So they invented the term agile coach. And so it became a title people used when they believed they were experienced. And started meaning that the scrum master role or term started getting degraded. And I think that’s one of the negative impacts of scrum Master certification in terms of those two day certificates.

Murray: Yeah. So first of all the term for this role of scrum master is a awful term for many reasons. One is that you become a certified scrum master after going on a two-day course. So you’re not a master of anything, and it’s nothing like getting a master’s degree in something. There’s a vast amount of difference. And the second thing is that scrum Master harks back to School master or Slave Master, which is pretty awful for a approach, which is all about self-managing, self-empowering team. So I think that the term is pretty awful for multiple reasons, But they’re not gonna change it cuz it’s got such strong, marketing and brand awareness now. 

Shane: yeah, but they should change it, we’re seeing other words in the world that come from a negative history being changed. So why don’t they update the scrum guide to say scrum coach. 

Murray: yeah, they should say Scrum coach 

Shane: hashtag Scrum coach.

Murray: So the scrum master is very focused on one team, the scrum team which as you know, is, under 10 people. But they do have a responsibility to serve the organization by leading training and coaching the organization in scrum adoption, helping people to understand it and removing barriers between stakeholders and Scrum teams. So even though it’s very team focused, scrum does have this goal for the Scrum master to help change the organization to Scrum. Still being very focused on one team and I’ve never seen anybody do it from that position. I heard of one person who says that they did it, he’s a real expert. I think that in agile coaching there’s a lot more than working on one team. So the Agile coaches I know are very experienced people. They’ve probably been doing Agile for at least 10 years and they’ve been Scrum masters and they know a whole lot of other Agile approaches, not just Scrum. And now what they’re doing is they’re helping the organization with the way it’s implementing Agile across many teams. 

Shane: Yeah, so if we look at it, what we should really be doing is saying that for those Scrum coaches, there’s a level of expertise. And I’ve talked before about the idea of, novice practitioner, expert and coach. So after a two day course you should probably call yourself a novice scrum coach, because you’ve got to go out and do some learning. If all you do is help people with Scrum, then you’re a Scrum coach. If all you do is help people with safe, then you’re a safe coach. If all you do is help people with less, then you’re a less coach. And then if you have experience and can adopt practices from a lot of the different, agile approaches. So if you have experience with Lean and Scrum, and Safe, and Nexus, then perhaps you are an agile coach because you’re across a lot of those things.

But again, there’s levels of expertise. So maybe you are a novice agile coach because you’ve done a lot of Scrum and a little bit of lean. And so again, you start up to your coach, an expert coach for agile maybe that’s where we, the industry should be going because that way at least there’s buckets. Then the question is, how do you decide when you change bucket? If your hourly rate is a contractor between being a expert agile coach and a coaching agile coach is a hundred bucks an hour difference, you gotta try and get yourself in that bucket. So how do we do that? Because it’s not certification unless it’s something other than running attending a course and getting a stamp.

Murray: To go back to Ron, what he’s saying is that he wants there to be a, much higher level of skills, particularly in in the developer community around Scrum. And what he’s asking for is developer courses developer certificates that can be earned via external sources and for them to support independent providers of developer focused scrum training. So he’s asking for the Scrum Alliance to move away from their monopoly scrum master certification. So if you go to the Project Management Institute, they have a much broader approach to this. So to be called a agile Practitioner in project management, you’ve got to pass their exam. But there’s lots of people who can help you. And then after that, you have to have a whole lot of experience and you also have ongoing certification or training units that you have to do to stay current. They aren’t provided by the Project Management Institute. So the Project Management Institute is much more open to supporting, independent providers of training.

Shane: So that sounds similar to the practices that the accountants. Groups have, and the lawyer guilds, they have this concept of continuous education and, proving your practicing in the industry and are worthy. Is that what he’s saying is we should be moving towards some of those patterns more.

Murray: Yeah I think so. He’s saying here that the Scrum Alliance is very focused on certification and Scrum alliance training and Scrum Alliance approved trainers. So it’s too narrow and it doesn’t support the independent training IC Agile is much more flexible. I signed up with IC Agile as a trainer a while ago because they have learning outcomes that you’ve gotta achieve in your courses. You produce a course, and they look through the slides and then they quiz you about it to see whether they think you’re going to deliver the learning outcomes. They want to provide a certification and then they insist that everybody who goes through the course do a survey with them so they can get feedback on the training providers to make sure they’re good quality. If they’re not, then they work with them to improve their quality. So that’s much more open.

He’s basically saying that scrum Alliance in particular is too narrow , or too controlling. Now there are alternatives. You can go with scrum.org, which Ken Schwaber set up. That is one where you don’t have to do a scrum org course you can just go and do the exam. So you can do any course with anybody. And If you do the exam and pass it, then you are a certified Scrum practitioner. They can’t call it certified scrum master because the Scrum Alliance went to court to sue them about the use of the term.

Shane: So another great idea for hashtag scrum coach. So they can’t sue people for that cuz they didn’t pretend they invented it. 

Murray: But to go back to what Ron is saying, he’s very concerned about Scrum from a developer’s point of view, and I’ve heard quite a few other people coming from a developer’s point of view complain about Scrum. So what I hear a lot is there’s a whole lot of meetings that are a waste of time for developers, particularly the daily standups. A lot of those meetings are quite controlling. What are you working on today? What are you working on tomorrow? And quite a few developers feel like they’re being micromanaged because they have to report every day. And then Scrum has no concern about technical practices at all. But Scrum says it’s a process framework or a container for technical practices. But nevertheless, developers will often complain that Scrum just ignores all of the technical practices and you get all of these Scrum masters who are non-technical. So they don’t support, or encourage the technical practices like T D D. And then the final criticism I hear a lot is that Scrum is most suitable for extroverted people because it’s based on a lot of communication and introverted people don’t work so well with all that verbal communication. So those are the four things I hear from the development community. I was wondering what you were thinking about that.

Shane: Okay, let me go through them in order or as I remember them, I think I only remember three. So tell me which one I missed. The first one the ceremonies, I’m gonna probably cause heresy here, cuz in his blog he talks about scrum by the book, not scrum on the ground. And talks about Scrum on the grounds, horrid and should be burnt to the ground. I don’t follow, I don’t work with teams and insist they follow Scrum by the book. I say to them, there’s some good practices in there that have value. If they have avenue for you, use it. If they don’t find something else that fixes the problem. So daily, standup’s a great one. In my experience starting off with daily standups helps.

So teams that I coach typically start off not being good at communicating to themselves. They have been taught to be factories. They’ve taught to be working as teams of one. They’re taught that the only time you communicate is once a week at that horrendous one hour team meeting where the team lead or team manager talks at them for 55 minutes and then says, so has anybody got anything they want to add?

And that’s just bollocks. So for me, forcing the team to stand up and talk to themselves every day for 15 minutes has value at the beginning. And I use the word forcing because they don’t want to do it. They’re not comfortable doing it. They don’t like doing it. But once they’ve done it for a little while, they typically see the value.

Now, that’s stand up done well. Stand up where the team are talking to themselves about what they’ve done, what they’re gonna do, and any problems they have. That’s not with the scrum coach standing at the front, drilling them on, whether they’ve done that card or not. At some stage, the teams I’ve worked with get to a stage where they don’t need to stand up. Where they’re actually communicating to each other on a regular basis because they’ve just learnt to do it. And therefore I suggest they drop the standup. Now when something changes, when they get a new team member or something fundamental changes to the way they work, I always suggest they go back to a standup because they want to reinforce that communication. It’s a practice that has value at the beginning and when they get really good at communicating without it, drop it. What was the next one? 

Murray: Technical Practices are ignored and Scrum masters are non-technical, so they ignore all the technical side of things. 

Shane: So I think there’s real value in having somebody coaching the team with technical patterns they’ve seen before in their domain. It’s one of the things we struggle with the data space because there’s lots of technical practices out of app dev or software development that are well published, well known, and easy to adopt. So I think there’s real value in having a coach that has domain knowledge as long as they’re treating it as a servant leadership role. So they’re using words like that’s an interesting problem. And then maybe waiting for the team to see if they’re gonna come up with an experiment themselves. And that’s hard when you’ve seen it before. If the team’s struggling, then the coach should be saying things like in other organizations or other teams, I’ve seen them try these things and they maybe list off a couple of things. Do any of those seem to, give you something you could try to see if you can fix this problem? So I think there is value if the coach has experience in that technical space. But I don’t think it’s mandatory. I think a good coach will let the team find their own solutions if they don’t have that expertise. So that’s okay.

Murray: The third one was that managers, product owners and project managers and other managers, software managers can use Scrum to micromanage the team and make the team’s life hell. And that’s what Ron talks about in his article on Dark Scrum. So you’ve got all of the daily meetings, you can turn those into status update meetings, and you’ve got the planning meetings where you can force people to commit to things. And then you’ve got the review meetings where you can make people show you what they’ve done and they haven’t done. And then you’ve got the retrospectives where you can yell at people and tell ’em they’re no good. So this is . This is how he describes Dark Scrum. It’s obviously not the way scrum is meant to be done.

Shane: Yeah, scrum and any other agile practice can be used as a weapon. So again, this is where the coach needs to step up. So yeah, I have worked in organizations with teams where I’ve suggested to the team that we no longer let anybody look at our velocity because people outside the team were starting to use it as a way of tracking progress, tracking effort, and 

Murray: comparing teams, which is a bad practice. 

Shane: And it became a weapon. It became a knife. I don’t believe anybody should be ‘ at the retro apart from the team. If you have somebody in a position of power who comes along and we start seeing bad behavior, then the coach should exclude them to tell them the bugger off. It’s the coach’s role to make sure that when they observe these negative behaviors, these weaponization of the agile practices, that we do everything we can to stop that because we need to help the team be safe.

Murray: Yeah, so I agree with you. And the last one is, developers are introverts and introverts don’t like all of the communication in Scrum. They would rather get on and do the work and communicate through email and documents.

Shane: A lot of introverts do not like the sticky note post-it, fluffy bollocks that we encourage ’em to do. I’ll tell you a funny story. I was working with a team and they had a lot more introverts than I was used to. And the team were quite uncomfortable doing retros with sticky notes on the board. So what they decided they would do is we were using Azure devOps as the kind of tool for keeping, track of stories and those kind of things. And that had an online retrospective capability. So the team decided that when we did retro. They all bought their laptops. We all sat in the same room. One person projected the Azure DevOps board up onto the screen and each person typed in their cards around what they think were well and what they thought didn’t. They then scored them, they then agreed what they were gonna work on next. They then agreed on what they were gonna do to see if that change was gonna be successful. And they did all of that by typing into the tool and not talking to each other. When they said they wanted to do that, I was like, you are crazy. This is never gonna work. But it worked for them. So we’ve gotta realize that there are introverts and some of the Scrum practices are designed for people that are more extroverted, so yeah, let them find their safe place to follow some of these practices. The retro still had value for them. They were still discussing what they were gonna try differently next time. They just didn’t do it with post-it notes on a wall, and lots of conversation.

Murray: Yeah. So the retrospectives is an interesting one. I always encourage the team to have a period of quiet reflection at the beginning of a retrospective where they write down on sticky notes, everything that went well, didn’t go well from their point of view. And then I asked them to put it up on the wall without talking about it And then when everybody’s ones are up on the wall, I get people to vote without talking for the most important things that we need to discuss as a team. And then I facilitate a discussion of the most important things and what they mean, and then what actions we might be able to take to improve.

So I do that approach because it engages everybody in the room, even people who are introverted. seen other people use different approaches where each person is expected to stand up and speak. And that’s not so good for introverts. And also I’ve seen teams where when somebody does, raise a problem that they get attacked by the product owner or the scrum master. Maybe not in the room, but maybe afterwards. so I try and make sure that when people put up all their notes, you don’t actually know who put up what note about issues. So it becomes depersonalized. I do my best to encourage everybody to participate, but also to depersonalize it. And that seems to work well. Also, I question the idea that developers are all introverts. I’ve been a developer, and I know a lot of developers and I’d say that they’re pretty much on the normal scale. I don’t think you get a lot of loud developers, but you do get some, I think maybe it’s just a bit more towards the middle, maybe a bit more introversion, but I don’t see that they’re a very different group of people. 

Shane: No. And no they’re not. but it’d be an interesting to do some, of those personality tests on developers to see if they do predominantly group and introverted versus the extroverted quadrant., 

Murray: I did some research on this cuz I was discussing it with somebody else who had this view very strongly. And the only research I can find it was a whole company where they did all of these tests and they found that the, developers were pretty much across the same spectrum as other people.

Shane: Wow. Yeah. Okay. Again, it’s that gut feel versus facts, 

Murray: just to go back to some of the 

other things, Shane, cuz I didn’t give my view on it. I think that the daily standup meeting is good and Scrum has changed it now. So you are no longer required to ask the three questions. You can say whatever you do, any format you like. Personally, I like the one where we use a CanBan board and we talk through what’s going on, what is the team working on, starting with the things that are closest to being deployed and then walking through the board backwards. And talking about it that way. I also think it’s a very good practice to talk about things every day, cuz some developers get stuck. And I remember being a young developer where I got stuck and I didn’t tell anybody for two weeks. And I think I didn’t make very much progress. they’re a bit disappointed, but would’ve been very helpful to have a, the senior developer come and say, let’s just go through what you’re doing and just gimme a bit of coaching each day. So I think that’s actually really helpful. It’s a way for the team to develop a bit of a plan for the day and also to find out who’s having problems and help them. 

On the micromanagement side, yes, scrum can be used to micromanage people. One of my first introductions to Agile back in 2004 was a program manager who told me that scrum is great cuz you can micromanage people and they don’t know. So there are people who use it that way. But as you said, Shane, you can warp any of the Agile practices and principles to do you always wanted to do. Leaders who are authoritarian and hierarchical and bullying will twist and warp anything so they can continue to do that. And things like velocity aren’t part of Scrum. Scrum is a container that you can use any of these practices in but you do need all of those practices. You need xP practices and the DevOps practices and all those other sorts of things. Scrum without that is it’s not, it’s nowhere near enough for software development. It can be okay for non-technical things. 

So my view on those criticisms is that mostly people have had experience with really awfully done scrum and that’s why they hate it. But when you do good scrum then it’s very helpful. But I guess I would say it’s not enough. That would be my criticism of Scrum. It’s only part of the solution.

Shane: After I read this blog, I noticed that there’s a couple of follow up ones, which I haven’t read yet. But looking at the short synopsis of the second one, I get the impression that he got some feedback that wasn’t positive over his first blog. 

Murray: Oh no. The Scrum Alliance attacked him like they do with anybody who’s critical. 

Shane: I pull myself up for my opinions on safe, and constantly berate myself for not being agile and not having an agile mindset with that particular methodology. It’s the same thing with Scrum, in Scrum we say to the team, do a retrospective. See what practices are working for you. And the ones that aren’t, figure out what you’re gonna change to make them better. If Scrum is all about Agile people looking at it and saying this bit of it’s not working as well as it could. Here’s some things we think we should experiment or change to see if they work better. Isn’t that the definition of Agile?.

Murray: Yeah. The manifesto of Agile software development says right at the very beginning that we are uncovering better ways of developing software by doing it and helping others do it. Now we, was a wide range of people from a wide range of different approaches XP, scrum, object-oriented design, small talk community, dsdm, Alistair Coburn and his crystal methods Bob Martin, Dave Thomas and Jim Highsmith from a project management point of view. Tons of different people. So it was about a community who were working together to uncover better ways of developing we’d say products these days and helping others to do it too. I don’t think Scrum is doing that because Scrum has become too narrowly focused on Scrum and , the certification process and the whole industry around it. That’s certainly a concern. 

Shane: Yeah. and I think that, theme comes through the blog. As people that coach other people, we should expect to be able to make a living outta doing it because we are putting time and effort into it. So that’s okay. Yeah. If we’re not adding value to a team, then they won’t keep paying us. But putting all the certification and training and all these things around it to monetize Scrum. Seems to be the underlying theme of one of the problems he’s calling out. Because once you start doing that, you have to protect your patch. You have to protect that way of making money and therefore anything that’s gonna change, that you’re gonna fight against. .

Murray: This is what Martin Fowler talks about with the Agile industrial complex. People become too focused on the money and stopping other people from teaching or excluding them because they’re not part of their little group. The other thing that’s a bit concerning for me is the first value in Agile is individuals and actions over processes and tools. And I feel like Scrum is very process focused. Now they say it’s a process framework because you can put other technical things in it, but it feels very much like a process to me. It’s got roles, it’s got steps, it’s got meetings, it’s got artifacts, it’s got a long description of how to do various things. So it’s a process for a team to manage their own work so that they can achieve an outcome. But it does seem more focused on the process than individuals and interactions. 

Shane: Yeah. Although one of the things in the blog that he talks about is Scrum doesn’t have enough practices, improved processes for the developer. Unlike xp, it doesn’t say how.

Murray: Yeah, the technical practice. 

Shane: yeah. So double-edged sword, if you have some you’re too prescriptive. And if you don’t have any, really you’re just too permissive or don’t answer the whole question. So I think for me, after reading the article, is scrum broken? No. I think the scrum certification market is dangerous and I think it’s causing some un agile like behavior. 

Is scrum itself broken? No. But is Scrum the only answer? No. I, I don’t believe you should implement Scrum and only Scrum and just what Scrum says. I think, you should use it as one of the many sets of practices and patterns that have value. I’m a permissive agile coach. As long as the team are doing things that seem repeatable, when they’re changing them, when they don’t work and they’re adopting as many of the practices they can find that have value good on them, that’s what I expect out of an agile team. I’m helping. Yeah, I don’t follow the scrum guide hook line, and sinker.

Murray: Yeah. I don’t think that scrum is dead and I don’t think it’s badly broken. I think it’s has flaws and gaps and is incomplete. So it has absolutely nothing to say about leadership and the role of managers except to say that a scrum master is a servant leader. And I think actually Scrum comes from an anarchist or libertarian philosophy where you just focus on the team and they’ve deliberately ignored leadership and management. And yet the thing that always goes wrong with scrum is that the leadership in the organization, destroys it or warps it or rolls it back. So I think ignoring leadership and management and how they need to change is a pretty serious gap. 

Shane: Yeah, there’s gaps everywhere. What would, what do I not wanna see? I don’t wanna see a 200 page scrum glide with a big a three diagram with 74 different moving parts. I don’t want them filling in all those gaps as part of Scrum. I don’t want Scrum 2.0 where, got scrum plus. There are gaps, and if people can identify good ways of fixing those gaps and publish it out, good on them. Thank you for helping us do a better job or doing things in a better way. I think that one of the beauties of Scrum is the scrum guide is so small and easy to read.

Murray: Do you remember the pigs and chicken stories? 

Shane: I use that cartoon in every training course I do with a team.

Murray: That’s quite hostile towards management that cartoon. And for that reason, scrum took it out before 2010. But I still think Scrum deliberately ignores leadership and thinks that the Scrum master should be able to change the organization from the team position, which I think is just unrealistic. So I think that there’s a big gap there. And yes, people are filling it. There’s a lot of discussion about agile leadership and we talked about, agile leadership in one of our podcasts recently. Some other issues. A lot of people still think Scrum has commitments in it because that’s the way it was taught before 2010. So this idea that the team commit to a certain amount of stories or features or whatever, there it is that they’re gonna complete and they have to work all weekend to get it done. Now that caused a lot of very serious problems over work and, quality issues and so on. Scrum removed that back in 2010, and not many people know about it for some reason. Were you aware of that 

Shane: I was aware that it got downplayed a lot, but I wasn’t aware of the background. 

Murray: That’s basically why it was removed and replaced with the idea of Sprint goals. So now the idea is that the scope is flexible within a sprint. You just start off with a kind of a plan to achieve a goal, and you can change it as you go, which is much better. But most people still act as if the old way with commitments are still there. 

The other concern I have is with the role of the product owner. I’ve seen a lot of product owners getting burnt out because there’s just huge expectations on them. The Scrum team expects that product owner to spend a large amount of their time with them, defining user stories or defining the work to be done anyway, and prioritizing it and being really involved with everything. And yet if you are going to be a product owner who is something like a product manager, you have an enormous amount of other things to do. Like we talked in our, product management podcast. You’ve got, user research, marketing business cases internal change management so many other things. So product owners are frequently burning out cause the team is, are asking so much problem that they don’t have time to do everything. So I prefer the concept of a product owner team, which is supporting the product owner with other people. Now Scrum has changed their approach to this as well. They’ve now said that the product owner can delegate pretty much everything to the team except for the prioritization and the decision making around that. So most people still think that the product owner, has to do an enormous amount for the team. Ken Schwabe used to say that they were the single throat to choke.

Shane: I’m never really been in an environment where we force the product owner to do everything. We definitely we talk about them working closely with the stakeholders and being the one person in the team can ask for trade-off decisions. And my view is we are removing the need to go to a committee. The team getting trade-off decisions made quickly with no ambiguity, helps them deliver more more product. So the product owner role have been able to deal with the stakeholders and very quickly come back to the team or make the decision themselves on those trade offs has massive value. Teams I work with, tend to use the Three amigos process for backlog grooming the stories before we get into sprint planning. Haven’t had a lot of experience where we are forcing the product owner to write everything up by themselves and hopefully never will. Cuz it just sounds like a really dumb idea to me. With Scrum we’re talking about teams working together. Why do we then do a team of one just seems like an anti pattern.

Murray: Yeah, it is. And scrum has evolved and changed. They meet together across the various Scrum groups and they put out a new release every couple of years to address these sort of issues. So I think the product owner issue has improved. but people are just not aware that the product owner can delegate everything to the team except for the prioritization.

Shane: You know why that is. They’ve got their certificate from their initial two day course 12 years ago, so they don’t need to go on training again because now they’re expert scrum coaches, 

Murray: Ah, yeah, exactly. Couple of other things that are quite a problem. I think Scrum leads the team to have a really short term focus on the current sprint and preparing for the next sprint. That can lead to really bad design and architecture outcomes. You need to be developing architectures and designs at a higher level, looking further out to provide a framework for the team, even if it’s just a plan and then you change it as you go. I see scrum teams taking a really short term focus and it’s tremendously frustrating to design people cause they’re not working at the level of buttons they’re working on, user flows.

Shane: Yeah, and I’ll add one in there. We use the term sprint. It’s hard for a team to consistently sprint every two to three weeks on a regular basis. It’s more like a marathon. So for me, that idea of delivering something every two to three weeks has massive value, but also brings with it a whole lot of unintended consequences. And a number of teams I’ve worked with end up with a sense of burnout. This relentless pace and no break. We need to be able temper that a little bit. I still like the idea that every two to three weeks there’s a celebration of success. There’s the ability to reset some of the focus or the priorities that those patterns have value. But yeah, the unintended consequences often seems to be the team are constantly sprinting. They’re constantly at a hundred percent, and they get burnt out.

Murray: Scrum doesn’t demand that you fill the team up to a hundred percent capacity. And a good practice would be to say that the team would maybe only plan 70 or 80% capacity and then leave some room for, unexpected things or changes. But people don’t tend to do it. Maybe cuz they only went on that two day course. 

Shane: I encourage that we look at the time people have and don’t overestimate how much of that time they’re gonna spend on this work. But even doing that, I dunno what it is, and I’ve never figured out the root cause, but there, there seems to be this inherent burnout after a certain period of time, it doesn’t seem to be sustainable. 

Murray: Another gap may be related to leadership is that there’s no career development, mentoring, training because there’s no managers, there’s no software manager who can coach and train people. This is why this is where, this, that kind of matrix model we talked about when we were talking about Spotify is quite helpful. It’s something that you can do with Scrum that can continue to provide developers with, a development community to be part of where they get mentoring and coaching and support. Scrum only talks about cross-functional teams that can deliver everything from end to end, and then that’s, it doesn’t talk about everything around Scrum. There’s a huge amount of staff that an organization has to do apart from what the team does. And Scrum just says that’s not something we talk about. Which is fine, but if you think that Agile is the way your organization should work and Agile is Scrum, then a lot of people coming away thinking we don’t need any of that. 

Shane: And, we do, we, I’ll bang on about it time and time again, we need pastoral care for the team members in the squad. They need somebody who’s gonna help them increase their skills when something’s going wrong outside their work life. They need somebody who’s gonna talk to them. And that pastoral care is really important for an organization, and therefore that role needs to be available, whether we’re using Scrum or not. 

Murray: Also related to this bigger picture if every team optimizes their process and approach and what they’re doing To achieve their objectives. You can have a very negative effect when you add up all those teams together because the system is made up of lots of teams doing things, and a team that optimizes just to do their little bit frequently has a negative effect on other teams in the organization that are relying on them. 

Shane: Yeah, but that’s a hard problem to solve and I’m not convinced that getting all the people from all the teams, all 500 of them into a large stadium for two days with, cards on the board and pieces of string, and trying to figure out a cohesive strategy across 500 people trying to deliver stuff is a better technique.

Murray: So maybe to summarize for me Shane I really like Scrum. I’ve had a lot of very good experiences with Scrum and the teams that I’ve coached or been a scrum master for, were really happy with how it was going and they were very productive teams. But I see a lot of really bad scrum out there. Really weak, inexperienced Scrum masters. And I see a lot of water scrum fall. Which is just a waterfall project done in sprints, which is horrible and nobody should ever do it. But I see it being done a lot. And that’s part of that bigger problem of management thinking that they don’t need to change cause Agile is Scrum and Scrum is a team thing, so the team changes. And then the leaders and managers all just behave the way they did before and try and force the team to work in their authoritarian, hierarchical waterfall structure with Scrum. 

But look I think Scrum is really good. I like it. Particularly combined with CanBan. I think CanBan solves a lot of problems with Scrum, particularly the problem of crunching at the end, which happens a lot, whether it’s supposed to or not, I know it’s not supposed to, but it still does. And CanBan really helps you visualize your work, which is very helpful and everybody does now. So I really like Scrumban. I would always ask teams to do some version of Scrum ban. Or just can ban. But, overall I’m a supporter. I see flaws and problems as we’ve talked about, but, I wouldn’t throw it out. I don’t think it’s broken.

I think it’s got gaps and flaws. And I wish the Scrum Alliance, would fix them a bit more. And I wish they would encourage people to think about Agiles being a much bigger thing. And I wish more people understood that.

Shane: Yeah. So my view is can Scrum being fixed? Everything’s broken because there’s always a better way of doing things. You just gotta figure out what it is. So yeah, scrum should be iterated on, but as you said, my sense is they do iterate on it every couple of years and they have changed things that had unintended consequences, so that’s good. 

Do I think the Scrum training certification market is broken? . I think there are some unintended consequences of how that training’s been done. And there’s some work that can be done in that. My view, we should start talking about scrum coaches. We should, one of the things he says in the blog is about training for developers. We should differentiate what we teach Scrum coaches versus product owners versus developers. It’s all based on the same thing, but we should articulate it differently. 

Is Scrum Agile, I think really is the question. And for me, scrum is just one of the toolkits that I use when working with a team and helping them work in an agile way. So it is just one of many, and like you, I’m probably more aligned to Scrumban than anything else. But that’s because it’s what I understand and it’s what’s worked for the teams that I’ve worked with.

Murray: Yeah. If you’re a builder, then scrum for me is be something like a hammer. Very useful. You use it all the time, but you’re not gonna be able to do everything with it. It’s just part of your repertoire. Maybe it’s, 20 or 30% of agile. Very helpful, very useful. People should keep doing it but they need to combine it with everything else. They need to combine it with, CanBan with, matrix organizational models with systems thinking, user experience design, agile architecture, all of the xP practices and the DevOps practices. Agile leadership as well. Absolutely. Critical. Must be a really important part of it.

Shane: Good on Ron for Issuing the article and starting the conversation yet again on how can the world make agile better, more useful, more effective. More enjoyable. That’s what it’s about. 

Murray: Yeah. , my teams who’ve done Scrum and Agile properly, I think it’s really improved their lives and it’s improved my work life as well.

Shane: That’s right. So the real answer is you’re not having fun, you’re doing agile. Wrong. So there we go. That’s my summary for this one. 

Murray: If you’re not continually improving the way you work, then you’re doing agile wrong and you should be able to iterate out of Scrum into Scrum Band or something else if that’s better for you 

Shane: I think that’s us we’ll catch you next time. 

Murray: That was a no nonsense. Agile podcast from Murray Robinson and Shane Gibson. If you’d like help to build great teams that create high value digital products and services, contact Murray evolve.co. That’s evolve. With a zero. Thanks for listening.