Lindsay Velecina: 0:03

Welcome to the scrum.org community podcast, a podcast from the home of Scrum. In this podcast we feature professional scrum trainers and other scrum practitioners sharing their stories and experiences to help learn from the experience of others. We hope you enjoy this episode.

Dave West: 0:20

Hello, and welcome to the scrum.org community podcast. I'm your host, Dave West CEO here@scrum.org. Today's podcast is going to be pretty awesome. I'm excited to be talking to Stefan Wolpe as a PST who's just finished a new book called Scrum antipatterns Guide, which, you know, I had the opportunity to review and to look at when I worked on the foreword. And there's some really good stuff in this in this in this book. And it's like it's going to be incredibly useful in in the community and in with people that are practicing scrum anyway. But before we talk about that, welcome to the podcast. Stefan.

Stefan Wolpers: 1:04

Thanks a lot. And thanks a lot for having me. It's a great pleasure.

Dave West: 1:09

Very welcome. Before we get started and start talking about anti patterns, which is why we're here, maybe you want to tell our listeners a little bit about yourself where you're talking to us from

Stefan Wolpers: 1:21

I'm located in Berlin and Germany so I can see the rice tag so to speak, from my my windows here. Well, background, I started chemistry I never run in laboratory though. I spent all my professional life in making art and software. And, like so many other people. Agile found me, you know, a long time ago, so almost 20 years and stayed with it. Ever since.

Dave West: 1:53

We're, yeah, I I'm very fortunate. I'm on one of your lists, I think on LinkedIn where I get a newsletter every I think week of your revelations and experiences. So it was That's why I was so happy that you started writing this book. And it's part of the professional scrum series that Addison Wesley. So great. So let's, let's get in it. Let's talk a little bit about anti patterns, which it's always evil patterns is another way of describing I guess. There's, there's a lot of Scrum books around right. There's, I think well over 100 in English. So I love the weather there about retros over there about you know, how do you do Scrum? What is scrum pocket guides to Scrum? So, what was your motivation for writing this particular scrum buck?

Stefan Wolpers: 2:51

Oh, the there was quite a bunch of motivation. First of all, I started the book with writing a series of blog posts. And those were form of venting my frustration was one of the project I was working on to use my commuting time. You know, we hopped on a train every every Monday morning and went to my client. So I used the time productively and wrote about this. And our timeline, I collected quite a quite a lot of material. And I thought okay, maybe this is something something bigger because all the books you mentioned are the great books, I have a lot of those in my in my in my bookshelf. They all have this idea of okay, how can we how can we turn this into something amazing. What's what are best practices, air quotes here? What shall we do to actually be successful with implementing and using Scrum for the benefit of everyone involved? Namely, our customers? And our founder? Okay, you have a different perspective. You started with okay, maybe we we get good at practicing scrum by avoiding the usual stupidity is that we run into. So this inversion of the learning principle, I would love to claim this for me, but it's been around for for a long time. You know, so if you're, if you're, if you like investing, you certainly have heard of Charlie Munger, and he's a big fan of that you. You can't avoid to be become to become a rather decent investor if you just avoid the stupidity of others. And there's so much stuff around you can learn from almost everyone. So that's the fun part. So I flipped this perspective. You know, it's a bit like a pre mortem, that is auto flipping the perspective or liberating structure called trees in a way you're deliberately asked, What can we do to ruin something? And that leads to actually new insight because you change the perspective. And that was my my whole idea. And of course, there's a very selfish motive because writing a book means that you actually have to deal with the content at a different level, you know, churning out a blog. Post was one thing, and Writing a book is something completely different. I can tell you so was the first time, my major experience, and I'm still recovering from

Dave West: 5:12

recovering, I think that's an interesting raise. You're right. I mean, obviously, we have a lot of editors, both technical and content editors that have been you've been working with, which is always great. It does make you think, because when you you can say something like, oh, x in the book, and then, you know, on a blog post you get away with, you're saying that in a book, you have to actually put wine, there's a lot more detail, which is, which is great. So the, if you look at that, that the book it, it's actually almost sort of anti recipe guide. You know, there's, there's all the chapters of each of the, you know, the, the key events or the key artifacts in Scrum. And then there's a series of of anti patterns for each one of those is, you could almost just dip in and dip out. Was that something you were looking for when you wrote the book?

Stefan Wolpers: 6:12

Yeah, absolutely. It's snackable. So my idea was, okay, maybe someone who's not that experienced with running a daily Scrum or facilitating a daily scrum, let me put it this way, may be interested in just getting a brief understanding what might go wrong. And that was my idea, make it a companion, you know, of everyone. So keep it simple. snackable easy. You know, it's, it's, I wouldn't be surprised if people were to read it from cover to cover. Of course, you can do this, but it's not intended to be that. So it's more kind of website printed between two, four color colors.

Dave West: 6:59

It is what I thought of it. When I looked at it, I remember my mom, always she had one of those recipe card boxes. And she would like when she was making a cheese sauce, or she was making her this, she would bring out one of those little cards and use it my mom's not English, though. Obviously, cooking isn't isn't in our DNA as it were. So she'd bring out these little card. And I felt that that was very much what this book was, which was, which is great. Because there's many days, I need one of those cards when I'm about to enter a sprint review or a sprint planning session. So tell me a little bit about which you know, which are the most frequent anti patterns that you saw, I mean, that was inspired from that those train journeys to your client. So they're probably the ones that stick in your mind the most right?

Stefan Wolpers: 7:52

There all the antipatterns. In the book, I personally experience one way or another, not just with one client, but with a lot of other clients. So that worked, that was my idea. There are some anti patterns derived from job ads, but that is part of the appendix. But all the other ones I've realized and experienced personally, you know, so it's, it's really a more kind of diary. With a bit of added information, you know, the cool thing is, I mean, if you write a blog post, you can just just quickly need, you know, you rant about a thing, and you have a few a few lines here and there, and then you're good, you're good to go. It's fine. And it looks different. You know, so always trying to understand, Okay, why are the things the way you observe, there's always a reason for it. And nowadays, there's always some rationale behind that very often at a system level, or at a personal level. And my idea was, okay, how can this be useful? So what what I try to, to help the readers with is actually provide some sort of recipe to get thinking about the situation occur, why is it the way it is? And how May the team or even you, the reader have contributed to the situation? And probably what can we do about it? What might be a first step to actually overcome this situation? And there's significantly more to it than meets the eye at first glance, it's absolutely amazing when you start digging. That's often reason why the editing process was was so great, for my perspective, because it was like you're paying, playing ping pong with someone knowledgeable about what you wrote. And they got back to you and sitting at it. This is not working. And this is contradiction, you know, and that was really the fun part. What antipatterns are really li recurrent, I think I try to create a taxonomy of anti patterns at a meta level, so to speak. And what I found was that there's one category that is really popular with a lot of organizations. And I think you can summarize them with applying practices from a different era to Scrum. It's a classic management tactics that are very, very well suited to undermine Scrum and deprive it of more of its purpose, so to speak. So normally, you might be doing something that resembled Scrum, you die, you do all the events, and, you know, have you printed your business cards, now you have a product owner, it's no longer business analysts, the de facto the, they're not doing it. That is certainly a very, very, very large category where you can put a lot of stuff in.

Dave West: 11:02

So an example being percentage complete on a task, task management, you know, all of this sort of those kinds of things, status reporting, demos, no detailed analysis Sprint's things like that, absolutely.

Stefan Wolpers: 11:22

Status report, I mean, don't get me wrong. I'm not a fan of status report, I wrote a lot of those in my past, and I hated it all. But there might be a situation where you may be at the beginning of introducing scrum to the organization and your stakeholders may not be totally familiar with the new world. And now and in that situation, I'm completely convinced that you need to bait the hook and feed the fish, you know, that the bait needs to be appealing to the fish. And if that in this case, is a status report, you know, you don't call it a status report, you maybe call it It's an invitation for the for the sprint review, right? If you just summarize what's been accomplished, you tell a story, you know, where we have a hero and a villain and how, you know, the hero managed to overcome the obstacles and how they lived happily ever after something along that line totally fine. Right? Maybe you don't want to do this for two years. But in the beginning, my goodness, if that takes to get your stakeholders to the Sprint Review, I'm all in. It's, it's, it's really not black and washed. I notice a lot of shades of grey. And you have to pick your your shade of gray that is compatible with the situation. It's

Dave West: 12:44

interesting. We talk to us talk about status reporting. But the the asking why is a really interesting question of your stakeholders why they want the status. You know, because what are the one of the changes with Sprint reviews, from a status reporting to a actually a positive and great scrum experience is the participation by the stakeholders, you expect as much from them as the people that are preparing and creating the review that the you know, the scrum team. So getting that participation? Sometimes you can really get at it when you ask that why. And I think you wrote about this, you know, getting into the why is it a status report? Why Why What do you need this for? Because you may discover that they need it to feed another engine. So maybe those stakeholders should actually be at their sprint review as well. There may be some, they may want to contribute and help. So Oh, hang on a minute, let's find out what you could contribute where your area is, it can really change the dynamic of everything. But instead of just saying no, we don't do status reporting and telling everybody know that no, stop doing that the scrum police are here. You actually lean into it and try to find out the why. And I think that that that I think super interesting. And something I hadn't actually thought that much about until I until I read your book.

Stefan Wolpers: 14:15

That's the whole idea. It's not a recipe book in the sense of okay, you read a chapter and then you're good to go. And you will never experience a bad sprint review again. I mean, I like to imagine that I will be that good, but I'm definitely not. Now it's more a question of think about this. One of these, of this bouquet of thoughts, what the origin or the reason for this behavior is might apply to your situation, and then pick something and think about okay, what can we do about it? Maybe take it to the next team retrospective and explain it to your teammates, folks, I believe our problem with our scene VP who insists on having status report is the following. And our A, B and C, what can we do about it? It's not about that you come up with all the solutions immediately by scanning a few pages in this book. I mean, I would be surprised if that will be working. Right? It's more about changing the perspective, getting a few new ideas, and then take it to the next level and ask other people. Okay, how can how can we deal with this issue? Yeah.

Dave West: 15:30

I really liked the fact that sometimes we have been accused in our community of being the scrum please, the, you know, you don't do this, stop doing that. Do this. And there's no why there's no context, isn't it? So I'm hoping we never do that. But one thing I really liked about the book is that it really refreshed that that whole thinking, you know, it isn't about yes, there are some things that don't necessarily help at her daily scrum, sprint review, or sprint planning, etc. But instead of instantly, just saying no, and leaving everybody feeling a little bit incomplete. We lean into them, we focus on them, we dissect them, and we explore them. And then that gives us the power to inspect and adapt and improve in the retro or in other events where we get to improve the process.

Stefan Wolpers: 16:26

I absolutely agree. Yeah.

Dave West: 16:28

So interestingly, and I know we haven't got long so I but I do want to touch on one thing. So I really sprint planning. I sprint planning is so many challenges from so many organizations, particularly as they wrestle with that sort of meta problem of old world meets new world. So talk a little bit about sprint planning, what patterns in particular in sprint planning anti pattern sorry, in sprint planning? Did you discover on your journeys and write about?

Stefan Wolpers: 17:04

I think the most notorious is always that. You, you bring a bunch of work items, and then you try to squeeze them under a sprint goal, because the scrum guide says so. Which, of course is not the way it's intended to be with Russia. I mean, II, it's also the part and the closet takes the most time to sprint planning actually does it okay, the product owner brings the business objective to the sprint planning, right. And the team collectively creates a sprint goal, a meaningful sprint goal that aligns with the business objective, then the developers commit to it. And because they do, they're allowed to pick to work to make this happen. Checks and balances, right? This is, it's a basic principle, it's not that complicated. If you take into consideration that Scrum is about outcome, you know, we want to improve the lives of our customers, and contribute to the sustainability of the organization, the process, of course, but it's not about output. And then in a complex environment, if you write a bit more code, it doesn't mean that you create more value. We're not assembling features here. And if you if you apply this, this, this idea, this this, there is a mental model to the whole challenge. Life becomes brighter, and then you can actually start thinking about okay, okay, maybe that is not a good idea is that the rapidity? Right, so that was really, it's the meanest one, by all means. Trying to find a sprint goal, because the scrum guide says so just to to be able to summarize a bunch of unrelated work on the one goal, which of course, is usually not helpful and not manageable. Yeah,

Dave West: 18:58

I think I see that all the time. And it certainly resonated with me. The the lack of good sprint goals ultimately, are illustrative often of other other fundamental problem around work versus value. And getting at the heart of that can suddenly turn work teams into value teams. And and I think it's incredibly interesting, or hidden in this very simple little anti pattern, which is, which is which is, which is great. I agree. So a lot

Stefan Wolpers: 19:36

of benefits to cover. Yeah,

Dave West: 19:40

I mean, if we can get motivated teams that clearly understand the value that they're trying to reach, and empower them and sort of de shackled them from the challenges of that get in the way of that. I think goodness happens and I think that's, that's the sort of theme for the book. Book Riot, this is a guide for freeing your teams from those anti patterns.

Stefan Wolpers: 20:06

Like this picture of breaking shackles.

Dave West: 20:11

It is good to break shackles, unless of course, you're hanging above a big pit. And then it's good to just hold on to them. So, Stefan, we tried to keep these short, we could talk for days on these. And this is an entire book designed to encourage this conversation. So thank you for spending the time today. And introducing this book to our to our listeners.

Stefan Wolpers: 20:39

Thank you very much for having me. It was a great pleasure.

Dave West: 20:42

So thank you, everybody, for listening. Today, we're joined by Stephen Walters, talking about his new book, which is called Scrum anti patterns guide should be available. But just check amazon.com or any of your favorite publishers, and I'm sure you would find it. It's an absolute interesting book that talks about all those sorts of things that you see in your teams that maybe are not necessarily as good as you would like them to be and give you some fantastic tips for approaching them and maybe turning that realization into a thing of value. So thanks for joining us today on the scrum.org community podcast. I was your host, and hopefully you'll be able to join many podcasts in the future. Keep on listening and Scrum on