Today, Justyna and Paul are talking about the new book, Fixing Your Scrum by Todd Miller and Ryan Ripley.
Get the book
Today, Justyna and Paul are talking about the new book, Fixing Your Scrum by Todd Miller and Ryan Ripley.
Get the book
spk_1: 0:00
Welcome to the agile Book Club. Your your hosts, Houston A and all. Hello, Houston.
spk_0: 0:07
Good morning, Full.
spk_1: 0:09
Good morning, Houston. We're back. Wait, It's not morning.
spk_0: 0:12
I know it's after I will. I just wanted to lie to our listeners that we wake up so early each morning just to record the podcast for them.
spk_1: 0:20
No, we talked about that enough in the last podcast, which was early in the morning. As you recall. So today Today is about giving our listeners and scram love because I had mentioned several times as we're talking about different books and such that we've been running an agile podcast now for almost a year. And we haven't talked about Scream at all, which is
spk_0: 0:47
coincident a
spk_1: 0:49
little bit of an oversight, I think, a little bit of an oversight Indeed. Scrum is insanely important to the agile world. And it it changed the way everyone thinks about developing software. And we haven't given it any love here on this podcast. And so when I saw that a guy I know who I follow online, Ryan Ripley had written a book along with Todd Miller about scrum. Now I'll tell you, I'm a little apprehensive. I came into this a little apprehensive because having gotten involved in the combine community once the first book was out. Once David wrote his Blue Book, the first book on CONVEN, more practitioners started doing it and coaches started started emerging, and you had people who were just specialist con Bon consultants and combine coaches. And it was coincided with this eruption of self publishing. Lean Pub had just launched, and Amazon had created their their self publishing platform. And so all of a sudden everybody had to write a book and one after another after another after another, people who I liked and respected enough to read their books were writing Kon Ban books and with maybe only one exception, they were mostly the same story. It's like, this is me explaining how how convent works, and this is me explaining how combine works and there were me to type things. And so I found myself wondering after what, 20 years, almost 20 years now, since Crumb furs came out. What in the world knew is there to say about Scrum? Why write another scrum book and well, I guess we'll get into it in his podcast. But I was pleased to discover that there's still room for new ideas in a 20 year old technology,
spk_0: 2:55
and I was happy to actually discovered there's some of the ideas that we can apply in Poland, which is scrambling and, you know, just to help our community.
spk_1: 3:06
So should we launch right into it with elevator pitches? Yes, What's yours?
spk_0: 3:12
Okay, so I would divide the audience for the book into two categories. The first group is like newbies in scram, worked for whom? I suggest first to read a scram guide just 20 pages and then go to a fixing scram. Why? Because I I think it will help you to be aware off more of the risks that are waiting for you all off anti patterns. That am I see in your organization. So it will just simply make you more hour and provide you with a load off tools and ideas off what you can do if you come across any off them. The second group, I would name people who are suffering from scram disasters or people who are self south called thought leaders in scram who changed everything because they think they can I think there is a lot off place in the book when Alters are describing that. Yes, you can adopts cramped your needs, but first you have to understand basic principles and values, and that's what you can do in the future. So for those two groups, I think that the book is perfect and especially if you're the representative off failed scram implementation. I suggested to read the book slowly with a notebook pen and a marker, and take your time to try with different exercises to look into your organization without your ego and tryto make scrum a successful as it's possible for you and your organization. Lovely. Thank you.
spk_1: 4:49
Although, as usual, I'm going to disagree with you.
spk_0: 4:51
Of course, I just lovely. But, you know, I will tell you.
spk_1: 4:57
No, no, I'll get into this a little bit when we're into the section. And
spk_0: 5:01
I bet you can.
spk_1: 5:05
When we're talking about the takeaways, I actually think that this is an incredibly frightening book for scrum newbies. Oh, yeah, and I'll talk about a little bit. But why? I think that as for the second group of people wholeheartedly, my elevator pitch is one
spk_0: 5:24
of the things
spk_1: 5:24
I liked about this book is so many books try to aim at the largest possible audience. You know this is Scrum. This is lean. This is whatever anybody who's interested in this topic should buy my book. This book is unabashedly focused at scrum masters. It talks to scrum masters. It talks to the as scrum masters. The language of the book is like Hey scrum masters. There is nothing in this book. I mean there there are things that other people can get out of this book. But the authors have written this book as a scrum master to scrum masters and it is absolutely for scrum masters. And so I would pitch this book at Scrum Masters Now. That's not to say that only scream Esther should read it or only scream. Esther's will read it. I have I have this imagination with all of the horror stories in here of the very common problems that that scrum teams face that some programmers and some designers and some managers are going to read this book and then anonymously, surreptitiously leave it on their scrum masters desk in the hopes that they read it too. But the book is written for scrub Masters. Oh my, my elevator pitch. Describe Masters would be a really simple one, and it is this. There's so much in this book, although it's not hard to read, it's It's a really well structured book. It's a really easy read. I read the whole book in one day and it is this. I dare you scram Masters. If you're a scrum master, novice or experienced, I dare you if you're working. Scrum master doing scrum in an organization I dare you to read this book. Sit down in a weekend, read the book and I dare you to tell me afterwards that you didn't find one problem that you are currently experiencing and a solution which you haven't thought off.
spk_0: 7:24
Yeah, nice. And I think just to prove your hypothesis that it's like I'm only to scram, Master. There were even jokes aimed for scram, Master, I could have I have one, Joe asks. What is the difference between a scram master and an idol coat? About $50 per hour. So
spk_1: 7:47
and the quicker it quickly follows up to say that if your scrub masters of properly empowered and doing their job in an organization they don't need. Agile coach. Definitely. This was aimed its grand masters and not agile coaches.
spk_0: 7:59
Exactly. So what would be your first take away if you could just dump into it? I want to
spk_1: 8:05
start really, really high level. I'm raising my people who can't see me, because because this is a podcast and not a video. I'm raising my arms high in the air. The really, um, really high level stuff. There's these two huge takeaways that I took from this, and I thought they were both enormously important. One is the amount of stress that this book places from Page One unveil use. And and I really liked the way that the authors talk about values the way they deal with values. For the first couple of chapters, the importance of values was so emphasized that I found myself thinking they're making a very strong case here. That scrum is never going to work. If everybody on the team doesn't subscribe to the core values of scrum and the way they explain it, I think it's really nice is that essentially scrum without the values is just a kind of wrote process. It's just exercises. They don't actually deliver value. It can't grow and learn and change and evolve and become the perfect fit for your organization without the values. Because there's there's nothing actually driving that change. It's just people ticking boxes and I found myself wondering, Is possession of these values a prerequisite for doing scrum? Because in the first couple of chapters they were emphasizing values very strongly. But luckily that the answer came in later chapters by Chapter three, I think I started seeing more and more exercise and sizes and activities and questions and discussion topics and such that were specifically aimed at what a scrum master can do to help a group of people explore the scrum values. Question the scrum values, think about ways to integrate them into their decision making. Look at ways in which it's helping them, looking at ways in which it could help them to try to live those values more. And so I had my answer, which is that there's a lot in here that is aimed at ways in which a scrum master can help a team or how people outside of a team that they need to work with scrum to understand the importance of living these values, at least at work
spk_0: 10:27
on this is
spk_1: 10:28
something. Now you know I'm an anthropologist, so I think a lot about culture. And one of the things that I find fascinating about culture is the way that a person can carry so many of them in their head. We tend to think of a culture is as a single big thing that we're born into and raised up in, and it becomes a part of us. But the truth is that you look at the very, very different ways that people behave at home and at work and at church and its school, and with their friends and and such. And in each case, they're capable of moving in indifferent cultural contexts and adjusting to them. And so one of the things I've often said that I enjoy about working in large corporations is they tended to have very, very specific sets of values, and all of the people come into that organization have learned how, even if they don't hold those values, even if they don't live by those values at home or outside of work. Within that context, they all in order to advance their careers have learned how to at least pretend like they hold those values, act like they hold those values, or even hold those values within that very narrow context of work. And so it's entirely possible that you can take a group of people who maybe aren't necessarily inherently trusting people. Or maybe they tend to be shy and and closed and they don't they don't feel courageous. They don't like being open. But when they're in a scrum environment, they can learn howto act in the courageous way, how to be open, how to how to assume trust. And and so that is the first big big takeaway, which is that this book is all about values.
spk_0: 12:11
I enjoyed your round as always, and I agree of you. There's a lot of placing the book when values are not only explained, but shown how anti Potter's arrives when we lack off any of the values here which leads me to one of my takeaway, which is scram itself doesn't go bad. That was just the beginning off the book and I think that the message was very clear and address all of us because we tend to see companies that claim with you scram or scram doesn't work for us. But what is the real reason behind this is like no one in the organization maybe even read the scram guide. They don't do scrum right in the first place, but they immediately booted their own rules and principles. And at the beginning of the book, Ryan gave example off one of the companies that wrote 5500 pages. Scram, guide with like principles and the best practices and off course we might think. Okay, they treat, scram, serious. They prepared such a big document and everything. But on the other hand, this is just such a waterfall approach. And also there is no recipe for scrum done right. I mean, you know, 500 pages and the agenda and points won't make it work for you. Good if you don't go scram right in the first place. And I really liked in this chapter. When outers outlined some off the anti patterns like, for example, teams that claim we know that we know what is happening in our team. We don't need a daily meeting is the waste of time. So it's two Daily Bi weekly. That's enough. Yeah, Or like another retrospective. Now there is no need. It's enough to talk like once per quarter. Nothing will change nothing about but will happen. Or like for example, let's cancel retrospective. We are too busy to work, so I understand that we should evolve and adjust frameworks for our needs. But we have to remember that at the beginning we have to follow principles and values to see what works, what doesn't and they then take a worst steps. The words adjusting scram, toe out there, and it's not the other way around that we just choose what we like and then complain about the framework that it just doesn't work. It'll
spk_1: 14:34
be one
spk_0: 14:35
of the
spk_1: 14:35
things that really struck me that I hadn't seen proposed anyplace else is in the first chapter when they're breaking down, what is scrum and what is not scrum? One of the points that they make is when a team is struggling with scrum. A common it piece of advice that the authors give to the team is to strip away everything that's not scrum and get good at scrum first, and they do a really nice job of explaining is breaking down those those 11 elements of Scrum.
spk_0: 15:03
This
spk_1: 15:03
room is actually ridiculously simple and even removing things that that have become so associate ID with Scrum that one might be forgiven for not realizing that they're now actually part of scrum things like planning poker and estimation and burn down charts. What Scream without a burned down
spk_0: 15:26
train? Right? We've been
spk_1: 15:27
doing burned down charts since day one, and and yet, yeah, there's no reason it's it's not a part of scream. You don't have to have burned down charts. You don't have to do planning poker. And I found myself thinking Indeed, if you strip away those things away, you still have to find ways of solving those problems that those air designed to solve. And you may very well come up with better ways of solving the problems. This conversation's still have to happen. There still has to be some kind of transparency. There has to be some kind of reporting and such, But when you start adopting just whole suite of practices as though they were best practices auras, though everyone does this, it must be the right thing to do it becomes really difficult to focus on what really matters and get good at that
spk_0: 16:15
first. Yeah, and I also like when they outlined that scram is much more than just a checklist off practices to follow.
spk_1: 16:26
So can I go with my
spk_0: 16:27
next big thing? Oh yes. Raise your hands. Ah, this
spk_1: 16:30
was my next big, big, big, big, big thing. And that is and this is the reason why I think it's kind of frightening for scrum newbies. Is that not only early on in the book, but also consistently throughout the authors emphasize the absolutely critical role of the product owner. Most of the anti patterns are not fatal in this book. Most of the anti patterns don't necessarily guarantee the failure of the project, But almost all of the anti patterns that stem from weaker, flawed product owners are fatal. They're they're terrible, And the description of the product owner role in this book led me to believe that number one it's absolutely critical toe have a fabulous product owner who is capable of completely filling the role, but secondly, that it's practically impossible for anyone to be that good that the description of all the things a part owner has to be brilliant and empathetic and and connecting with everybody up and down, in and out of the organization. They have to be able t to keeping in mind so many different competing stakeholder groups and visions and values. And they have to make makes decisions, big decisions, small decisions on the fly communicate clearly. My goodness gracious. But that s so I was thinking Is this like a fundamental flaw of scrum? Which is that if scrum only works if you have this, this practically superhuman part of owner, then is that a flow of scrum? But as I was reflecting on my own experience and I have an unusually large amount of experience with scrum projects because I work in Web development and so a lot of our projects are reasonably small, like three months to two years maximum and and so I literally have hundreds of end to end product development experiences. The vast majority of them failed. Vast, vast, vast, vast, vast majority of them failed. I have seen all of the anti patterns the product owner, owner, anti patterns that the authors write about their incredibly common. And when I think back on the part of donors have worked with. I can only think of wth E 152 100 part of donors that I've met and worked with only a handful. I can count on my fingers of one hand who really filled the role the way the role is meant to be filled. And those were the ones who build successful products that had successful exits. And so I don't think that it's a weakness of scrum. I think it's a weakness of of product development. I think it's the weakness of I think it just reflects the fact that it's the reason why the vast majority of all businesses fail is that whether it's a product owner or a product development manager or a CEO or startup founder, whoever is doing this role, identifying people's real needs, that they're willing to pay, to satisfy and then satisfying them better than anybody else in the world can do is ridiculously hard. And it's only in scrum that all of that is bundled too neatly into this one person. And I'm not absolutely convinced that you can't have product development by committee, but in fact I think this is the reason why, if being a part of owner were easy and anyone could do it, we would all be Steve Jobs. So that was the other big takeaway is that the values and the product owner are the two absolute key components. Toe. Have a successful scrum implementation Those Those are the two biggest points of failure. The team that doesn't have the values and the product owner that doesn't have the skill set.
spk_0: 20:52
Okay, Yeah, Speaking about product owners, I also enjoyed the chapter in which all of the anti patterns were listed with different types of product owners that we might meet that you might actually come across. And the 1st 1 I think that that might be useful for our listeners because probably they met already those kind off product owners. Or maybe they will come across them. So the first, the first anti pattern when it comes for the product on the roll. It's many products, owners, one product. And actually, whenever I see this kind of situation or hear about it, I imagine the game off truck Imagine, like everyone wants to just have the whole kingdom, and there's like so much maybe not out loud fight, but re some men the games that are happy happening in the organization. It slows down the process. Team simply doesn't know who is the right person to tow us. They all work at the one product, but there's like too many people involved, and too many people are driven by their own agenda. So doesn't help the product. It doesn't help the team. It basically doesn't help anyone. The 2nd 1 is the part time product owner, which very often has many other functions. Sometimes it might even your senior developer and the team decided the organization, the Celica product honorees. It's not a lot off tasks to do. It's not a lot of responsibilities will choose the person who has, like the most experience they know the product. They've been building that for years so that the part time productive owners okay, but what they don't see is actually the horrible risk that it's putting on on the team because whenever they need approval, whenever they need a decision to make, they just have to wait. The product owner becomes the bottleneck. Stakeholders are not happy because the person that they can talk about the product. It's not available for them because he has other or she has another job to do. Users also are not happy because also take the clients are not happy. They don't have, like the 1.1 person that they can come, too to know to ask for help. So, yeah, basically, it is like the recipe for the disaster and failure and then the 3rd 1 the proxy product owner, which it's kind off back, look manager or for Bart Monitor. In my opinion, the product owner that doesn't have a full responsibility that it's not empowered to actually do her drop. She just has to ask for all the permission constantly. And it leads to a lot off problems within a team because they lose the authority towards her because she never can make a cautious to just wait. It slows down the whole process, and it's like we've been there. I think we we all have seen those kind of product owners who try to do their jobs, but they are just not empowered to do that. And then one of my favorite, it's a coon scram master doesn't have a lot of dope to the product on their also. So let's combine these rolled on and the whole page in fixing scram was actually dedicated to this misconception and showing what is their responsibility off. Scram us. What is the responsibility for the product owner and how country Dick Contradiction article can help him pull? Happy? Contradictory? Exactly. That's what I say they both are that it just brings damage for the team, for the stakeholders, for the whole organization and your little money saving that you've done by combining the role will actually disaster in the future for the whole organization. And the last one is the Commander in Chief, which is basically the product owner who's kind of maybe like a negative superhero, I would say, because he's empowered to do the right things. But because of probably the whole plant pressure and the difficulty that comes from his position, he's taking all the decision by himself. He's droving by his own agenda because he's constantly pushed, pushed, pushed by other people. So he just comes to this print planning with the things that he decided that they're going to do. He comes to retrospective with the feedback that he has for the team, and he just that doesn't have time. Even like I would say, to listen to other people because he just constantly like pushing war and dress, going with his check, please, and trying to make it happen. But it has the negative impact for the hold him.
spk_1: 25:37
One of the strong point of this book is I think it deals more effectively with the idea with expressing the concept of the Sprint goal than anything else I've ever read on. And I remember I remember very clearly the bad old days of commitment when three commitment WAAS to deliver a certain number of features and the certain number of feature was was based on historic velocity. So this team can deliver 35 story points in the Sprint. We've pulled the top priority 35 story points for the workout of the backlog, and we're committed to delivering it. This sprint and the idea of a sprint goal is more recent, although it's it's, I think it dates back to No, not really. I guess it's been a long time. It's been a long time since the bad old days of Sprint commitments, but I don't think the idea of a sprint goal is really clearly understood and it's such a common phenomenon for people to think that the goal is to finish the sprint backlog and the authors in this book do a fabulous job. I'm not gonna be able to do it justice myself. But they do a fabulous job of expressing the very complex and an empowering nature of a sprint goal, which is the thing that connects the scrum team to the stakeholders. It's the thing that the scrum team can pursue and get excited about and feel like they're delivering something valuable that the stakeholders can look at and say yes, if you achieve that goal, we will be happy and in that way what What can happen here as as opposed to the idea of trying to work through a sprint backlog should be a living thing. If a person comes, a person to be will come to a daily stand up and say since yesterday I discovered a different way of achieving this print goal rather than doing this task which is next next in the queue, there's something better that we could do which is better aligned with the sprint goal and that's fine. That's fabulous. That's something that everyone should be doing and would be doing. If the Sprint goal is actually something that brings value to the stakeholders and that the team can get excited about delivering and that way the whole team is thinking about the best way of achieving that goal and and and and it gives them the flexibility to do it in the best possible way during the operation.
spk_0: 28:06
But you know what terrified me when I when I was reading this chapter, I was thinking about that last engagement that that they had, and in 10 teams that I've seen, none off them had defined Sprinkle. None of them was very
spk_1: 28:23
uncommon. I don't think the sprint goal is is absolutely key and core to a successful sprint, but I think very, very few people understand the current understanding in the scrum community of what a sprint goal ought to be in and the function that it serves
spk_0: 28:43
our temple and I have one more question because I mentioned all of those anti patterns and comes for product on the roads. Do you have any more like from your experience?
spk_1: 28:54
Ah, yes, there is one and that I wasn't gonna talk about this in this section. But But I I can. And that is that one of the things that struck me about the difficulty of the product owner role is part of the products owners role is to satisfy all of the stakeholders and to satisfy all the stakeholders. You have to know who all the stakeholders are and something that I have seen happen again and again and again is something that a couple of folks who who spoke at the very first days conference called a stealth holder thing. The concept of the stealth holder and stealth holder is a very real thing. And it's it's a person who is too important to show that meeting's a person who is two senior to ever be around too high in the hierarchy for anyone to know them personally. But who has a vested interest in the project that nobody knows about who shows up 16 sprints, sprints in and just as this is completely unacceptable, and so that that is an end, a pattern that I have seen often enough that that it deserves the name it deserves. The name of its own stealth holders or a real thing, and I don't think it's something that a product owner can reasonably be expected to prevent. Although the the authors of the book have one good suggestion, which is follow the money.
spk_0: 30:28
Oh yes, if
spk_1: 30:30
if you need budget, A good question to ask is if we need but needed budget to expand the team or if we needed a budget to invest in training, or if we needed budget to extend the life span of this product delivery process by another year, who would we need to ask? And if that person is not in the room ever when you're doing your sprint reviews, you have a nasty surprise coming.
spk_0: 30:58
Uh, what out without okay, pull another take away from you. The rest of my
spk_1: 31:05
takeaways are pretty are well, they're they're off. There's a lot of really fabulous stuff in this book. The rest of my takeaways are smaller, but they're things that just kind of jumped out at me. So one of them, in the last big engagement that I had, I was one of many agile coaches, and the other agile coaches were all assigned two teams and one thing that I saw is different approaches of scrum masters to their role And I saw in one company I think all of these anti patterns I saw and I love the names that they have for them There's wth e scrum Lord
spk_0: 31:44
Oh yeah
spk_1: 31:45
Scrum Lord is the scrum Master comes in and says, Oh, this is what we're gonna do this how we're going to do it? We're going to have these meetings. This is when they're going to be this hot, little bit in the last. This is the agendas. After the planning session, I'm gonna be assigning work to these people. You know, the scrum Lord, I love that I've seen this crime Lord I've seen and the other one that I like a lot And I knew this this poor guy. I wish I had this term because it might have helped him to understand what he was doing to himself. But that is the scrum janitor.
spk_0: 32:15
Yeah,
spk_1: 32:16
I, the hardest working man in the last company that I had a long term engagement in, was a scrum master who adopted the role of scrum janitor. He did all the cleanup work he made sure all the reporting was done. He made sure everything was accurate. He was. He was constantly checking with people to see whether the status of their work matched the status of the tickets on the physical board. And those matched the status of the tickets in the Elektronik tool and such. And so one of the things that I want. My takeaway is one of the ideas that I really liked about in this book, although those minor is powerful. And that is one of the authors wrote that when they go in and they're in some sort of a scrum coaching rollers, crime master role as as coming into a new team, one of the first things I do is, if they are automatically given access to all of the various tools that that the team uses, they go to the administrator of the tools And they say, If I must have access to your Jiro or or whatever tool you're using, make sure it's read only. I don't want tohave the ability to interact with any of these tools, and I think that's fabulous because people used to ask me, Well, what do you do then? If you've got both of physical board, which is for the teams use and a virtual board, which is for for radiating data to offsite stakeholders. How do you keep them properly synchronized if there's nobody responsible for doing that? And my solution was, whenever I noticed anything out of sync, I would put I had this little avatar shaped like an exclamation point. I would just put an exclamation point avatar on the thing that was out of sync on the physical board. I wouldn't take responsibility for it. I would just call that I would make it visible and then the person who knew best. Which of the which of the two status is was right? The one that was in the virtual tool that the one that was in the physical board wouldn't notice the explanation point and fix it. And within a matter of weeks, I didn't need exclamation point avatars anymore because the best person to take responsibility for keeping things in sync is the person who knows best. And there's no one person who knows best. It's It's the team's responsibility to maintain their tools because the tools exist for the team's benefit, so that was a nice one. Just just turn off my access to all tools. I don't want to be able to do it.
spk_0: 34:45
And there's also a few more and patterns. There was, uh, scram muster superhero. Oh, yeah, When I read the description, it was like, Oh, my God, that could be me, like, you know, save the world rush of adrenaline. Applause from everyone do more than I should hear exactly. Then, through a scram master secretary which is close to janitor. Yeah, yeah, but, uh, sure, he 1000 only cleaned also, like put everything correctly, takes notes and everything. We don't remember
spk_1: 35:21
the advice that I always give if you are an agile coach or scrub master or whatever. And you are involved in the daily stand up my rules for working in the daily stand up. The ideal scenario is one in which I attend to stand up and never speak ever at all. So, Mr the best case scenario is one in which I don't speak at all. If there is a problem that needs to be discussed, the best thing I can do is say nothing and see it resolve itself If it doesn't resolve itself. The second best thing I can do is ask open ended questions. Is this something we should be concerned about? Does anybody have any ideas what we could do about this? Is there a better way we go about that? That kind of thing. The third best thing I can do, which is actually getting close to the worst end of the scale, is educate. So if, for example, the team is facing an issue with a bottleneck then and they just cannot find a solution for it, I might ask, Is anyone familiar with the theory of constraints? Does anyone know about the five focusing steps and maybe do a little bit of education? Don't solve the problem, but give them some tools that they can use this off The problem And the absolute worst thing that a coach can ever do is to just say no, no, no, this is the way you you fix that kind of problem. I've seen this before because nobody learns from that. I remember in one engagement I was working with a team and it was a combine team and the whole organization is adopted. Conven and the one of very senior managers like like two steps above my boss was was ahh, hardcore con bun evangelist. And she came on a kn office visit once and she was looking at our con bun board. She said it like the team is breaking the whip limits. Why are they doing that? And I said, because they don't understand the value of whip limits And she said, Well, you need to make them understand And I said, I am I'm letting them break them And And she said, Well, this isn't a slow things down. I said, We'll slow things down a bit. Will cost some money, but I think it's it's it's money well spent because a team that that obeys whip limits because they're Scrum master tells them to needs a scrum master to tell them that every day. But a team that obeys whip limits because they understand the value of limiting work in progress and they understand the value of slack. And they understand that send the value of having a pool based system and they understand the value of maintaining a steady flow of work. That's
spk_0: 37:48
a
spk_1: 37:48
team that doesn't need me at all, and that should be the goal of every coach is to become a necessary
spk_0: 37:55
and if we can just go a little bit deeper into scram, Muster roll again, one of the first chapters in which was the finder. Scram! Muster roll. I found it extremely interesting because I haven't seen it in money organization, the scrum muster position in which the person is also helping HR two. Defining different job roles when they're not getting through the transformation. And they're like skirt product managers who are afraid like what will happen to them or when they just have to hire people to come along. So describe muster roll. It's actually liketo help hr in order to make it smooth toe. Also educate them a little bit about, like what sort of people they can take on board, or, like, how to help the people that are already in the organization. And they have toe transform, get through the change together with them or, for example, toe support finances to understand how the budgeting process impact on the teams that are building the product. Because I haven't seen that before. I haven't seen this crime master who is actually talking with finances Department and try to educate them and help them to understand that their decisions impact the tech team, that it's
spk_1: 39:16
working on the
spk_0: 39:17
product, that they makes money for the whole organization or even different to remove the invisible world between I T department and business. I haven't seen many scram Master who are actually doing that and I don't know if it's the problem with sort of organizations that I've seen or maybe like with the two small sample over organization that I worked with. But I was kind of shocked with those extra tasks and responsibilities. That's crime master should dough. I agree with them. I find them fabulous. I see how they can help team to work and PM power to deliver the product but haven't seen it in your life.
spk_1: 40:01
And I think the reason for that is that the scrum masters embedded in the team and so I think it's very common for a scrub master to see the team is the primary responsibility. They their job is helping the team to do scream as well as they can possibly do scrum rather than scrum masters, seeing themselves seeing their responsibility being to the organization and especially if you're going through some sort of a transformation. Like like a new scrum. Implementation in an organization hasn't used scrum. And this is what the authors mean when they say that if a scrum master really has the trust of the organization and the the empowerment to do their job to their fullest, you don't need an agile coach driving the transformation. The scrum masters will do that, but they need to feel like they're allowed to. Oh,
spk_0: 40:49
okay, yeah. And also in one part of the book, there was a short story about this crime master who said that he doesn't have anything to do, that he's kind of bored. And there was, like, this funny conversation. I don't remember if it was with Ryan or told when he started asking questions like I was your team doing Are they delivering something? And by having the conversation, he realized how white is the rent off his duties as a scram mastered he haven't seen before?
spk_1: 41:19
Indeed, if a scrum master should never be bored, there is plenty and plenty of work to do. So if you're a bored scream master, read this book, it'll give you tons of ideas on how you can. You can become even more powerful in your organization. Can I? You know I love this book, but I want I want to nit pick a little bit. There were there were three things that rubbed me the wrong way. Oh yeah, I
spk_0: 41:48
wish I would have drums to
spk_1: 41:51
sister. No, it it's this the 1st 1 in Easiest One is that in this book they say the same thing that so many of us have been saying for years and years and years, which is in the brief discussion on estimation. Ah, the the idea that the the reasons you do estimation as part of your backlog refinement and the reason to do estimation is part of your your sprint planning is that it facilitates an important conversation among the team. Were they that that the process of estimating is a very valuable way of clarifying the work and understanding it and making sure that it's it's adequately defined and such? And I myself said that we used to always in my last company, we always used to do planning poker, and I didn't have any faith in the numbers I haven't had faith in estimations for a very, very, very long time. But I did them for a long time before I stopped estimating, and my explanation was that which is that interesting things happen when the people who know the task best estimated as 3335 13. That person who said 13 knows something nobody else does, and that kicks off the conversation. But I think it's lazy. Uh, I think that if you're doing a practice that has an ulterior motive other than its primary motive, if you're estimating but the point of estimating is not an estimate, then there's got to be a better way of having that conversation, one that doesn't have all of the risks associated with producing an estimate, because once you've produced in estimate, people then start having expectations about it and you have to manage those expectations. So I I think it be hooves the community if they don't believe in the numbers and estimates to find better ways of having those conversations because that was the 1st 1 The 2nd 1 is I don't believe and I think this is a common problem that scrum teams face. I don't think they adequately cover the rial issues of dependency management that you have in large organizations any time you
spk_0: 44:13
mean what I
spk_1: 44:14
mean is that the example that they gave is they had a bunch of teams over each responsible for a different part of a product, and it wasn't working very well. So they let the team's self organize into cross functional teams and by allowing the teams to self organizing a cross functional teams, what emerged out of this was teams that were capable of fully delivering on an increment of work autonomously. And I don't buy it. I don't buy it. I don't believe that in any organization that has more than one team working on a product, you are ever going to achieve total autonomy within a team. Now, if the company is small enough, what's that? You've got three or four teams and they're all in the same development space, and they all know each other. Then they might have ways of dealing informally with dependencies like, uh, you know, nudging another person when you need a cross team code review or something like that, Slack gifts, Yeah, but I think I think it is is misleading to suggest that self organization and cross functional teams can solve dependency problems in an organization, especially when so many large organizations are using scrum. And so I think that is I'm glad that we started this whole podcast with closely upholds rethinking, agile because I think that is the best answer I've found so far. And it's it's very compatible a scrum, the whole idea of letting your yourself organizing teams self organized around whatever framework of practices they want. But then putting in place some sort of what close calls a flight level two, some sort of a framework in order to facilitate the right conversations with the right people at the right time about managing those dependencies that are going to exist between teams. Exactly. So that was the 2nd 1 The 3rd 1 this is this is touchy, and I could come across as ranting a bit here, and I haven't really fully got my my mind around this. But that is that in this book, combine gets a paragraph. I looked it up in the table of contents just to verify conman gets a paragraph, and the paragraph is something along the lines of Oh, And by the way, if you haven't considered looking at at how the combine method can help your scrum team, you might take a look at that scrum down. Or GE has put together this document and scrubbed out organs created this class and yet, at the same time, littered throughout this book, our practices that emerged from combat. So without any specific discussion of Con Bon at various places in this book you see things about flow, about pole, about limiting whip, about managing, aging, of of work items in progress, about measuring cycle time, about all of these things that that emerged out of the combine community. And it troubles me that in the very early days of Con Bond there was such animosity between the combine community and the scrum community, and it seems to me as if it's resolved itself with some sort of how do I put it? Scrum has adopted the scrum community has has adopted combine practices in their own way, but in a way that still keeps those two communities separate in the the convent for scrum teams that did the scrum I forget with the name of it is the, uh the convent for scrum guide. I don't believe that David Anderson's name is even mentioned. Nobody mentions the fact that the this scrum dot org's scrum come in for Scream teams. Class was developed by two people who were both key figures in the combine community. And that's okay, But But what worries me is the fact that you still have this conven community out there innovating and learning, and you've got the scrum community out there innovating and learning, and they could learn so much from each other. But if they don't even acknowledge this is not existence, But if they don't acknowledge the fact that they've been borrowing from each other and learning from each other and do it in a more transparent and open and respectful collaborative way, then it's limiting the possibilities for collaboration and for improving the community as a whole. And this book just does it again. It's it's full of con von stuff without giving credit to the ways in which those those ideas have filtered into the scrum community. And I wish I wish somebody could just bring people together. I wish we could all just be friends. Oh, so it's a fabulous book. Those are my are the three things that stood out as as kind of rubbing me the wrong way. But but the sum total of all of those things accounts for only about three paragraphs of a 260 something page book. And in general, if I can wrap the whole thing up, one of the things that I really, really loved about this book is it felt, and you see this sometimes in books in nonfiction books is they feel like a series of block posts. And that's because a common way of writing nonfiction books is to come up with a list of questions and then just just sit down and write 10 pages on each question or a series of chapters and just right 10 pages on each chapter in each of those is approached like a block post typewriting. But the thing about it that that I really liked about this one is how naturally and seamlessly they all float together. So if I could, at the risk of of making an analogy, it's almost a cz, though in the process of reading this book cover to cover your being delivered incremental pieces of value off of a very well ordered backlog. I don't know what process could possibly have produced such a book, but I hate you. It was it was a very, very comfortable and and and satisfying read with with Problem's solution problem solution, problem solution like a train. Chugga chugga. Interesting things. Satisfying conclusion. Interesting things. Satisfying conclusion ideas, ideas, ideas, ideas, ideas all the way to the end. And so I wanted to wrap up with something positive after those criticisms. This is a fabulous and useful book. That's really fun to read.
spk_0: 51:17
Yeah, I agree in 200%. And I would even add one more positive things to wrap up that, actually, very often in our podcast symptoms. I'm still having a hunger like Okay, that's amazing. But how do I do it like, you know, actually, please tell me because you know I never done it before. I would like to do that, but I have no idea how. And this book actually tells you everything. Maybe 90% some off the things you can figure out and just adjust to your environment. But he did really doesn't live you alone. This book, like made me feel like Wow, I'm not alone. There's like, so many body of knowledge that can, like, help me people who actually suffered from similar problems. We've seen similar situation, like already to share review. So yes. Do yourself a favor. Don't fight alone. You're not alone, outer. You're a scram, Mr Product. Under this plenty of books that can help you in fixing your scram is definitely one of them.
spk_1: 52:18
So favorite quotations there were There were some great one liners in this book, but well, what were yours?
spk_0: 52:23
Oh, yes. About figure quotations already had, like, the whole document for our social media Thanos to shirt looking through the next month. But one of my favorite waas scram is designed to keep failure small and manageable, making risk management build in feature off the framework. If your team can't talk about it, small failures openly. That increases the risk that big troubles are just around the corner. I don't know if I need to command of that. I think that is extremely clear, but just try to put it down. All the small flickers don't wait for the big fire in your organization. I think it's a healthy, healthy, healthy approach.
spk_1: 53:09
Absolutely. I like that one. I like some of those, some of the more clever turns of phrase. So, uh, one of my favorite quotations was the backlog of broken promises and crushed dreams where every story we promised to deliver but didn't goes to die from the chapter on backlog management, where amongst other things, they recommend throwing away everything that's over six months old. That's on your part of backlog. If it's important, it'll come back. But this idea that that every idea that has ever come up in history, every promise that's ever been made, every request that's ever been been ignored is somehow valuable needs to be held onto in the backlog of broken promises and crushed dreams.
spk_0: 53:49
Speaking about the clever expressing, I really loved the secret back look like you are afraid to delete your battle. You know, the items are there nine years old, so we just create like a secret. But no one will. Yeah, scene that we've been there. Okay, the last one. Scram. Want magically fix the issues it uncovers. But it does provide tools and techniques that, if it applied well, can lead to success very positive. Very true. Agreed. Okay. Okay. I have
spk_1: 54:25
a bunch of them, but you could just use these on for the social media. We don't have to go through all of these, but one of my favorites. One of my favorite. Probably. Yeah. One of my favorite sentences in the whole book that just jumped out at me. Was this one? No, that was a sentence. That was the context was in a in an unanswered question. Is it ever OK to deploy unfinished code? No, period. It is so rare to get a straight answer out of a coach.
spk_0: 54:59
You
spk_1: 55:00
know, the answer to every single question is always it depends. So it's so nice when when a coach is able to make a declarative statement that way, you know that when they're saying it depends, they really mean it. They they are capable of saying no. And and here is the proof too agile. Coaches wrote a book, answered an open question with No, no, no, no. And no period.
spk_0: 55:29
Okay, last last one from your pole.
spk_1: 55:32
Oh, I get one more. Okay. It's this one. I like this because I've said this myself. I have observed the same thing myself, which is that if you don't hear laughter in the development teams area every now and again, that's a sign that the Dev team is operating more like a golf team than a base basketball team. And and indeed, laughter is a very important sign When human beings collaborate, they have fun. Where they get nervous, they have stress, and they have to blow it off on one of the most common ways that people people express both relief and joy is laughter, and a group of people never laugh. They're not really working together,
spk_0: 56:12
so it moves like I'm a true team player. Okay, before we jump into the book that we're going to read for the next month, I think that we just have to explain our listeners why we were not reviewing today the book that we promised them tow way. We're going
spk_1: 56:33
to review um, thinking in bets. Yes, and the author of Thinking in Bets said that she would be delighted to talk to us, but she can't do it right now. And the former the podcast is that we review a book and then we interview the author and so far we haven't had to break that format are authors. We've always been able to schedule author interviews, and she's not not going to be available to talkto us until
spk_0: 56:56
Auguste is writing a new book, citing. Maybe we'll even get to in the price of one. So yeah,
spk_1: 57:02
so we'll be We will be reviewing thinking and bets, but But we'll be doing it in August
spk_0: 57:06
for summer. So what are we going to read this month? You know? I know, I know.
spk_1: 57:13
Uh, So I had said that that what I really wanted to do is give it, give out a little scrum bluff to our scrum friends and
spk_0: 57:21
not only scramble in Poland,
spk_1: 57:23
not only in Scrabble in Poland, but scrum friends worldwide, I think because I've been perceived for so long as being a con bond guy, people forget that the only reason that I ever took an interest in CONVEN was to solve some of these these scrum dysfunctions because I was and still am a hard core scrum guy. Ah, And so, after reading, reading this book and this is the first scrum book that I've read in, I I hate to say it but many, many years. I mean, uh I know, I know, I know. Um but But it's been a long time since I've really delved into new thinking. What? What? What people are currently thinking and talking about in scrubland. And I'd like to do it again and And a friend of ours, somebody that we've known for many, many years. Ah, frequent speaker at the AIDS conference has written a book now. She wrote it almost two years ago now, and I hate to say it. I'm sorry to say it if she ever listens this podcast Zoo zee, I'm so sorry I haven't read your book. I have it. I bought it. I felt it belies your friend of mine, writes a book. I'm gonna I'm gonna buy the book. Right. I have
spk_0: 58:41
a friend of your translator book. Will you also buy the book
spk_1: 58:44
that you translated? A pistol that's that's distributed for free. So yeah, I did. I downloaded your your translation of the conven condensed Guide. I haven't read it yet
spk_0: 58:59
in two years. It's not totally you know, I see people every day, but
spk_1: 59:04
I I do this, I do this. I have I've put in in a set of bookcases in my home in order to store all of the books that I've got, like a small set of reference books that I come back to again and again. But the majority of books on level case or books that I just really want to read and and I think that buying the book is 90% of reading it right, but it's not really it's nothing. It's nothing at all. I like what Marie Condo said. She said that the right time to read a book is when you get it, uh, and that if you've got a book that you've had for a long time and you haven't read that what you're really doing is you're keeping the rest of the world from being able to read it. You're denying other people the opportunity to enjoy that book. It's it's selfish to keep it to yourself. But for almost two years, the great schoolmaster Bye, Susie Salva Susannah's ova has been sitting on my bookcase and and sit no more. I'm dusting that thing off and I'm taking another another dive into scrum land. Will you join me?
spk_0: 1:0:09
Yes, I will do improve applause for you. Uh, okay, G, thank you. Thank
spk_1: 1:0:24
you for that. That's it for this review of fixing your scrum by Todd Miller and Ryan Ripley. We will be speaking with Ryan in a couple of days, and our interview with him is going to be out on the 15th of February. So stay tuned for that. Thank you so much for listening. If you enjoy this, tell your friends. Vote for it in your favorite podcast player.
spk_0: 1:0:45
Right? It's a review, right? A Subaru. You
spk_1: 1:0:48
know, we've only got one review on iTunes, lots and lots of people. Listen, I don't know how many thousands of listeners you need in order to get a written reveal. I used to think it was like two. For one, maybe. No, no, no, no, no. We've only got one written review in in iTunes. And I'd love to see more people's feedback on ideas. And it's really good for us. It's good for getting the word out. And it's good for reaching new people. So if you if you like this, let us No, let everyone know. We appreciate it. And thanks for joining
spk_0: 1:1:23
us. Thank you.
spk_1: 1:1:24
Bye bye.