Scrum Anti Patterns with Stefan Wolpers

Join Murray Robinson and Shane Gibson as they chat with Stefan Wolpers about scrum anti-patterns. Explore common anti-patterns, such as scrum masters assigning tasks to disempowered teams, and discover the solutions for overcoming these challenges.

Key points of discussion include:
🔸 Why scrum anti-patterns keep occurring
🔸 The issues with scrum master education and training
🔸 The role of big consulting companies in selling scrum as a project management process
🔸 Core differences between scrum and bureaucratic organisations’ assumptions about work

Tune in to gain insights into scrum anti-patterns, their impact on team performance, and how to overcome these challenges to achieve more effective agile processes.

Read along you will

Murray: In this podcast, we talked to Stephen Wolpers about scrum anti-patterns and why so many organizations aren’t getting the benefit from scrum and agile they expect. We discussed 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. 

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

Murray: And I’m Murray Robinson.

Stefan: And I’m Stefan Wolpers.

Murray: Hi Stephan. Thanks for coming on today. We wanna talk to you about Scrum anti-patterns, which is your new book that’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.

Stefan: Sure. I started studying chemistry, but I never worked in a laboratory by 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 ‘ve 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 scrum.org as a professional scrum trainer in 2019.

Murray: And did you say you were a software developer?

Stefan: 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 that.

Murray: 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?

Stefan: Not really. I was more the 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.

Murray: 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. 

Stefan: Yeah, we’re nearing 40,000 subscribers by now.

Murray: Yeah. All right. So I see that you’re coming out with a book called scrum anti-patterns why did you decide to write this book? 

Stefan: 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 of 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 the business. Of course it’s 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 rides. And then I started to write blog posts about those anti patterns. And then I aggregated the, the block post into some brochure 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 patterns.

Murray: Are there a lot of teams that are doing Scrum an Agile poorly? What’s the state of agile at the moment 

Stefan: 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 that 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 the 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, of Scrum.

Scrum has by nature, a technical 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, 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 nuance looked at Scrum and how Scrum is supposed to work.

Murray: 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.

Stefan: There’s this one book from Jeff Sutherland Scrum, The Art of Doing Twice Work and 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 liable, 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 are really into maximizing the 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-manage? Are they writing their paychecks in the end themselves? 

So, what I really like to do is run delegation poker from management 3 to figure out, okay, what understanding do we as a team including our stakeholders have, what self-management actually means.

And it’s always amazing to see what people understand by the term , of 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, they just build on their assumptions. And then they’re also surprised that their assumptions are not the assumptions of other people.

Shane: 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 , a set of guidances that you have to fill in the blanks.

And so if we look at Scrum, do you think it’s more principle based or more patent based? What would you.

Stefan: My version of Scrum is, principle based. The patents 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 in? 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, about 500. And I 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 Meg Boston 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 scrums principle might manifest themselves in real life. This has to be tailored to the individual organization.

Murray: Let’s go through some of these anti-patterns and Let’s start with the Scrum master.

Stefan: Okay. Scrum Master. Depends a bit on, where you’re coming from. if you’ve 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, 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 they’re still on track accomplishing the sprint goal and what they can do to stay on track or get back on track.

Scrum guide says, we’re responsible that it happens, but otherwise we don’t have to do anything here. 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. 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.

That certainly is not your job as a scrum master. I’ve never met anyone who had no idea how to get new stickies, either by purchasing them from the department local or by organizing them from the neighboring team when they have lunch. And they said, no, never happens. It’s not my job to organize stickies .

Maybe you succumb to the idea that as your job as scrum 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, it’s not about the contribution of the single individual. 

Shane: 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 they actually delivered.

Stefan: Yeah, thats y et another dimension. So, the ratio of points estimated, whether it’s forecasted, whether its delivered, , and then this is a complete new rabbit hole you can dive into, , so 

Murray: 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, dates that they’re supposed to be done by.

Stefan: Mm-hmm. Totally. Yes. So that’s basically an anti patam both for product owners as well as Scrum masters. 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.

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

Stefan: I think a lot of anti patents 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. So 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. We are fear-driven creatures. , there may be say the tooth tiger around the next next tree, and , then we’re gone.

And this is just manifesting itself in real life. And a lot of organizations you’re rewarded for accomplishing goals not creating value for customers. 

Murray: Scrum Guide does say now, doesn’t it, that the Scrum Master’s responsible for the outcomes of the team.

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

Shane: 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? 

Stefan: The larger the organization, the more control driven anti-patterns are prevailing. The, 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 oxymoron 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 ’em 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.

Murray: Yeah. What about some of the anti-patterns with the sprint itself? For instance I’ve seen scrum Masters assigning work to developers,.

Stefan: 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. 

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

Stefan: 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 a 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 retrospective. Probably not. So I had a lot of one-on-ones in the 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 the consequences. But that’s the only thing that you can do. You can’t force issue.

Murray: yeah. What about some product owner anti-patterns that are quite common?

Stefan: Oh. Tons of those. , 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 at 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. Stefan, 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 the 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 but the developers were creating the backlog entries. So I never wrote them myself. There was always a developer who wrote them because then it’s our ticket and not my ticket. Because if it’s our tickets everyone is willing to go the extra mile to make it work.

Shane: 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? 

Stefan: Shane, I believe you’re absolutely right. There is no ready made toolbox available that says, oh if you run into this problem, you would 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. Management for Zero 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.

Shane: 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. I don’t see that , in the Agile community or in the Scrum community. Is that what you are seeing or am I just not, seeing organizations where that happens on a regular basis.

Stefan: 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 Shu, Ha, Ri . So you start sticking to the rules and then you start bending the rules and when you really experience, you break the rules and figure out your own way of working. yes, There 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 laid out in the scrum guide on the other side is Shu, Ha, Ri idea. This is how we move forward. We’re 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. 

Shane: Yeah. One thing I really love about the Agile community is it is so open at sharing and it’s, 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?

Stefan: 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 it worked in the past, or why should 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 round, there is a path to creating value for our customers. Which is totally fine. But the deliberate idea to say, okay we need to talk about this. Something is going wrong and we have the capabilities to do better here. Let’s talk about this is really, really challenging.

Shane: 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 think? And if they agree, then it’s a case of, okay what are we gonna do to fix it? Because actually we are not happy with that way of working. Do you think that shared language is really important?

Stefan: 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 the next retrospective to talk about this issue? Ideally, those topics could 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.

Murray: It strikes me that one of the most fundamental ideas in Agile is that we are going to be open and honest with our thinking and our communications. So you are 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.

Stefan: It should be that way, yes. But very often it’s not 

Murray: Well, why not though?

Stefan: 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 this sprint on zero to 10? So classic NPS 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 survey before every single retrospective as 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 a deadline that sales pushed on you. So 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. This is cold hard data. And that helps, to start conversations. You need to give the people a few supportive means to get the discussion going.

Shane: 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?

Stefan: 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 door. 

I thought, you put so much effort into here, slow down. Think about what we’re doing here. Is there a way we can do this better. 

We used a physical board at the time and 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 board. 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’re focused on limiting work in progress and abandoning this crazy idea of multitasking that flow metrics improved. Cycle time went down, and stakeholders were much more pleased with the work of the team. It was less stressful. They 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.

Murray: Okay. The other Fundamental issue I see a lot Stefan, is that the team is improving in 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?

Stefan: 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 products.

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.

Murray: Yeah. But the Scrum Master’s supposed to be responsible for helping raise these issues with management and help management to resolve them, aren’t they?

Stefan: 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, but beyond that, it’s out of their control.

And 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 because 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. 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. That is really something that you have to solve at a different level with support of other people.

Murray: Yeah, I, 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 MacBain 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 see that?

Stefan: 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, but 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 are probably become interpreting the scrum guide literally. Than you have a bit more ideological approach to Scrum.

Or you say, it’s an augmentable framework. Let’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.

And very often it’s not a deliberate career decision, it’s more kind of occasion that , you rise 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, this all makes sense. Let’s do it this way.

Murray: 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.

Stefan: Totally fine. , so I mean if you’re still doing scrum after three years, you probably haven’t learned a lot.

Murray: 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 scrub is like a unicycle, it’s 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 unicycles fault.

Stefan: I like the metaphor of a unicycle. It’s a very good visualization because what I 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.

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

Stefan: Mainly would say no, I think the intentional incompleteness is a good thing. It’s 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 achilles heal is the product owner and the assumption that the product owner knows what is worth building because this is absolutely not the case. And I don’t think that the product owner should be the person who knows whatever is worth building. it’s 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. 

Murray: 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 fifties and sixties. So, yeah, I think there’s not many product owners who know how to be product manager. All right. Perhaps we should go to summary. 

Shane: 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 methodology is 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, rolls, events and artifacts. That just helps me understand, okay, I’ve got an anti pattern that I think relates to a role. Maybe that’s what I’m gonna 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 then 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. Cuz that’s not the principle that 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-patent, but it doesn’t really matter right now. So that’s okay. There’s always things we can work on. We are 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 kinda my view of what we talked about. And my question for you is Jira and using tickets in Jira an anti-pattern?

Stefan: No, 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 this stupid definition of ready, plug in, 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 sprint, then Jira is toxic. But at the beginning, out of the box, , everyone can do everything fine. It’s a good tool. 

Shane: I’m gonna 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. 

Murray: 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 sub-tasks too much. So you have a user story and then the scrum master creates all of these tasks and sub-tasks 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 cuz 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,

Stefan: Yeah, that’s an issue. And then they start estimating subtask and stuff like that. And then you’re walking in the wrong direction.

Shane: Anyway, enough of renting from me. Murray, what have you got in summaries?

Murray: Yeah. We decided we wanted to talk about anti-patterns, cuz 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 are taking the ball down the basket and scoring points and we are doing it together.

And the Scrum masters, the coach. I dunno 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 bureaucratic 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. Cause, they’re not really accepting the change in assumptions that comes with doing Scrum and Agile properly. I think a lot of times cause they don’t understand it. The two day training’s 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 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, woo-hoo twice as much work in half the time. Fantastic. Who wouldn’t want that? Well, I suppose if you’re doing the wrong work, 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 a bureaucracy it would appear cuz then you can sell more safe training. 

What else? We dived into a few of the patterns. I think people should know that 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 doing things wrong because of lack of understanding, mismatched assumptions. Is it scrums fault? Some people are saying it is scrums 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 juggling. 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?

Stefan: I would suggest these ways to start with my blog, so ageofproduct.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 this scrum anti patterns guide for free. Could sign up for the newsletter if you’d like to get once a week an update on interesting articles I’ve found and maybe also interested in joining our meetup group that’s really large by now. And there’s also fancy slack group that we have which spans around the globe. So we’re 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 they have endless patients 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.

Murray: All right. Thanks for coming on.

Stefan: Thanks for having me. Shane Murray was a pleasure.