#0078 - Stefan Wolpers - Scrum Anti Patterns

This is the no Nonsense Agile podcast. Join us for weekly discussions on agile product development and leadership with world class experts who provide valuable insights and practical advice for industry professionals. Subscribe now to learn the latest trends and best practices in the field.

In this podcast we talk to Stefan Wolpers about Scrum Anti Patterns and why so many organizations aren't getting the benefit from Scrum and Agile they expect. We discuss common anti patterns, such as a Scrum Master assigning tasks to a disempowered team and the solution for them. And we discuss why these anti patterns keep occurring, the problems with Scrum Master education and training, and the big consulting companies who sell Scrum as a project management process. And finally, we delve into the core differences between Scrum and the assumptions that bureaucratic organizations have about the nature of work.

Welcome to the no Nonsense Edge old podcast. I'm Shane Gibson.

And I'm Murray Robinson.

And I'm Stefan Wolpus.

Hi Stefan, thanks for coming on today. We want to talk to you about Scrum Anti Patterns, which is your new book. It's coming out, but why don't we start by getting you to give us a bit of an introduction into your background and experience.

Sure. I started studying chemistry, but I never worked in a laboratory. I spent my whole professional life in the IT industry, so creating software and hardware and I think it was 2005, I was working for a startup and the developers asked me whether I would be interested in becoming the Scrum Master besides my usual other obligations. And I said yeah, sure, why not? I had no clue what that would entail, but how hard could this be? And stayed with Scrum ever since. I been working mostly as a consultant in various roles. Scrum Master, product owner, a lot of time and Agile coach. Sometimes you get labeled as an agile coach. And I joined the scrum.org as a professional scrumtainer in 2019.

And did you say you were a software developer?

I've never developed any software. You don't want me to develop software. My code is really bad. I'm comfortable with CSS and HTML, but beyond that I really don't want to delve into.

So how come the team asked you to be a Scrum Master? Were you working in an Agile team as a like an SME or something?

Not really. I was more kind of right hand of the founder. Founders have this tendency to be difficult individuals, know it all and this is my vision and I seem to have a smoothening effect on him. And the developers, smart as they are, thought hey, we could Use that, and maybe we can work out a better way of communicating with our founder, because there was a lot of conflict.

And I think it's also worth mentioning that you run the Age of Product newsletter, which is one of the biggest Scrum newsletters online with about 40,000 members.

Yeah, we're nearing 40,000 subscribers by now.

Yeah. All right, so I say that you're coming out with a book called Scrum Anti Patterns. Why did you decide to write this book?

So a few years ago, I was working as a consultant for one of the large utilities here in Germany, and the utility followed the ideas of Jack Welch and maximizing shareholder value and focusing off the core competencies, which was generating electricity and buying gas and then distributing the two. And they never put a lot of thought into that. Software creation might actually be a big part of their business. Of course, this all changed when markets became commoditized and you could source your electricity from wherever you wanted. And now they found out that, hey, actually, we need to provide software to our customers to distinguish our services from the other competitors that we have. I was located somewhere in the rural area, so I traveled there four days a week and I started to take notes about my observations during my train ride. And then I started to write blog posts about these anti patterns. And then I aggregated the blog post into something that you could download from my website just to provide some kind of systematic approach to what I was observing. I'm a natural scientist by heart. I observe things, I take notes. And maybe I don't know exactly what I'm observing, but I sure can replicate it and I sure can analyze it at a later stage. That was the whole origin of these anti pipelines.

Are there a lot of teams that are doing Scrum and Agile poorly? What's the state of Agile at the moment?

The tricky thing with Scrum is that it's intentionally incomplete as a framework, so you have to augment it. It doesn't work out of the box, which I believe is a very good thing, because otherwise it will be very prescriptive. And the more prescriptive something is, then you move from a framework to a methodology. And I don't think the methodologies work in a complex environment because we very often have no idea how to solve a certain problem unless we slowly but steadily make progress inching forward to the solution. The question is how to augment it. There are first principles on the one side, how Scrum works. Please use Scrum only for complex adaptive problems. Otherwise it might be a waste of your time. Think about the importance of having a high quality product, keeping technical debt at bay, because otherwise you won't make a lot of progress if you are a problem ridden technical application and you no longer can move anywhere. Embrace the idea of self management. This is mission critical. I mean, Scrum is remarkably egalitarian. There are no subclasses within a Scrum team. No one can tell anyone how to do things, when to do things. It's all checks and balances. And this is done so intentionally because you want the outcome to be a team effort. The team wins, the team loses. Really simple. And then embrace the idea of having an actionable product backlog with branches out in this huge area of product discovery, product management. I mean, this is a very weak spot of Scrum. Scrum has by nature a tactical delivery framework. We're good at getting things out of the door. We're not really that good at identifying what is worth building in the first place. Product owner somehow knows what this is, but there's no further indication on how they actually come to that conclusion. So this is the conflict that we're always facing with Scrum. And if you keep that in mind, it's not a surprise that people will come up with their way of working in Scrum that may comprise anti patterns. If you have a more nuanced look at Scrum and how Scrum is supposed.

To work, it strikes me that one reason for a lot of anti patterns is people are trying to implement Scrum within traditional hierarchical organizations. So when they're implementing Scrum, they will compromise and accept what they have to work with.

There's this one book from Jeff Sutherland, Scrum the Art of Doing Twice the Work in Half the Time. And I think a lot of the management folks just read the subtitle and say awesome, now I get more bang for my buck. I want this because from a feature factory perspective, driven now I get more features, quicker, earlier, maybe more reliable and everything will smoothen in my organization and we will be able to meet our objectives here. But the case is actually that Scrum is a excellent probe to figure out all the things that are wrong in your organization and you need to be prepared for that. I've never seen anyone trying to use Scrum. That was a conflict free endeavor where all were holding hands and singing Kumbaya. Never happens. On the contrary, if you're really into maximizing value that you create for your customers per given period of time and available budget, this requires a lot of hard choices that you have to make and you really need to be open about this. And a lot of people will not like Scrum because no one has authority within the Scrum team. You can't tell a developer what to do, when, where and how. This is not how it's working. Self management is mission critical. And merely the fact of figuring out what self management in the context of the organization means is a huge undertaking. What does it mean, self management? You know, are they writing their paychecks in the end themselves? So what I really like to do is run delegation pokers from Management 3 to figure out, okay, what understanding do we as a team, including our stakeholders have what self management means. And it's always amazing to see what people understand by the term self management. It's not obvious, even if the term seems to be obvious to anyone else. And that, I believe, is why we have so many anti patterns. People have assumptions and instead of talking about them and figuring out whether their assumptions are reflecting reality, they just build on their assumptions and then they are surprised that assumptions are not the assumptions of other people.

So if we look at Scrum, you've talked about the difference between frameworks and methodologies, with methodologies being far more prescriptive and frameworks not. You've talked about Scrum being incomplete and a set of guidances that you have to fill in the blank. And so if we look at Scrum, do you think it's more principle based or more patent based? What would you say?

My version of Scrum is principle based. The patterns that emerge are really based on your environment. What kind of market are you working in? Is this highly regulated or is it more kind of Manchester capitalism style market that you're operating? Are you a small organization? Are you a large organization? Are you established player? Are you a brand new player? How has your organization been developed? I was working in startups with five people and two years later there were 500. And rest assured your approach to solving problems change during this phase of expansion. You probably start as a really good agile organization and six months later, because you are growing so fast as an organization, you actually revert to some traditional organization because your investors pressure the founders to hire more experienced people. And those more experienced people tend to come from traditional sources. Maybe they have a McBoston background as consultants and within a second you end up with Ms. Project and waterfall planning. No one ever said we would like to go that way. It just happens by hiring new people. So it's really difficult to understand how Scrum's principle might manifest themselves in real life. This has to be tailored to the individual organization.

Let's go through some of these anti patterns and let's start with the Scrum Master.

Okay. Scrum Master depends a bit on where you're coming from. If you have been promoted to Scrum Master because you used to be a business analyst or a project manager and now because your organization is going agile, you get a two day training. You may be sticking to your old ways of doing things just with a thin agile veneer on top. You call events a bit differently, but otherwise you just proceed the way you've been doing that before. So daily Scrum is the meeting where the developers figure out whether we're still on track, accomplishing the Sprint goal and what they can do to stay on track or get back on track. Grum guide says we're responsible that it but otherwise we don't have to do anything. Now if you probably use more to project management approach, you may be tempted to run the meeting. So you basically organize and facilitate the meeting, which actually is not your job. It's the developers meeting. It's so very very simple. Or maybe you have the habit of keeping the Scrum team dependent by organizing meetings, purchasing and organizing stickies and sharpies, taking notes, updating Jira. So really classic secretarial task here certainly is not your job as a Scrum Master. I've never met anyone who had no idea how to get new stickies or either by purchasing them from the department local or by organizing them from a neighboring team when they have lunch. Never happens. It's not my job to organize stickies. Maybe you succumb to the idea that as your job as Chrome Master is to create extensive reporting to your superiors how well the team is performing. So you spend most of your time in assembling these kind of metrics and then aggregate them into reports. The worst metric I've ever seen in that respect was story points per developer per Sprint. Because Scrum is a team sport, we win as a team, the team accomplishes the Sprint goal. It's not about the contribution of the single individual.

I'm assuming you're talking about points delivered, not points estimated. They didn't care how well they estimated, they only cared what points actually delivered.

Yeah, let's get another dimension. So the ratio of points estimated, reverse forecasted, reverse delivered. And then this is a complete new rabbit hole you can dive into.

Have you seen this one where people are giving individual tasks to individual developers in Jira? So you create your stories and then you break it down into tasks and assign them all to individual developers with date that they're supposed to be done by totally.

Yes. So that's basically an anti pattern, both for product owners as well as Scrum marketers. Of course, it's not what we do as a Scrum team. We agree on a Sprint call and then it's up to the developers to pick the work that is necessary to accomplish the Sprint goal and they decide how to actually turn those work items into product increments.

That's the idea of self management as a team. Collectively we identify the goal, but it's up to the developers as they commit to that goal to actually then pick the work.

So these patterns are mostly around acting like a project manager and not letting the team manage themselves.

I think a lot of anti patterns derive from this need to be in control or have the perceived feeling of being in control. Of course the whole idea is an illusion. In a complex environment you're not in control of anything. The best you can do is build a resilient system that can deal with problems that you run into. In my experience, a lot of these issues arise from this classic idea of okay, let's do planning. If we fail to accomplish a goal, it's because we did not plan adequately in advance. So next time we plan more, we take into consideration more of prospective problems and how to deal with them. And then you have this vicious cycle that you never can break out. I think it's very human that we want to be in control. Fear driven creatures. There may be saber toothed tiger around the next tree and then we're gone. This is just manifesting itself in real life and in a lot of organizations you're rewarded for accomplishing goals, not creating value for customers.

Scrum Guide does say now doesn't it, that the Scrum Master is responsible for the outcomes of the team.

Scrum Master is responsible for helping the team to live up to its potential. I would put it this way, that's a bit like classic coach of a sport team. There's a set of individuals and your job is to achieve the best possible outcome by coach the individuals to act as a team work in the same direction. That's my job as a Scrum Master.

So have you ever got a sense of scale? Is there any ranking about these anti patterns to say worry about these ones more or these ones happen more often?

The larger the organization, the more control driven anti patterns are prevailing. I think the classic misunderstanding is that if you want to scale agile, you do so by adding more processes and more reporting more tools. I think this is Dr. Moran, because scaling agile only Works by descaling the organization by empowering the people closest to a problem with actually solving the problem. It's the job of the management to create guidelines. Guardrails. Okay, how do we go about solving problems in this organization? What do we have to take into consideration within these guardrails? It should be up to the team to come up with a solution. Because in a complex environment there are no experts. Everyone can have the right idea here. So why limit your chances to actually solve a problem as an organization by telling people what to do? There's this nice Steve Jobs video where he says we're not hiring smart people to tell them what to do. We hire them to help us solve our problems. And this should be the approach to take to Scrum when you use it as an organization.

Yeah. What about some of the anti patterns with the Sprint itself? For instance, I've seen Scrum masters assigning work to developers.

Yeah, that's a classic one. This is not supposed to happen because it's a team sport and it's a collective responsibility. The problem is the moment you start doing that, you reduce the level of involvement of other people. So from now on it's no longer a team based decision how to proceed and solve a certain problem. Now you're basically absorbing a part of this decision process and you want missionaries, not mercenaries on your team.

One I've seen quite common is the retrospective becomes personal. So the Scrum master says, Joe, what went well and didn't go well last sprint? And because it's personal, people start to criticize the people who raised issues or ends up with people being afraid to say things.

Absolutely. Which is also a reason why you shouldn't do this. If you have a fear driven culture, no one will tell the truth. Our job is to create an environment where people can speak up without the fear of repercussion. For example, the utility I was working for had this idea that outside freelancers were on revolving contracts. So they always got a contract for three months and then they would extend the contract. However, the extension of the contract was also based on the feedback of the employed developers on the same team. Now if you're a freelancer and if you want to continue your contract, would you speak up in the retrospective regarding the not so good things that one of the payroll developers did in the last Sprint? Knowing that the prolongation of your contract depends on that individual's supporting it? Probably not. Another issue they had. They for example, started to create reporting structures within the team. So junior developers were assigned to senior managers on the same team and they had to report to them same issue. If your career is at least partly influenced by your superior's opinion, who's working with you on the same team, Are you speaking up? In a retrospect, probably not. So I had a lot of one on ones in a cafeteria where the juniors were telling me what happened, which was an uncomfortable situation. Of course you can suggest to the organization this is not a good thing what you're doing here. Please consider consequences. But that's the only thing that you can do.

Yeah. What about some product owner anti patterns that are quite common?

Go tons of stories. I think the most prevailing one is I know what to build. Follow me. When I was working as a product owner, I always made sure that I didn't show up the refinement session and told the developers, okay, here's a new story. This is what we're going to build. It was more like I was pitching the developers. So based on data and information that we gathered, I believe this could be valuable to our customers. I was also expecting my developers to push back. Stephane, do you really think that this is the best use of our time? Aren't the other thing that would create more value for our customers? What are our opportunity costs here? And only if you have this level of discussion, then you actually come to the state where you can say, okay, it's not product owner's backlog item, it's our backlog item. I always put a lot of emphasis on the fact that I bring the data and the suggestion that the developers were creating a backlog entries so I never wrote them myself. It was always a developer wrote because then it's our ticket and not my ticket. Because if it's our ticket he's willing to go the extra mile to make it work.

So do you find that the patterns that you need to break these anti patterns aren't readily available, they're not well described, they're not actually taught that often to people that are entering into these types of roles.

Shane, I believe you're absolutely right. There is no ready made toolbox available that says, oh, if you run into this problem, you'd use that tool as a remedy. And you really have to tailor this to the need of the organization in that specific moment which makes liberating structures so helpful. And management3.0 is another good toolbox. Then as a scrum master, most of the time it's about starting the conversation. It's not about find a solution and then rolling it out.

Yeah, we start off with the basic training and then we don't follow it up with that reinforcement as people get more mature in their careers. In a previous life I had a role as a systems sales engineer. So my job was to stand in front of the customer and present the product to that customer in a way that they thought it solved their problem. And being part of a sales organization, we had intense training on that and that was pattern based. We were constantly given scenarios which we had to respond to and then we were given hints or patterns that we could try to apply in the future. And I don't see that in the Agile community or in the Scrum community. Is that what you're saying or am I just not seeing organizations where that happens on a regular basis?

I think it depends. On the one side, the absence of taxonomies or pattern categories can be a good thing. On the other side, if we're all free floating, if there is no pattern toolbox available, it's probably not a good idea either. Yes, of course we all like Fu Hai Ri. So you start sticking to the rules and then you start bending the rules. And when you're really experienced you break the rules and figure out your own way of working. Yes, that might be a way, but how do we go about it? I think this is the muddy middle that we are facing. So on the one side the principles are laid out in the Scrum guide. On the other side this sure re idea, this is how we move forward. Not really very focused on the middle part because it is so messy and so complex and it really has to be tailored to the individual needs of the situation. Yeah.

One thing I really love about the Agile community is it is so open at sharing and it follows almost an open source principle. Lots of people publish things they found useful so other people can pick it up. So there is that whole philosophy of sharing patterns amongst the community, yet somehow we see anti patterns happening. And do you think we see anti patterns happening? For people that are starting their journey into Agile, they're just natural places that they fall or it's learned behavior from the previous ways they've worked. So they just naturally fall into those traps and then as you get more and more mature, you tend to find or learn patterns that will break those anti patterns. So is it just a maturity and experience problem?

Most of the time people do not do this deliberately. Probably they don't even recognize it. It's certainly part of previous behavior that had worked in the past. So why shouldn't it work here? And then we're not reflecting about what is happening. Probably we take retrospectives not as seriously as we should take most of the time. And it's an issue addressing the elephant in the room. And if we decide not to address issues, we're on the path that is leading us out of the agile realm and then we end up somewhere else. We're not getting paid to practice Scrum, but solve our customers problems. Maybe somewhere outside of this realm there is a path to creating value for our customer, which is totally fine.

The deliberate idea to say, okay, we need to talk about this, something is going wrong, we have the capabilities to do better here. Let's talk about this. It's really, really challenging.

Do you find that that way of describing these anti patterns actually gives people a shared language so then they can have a conversation amongst their team saying, hey, I think we're actually doing this anti pattern. What does everybody else? Yeah, and if they agree, then it's a case of okay, what are we going to do to fix it? Because actually we're not happy with that way of working. You think that shared language is really important?

Absolutely. That was one of the main driving ideas behind this. In my experience. It's easier if you can pull out a book and say, look, this is what's happening here and this is probably not a good thing. I think we can do better here. What do you think? Shall we use an ETH retrospective to talk about this issue? Ideally, those topics all come up intrinsically driven out of the communication within the team, but there are a lot of environments where this is not going to happen.

It strikes me that one of the most fundamental ideas in Agile is that we're going to be open and honest with our thinking and our communications. So if you're doing your retrospectives properly, then if any of these issues we're talking about are a problem, they should come up in the retrospective and the team can talk about how they can solve them.

It should be that way. Yes, but very often it's not.

Well, why not though?

It's an endless list of reasons why that might be. Starting with the individual contributor who is fearful of speaking out in public. I always suggest teams run anonymous surveys before you have a retrospective and repeat the same questions. My favorite set of questions is very simple two minute survey. Question one is how do you consider the value we deliver the sprint on 0 to 10. So, classic MPS scale. How do you think that the technical health of our platform has developed over the last sprint? Would you recommend an open position in this organization to a good friend who has an agile mindset and my Last question always is, is this the time of your life or are you looking for a new job? I really like to run these surveys before every single retrospective. It's an anonymous survey. So if you see that for the last two sprints, the quality of your tech stack has been dropping. Maybe it's correlated with the deadline that sales pushed on. But then you should really talk about this. And now you have data that you can use to talk about this. This is not a hunch of one of the team members. It's cold heart data and that helps to start conversations. You need to give the people a few supportive means to get the discussion going.

Here's one.

I got in the Slack channel the other day and the problem was the developers on the team were constantly grabbing multiple work in progress off the board, working on them at the same time, and delivering none of them at the beginning. So that common multitasking anti pattern. Do you have a pattern to solve that?

I had the same problem with one team in the past. So a lot of work in progress, nothing was done and everyone was totally busy. They were not exchanging ideas, they were not helping each other. They were totally frantic at the end of the sprint, getting things out of the wall. I said, like, you put so much effort into here, slow down, think about what we're doing. Is there a way we can do this? We used a physical board at the time and so we came up with dedicating space. So work in progress limit, not just visualizing in Jira or something like that, but really having a space. And we had this rule, okay, when the space is occupied, no one puts any more work in here. And you start working on the column that is most congested. And we coupled this with our daily scrums. We were always walking the ball. So we started with a column that was closest to done and then we thought, okay, what can we do today to actually get these issues that we have in this column into done? And then we moved on to the next column. And sooner or later the team picked up on this and said, hey, actually this is a better way of working than we used to work before. When they focused on limiting work in progress and abandoning this crazy idea of multitasking. Flow metrics improved cycle time went down and stakeholders were much more pleased with the work of the team. Was less stressful, received more praise, customers were more happy. It was win, win, win. But it took several months to get there. You can't switch it on.

Okay? The other fundamental issue I see a lot, Stefan, is that the team is improving and dealing with their issues. But they are blocked by a lot of issues in the surrounding system, in the environment that they work in. Issues often due to dependencies on other teams or there's some centralized process that they have to follow. So management often see Scrum as a team thing. The team's not performing. The team need to get better, but the team are getting better. And actually the problem is the organization system that they're in. And then somehow the team is not able to get those issues resolved. Do you see that as being a common cause?

It's a common issue in larger organizations because SCRUM is always designed around one team. One team that has all the competencies to deliver end to end and it's in complete control of what they're doing. And of course this is not reflected in larger organizations and how you typically work. How many products are supported by a single Scrum team? Very few. Most of the time you have multiple teams working on the same product. This is adding another alignment layer. And then you have to see this unit that is working on one product aligning with all the other units working on the other product. And very quickly you end up figuring out how we set up the whole system. And it's easier said than done because we tend to ship the org chart. And this is not very compatible with the basic idea of Scrum. Cross functional independent teams that shall solve customer problems on their own because the organization empowers them to do so. So that is really the ideal that we always have. Reality is very often very different.

Yeah, but the Scrum master is supposed to be responsible for helping them raise these issues with management and help management to resolve them. Aren't they?

Absolutely. I'm not saying that you shouldn't work on that, but on the other side, you have to distinguish between these two different areas. On the one side, the team itself can optimize how the team is working to a certain extent. Beyond that, it's out of their control. Then after that, you actually have to work with the organization to move the whole situation in the right direction. Which would imply thinking about how are we structuring our work? How are we doing this? Is it absolutely necessary that we have components that are merely controlled by a component team and no one else is allowed to touch them? So coming up with different ideas. This is a lengthy process and it starts with opening discussions. Is as humans, we all play a status game. Never underestimate the importance of the status game. There are always people who have a vested interest in preserving the status quo because their Network is built on the status quo. Just quote, they invested a lot of time, a large part of their career into building this and now you're suggesting that you should change everything so that your Scrum team can be more productive. Why would you do that as a protagonist of the existing system and actually Scrum is not designed to solve these issues. It is really something that you have to solve at a different level with support of other people.

Yeah, I guess the other thing we see a lot of these days is either the Scrum Masters themselves are really inexperienced because there's been a lot of new Scrum Masters coming in to the field, or you've got a bunch of consultants who are recommending things, particularly from the Safe school of Thought or from The Spotify Model McBain School of Management Consulting. You're getting people who don't understand and never been part of a good Agile team telling people how to do all this stuff. Now do you say that?

Absolutely. The issue is that many people do not have hands on experience in developing products. It doesn't have to be as a developer that on the product side or sales side could be customer care people too. Just this idea, okay, our customers have a problem and we would like to help them fix that problem. How do we best go about it? This is a fundamental experience that you need to have to appreciate what Scrum is providing. If you start with Scrum by reading the Scrum Guide, how far can you take this approach? I don't think very far because you probably become interpreting the Scrum Guide literally. Then you have a bit more ideologic approach to Scrum or you say it's an augmentable framework that's just put in whatever there is and call it Scrum. Maybe you just continue what you've been doing anyway, but now you call it differently. So the good people I know in the industry always have a long experience and they always started on the product side. Either creating the product, thinking about the product, supporting your customers, selling the product. So they're always product related, they have hands on experience. Very often it's not a deliberate career decision, it's more a kind of occasion that you wise to accept. I never thought I would like to do Scrum. I never knew this way of working at a name in the beginning. I was just following what developers did in my little start 18 years ago or so and I thought, hey, this makes sense, it's a good way of working. At the time I didn't know that they were also using extreme programming practices at the same time. So, but to me it looks, hey, this all makes sense. Let's do it this way.

Yeah. Well, there seems to be plenty of people who are doing things which are agile, but they don't call Scrum or Agile. We're hearing this from some of the Silicon Valley teams. They just say they do what works totally fine.

So, I mean, if you're still doing Scrum after three years, you probably haven't learned a lot.

I wanted to ask you, how much responsibility does Scrum have for these problems? So we say Scrum is easy to learn and difficult to master. Maybe Scrum is like a unicycle, very simple. It's got one wheel, somebody can show you how to ride it, but actually it's very difficult to ride down the road or to do tricks. So maybe the problem here is we shouldn't even be riding a unicycle at all. It's the unicycle's fault.

I like the metaphor of a unicycle. It's a very good visualization because what they don't tell you is you do not only have to ride the unicycle, you have to juggle as well. And then it's getting really, really tricky. And a lot of people underestimate that part.

Yeah, but does Scrum have any responsibility for these anti patterns?

Mainly, I would say no. I think the intentional incomplete is a good thing, but less prescriptive. It provides room for breathing and finding your way of working in any given situation. So I think it's a good approach. On the other side, there are aspects where Scrum could point better in the right direction. So the kill is here is the product owner and the assumption that the product owner knows what is worth building, which is just absolutely not the case. And I don't think that the product owner should be the person who knows whatever is worth building, just the individual that needs to figure out what is worth building and collaboration with the stakeholders and the rest of the team and then make a decision.

Yeah, I agree with you. Product management is a huge field all on its own. It's as big as engineering as a field. People were doing it in the 50s and 60s. So, yeah, I think there's not many product owners who know how to be a product manager. All right, perhaps we should go to summary.

Look, it's been an interesting podcast because we've jumped between the detail of some of the anti patterns and the kind of principle or pattern of anti patterns. I like the way you defined that methodologies are prescriptive and they don't work in complex environments. So what we need is frameworks or approaches or what I call ways of working which give guidance but aren't prescriptive. That aligns a lot with the way I think. I love the fact that you said Scrum is incomplete and that's okay. It's designed for complex adaptive problems. If you don't have complex adaptive problems, it may not be the best thing.

For you to use.

There may be other ways of working. There are other options that are okay. I love that you've distilled your anti patterns down into three groups, roles, events and artifacts. That just helps me understand. Okay, I've got an anti pattern I think relates to a role. Maybe that's where I'm going to go search for first to find that content. So I think I'll find that particularly useful. I love the comment Scaling agile can only happen by descaling the organization. So it's not about adding more complexity to our teams and how they work and more teams and more control. It's about removing the complexity in the organization and then we'll be more successful. And that's what most people don't do. I love the comment hire smart people to solve problems, not tell them what to do. Again, it's one of the core principles. We have a bunch of people who know how to do their job. Get the hell out of the way and let them get on and do their job and then give them the support they need to be successful. Don't tell them what to do because that's not the principle we're aiming for. And for me, context is key. The context of why those anti patterns are happening, the context of which patterns may help solve that problem. And what we didn't talk about is that actually sometimes it's an anti pattern, but it doesn't really matter right now. So that's okay. There's always things we can work on we're never done. If your Scrum team's working the same way three years later than they did on day one, then we've got a problem because they're not inspecting and adapting.

The way they work.

I'd love to see a survey done globally from people in teams with your list of anti patterns and them to rate the ones that they constantly see. Is there a cluster of standard anti patterns? I think that would be really interesting data. That's kind of my view of what we talked about. And my question for you, is JIRA and using tickets in Jira an anti pattern?

Now, if you use JIRA right Out of the box. So no customization. Everyone has every all the rights to do what they want. JIRA is actually a quite capable tool. So actually, I like Jira. It's okay. The problem starts if you start tweaking it, if you enforce certain processes on top of jira, so only the Scrum Master can move tickets or can move a ticket back, for example, and you cannot delete tickets, then it starts to get really, really nasty. The next step on my escalation scheme would be that you outsource the JIRA administration to some nearshore company and it takes three to four weeks before anything gets done. And the top of that is that you add the stupid definition of ready plugin and that you create a report at the end of each sprint for every team whether they're actually complying with the definition of ready and align that to the outcome of the spread. Then JIRA is talking. But at the beginning, out of the box can do everything. Fine. It's a good tool.

I'm going to agree with everything you've said on this podcast, except for that it's a factory system. It's based on tickets. We don't work on tickets. We work on jobs to be done to get outcome or value for our customers. And it just reinforces every anti pattern that's ever been invented in the agile world.

So I don't mind it. Like you, I quite like the vanilla Scrum and Kanban with no rules, no adjustments. The only thing you can still stuff it up even with using everything vanilla is using tasks and subtasks too much. So you have a user story and then the Scrum Master creates all of these tasks and subtasks for each tiny little bit of work and then assigns them to people or they assign them to each other. But then you can't see what the hell's going on with the story because you just get, I've completed this task and that task is a story done. I don't know, that's somebody else's responsibility.

Yeah, yeah, that's an issue. And then they start estimating subtitles and stuff like that, and then you're walking in the wrong direction.

Anyway, enough of ranting from me. Murray, what do you got in summaries?

Yeah, we decided we wanted to talk about Andy Battens because that's the book coming out. And then we talked about the context. Why are these all these anti patterns? Which is because of lack experience, because of poor advice from the safe and management consulting community, because it conflicts with the current assumptions of the hierarchical organization that you're in. I'd say that's the most important one. People are working in a hierarchical bureaucratic organization and there are basic assumptions there. Like you must have a manager who assigns work to team members and then you must manage each person's performance individually. So Scrum comes along and says, no, we're not working like that anymore. We're working like a basketball team, that's what we are. And we're taking the ball down the basket and scoring points and we're doing it together. And the Scrum master's the coach. I don't know what the product owner is in this scenario. We're working as a team. And that conflicts so much with some of the traditional bureaucratic ways of working that what people do is they change Scrum to make it fit with basic bureaucratical assumptions. So they do start assigning work and breaking stories down into individual tasks and giving them to the team and manage task velocity by individuals and all that stuff. Because they're not really accepting the basic change in assumptions that comes with doing Scrum and agile properly. I think a lot of times, because they don't understand it, the two day training is not enough. People really need an apprenticeship model. Scrum masters need to be working with experienced Scrum masters and Agile coaches who really know what they're doing. We're seriously lacking in that's proper passing of knowledge to people. And the two day cert is nowhere near enough. So apprenticeship model would be much better. The other reason why this happens is because managers have not bought into this change at all. They just see Scrum as a way of doing twice as much work in half the time, which is a terrible title for a book and completely wrong. I would accept twice as much value in half the time. That makes sense. That's what the book should have been called. Jeff has really misled people with that book. And as you say, Stefan, managers have seen this and thought woohoo, twice as much work in half the time. Fantastic. Who wouldn't want that? Well, I suppose if you're doing the wrong work that it'd be a waste of time, wouldn't it? So this is why it's happening. There's these basic mismatch of assumptions and values leading to people to distort Scrum into something more familiar with their bureaucratic organization. Same thing happens with SAFE on a larger scale. And also SAFE is much more accommodating of that. It's happy to be distorted into bureaucracy, it would appear, because then you can sell more safe training what else? We dived into a few of the patterns. I think people should know that Safety Stefan has a lot of these patterns on his Age of Product blog already. So you can go and see quite a lot of them there. You can drill down on them. What else can I say? The core thing is a lot of people are doing things wrong because of lack of understanding, mismatched assumptions. Is it Scrum's fault? Some people are saying it is Scrum's fault. I don't really think so. I think Scrum is a way of shining a light into the dark places in your organization so that you can see the spiders, rats and mice that are lurking and you can get rid of them. Scrum is very good at making the problems open and transparent if you do it properly because of its empirical nature and the short goals. So I do like the analogy of Scrum is like you're on a unicycle juggle. It looks easy when you see somebody else do it. It's not so easy to do in practice. So I think that's where I've landed. Shane.

Now where can people learn more about these things we're talking about?

Stefan I would suggest these ways to start with my blog. So hofproduct.com, it's relatively simple. You can Google it or Google me Stefan Wolpers and it will lead you to the blog as well. You can download the public version of the Scrum Anti Patterns Guide for free. Can sign up for the newsletter if you'd like to get once a week an update on interesting articles I found. And maybe you're also interested in joining our meetup group really large by now. And there's also fancy Slack group that we have which spans around the globe. So we're at 12,000 people. It's called Hands On Agile and the amazing thing is it's people from all over the world. So wherever you are you can ask stupid questions and have endless patience of answering your questions. So I find this really, really helpful as a community and everything is free of charge. All depends on your willingness to engage and contribute.

All right, thanks for coming on.

Thanks for having me. Shane Mario was a pleasure.

That was the no Nonsense Agile podcast from Murray Robinson and Shane Gibson. If you'd like help to create high value digital products and services, contact murrayvolve.co. that's evolve with a zero. Thanks for listening.