Is Scrum broken?
Thu, 8/5 6:04PM • 1:05:40
SUMMARY KEYWORDS
In this podcast, we discuss Ron Jeffries' recent article “Can scrum be fixed?” We discuss Ron’s concerns with the Scrum Industrial complex and Developer’s 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 Gibson
This week we're going to talk about whether Scrum is broken.
Murray Robinson
Yes. Is Scrum broken? Ron Jeffries, one of the Agile Manifesto authors, wrote an article called “Can Scrum be fixed?” which has generated a lot of discussion in various social media forums. I thought we should talk about it.
Shane Gibson
He calls it Windmills - can Scrum be fixed. I don't get the reference to tilting at windmills, do you?
Murray Robinson
Don Quixote is a knight who jousts with windmills that he imagines are giants. It’s things that you'll argue with, and the windmills going to hit you, and nothing's going to change.
Shane Gibson
Okay, I might have to go and do some googling on that one. If you want to give us a summary of some of the points Ron makes, we can go through and pick them up one by one and have a better chat about them.
Murray Robinson
I'd like to talk about Scrum generally and what we think about it, starting with Ron’s article. He’s saying that, for most people, Agile is Scrum, whether we like it or not, and he sees many problems with that. He has previously written articles on Dark Scrum. About organisations using Scrum to oppress developers and make their lives horrible. He's talked about imposition, which is Scrum being forced on people whether they like it or not. He says Scrum ignores developers. It has a developer course, but he doesn't think it's good. I don't think he's anti-Scrum. But he's very concerned about it. 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 Gibson
Let's pick up that first one that you mentioned. Is Scrum Agile? Or is Agile Scrum? So, I’ve seen a lot of behaviour where we interchange Scrum and Agile as 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. So, for example, when working with a new team, I will introduce some of the Scrum practices first because of my experience working with them over many years. We seem to get better results by doing that first and adopting some other Agile practices later. But I've always struggled with this idea that Agile is Scrum because, for me again, Scrum is a bunch of patterns that typically have value. But it's not what you would define as Agile.
Murray Robinson
Yes, I agree. This idea that Agile is Scrum is widespread. Most people I come across who are doing Scrum think that they're doing Agile. But Ken and Jeff were two out of 14 people who developed the Agile Manifesto. most of the people there were coming more from an XP object-oriented design and development approach. In any case, Agile is a lot broader than Scrum.
Shane Gibson
The XP one's interesting because I haven't done a lot of XP or worked with teams who have, but he says in his blog that Scrum is like XP, except that it doesn’t mention how to do the work.
Murray Robinson
A lot of people say that.
Shane Gibson
I've always found it interesting that XP, which I understand, has been around longer than Scrum didn't become overly popular, yet somehow Scrum did. Is that because Scrum is easier to adopt because there are fewer rules to follow, or was there better branding, or was it the time and place?
Murray Robinson
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. You can become a certified trainer and get people on your courses. All that money means that people have a solid incentive to spread Scrum. XP doesn't have any of that. XP doesn't have certifications or courses. That is the main reason that XP has been forgotten and Scrum has triumphed.
Shane Gibson
Wow. If we want to make some money, we can start doing XP certification, branded as Scrum 2.0. We'd make a fortune. I like it.
Murray Robinson
Some people say that's what SAFe has done.
Shane Gibson
Ron uses the term Scrum industrial complex or SIC. I'm guessing that’s a negative view of the certification industry around Scrum training.
Murray Robinson
Martin Fowler first talked about the Agile industrial complex a few years ago. Ron's applying it to Scrum because Martin was mainly talking about Scrum. Martin's one of the other Agile Manifesto authors. Yes, there is an industrial complex around Scrum, particularly around the Scrum Alliance. You might be aware that there's been a lot of splitting off. The founders of Scrum have both had big fights with the Scrum Alliance and split off to found other groups; Jeff set up Scrum at Scale, and Ken founded Scrum. Org. While most of the leaders in the Scrum Alliance are humble, friendly and cooperative, some are tremendously arrogant Gurus. Their way is the only way. If you say anything critical about Scrum on social media, people will attack you personally. They'll call you an idiot or say you don't know what you're talking about or you're not doing Scrum. There'll be people who respond to this discussion in that same way. I'd like those people to remember that an attack on the person rather than the argument is a logical fallacy that doesn't prove or disprove the assertion.
Shane Gibson
One of the signs that Scrum is working is that it's prevalent, and many passionate people believe it solves their problems. That’s a good thing. But like we've talked about in previous podcasts, you get people who have different personality styles. You have servant leaders, and you have people that like to be at the front. It’s the same when you get things that are popular like this. You get humble people and arrogant people. Let's go back to certifications because his blog talks a lot about that. Certifications are one thing that I've been relatively opinionated on for quite a while. My view is that training is a good thing. When teams are starting with Scrum, a two-day course is a good thing. A short course that explains the concepts and terminology and gives them some practice is a good thing to encourage. But I don’t think you should get a certificate that says that you are a master of Scrum after two days. I giggled when Ron said many Agile coaches are retrenched project managers and consultants who would otherwise be mowing lawns.
Murray Robinson
I remember that.
Shane Gibson
I've always struggled with the difference between a Scrum Master and an Agile coach. Scrum Masters used to be experienced people who worked with teams to help them use Scrum practices. When the two-day ScrumMaster certificate came along, experienced people had to differentiate themselves. they invented the term Agile coach. It became a title people used when they believed they were experienced, which meant that the Scrum master term was degraded. That’s one of the negative impacts of the Scrum Master certification.
Murray Robinson
The Scrum Master term is awful for many reasons. One is that you become a certified Scrum Master after going on a two-day course. But you’re not a master of anything. It’s nothing like getting a master's degree; it's a vast amount of difference. The second thing is that Scrum Master harks back to school master or slave master, which is awful for empowering self-managing teams. The term is terrible, but they're not going to change it because it's got such strong marketing brand awareness now.
Shane Gibson
It should change. We're seeing other words with negative connotations changing. Why don't they update the Scrum guide to say Scrum coach?
Murray Robinson
They should call it Scrum Coach. I started a petition at one point to get them to change it. if you're listening, guys, change it to Scrum coach,
Shane Gibson
hashtag Scrum coach. That's what we should do. We should start one of those Twitter campaigns.
Murray Robinson
The Scrum Master is very focused on one Scrum team, which is supposed to be under ten people. But they also have a responsibility to serve the organisation by leading training and coaching the organisation in Scrum adoption, helping people understand it, and removing barriers between stakeholders and Scrum teams. So, even though the role is very team-focused, Scrum does expect that the Scrum master will help change the organisation to Scrum. I've never seen anybody do it from that position. I know one person who says they did it, but he's a real expert. The Agile coaches, I know, are very experienced people. They’ve been doing Agile for at least ten years; they’ve been Scrum masters, and they understand other Agile approaches. What they're doing is helping the organisation implement Agile across many teams.
Shane Gibson
We should say that there are levels of expertise for Scrum coaches. In any area, there are novices, practitioners, experts and coaches. Someone who does a two-day Scrum course is a novice Scrum coach. 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, you're a LEss coach. some of these titles sound stupid. An experienced LESS coach would be a LESS coach with more. If you can adopt practices from many Agile approaches, such as Lean, Scrum, SAFe and Nexus, then perhaps you're an Agile coach. But again, there are levels of expertise. Maybe you're a novice Agile coach because you've done a lot of Scrum and lean. Perhaps that's where we, the industry, should be going because that way, at least there are buckets. Then the question is, how do you decide when you change the bucket you’re in? If your rate goes up $100 an hour as you change buckets, you’ve got to try and get yourself in a higher bucket. How do we do that? It's not certification unless it's something other than attending a course and getting ready.
Murray Robinson
Ron wants Scrum to focus more on the developer community. He's asking for developer certificates that can be earned via external sources. For the Scrum Alliance to support independent providers of Scrum training. He's asking for the Scrum Alliance to move away from their monopoly on Scrum Master training. The Project Management Institute has a much better approach to this. To be called an Agile Certified Practitioner, you’ve got to have a lot of experience and you've got to pass a rigorous exam. After that, you've got to do ongoing certification, or training unit's to stay current. They aren’t provided by the Project Management Institute. The Project Management Institute is much more open to supporting independent providers of training.
Shane Gibson
That sounds similar to accountants and lawyers. They have this concept of continuous education and proving you're practising in the industry and are worthy. Is that what he's saying we should be moving towards?
Murray Robinson
He is saying that the Scrum Alliance is very focused on certification and training by Scrum Alliance approved trainers. It's too narrow and doesn't support independent training providers. ICAgile is much more flexible. I signed up with ICAgile as a trainer a while ago, because they are much more open. You produce a course and they look through the slides and then they quiz you to see if you’re going to deliver the learning outcomes. They insist that everybody who goes through the course do a survey with them so that they can get feedback on training providers quality. If they're not meeting standards then they work with trainers to improve their quality. He's saying that the Scrum alliance is too controlling. However, 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 go into the exam. You can do any course with anybody and if you do the exam and pass it, then you're 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 Gibson
That’s another great idea for hashtag Scrum coach. Sue people for that because they didn't invent it.
Murray Robinson
Ron is very concerned about the impact of Scrum on Developers. I've heard a few developers complain about Scrum. They complain that there are a lot of meetings that are a waste of time. They often feel that they’re being micromanaged in the daily standup meetings when they’re asked: What are you working on today?, What are you working on tomorrow? Developers often complain that Scrum ignores technical practices and there are a lot of non-technical Scrum masters who don’t support or encourage technical practices like TDD. The other criticism I hear a lot is that Scrum is designed for extroverted people. Introverted people don't work well with all that verbal communication. Those are the four things I hear from the development community. I was wondering what you think about that?
Shane Gibson
Okay, let me go through them in order or, as I remember them. The first one, the ceremonies, I'm going to cause heresy here because, in his blog, he talks about Scrum by the book, not Scrum on the ground. He says Scrum on the ground is horrid. I don't follow. I don't insist teams follow Scrum by the book. I tell them that there are some good practices in Scrum that have value. If they have value for you then use them, if they don't find something else that fixes the problem. The daily standup is a good example. In my experience, daily stand-ups help teams that are not good at communicating. They have been taught to be factories. They’ve been taught to be working as teams of one. They are 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, has anybody got anything they want to add. For me, forcing the team to stand up and talk to each other every day for 15 minutes, has value at the beginning. 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. That's a stand up with a team talking to themselves, not with the Scrum coach standing at the front, drilling them on whether they've done their card or not. At some stage, the teams I've worked with get to the point where they don't need the daily stand up because they're communicating with each other on a regular basis. When they get to this stage I suggest they drop the daily stand-up. 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 the daily stand-up to reinforce their communication. For me, it's a practice that has value at the beginning but when they get good at communicating they can drop it. What was the next one?
Murray Robinson
Non-technical Scrum masters ignore the technical practices.
Shane Gibson
There's real value in having somebody coach the team on technical patterns they've seen before in their domain. It’s one of the things we struggle with in the data space. There are lots of technical practices out of application development that are well published, well known and easy to adopt. But the data space has fewer patterns. There's real value in having a coach that has domain knowledge as long as they're treating it as a servant leadership role. They're asking questions and waiting for the team to come up with an experiment themselves. That's hard when you've seen it before. If the team is struggling, then the coach should describe things they’ve seen other teams try to see if it can fix the problem. There is value if the coach has technical experience but it's not mandatory. A good coach will let the team find their own solutions if they don't have that expertise.
Murray Robinson
I agree with what you've said so far. The third issue was that managers can use Scrum to micromanage the team and make the team's life hell. Ron talks about this in his article on dark Scrum. You've got the sprint planning meetings and daily status meetings where managers can tell the team what to do. You've got the review meetings where you can make people show you what they've done, and haven't done and then you’ve got the retrospectives where you can yell at people and tell them they're no good. This is how he describes dark Scrum. It's obviously not the way Scrum is meant to be done.
Shane Gibson
Any other Agile practice can be used as a weapon. This is where the coach needs to step up. I have worked in organisations 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.
Murray Robinson
And using velocity to compare teams, which is bad practice.
Shane Gibson
Velocity became a weapon. I don't believe anybody should be at the retrospective apart from the team. If you have somebody in a position of power who behaves badly at the retro then the coach should tell them to bugger off. It's the coach's role to do everything they can to stop these negative behaviours and weaponization of the Agile practices. We need to help the team be safe.
Murray Robinson
I agree with you. The last one is the idea that 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 Gibson
A lot of introverts don’t like the fluffy post-it note crap that we encourage them to do. I was working with a team that had a lot more introverts than I was used to. This team was quite uncomfortable doing retros with sticky notes on the board. they decided to use Azure DevOps to do their retrospectives. One person projected the Azure DevOps board up onto the screen. Then each person typed in their cards around what they thought went well and what they thought didn't. They then scored them. They then agreed on what they were going to work on next, they then agreed on what they were going to do to see if that change was going to be successful. They did all that by typing into the tool and not talking to each other. I thought this was never going to work, but it worked for them. We've got to realise that some of the Scrum practices are designed for people that are more extroverted. Let them find a different way to follow some of these practices that don’t require lots of post-it notes and verbal conversation.
Murray Robinson
The retrospectives are an interesting one. I encourage the team to have a period of quiet reflection at the beginning of a retrospective to write down their thoughts about what went well and what didn’t without talking about them. Then I ask them to group their ideas on the wall and vote on the most important issues without discussion. Then I facilitate a discussion of the most important issues and what we might be able to do to improve. I use this approach because it engages everybody in the room, even people who are introverted. I've seen other people use different approaches that are less friendly to introverts. For instance, an approach where each person is expected to stand up and speak or an approach in which the person who raises an issue is attacked by a manager or product owner, sometimes in the room and sometimes afterwards. I do my best to encourage everybody to participate by depersonalising the retro, and that seems to work well.
Also, I question the idea that developers are introverts. I've been a developer and I know a lot of developers and I'd say that they're on the normal scale. Introversion and extraversion are on a bell curve. You don’t get a lot of loud developers and you do get a few quiet ones. You might get more introversion but it’s more towards the middle of the curve. I don't see developers as being very different from other groups of people.
Shane Gibson
No, they're not, but It’d be interesting to do some of those personality tests on developers to see if they predominantly group to the introverted versus the extroverted axis.
Murray Robinson
I did some research on this because I was discussing it with somebody who strongly believed that developers were introverts. There isn’t much research on this subject. The best research I found was on a web development company that did all of these tests on everyone. They found that developers were across the same spectrum as other people.
Shane Gibson
Well, okay. Again, it's that gut feel versus facts.
Murray Robinson
Just to go back to some of the other things Shane, because I didn't give my view on it. the daily stand up meeting is good. Scrum has changed it now you're no longer required to ask the three questions. You can say whatever you want in any format you like. Personally, I like the one where we use a kanban board and we talk through what the team is working on starting with the things that are closest to being deployed and then walking through the board backwards. I also think it's very good practice to talk about things every day because some developers get stuck. I remember being a young developer where I got stuck, and I didn't tell anybody for two weeks. I didn't make much progress, and they were disappointed. It would have been very helpful to have a senior developer go through what I was doing each day and give me coaching. That's helpful. It's a way for the team to develop a plan for the day and to help people who are having problems. On the micromanagement side, yes, Scrum can be used to micromanage people. My first introduction to Agile was from a programme manager in 2004 who told me that Scrum is great because you can micromanage people and they don't know it. There are managers who use Scrum that way. But as you said, you can warp any of the Agile practices to do what you want. Leaders who are authoritarian, hierarchical and bullying will twist and warp anything they can to continue to do that.
On the technical issues. Things like velocity aren't part of Scrum. That's an XP practice. Scrum says that Scrum is a container for all these other practices which is fine. But you need the XP and DevOps practices to develop software. Scrum is nowhere near enough for software development although it can be good for non-technical things. My view is that most people who hate Scrum have had experience with awfully done Scrum. Good Scrum is very helpful but it's not enough. My criticism of Scrum is that it's only part of the solution.
Shane Gibson
After I read Ron’s blog, I noticed a couple of follow up ones, which suggest that he got some feedback that wasn't positive over his first blog.
Murray Robinson
Scrum Alliance people attacked him like they do with anybody who is critical of Scrum.
Shane Gibson
I constantly berate myself for not having an Agile mindset about SAFe. It's the same thing with Scrum. In Scrum, we ask the team to do a retrospective, say what practices are working and which aren't and figure out what you're going to change to make things better. If Scrum is Agile then teams should be able to review it's practices in retrospectives and experiment with changes to see if they work better. Isn't that the definition of Agile?
Murray Robinson
Yes. The manifesto for Agile software development says that we are uncovering better ways of developing software by doing it and helping others do it. “We” refers to a wide range of people from a wide range of different approaches. It includes XP, Scrum, object-oriented design, the Smalltalk community, DSDM, Alastair Coburn and his crystal methods, Bob Martin and Dave Thomas from a developer view and Jim Highsmith from a project management point of view these days we talk about products, not software. Agile is about a community working together to uncover better ways of developing products and helping others to do it. I don't think Scrum is doing that. Scrum has become narrowly focused on the Scrum certification process and the industry around it.
Shane Gibson
That theme comes through Ron’s blog. He says that as people that coach other people, we should expect to be able to make a living out of doing it because we’re putting time and effort into it. That's ok because if we're not adding value to the team, then they won't keep paying us. But all the certification and training to monetize Scrum seems to be the underlying theme 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 is going to change that you're going to fight against.
Murray Robinson
This is what Martin Fowler talks about with the Agile industrial complex. People become too focused on money and stop other people from teaching because they're not part of their little group. The other thing that's concerning for me is that the first value in Agile is “individuals and actions over processes and tools”. I feel like Scrum is very process-focused. Scrum says it's a process framework because you can put other processes in but it feels very much like a process to me. It’s got roles, steps, meetings, artefacts and a long description of how to do various things. It's a process for a team to manage their own work that can have other processes in it. But it does seem more focused on the process than individuals and interactions.
Shane Gibson
One of the things Ron says is that Scrum doesn't have enough practices and processes for the developer. Unlike XP, it doesn't say how to do things.
Murray Robinson
Scrum doesn't have any of the technical practices of XP.
Shane Gibson
That criticism is a double-edged sword. If you have some processes you're too prescriptive. If you don't have any then you’re too permissive or don't answer the whole question. I don’t think Scrum is broken. The Scrum certification market is dangerous and it's causing some unAgile-like behaviour but Scrum itself isn’t broken. But Scrum isn’t the only answer. I don't believe you should implement Scrum and only Scrum and only do what Scrum says. You should use Scrum as one of many sets of practices and patterns that have value. I'm going to get burned for saying this because I'll be accused of not doing Scrum but I openly say I'm a permissive Agile coach. A good Agile team does repeatable things, changes them when they don't work and adopts as many other practices they can find that have value. That's what I expect out of an Agile team I'm helping. I don't follow the Scrum guide hook line and sinker.
Murray Robinson
I don't think that Scrum is dead and I don't think it's badly broken. It has flaws and gaps and is incomplete. It has absolutely nothing to say about leadership and the role of managers except to say that a Scrum is a service and the Scrum Master is a servant leader. Scrum comes from an anarchist philosophy that is focused on the team doing the work. They've deliberately ignored leadership and management. Yet, the thing that always goes wrong with Scrum is that leadership in the organisation, destroys it, warps it and rolls it back. Ignoring leadership and management and how they need to change is a pretty serious gap.
Shane Gibson
These gaps are everywhere. I don't want to see a 200 page Scrum guide with a big A3 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 you've got Scrum Plus. There are gaps and if people can publish good ways of fixing those gaps then 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 that the Scrum guide is small and easy to read.
Murray Robinson
Sure. But do you remember the pigs and chickens story?
Shane Gibson
I use that cartoon in every training course I do with a team.
Murray Robinson
The pigs and chicken cartoon is hostile towards management, and for that reason, Scrum took it out in 2010. But I still think Scrum ignores leadership and thinks that the Scrum master should be able to change the organisation from the team position, which is unrealistic. That is a big gap and people are feeling it. There's a lot of discussion about Agile leadership now. We talked about it in one of our podcasts recently.
Some other issues. Before 2010 the Scrum guide said that the team committed to the sprint plan and worked all weekend to get it done if necessary. That caused a lot of serious problems with overwork and poor quality. Scrum removed that back in 2010 but not many people know about it and they are still using that idea. Were you aware of that?
Shane Gibson
I was aware that it got downplayed a lot, but I wasn't aware of the background.
Murray Robinson
Commitments were removed and replaced with the idea of sprint goals; the idea is that the scope is flexible within a sprint. You start off with a plan to achieve the sprint goal but you can change it as you go. This 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 product owner role. I've seen a lot of product owners getting burnt out because there are huge expectations of them. The Scrum team expects the product owner to spend a large amount of their time working with them to define user stories and the work to be done. Both prioritising it and being involved with everything the team does. Yet, if a product owner is something like a product manager, then you have an enormous amount of other things to do like we talked about in our Product Management podcast. You've got user research, marketing, business cases, internal change management and many other things to do. Product owners are frequently burning out because the team is asking so much from them that they don't have time to do everything. I prefer the concept of a product owner team that supports the product owner with other people. Scrum has changed its approach to this as well. They now say that the product owner can delegate everything to the team except for prioritisation. That's good but most people still think that the product owner has to do an enormous amount for the team because they are the single throat to choke as Ken Schwaber said.
Shane Gibson
I've never been in an environment where we forced the product owner to do everything. We definitely talk about them working closely with the stakeholders and being the one person the team can ask for trade-off decisions. My view is that we're removing the need to go to a committee. When the team gets clear trade-off decisions made quickly then it helps them deliver more product. A product owner who can deal with stakeholders and very quickly come back to the team or make the decision themselves has massive value. We've still got to do a podcast about three amigos but I typically see teams use the three amigos approach for backlog grooming the stories before we get into sprint planning. I haven't had a lot of experience where we make the product owner write everything out by themselves. Hopefully, we never will because it sounds like a dumb idea to me. We're Scrum we're talking about teams working together. Why do we then do a team of one? That seems like an anti-pattern.
Murray Robinson
Scrum has evolved and changed. They meet together across the various Scrum groups and put out a new release every couple of years to address these issues. The product owner issue has improved. But people are not aware that the product owner can delegate everything to the team except for the prioritisation.
Shane Gibson
We know why that is. They've got the certificate from their original two-day course 12 years ago and they don't go on training again, because now they are expert Scrum coaches.
Murray Robinson
Exactly. A couple of other things that are quite a problem. Scrum leads a team to have a short term focus on the current sprint and preparing for the next sprint. That can lead to bad design and architecture outcomes as we talked about in our Agile architecture and design podcast. You need to develop architecture and design at a higher level, looking further out, to provide a framework for the team. You need a plan, and then you change it as you go. I often see Scrum teams taking a short term focus. Scrum is tremendously frustrating for design people because they're not working at the level of buttons they're working on user flows and pages.
Shane Gibson
I’ll add one issue. It's hard for a team to consistently sprint on a regular basis. Development is more like a marathon. The idea of delivering something every two to three weeks has massive value but it brings with it a lot of unintended consequences. A number of teams I've worked with have been burned out by the relentless pace. We need to be able to temper that. I like the idea that every two to three weeks is a celebration of success. This gives the ability to reset the team's focus and priorities but when the team is constantly at 100% they get burnt out.
Murray Robinson
You could argue that's a misunderstanding of Scrum, because Scrum doesn't demand that you fill the team up to 100% capacity. Good practice would be for the team to plan at 70% or 80% of their capacity to leave some room for unexpected things. But people don't tend to do it, maybe because they only went on a two day course.
Shane Gibson
We should look at the time people have and not overestimate how much of their time they're going to spend on this work. But even doing that, I've never figured out the root cause. There seems to be this inherent burnout after a certain period of time that doesn't seem to be sustainable.
Murray Robinson
Leadership is another gap. There's no career development, mentoring or training in scrum because there's no managers who can coach and train people. This is why the Matrix Model we talked about in our discussion about Spotify is quite helpful. It's something that you can add to Scrum to provide a technical group that provides mentoring, coaching and support. Scrum only talks about cross functional teams that deliver everything from end to end. It doesn't talk about everything around Scrum. There's a huge amount of stuff that an organisation has to do apart from what the team does. If you think that organisations should be Agile and Agile is Scrum, then a lot of people come away thinking that we don't need any of that other stuff.
Shane Gibson
And we do need pastoral care for the Scrum team members. They need somebody who's going to help them increase their skills and they need someone to talk to when something's going wrong outside their work life. Pastoral care is important for an organisation. That role needs to be there whether we're using Scrum or not.
Murray Robinson
While we are on the big picture, if every team optimises their approach to achieve their objectives, you can have a very negative effect on the organisation overall. The organisation is a system made up of lots of teams doing different things. A team that optimises to do their bit frequently has a negative effect on other teams in the organisation that are relying on them.
Shane Gibson
That's a hard problem to solve. I'm not convinced that getting all the people from all the teams into a large stadium for two days with cards on the board and pieces of string is a good way to figure out a cohesive strategy to deliver stuff.
Murray Robinson
No, I'm not saying that's a better technique.
Shane Gibson
I agree that it's a problem. I haven't seen a good answer to that problem and I look forward to somebody coming up and publishing some good ways of dealing with it.
Murray Robinson
Well, we had a podcast on scaling recently, where we talked about lots of things like minimising dependencies and having internal products. So there are some answers there.
Shane Gibson
We focused on dependencies. I don't think we focused on alignment. There's going to be an interesting one that we should do at some stage.
Murray Robinson
To summarise, I 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 we're happy and productive teams. But I see a lot of bad Scrum out there done by weak and inexperienced Scrum masters. I also see a lot of Water-Scrum-fall, which is a traditional waterfall project done in sprints. It's horrible and nobody should ever do it. But I see it being done a lot. There is a big problem that management thinks that they don't need to change because Agile is Scrum and Scrum is a team thing. The team changes and the leaders and managers behave in the same authoritarian hierarchical waterfall way that they did before. But look, Scrum is good. I like it particularly when combined with kanban. Kanban solves a lot of problems with Scrum, particularly the problem of crunching at the end of a sprint which happens a lot. Whether it's supposed to or not. I know it's not supposed to but it still does. Kanban helps you visualise your work, which is very helpful and everybody does it now. I always suggest teams do some version of Scrumban, or Kanban. But overall, I'm a supporter of Scrum. I see flaws and problems but I don't think it's broken or should be thrown out. It's got gaps and flaws that I wish the Scrum Alliance would work to fix more. And I wish they would encourage people to think about Agile as being a much bigger thing than Scrum. I wish more people understood that.
Shane Gibson
My view is that Scrum can be fixed. Everything's broken, because there's always a better way of doing things. You've got to figure out what it is. Scrum should be iterated on. But as you said, they do iterate on it every couple of years and they have changed things that had unintended consequences. That's good. I do think the Scrum training and certification market is broken. There are some unintended consequences of how that training has been done and there's some work that can be done to fix it. In my view, we should start talking about Scrum coaches. One of the things Ron says in the blog is that we should teach developers differently from Scrum coaches and Product Owners. It's all based on the same thing, but we should articulate it differently. The main issue for me is that Agile is not Scrum. Scrum is one of the toolkit's that I use to help a team work in an Agile way. It's one of many and like you, I'm more aligned to Scrumban at the moment than anything else. But that's because it's what I understand and what's worked for the teams that I've worked with.
Murray Robinson
If you were a builder then Scrum would be a hammer or a ruler. It's very useful but you can't do everything with it. It's part of your repertoire. So, maybe it's 20% to 30% of Agile, possibly less. People should keep doing Scrum, but they need to combine it with kanban, matrix structures, systems thinking, user experience design, Agile architecture, XP and DevOps. Agile leadership is absolutely critical as well.
Shane Gibson
Good on Ron for issuing the article and starting the conversation on how can the world make Agile better, more useful, more effective and more enjoyable.
Murray Robinson
More outcome-focused as well.
Shane Gibson
It's more enjoyable when you're Agile.
Murray Robinson
When Agile and Scrum are done properly it improves people's lives at work.
Shane Gibson
If you're not having fun then you're doing Agile wrong. That's my summary for this one.
Murray Robinson
If you're not continually improving the way you work, then you're doing Agile wrong. You should be able to iterate your way out of Scrum into something that's better for you.
Shane Gibson
That's the key. What's better for you? What works? Keep doing it? What doesn't, look at it and change it
Murray Robinson
We need to focus on uncovering better ways of developing products by doing it and helping others do it.
Shane Gibson
Well, that's us. we'll catch you next time
Murray Robinson
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 ev0lve.co. That is Ev0lve with a zero. Thanks for listening