Is scrum broken?

Join Murray Robinson and Shane Gibson in a no-nonsense agile discussion. In this podcast, we discuss Ron Jeffries’ recent 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.

Resources

Recommended Books

Podcast Transcript

Read along you will

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 we decided, uh, this week we are gonna talk about, is Scrum Broken? 

Murray: Yes. Is Scrum broken? Um, because Ron Jeffries, who is one of the Agile manifesto authors, um, wrote a article called Can Scrum be Fixed Just recently.

And, uh, it has been getting, uh, a lot of discussion in various social media forums, so I thought we should talk about it. 

Shane: Yeah, so he actually calls it windmills. Cam scrumpy fixed. I don’t get the reference at tilting at windmills. Do you? 

Murray: Uh, well, so Don, don Kuti tilts it, windmills basically, you know, it’s, it’s things that, that, you know, you’ll tilt at it and the windmills gonna hit you and nothing’s gonna change.

Shane: Yeah. Okay. I might have to go and, uh, do a bit of Googling on that one. So do you wanna give us a bit of a summary of, uh, some of the key points, uh, Ron makes, and then maybe we can go through and pick them up one by one and have a bit of chat about them? 

Murray: Yeah, I, I’d just like to talk about Scrum generally and what we, what we think about it.

Um, kicking off from his article, so he’s basically saying that, uh, for most people, Agile is Scrum, whether we like it or not, and. Um, he sees a lot of problems with it. He, he’s previously written articles, um, on Dark Scrum, which is about organizations using Scrum to oppress developers and make their life horrible.

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

uh, this is the, this is the sort of things he’s, he’s talking about. He’s, I, I don’t think he’s anti scrum, but there’s, he’s very concerned about it. And, um, I have some things I like about Scrum and some things I, I don’t like, and I thought maybe we could talk about those. 

Shane: All right, well 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 Hhl. Is being executive the same thing? Um, You know, 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.

Mm-hmm. . Um, when I’m working with a new team, I will typically, uh, 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, again, Scrum is just a bunch of patterns that potentially and typically have value. Um, but it’s not actually what you would define as. 

Murray: Yes, I, I agree. This idea that Agile is Scrum is, is very common and most people I come across who are doing Scrum think that they’re doing Agile, but Ken and Jeff were just two out of, I think 14 people who developed the Agile manifesto.

Most of the people there were coming more from an xp, um, you know, object oriented design and development approach. And, um, so in any case, Agile is a lot broader than Scrum, I think. 

Shane: Yeah, and actually the XP one’s really interesting cause I haven’t done a lot of XP or worked with teams who have, But he says in his blog, you know, Scrum, if you fuzz your eyes right, is like xp, except it forgets to mention how to actually do the work.

Um, yeah, a lot of people say that. Yeah. I’ve always found it interesting that, you know, xp, which is my understanding being around a lot 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, um, that XP decided not to do. So, um, Scrum has developed a way for people to make money by spreading Scrum so you can become a certified trainer and, um, get people on your courses. Um, and so all that money means that people have a strong incentive to spread it.

Now, XP doesn’t have any of that. It didn’t ha doesn’t have certifications or courses. And, um, that is talking to other Agile coaches. That is what we think is the main reason that XP has been forgotten. And Scrum has, has triumphed. 

Shane: Wow. So what you’re saying is, you know, if we wanted to make some money, we could start doing XP certification branded as Scrum two Zero and we’d make a fortune, um,

I like, maybe 

Murray: some people say that’s what safe is, . 

Shane: Um, so one of the things he uses, he uses a term scrum industrial complex or sick. Um, yes. So I’m, I’m guessing that’s, uh, um, a slightly negative view on the certification industry around scrum training. 

Murray: Yeah, so Martin Fhu talked about the agile industrial complex at, um, a few years ago, and um, he’s just applying it to Scrum cuz Martin was really mainly talking about Scrum anyway, um, Martin’s one of the other Agile manifesto authors and um, so yes, there, there is a.

There is a kind of industrial complex around it, particularly around the Scrum Alliance. Um, and you might be aware that, that there’s been a lot of splitting off. Like Jeff, the founders have both had big fights with the Scrum Alliances split off into their own, uh, groups. Jeff has gone to, um, Scrum at scale and Ken has gone to Scrum or they both set those up.

So, um, I, I have found, People in the Scrum alliance to be very mixed there. There’s people there who in, who are terrific, you know, humble, friendly, cooperative, But there’s also leaders in that community who are tremendously arrogant and, you know, guru, like their way is the only way. And there’s at least, you know, one in each country who’s a leader, who, who has that sort of approach.

And there’s been, um, there’s, there’s just, you can tell if you say anything critical about. Scrum at all on LinkedIn or anywhere, anywhere else, you’re gonna get a whole hoard of people coming and attacking you. And they’ll often make very personal, um, remarks. I’ll call you an idiot or say you dunno what you’re talking about, or you’re not actually doing scrum.

And there’ll be people who respond to this discussion in, in that same way. And I’d like those people, um, just to remember that an an add ho attack that is an attack on the person rather than argument is a logical fallacy that doesn’t prove or disprove an argument at all. 

Shane: Yeah, I mean I suppose that’s, um, if we ask the question, is scrum broken?

We can say, uh, one of the signs that it’s not is that it’s very popular and uh, there are a lot of passionate people that, uh, believe it solves some problems. So that’s a good thing. But like we’ve talked about in previous podcasts, You know, you get people who all have different personality styles. So you know, 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. Um, So let’s go back to that certification. Um, cause his blog talks a lot about that, and it’s one thing that I’ve had fairly been fairly opinionated, uh, on for quite a while. And so my view is 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. You know, going on something that takes them and explains some of the concepts and, and gives them some practice and gives them the terminology and gives ’em their introduction, uh, that, that’s, that’s a good thing and we should encourage it.

Not a great fan of the fact that, uh, a two day, yeah, you get a certificate at the, 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, you know, an experienced scrum master. And in the blog Ron, Ron talks about coaches and, uh, let me just find it because, you know, I did giggle, uh, quite a lot.

Some of the, he used, um, But I think he was talking about, um, People who define themselves as an agile coach, um, often being, um, a retrench management consultant or a project manager. Um, or I think you said, um, somebody who looks after lawns, Uh, I can’t find it. Um, , 

Murray: Yeah, I remember that. 

Shane: Um, and so it’s one thing that I’ve always struggled with is the difference between a Scrum master and a, and an agile coach.

And, and the, when people ask me, what I say is, um, Scrum masters were the original Agile coaches. They were people who were experienced working with teams, introducing these practices and helping them be successful. Um, and then the advent of the two day certificate meant the people who were experienced, uh, had to differentiate themselves.

So they invented the term Agile coach. Uh, and so it became a title people used when, uh, they believed they were experienced. Um, and it kind of started meaning that the, the scrum master role or term started getting degraded. And I think that’s one of the, the negative impacts of, uh, Scrum Master certification in terms of those two day certificates.

Murray: Yeah. Yeah. So first of all, the, the term for this role of scrum master is, is a pretty 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 there’s nothing like getting a master’s degree in something is a vast amount of difference.

Um, and the second thing is that, um, scrum master hearts back to school master or slave master, which is pretty awful for, um, For a, uh, approach, which is all about self-managing, self-empowering, uh, team. So I think that the term is pretty awful for multiple reasons, but they’re not gonna change it cause it’s got such strong, you know, marketing, um, and brand awareness now.

Shane: Yeah. But they should change it, right? We’re seeing other words in the world that have come from a, a negative. Changed. Yeah. So why don’t you know, why don’t they update the scrum guy to say Scrum coach? 

Murray: Yeah. They should say scrum coach. I, I started a petition at one point to get them to change it, but, um, yeah, they should change it to Scrum coach.

So if you’re listening guys, change it to Scrum coach. Hashtag 

Shane: scrum coach. That’s what we should do. We should start one of those Twitter things. Yeah. . 

Murray: Uh, so the scrum master is very focused on one team, the scrum team, which as you know, is, you know, under 10 people supposedly. Um, but they do have a responsibility to, um, the organization by leading training and coaching the organization in scrum adoption and planning scrum adoptions and helping people to understand it and, and removing barriers between stakeholders and Scrum teams.

So even though it’s very team focused, Scrum does have this, Um, goal for the Scrum master to change the organization or help change the organization to Scrum while, you know, still being very focused on one team. And, um, I’ve never seen anybody do it from that position. Um, I heard of one person who says that they did it, but you know, he’s a real expert.

So I, I think that there’s, um, in agile coaching, there’s a lot, there’s a lot more than working on one team. So the Agile coaches I know, um, are very experienced people. You know, they’ve probably been doing Agile for at least 10 years and they’ve been Scrum masters and, um, now they, and they know a whole lot of other Agile approaches, not just Scrum.

And now what they’re doing is they’re helping, um, 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. You know, and I’ve talked before about the idea of, you know, novice practitioner expert in coach.

So after a two day, uh, course, you should probably call yourself, uh, a no scrum coach, right? Because you’ve got to go out and, and do some learning. If you are, if, 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.

I mean, some of these words start sounding really stupid, especially if you’re a less coast who’s well experienced. So you’ll be a less coach with more

you have experience and can. Practices from a lot of the different, you know, agile approaches. So if you have experience with Lean and you have experience with Scrum and you have experience with Safe and you have experience with Nexus, then perhaps you are a, 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 lead. Yeah. And so again, you know, you start up to your, uh, coach, you know, an expert coach for, for agile, uh, 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? You know, if you are hourly rate as a contractor between being a expert agile coach and a coaching agile coach is a hundred bucks an hour difference, you know, you’re gonna try and get yourself in that bucket. So how do we do that? Because it’s not certification.

Um, unless it’s something other than running, you know, attending a course. And 

Murray: to go back to Ron, what he’s saying is that, um, He, he wants there to be a, a, um, a much higher level of skills, particularly in, um, in the developer community around Scrum. And what he’s asking for is for, um, developer courses, uh, developer certificates that can be earned via external sources and for them to support independent providers that developer focused Scrum training.

Uh, so he’s, he’s asking for the Scrum Alliance to, um, move away from their monopoly on, um, scrum master certification. So if you go to the Project Management Institute, they have a much, um, broader approach to this. So to be called a Agile certified. Practitioner in project management, you’ve gotta pass their exam.

But there’s, um, lots of people who can, who can help you. And then after that, you’ve gotta do a, you have to have a whole lot of experience and you also have ongoing certification, um, or training units that you have to do to stay current. And there’s, they aren’t provided by the Project Management Institute.

So the Project Management Institute is, um, much more open to, um, supporting, you know, independent providers of, of training.

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

Murray: Yeah, I, I think so. He’s, 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, it’s too narrow and it doesn’t support enough. Um, you know, the more independent training providers like IC Agile for example, is much more flexible.

I signed up with IC Agile as a trainer a while ago, um, because they have a, uh, learning outcomes that you’ve gotta achieve in your courses. You produce a course and they look through the slides and then they, um, quiz you about it to see whether, um, they think you’re going to deliver the learning outcomes.

They want to provide a certification. And then they basically just, um, insisted everybody who goes through the course do a, um, survey, uh, with them so they can get feedback on the training providers to make sure they’re good quality. And if they’re not, then they work with them to improve their quality.

So that’s much more open. I mean, he’s basically saying that that, um, scrum lines in particularly is too narrow. Now. There are, or too controlling now there are alternatives. You can go with scrum.org, which can schwaber set up, um, That is one where you don’t have to do a scrum org, uh, course you can just go and do the exam.

Um, so you can do any course with anybody. And, um, if you do the exam and pass it, then you are a certified scrum practitioner. They can’t call it sort of I’d scrum master because the Scrum Alliance, um, went to court to sue them about the use of the term. 

Shane: Oh, it’s another great idea for hashtag scrum coach.

So I can’t sue people for that cuz they didn’t pretend they invented 

Murray: it. So, um, but to go, to go back to what Ron is saying, he’s very concerted 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 a lot. So let me just go through what they are and, and you tell me what you think cuz you’ve been much more hands on than me of the last few years.

So what, um, what I hear a lot is, There’s a whole lot of meetings that are a waste of time for developers. That’s the first thing, particularly the daily standups. A lot of those meetings are quite controlling. So, you know, what are you working on today? What are you working on tomorrow? Um, and quite a few developers feel like they’re being micromanaged because of that, because they have to report every day.

Um, So there’s those two things. And then Scrum has no cons, no, um, concern about technical practices at all, except this is what, this is what developers say. Um, uh, but Scrum says it’s a process framework or a container for those sort of technical practices. It’s, it’s, 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.

Um, so they don’t support the, or encourage the technical practices like tdd. Um, and then the final criticism I hear a lot is the, is it Scrum? Is something that, um, 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. Okay, 

Shane: let me go through them in, in order or as I remember them, I think I only remember three. So tell me which one I missed. So, um, the first one, uh, the ceremonies, you know, um, I’m gonna probably cause heresy here cuz in his blog he talks about, uh, 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, 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. Um, 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. Um, in my experience starting off with daily standups helps.

So teams that I coach, uh, 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 have 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?

Um, and, and there’s just s um, 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, what I think happens, uh, and sorry, that’s stand up done well, that 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 at some stage, the teams I’ve worked with get to a stage where they don’t need the stand.

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 standard. 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 wanna reinforce that communication.

Um, but for me, yeah, it’s a practice that has value at the beginning and when they get really good at communicating without it, drop it. Mm-hmm. , um, what was the next one? The next one was, 

Murray: um, technical practices, uh, ignored and scrum masters and non-technical. So they, 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. Um, it’s one of the things we struggle with, with the data space because there’s lots of technical practices out of app dev or software development that are well published, known and easy to adopt.

And in our data space, it seems we’re little less served. Um, so I think there’s real value in having a coach that has domain knowledge, um, but as long as they’re treating it as a survey leadership role. So they’re, they’re using words like, Hmm, well that’s an interesting problem. Um, 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, the coach should be saying things like, Well, in other organizations or other teams, I’ve seen them try these things and then maybe list off a couple of things. Do any of those seem to, you know, give you something you could try to see if you can fix this problem?

So I think there is value, um, if the coach has experience in, in that technical space. Um, but I don’t think it’s mandatory. I think, uh, a good coach will let the team find their own solutions if they don’t have that expertise. So that’s okay. 

Murray: Mm-hmm. , Yeah. Look, I’m basically agreeing with, with what you’ve said so far.

The, the third one was that, um, uh, 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 um, that’s what, uh, 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 that they are quite unsure of.

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 has meant to be done.

Yeah. But it does seem to 

Shane: happen. Yeah. Scrum and any other agile practice can be used as a weapon. Uh, so again, this is where the coach needs to step up. So yeah, I have worked in organizations with teams where, um, I’ve suggested to the team that we, 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 Oh, and 

Murray: comparing teams, which is a bad practice.

Yeah. And 

Shane: it became a weapon. It became a knife. Uh, I don’t, personally, I don’t believe anybody should be at the retro apart from the team. Um, if you have somebody in a position of power who comes along and, and we start seeing bad behavior, then again, the coach should exclude them to tell them to bugger off.

Um, it, it’s the coach’s role to make sure that when they observe these negative behaviors, these weapons weaponization of, 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, um, introverts don’t like all of the communication in Scrum.

They would rather, um, get on and do the work and communicate through, uh, email and documents. 

Shane: Yeah, no, that’s true. Uh, a lot of, a lot of introverts do not like this sticky note post it, fluffy bollocks that we encourage them to do. I’ll tell you a funny story. I was working with a team, um, and they, they were in, they had a lot of introverts, a lot more introverts than I was used to.

Um, and the, 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, um, as the, the kind of tool for, for keeping, you know, track of stories and those kind of things. And that had a, uh, an online retrospective, um, Capability.

So the team decided that when we did retros, they all bought their laptops. We all sat in the same room. Um, one person projected the, the Azure DevOps board up onto the screen and each person typed in their cards, uh, around what they think went 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, 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. Um, When they said they wanted to do that, I was like, You’re crazy. This is never gonna work. But it worked for them. Um, yeah, so we’ve gotta realize that there are introverts and they don’t, you know, some of the Scrum practices specifically are designed for people that are more extroverted.

So yeah, let them find a 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, lots of verbal conversation. 

Murray: Yeah. So the retrospectives is an interesting one.

Um, for me, I, I always encourage the, 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. I asked them to put it up on the wall without talking about it. And then when everybody’s ones are up in the, on the wall, I get people to vote without talking.

And then, um, the votes are for the most important things that we need to discuss as a team. And then I go through and I facilitate the 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 really engages everybody in the room, even people who are introverted.

Um, I’ve seen other people use different approaches where you just go around the room and you, each person is expected to, to stand up and speak. And, um, that’s, that’s not so good for introverts. And also I’ve seen teams where, um, When somebody does, you know, raise a problem that they get attacked by the product owner or the scrum master.

Sometimes, um, maybe not in the room, but maybe afterwards. And, uh, so I try and make sure that when people put up all their notes, you don’t actually know who put up what note you know, about issues. So it becomes depersonalized. I do my best to encourage everybody to participate, but also to depersonalize it and that, that seems to work well.

Um, 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. You know, there’s a bell curve of introversion and extroversion. I don’t think you get a lot of. Loud, um, developers, but you do get some, I think maybe it’s just a bit more towards the middle, maybe a bit more.

I introversion, but I don’t see as being, you know, that there are a different, very different group of people. 

Shane: So no, and no they’re not. But I, I, it’d be interesting, wouldn’t it, is to do some of the, uh, the, those personality tests on, uh, developers to see if they do dominantly group and, and introverted versus the, uh, extroverted quadrant.

Um, I 

Murray: actually did some, I did some research on this cuz I was discussing it with somebody else who had this be very strongly, and the only research I can find on a, uh, 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: Yeah. Okay. Again, it’s their gut feel versus fact. Right. 

Murray: Um, just to go back to, to some of the other things, Shane, cuz I didn’t give my view on it. So, um, I, I think that the, the daily standup meeting is good and Scrum has changed it now. So you 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, um, use a can van board and we, we talk through, um, what’s going on, what is the team working on, starting with the things that are, are closest to being deployed and then kind of walking through the board backwards, um, and talking about it that way. I also think it’s very good practice to talk about things every day.

Cause 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, um, I think I didn’t make very much progress. , they were 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 give me a bit of coaching each day.

So I, 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. Um, on the micromanagement side, yes, Scrum can be used to micromanage people. One of my first introductions to Agile was a program manager who told me that, um, you know, Scrum is great cause you can micromanage people that was back in 2004 and they don’t know

And uh, so there are people who use it that way. But as you said, Shane, you can, you can any of the Agile values and, and practices and principles to um, you know, do what you, what you always wanted to do. Leaders can, like leaders who are authoritarian and hierarchical and bullying will, will twist and war anything so they can continue to do that.

Um, so, you know, and things like velocity aren’t part of Scrum, that’s an XP practice. So I, I think that, um, the idea that Scrum is a container that you can use any of these practices in is, um, fine, I suppose. But you do need all of those practices. You need the XP practices and the practices and all those other sorts of things.

Scrum without that is, um, you know, it, 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, um, most people have had experience with really awfully done scrum and that’s why they hate it. Um, but when you do good scrum then you know, it’s very helpful.

But I guess I would say it’s not enough. This is this. That would be my criticism of Scrum. It’s only part of the solution. 

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

Murray: Oh no, the scrum lines attacked him like they do with anybody who’s critical. 

Shane: Um, and so, you know, I pull myself up for my opinion, my opinions on safe, um, and constantly berate myself for, for not being agile, not having an agile mindset, um, with that particular methodology. It’s the same thing with Scrum, right?

I mean, in Scrum we say to the team to 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, is all about agile, People looking at it and saying, Well, 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. Well, the manifesto, 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 right now, we, in that case, was a wide range of people from a wide range of different, you know, approaches, xp, Scrum, um, object oriented design, um, small talk community, dsdm, you know, Alice Coburn and his crystal methods.

Um, Bob Martin and, uh, you know, Dave Thomas and, and Jim Highsmith from a project management point of view. Um, tons of different people. So it was about a community who were working together to uncover better ways of developing, um, software or we’d say products these days and helping others to do it too.

And, um, this, and Scrum has, I don’t think Scrum is, is doing that because Scrum has become too narrowly focused on Scrum and the, you know, the certification process and the whole industry, um, around it. So, uh, that, that’s certainly a concern. 

Shane: Yeah, and I think that that theme comes through the blog a little bit in terms of, I’m not sure the exact words are users, but it’s 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. Yeah. So that’s okay. Um, yeah. If we’re not adding value to a team, then they won’t keep paying us. But putting all this certification and training and all these ro all these things around it to monetize scrum seems to be the underlying theme of, 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, um, yeah, that maybe that’s one of the underlying themes. 

Murray: Well, this is what Martin Fowler talks about with the agile industrial complex.

Um, you know, People become too focused on the money and stopping other people from, from teaching or excluding them because they’re not part of their, you know, their little group. The other thing that’s a bit concerning for me is, um, the, the first, uh, value in Agile is individuals and actions over processes and tools.

And I feel like Scrum is very process focused. Um, now they say it’s a process framework because you can put other technical things in it, but, um, it, it feels very much like a process to me. And it’s, it’s got, you know, it’s got um, 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.

Um, so you know, it’s a process for. Um, a team to manage their own work so that they can achieve an outcome and it can have other processes in it, but it does seem more focused on the process than individuals and interactions. Yeah. Well though, one of the things 

Shane: in the, in the blog that he talks about is Scrum doesn’t have enough practices and pro processes for the developer, right.

It has, it’s unlike xp, it, it doesn’t say how, Right. 

Murray: Yeah. It doesn’t have any The technical practices. 

Shane: Yeah. So double edge sword, right? You, you, if you have some, you, you kind of too prescriptive and if you don’t have any or you really just, um, too permissive or, or don’t answer the whole question. So I think for me, after reading the article is scrum broken.

No, I, 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, and just what Scrum says. I think you, again, you should, uh, use it as one of the many sets of practices and patterns that have value.

I’m probably gonna get burned for saying this because, uh, you know, I’ll be accused of not doing Scrum, but I openly say I’m a, I’m a permissive agile coach in my head. I, 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, um, good on them, that that’s what I expect out of an agile team.

I’m helping. So, yeah, I don’t follow the scrum. Upline and sinker. 

Murray: Yeah. Um, I, I don’t think that scrum is dead and I don’t think it’s, it’s badly broken. I, I think it’s has flaws and gaps and is incomplete. Um, so it has absolutely nothing to say about leadership and the role of, of managers except to say that a scrum is a scrum master is a servant leader.

Um, and I think actually Scrum comes from an anarchist or libertarian, um, philosophy, um, where you just focus on the team and, um, they’ve deliberately ignored leadership and management. And yet the thing that always goes wrong with Scrum is that the leadership in the organization, you know, destroys it or warps it or rolls it back.

So I think ignoring. Um, leadership and, uh, management and what they, how they need to change is, is a pretty serious gap. 

Shane: Yeah. There’s gaps everywhere. I mean, what would, what do I not wanna see? I don’t wanna see, uh, 200 page Scrum Glide with a big a three diagram with 74 different moving parts. Yeah, yeah, yeah.

No, I don’t want them filling in all those gaps as part of Scrum. I mean, I don’t want Scrum 2.0 where, you know, you’ve got Scrum plus. Um, there are gaps, and if people can identify good ways of fixing those gaps and publish it out, good on them. Thank you for, for helping us do a better job or, or doing things in a better way.

Um, but I don’t think, you know, I think that one of the beauties of Scrum is the scrum guide is so small and easy to read, 

Murray: but, you know, do you remember the pigs and chicken stories? 

Shane: Um, Shane, I use that, I use that, uh, cartoon in every training course I do 

Murray: with a team. Well, that’s quite hostile towards, um, management that cartoon.

And for that reason, Scrum took it out back in before 2010. They took it out. Um, but I still think Scrum deliberately ignores leadership and thinks that, um, the scrum master and that should be able to change the organization from, you know, 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, um, agile leadership in one of our podcasts recently. Um, some other issues. Um, 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.

Um, you know, a certain amount of stories or features or whatever, there it is, 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, overwork and, you know, quality issues and, and so on. But that was actually Scrum removed that back in 2010 and not many people know about it for some reason.

Were you aware of that? 

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

Murray: So yeah, 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, you can change it as you go, which is much better. But most people still act as if the old way with commitments is still there. The other concern I have is with the, the role of the product owner. Um, you know, I’ve seen a lot of product owners getting burnt out because there’s just huge expectations on them.

The, the Scrum team expects the product owner to spend, you know, 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. Um, 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, you know, product management podcast. You’ve got, you know, user research, marketing business cases, um, internal change management, um, so many other things. Um, so product owners are, are, are frequently burning out cause the team is asking so much from them that they don’t have time to do everything.

So I prefer the concept of a, um, product owner team, which is, um, you know, supporting the product owner with other people. Now Scrum has, 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 that’s, that’s good. But, um, in most, most people still think that the product owner is, has to do an enormous amount for the team. And they’re, you know, they used to say they were the single throat to choke. I don’t remember Ken Schwab used to say that. I believe. 

Shane: Yeah. I’m, I’m never really been in an environment where we force the product owner to do everything.

We definitely, we, we talk about them working closely with the stakeholders and being the one person, the team can ask for tradeoff decisions. And my view is we are removing the need to go to a c. Yeah, the team, the team, the team getting trade off decisions made quickly, um, with no ambiguity, helps them deliver more, uh, more product.

So the product owner role have been able to deal with the stakeholders and, and very quickly come back to the team or make decision themselves on those trade offs, has massive value. Um, we still do gotta do a podcast about three Amigos, but I typically see, um, teams I work with, we tend to use the three Amigos approach Yes.

For, um, backlog, grooming the stories, um, before we get into spread planning. So, um, I haven’t had a lot of experience where we are forcing the product owner to write everything up by themselves. Um, and, and hopefully never will. Cuz it just, it just sounds like a really dumb idea to me. Um, you know, with Scrum we’re talking about teams working together.

Why do we then do a team of one just seems like an anti 

Murray: patent. Yeah. Yeah. It, it is. And um, you know, Scrum has, has evolved and changed. So they, 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 that’s good. Uh, so I think the product owner issue has improved, um, but people are just not aware that, that, that the product owner can delegate everything to the team except for the prioritization.

Well, you know why 

Shane: that is. Yeah, go on. Well, they’ve got their, 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, uh, expert scrum coaches. . 

Murray: Ah, yeah, exactly. Um, couple of other things that are, are quite a problem. I think the Scrum leads a team to have a, a really short term focus on the current sprint and preparing for the next sprint.

And as we talked about with agile architecture and design, um, that can lead to really bad, um, design and architecture outcomes. You, you need to be developing architectures and designs at a higher level, looking further out to provide a framework for the team, even if you, you, even if it’s just a plan and then you change it as you go.

I say scrum teams all the time, just taking a really short term focus and um, it’s tremendously frustrating to design people cause they’re not working at the level of buttons they’re working on, you know, user flows, which a button happens to be a part. 

Shane: Yeah. And I had one in there. Um, we use the term sprint.

Uh, it’s, it’s hard for a team to consistently sprint every two to three weeks on a regular basis. It’s more like a marathon. Um, so for me, That idea of delivering something every two to three weeks has massive value, but also brings within a whole lot of unintended consequences. And a number of teams I’ve worked with always end up with a sense of burnout.

This, this relentless pace, um, and no break. So, you know, we need to be able to, to 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, the things people, the priorities. Um, That those patterns have value.

But um, yeah, the unintended consequences often seems to be the, the team, uh, constantly sprinting their constantly at a hundred percent and they get burnt out. 

Murray: Well, again, you could argue that’s a misunderstanding of Scrum because, um, Scrum doesn’t demand that you fill the team up to a hundred percent capacity.

And good practice would be to say that the team would maybe only plan 70 or 80% capacity and then leave some room for, you know, unexpected things or changes, but people don’t tend to do it. Um, you know, as you say, maybe Cuz only went on that two day course. Um, Yeah, 

Shane: well, yeah, I mean, I, I’d encourage that we take, you know, we do do the, you know, 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. Um, but I dunno 

Murray: why. Um, another gap maybe related to leadership is that, uh, there’s no, there’s no, um, career development mentoring.

Training, um, because there’s no, uh, no managers, you know, there’s no software manager who can coach and train people. Um, this is why this is where, you know, this, that kind of matrix model we talked about when we were talking about Spotify is, is quite helpful. It’s, it’s, it’s something that you can do with Scrum that can continue to provide developers with, you know, a development community to be part of where they get mentoring and coaching and support.

As Scrum only talks about cross-functional teams that can deliver everything from end to, and then that’s, it sort of doesn’t, doesn’t talk about everything around Scrum. You know, the, there’s a huge amount of staff that an organization has to do apart from what the team does. So, and, and Scrum just says, Yeah, that’s, 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, Well, we don’t need any of that. 

Shane: And we do, We, you know, I’ll bang on about it time and time again, we need pastoral care for the team members in the scrum and, and the squad.

They need somebody who’s gonna help them increase their skills, uh, when something’s going wrong outside their work life. They need somebody who’s gonna talk to them. And, and that pastoral care is really, really important for an organization and therefore that role needs to be available whether we are using Scrum or not.

Murray: Um, also related to this bigger picture, um, If every team optimizes, uh, 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, 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, you know, cards on the board and pieces of string, and, and trying to figure out a cohesive strategy across 500 people trying to deliver stuff is a better t.

Murray: No, I’m not saying it’s a better technique. , did I say 

Shane: that? . So I’ll, I’ll give you that. It’s a problem. Uh, I’ll, I’ll take, uh, that I haven’t seen a good answer to that problem and I look forward to, uh, somebody coming up and publishing some good ways of dealing 

Murray: with that little wait. When you and I had a podcast on scaling recently, where we talked about lots of things like minimizing dependencies and, and you know, having internal products and so on.

So, yeah, I 

Shane: think we focused on dependencies. I don’t think we are focused on alignment. Um, yeah. So, yeah, that, that’s gonna be an interesting one that we probably should do at some stages. Always. 

Murray: So, maybe to summarize for me, uh, Shane, um, I, 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, I think, you know, were, were really happy with how it was going.

And they were, they were very productive teams. Um, but I see a lot of really bad scrum out there. Really weak, inexperienced scrum masters. Um, and I, I see a lot of water scrum for which I always wrap it on about, which is just a waterfall project done in sprints, which is just horrible and nobody should ever do it.

But I see it being done a lot. And um, that’s part of that bigger problem of management thinking that they don’t need to change. Cause, cause Agile is Scrum and Scrum is a team thing, so the team changes. And then Agile, just the, the leaders and managers all just behave the way they did before and try and force the team to.

You know, just basically work, working their authoritarian, hierarchical waterfall structure with Scrum. So, but, but look, I, I think Scrum, 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, um, uh, you know, crunching, which 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 Scrum band. I, that’s pretty much what I would always ask teams to do is some version of, of Scrum band. Um, or, or just can. But you know, overall I’m, I’m a supporter. I, I see flaws and problems as we’ve talked about, but, um, it’s, I wouldn’t throw it out, I don’t think, I don’t think it’s, it’s broken.

I think it’s got gaps and, and flaws. And I wish the scrum lines would, and some mothers would’ve, would fix them a bit more. And I wish they would encourage people to think, uh, about Agile as being a much bigger thing. And I wish more people understood that. 

Shane: Yeah. Um, so my view is can Scrum being fixed?

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

Yeah. Do I think the Scrum training certification market is broken? Yes. I think there are some unintended consequences of how that training’s been done. Um, yeah, and there’s some work that could be done in that. So, you know, my view, we should start talking about Scrum coaches. Uh, 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. Um, Yeah. 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.

Um, so it it’s just one of many, and like you, I’m probably more aligned to Scrumban, um, Yeah. At the moment 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. 

Murray: Yeah. So, you know, if, if you’re a builder, then Scrum for me is be something like a hammer.

Very useful. Use it all, all the time, but you’re not gonna be able to do everything with it. You gotta, it’s just part of your repertoire. So, you know, maybe it’s, I don’t know, it’s, it’s 20 or 30% of agile or, or possibly less. Um, 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, you know, matrix organizational models, with systems thinking, um, user experience design, agile architecture, all of the XP practices and the DevOps practices. Um, and, and you know, then, then it, I think it’s, it’s really useful Agile leadership as well. Absolutely.

Critical. Must be, must be really important part of it. 

Shane: Yeah. So, yeah, go on Ron for, uh, Issuing the article and, uh, starting the conversation yet again on how can the world make agile better. Yeah. More useful. More effective. More enjoyable. That’s what it’s 

Murray: about. More outcome focused as he’s saying. 

Shane: More enjoyable.

Yeah. And more 

Murray: fun when you’re I think so, yeah. My, my teams, um, who’ve done Scrum and properly, I think, uh, I think it’s really improved their lives and it’s, it’s, you know, 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 the, uh, that’s my summary for, for this one, . 

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

Shane: Yeah. That’s the key. What’s better for you? What works?

Keep doing it, What doesn’t look at it. Inspect at a, 

Murray: Yeah. Continually improve, you know? Yeah, that’s right. We’re uncovering better ways of developing products by doing it and helping others do it. That’s what we need to focus on. Yeah. Excellent. 

Shane: All right. Alright, well I think that’s us, so, uh, we’ll catch you next time.

Murray: All right. Thanks Shane. Keep it real. That was the No Nonsense Agile Podcast from Murray Robinson and Shane Gibson. If you’d like help with Agile contact Murray at Evolve Co. That’s evolve with the Zero. Thanks for listening.