In today’s episode of the Agile Coaches’ Corner podcast, Dan Neumann is joined by Ryan Ripley. Ryan is a Professional Scrum Trainer, the host of the Agile for Humans podcast, and the co-author of the new book, “Fixing Your Scrum: Practical Solutions to Common Scrum Problems.”
Together, Dan and Ryan dig into his new book to uncover some of the common Scrum problems that hold back teams, and what a Scrum Master can do to find them and help their teams get back on the path to delivery. “Fixing Your Scrum” is all about the steps you can take as a Scrum Master to transform your Scrum practices, bring life back to your Scrum events, and use Scrum as a competitive advantage for your organization.
Tune in to this episode to hear all of Ryan’s insights and highly practical (and actionable) tips regarding the Scrum Framework.
- What does “Fixing Your Scrum” set out to accomplish? What does it cover?
- Helps Scrum teams inspect and adapt the way they’re working and to discover ways that they can improve
- Aims to help Scrum teams solve common problems
- Focuses on practicality and actionable steps; it’s not another theoretical tome
- It’s not about defining agility but rather how to use the Scrum Framework to position your teams to have a shot at agility
- The book provides ideas and structures; it’s not super prescriptive (i.e. Ryan and Todd take a consulting approach rather than a “thou shalt do this…” approach)
- Aims to provoke discovery with suggestions
- It is aimed at the Scrum Master to hone their craft
- What is the 15% solution approach?
- The approach emphasizes not getting overwhelmed with the big things but rather to move the needle a little bit in the direction you want to go
- It’s about discovering what your next step is (that could lead to something impactful) instead of trying to plan out the next thousand steps which are going to change as you get feedback
- Diminishing the Scrum Master to an administrative role (they’re supposed to have an impact on the way that the teams are using Scrum and how the organization is using agility)
- A commitment to deliver on a specific set of product backlog items in a Sprint (there should be a Sprint goal that you hold sacred rather than a commitment to a bunch of backlog items)
- Change, change, change all at once (changes need time to bake in to ensure that they’re effective)
- Teams that are a group of loosely associated people rather than a truly collaborative group working together
- Important notes about the Product Owner role and the product backlog:
- There’s a misconception about the product backlog that it just needs to be posted somewhere to be transparent, but transparency means whole-team understanding (which requires refinement, continual collaboration and whole-team discussions)
- Go beyond visibility by making sure the product backlog is fully understood by the whole team (by continually refining, enhancing and sharing your understanding of the product)
- The product backlog should represent the future vision of the product
- Ruthlessly delete old/unnecessary product backlog items (product backlog items shouldn’t be treated like inventory so don’t be afraid to delete [if it’s a good idea it will come back])
- Shift the language around the product backlog—it’s more of a forecast, not a commitment
- The importance of implementing Scrum values:
- Scrum values change behavior
- Without them, every practice that “Fixing Your Scrum” recommends becomes rote
- By bringing Scrum values in, you’re honoring the human side of the work
- If you bring them forward correctly, it brings life to the framework
- When the values are present, agility becomes possible
Mentioned in this Episode
- Ryan Ripley’s Website
- Ryan Ripley’s LinkedIn
- Ryan Ripley’s Twitter
- “Fixing Your Scrum: Practical Solutions to Common Scrum Problems,” by Ryan Ripley and Todd Miller
- The Pragmatic Bookshelf
- Woody Zuill Quote
Ryan Ripley’s Book Pick:
Transcript [This transcript is auto-generated and not completely accurate in its depiction of the English language or rules of grammar]
Intro [00:03]: Welcome to Agile Coaches’ Corner by AgileThought, the podcast for practitioners and leaders seeking advice to refine the way they work and pave the path to better outcomes. Now here’s your host, coach and agile expert, Dan Neumann.
Dan Neumann [00:16]: Welcome to the agile coaches corner. I’m Dan Newman and I’m excited today to be joined by Ryan Ripley. He’s a Professional Scrum Trainer, the host of the agile for humans podcast and a coauthor along with Todd Miller of the book fixing your Scrum. And so thanks for joining this morning. Well morning for us. I don’t know when people are listening.
Ryan Ripley [00:37]: Yeah, it’s definitely morning for us and I think it snowed most of last night, but uh, but yeah, Dan, thanks for having me. This is uh, this is fun.
Dan Neumann [00:44]: Yeah, I’ve got the, I’ve got the space heater going cause it’s 20 something degrees in Indiana where we live. And uh, yeah, we’ve both got hooded sweatshirts I think and space heaters. I’m guessing.
Ryan Ripley [00:55]: We can’t complain though. This has been a super mild winter for, for Northern Indiana so far. Um, if it was once or twice, I mean we probably got away. Lucky.
Dan Neumann [01:04]: I love it. I love it. Well, Hey, let’s dig into your book a little bit. We were talking before we clicked record. Um, you’ve been talking about the book for a while. I’m sure you’ve spent a lot of time creating it with Todd, and so we’re going to kind of follow along the path as I started to consume the book and pull on some things that I thought were interesting. So first I was, I noticed that you are, the book is specifically about the Scrum framework, not agility in general.
Ryan Ripley [01:35]: Well, yes. I mean that’s a very fair point. So with the way that Todd and I look at it is if we can use the Scrum framework to opportunistically create products in the marketplace and stay tightly coupled to a customer and get great feedback and collaborate with our Product Owner and our stakeholders. And if all those things come together, we think agility is a byproduct. And so, yeah, we’re not specifically going into the manifesto and we’re not talking about business agility. What we’re trying to do is get Scrum teams to inspect and adapt the way that they’re working today. See if there’s ways that they can improve, um, or conversely if they’re stuck. Right. I mean, this book is really for Scrum Masters or Scrum teams who are stuck. Like they, they kind of sense that there’s an issue with one of their events. They’re kind of sensing there’s a problem with the way they’re fulfilling a role and they just want to flip to that event. They want to see what we think, what we’ve seen in the past 20 years and how we’ve addressed it. I mean, that’s also good for them, but, and it can, it can hopefully help them get through that. But yeah, it’s not specifically about defining agility and all that. It’s really, how do we use a framework to position our teams to have a shot at agility?
Dan Neumann [02:42]: Agreed. Yeah. Agility is part of it. I guess what I’m thinking of is I’ve read a 500 page books where I’m like, Oh dear God, I won’t get that part of my life back. And you guys focus right in on Scrum framework, really practical tips. And it’s, it’s highly actionable. So I think that’s what I like about it.
Ryan Ripley [02:59]: I appreciate that. I mean, when Todd and I set out two years ago to start on this thing, we, I mean we, we took a look at the book market and there are, there’s an endless supply of, well this is what Scrum is kind of books and there’s an endless supply of, you know, here’s the theory of, of how you use the framework. You know, go figure it out for yourself kind of books. And we decided if we’re actually gonna spend two years on a book, I mean, we didn’t know up front it would be two years, but if we’re going to put this time and effort in, um, let’s do something interesting, let’s do something different. And so we made it, we tried to make it actionable. You know, people read the chapter, you know, if you’re struggling with the daily Scrum, turn to the daily Scrum chapter we’ll lay down some theory for you. We’ll tell you some stories about how Todd and I have messed this up a thousand times. Um, and then at the end here, here’s exactly what we do when we go into a company and we see this problem, right? So we’re not holding anything back. Like we decided very, very early. We’re going to put everything that we try, every question that we ask, every technique that we, that we know, um, to help teams get better. And then we’re going to do a coach’s corner section, which takes that and turns it up to 11. It’s like, really do this first, like really, you know, go through this activity, go through this retro format, try this liberating structure, you know, whatever we thought was best for that, for that particular idea. And I mean, you know, hopefully at least one good idea is in there for every Scrum Master on the planet. Um, but we really tried to overemphasize the whole practicality rather than just yet another theory, theoretical tome on a, on a 20 year old framework.
Dan Neumann [04:34]: Yeah. I love the coaches corner chapter at the end. Although the irony today, I’m like, wait, you’re on a podcast about agile coaches corner and I love that there’s a coaches corner at the end of each of your chapters. So I would like the planets aligned to this morning for me as I was doing some final prep. So does it keep you awake at night that you’re putting coaches out of a job?
Ryan Ripley [04:53]: You know what, it’s a view towards the front of the book where there’s just a we got overwhelmed and humbled by just the number of praise quotes that ended up coming in for this book. And one of them was from a good friend of ours who was like, guys like he was in a, and we thought he was joking at first. He’s like, guys, you’re going to put some consultants out of business. You’re giving away too much. You really should shouldn’t be doing this. And we’re like, ha ha, very funny. And his face was like serious. I’m like, well wait a minute, are you serious? He’s like, yeah, like people, people make their money going in and solving the common problems for Scrum over and over and over. You’ve, you know, this will definitely impact people if they actually read the book. And we thought, well, there’s, I mean it’s, we, we weren’t thrilled that he was kinda mad at us. Like in all seriousness, he was kinda mad. But I mean, that’s probably one of the best compliments we could get for the book is that, you know, if we’ve cataloged the common problems correctly, if we provided actionable things that could actually, you know, help. Um, then Todd and I are happy because, I mean, selfishly, yeah, we’d like to see a lot of these problems go away so that the next time we go in and work with a company, the problems are more complex. Or maybe we can focus, focus on value or focus on, you know, product delivery or some of these better, bigger problems than, than the same anti-patterns repeated over and over and over and over for the past 20 years. So, yeah, it’s funny you mentioned that because it’s, we’ve had actually a number of um, a number of reviewers and a number of people now who have the book have just said, guys, you put a little too much in here.
Dan Neumann [06:23]: Oh, that’s interesting. So I was, it was a little tongue in cheek. Um, there is a lot in there and as I reflected on my, my smart Alec kind of question you, yeah, there’s a lot in there and it’s great. It’s questions that, you know, if I go in to do a Scrum training, I’ll hear the things, well what about the Product Owner and the Scrum Master combined? You’ve got that in there. What about, you know, the proxy Product Owner, you’ve got that in there. And what I like then is then you also introduce, Hey, here’s the liberating structure that you can use to address one of these challenges. Oh, that’s where now somebody can go pull on the third. What’s this liberating structure thing? What are all the other liberating structures? What’s a powerful question? What are other powerful questions? And so it raises the level of the conversation, like you were saying to what I would consider more consulting as opposed to straight up teaching the Scrum framework, the goods, the bads. And so, um, I love that it’s in there and yeah, I bet. I would think, um, it’s, I, I don’t recall the pricing on the book exactly. It’s on, um, pragmatic publisher.
Ryan Ripley [07:27]: Yeah. It’s pragprog.com it’s the, uh, the pragmatic bookshelf. So Andy Hunt and Dave Thomas’ publishing company. I think you can get the ebook for 24 bucks. I think if you go to Amazon, you can buy the, the hard or the paper bag for 40, I mean 40 bucks to solve one problem on your Scrum team, you know, we’re, we’re not working on the book so much. I mean, you don’t get rich selling books. What we’re trying to do is put some ideas out into the world that we think could help teams and, uh, if we’ve done that, no, we’re happy about it. It’s a, yeah. So far so good. We’ve, we’ve heard a lot of good feedback, but, uh, yeah, we just hope it, you know, if you’ve got problems out there with your Scrum teams, if you just sense something’s not quite right and we hope that, uh, that this could be useful.
Dan Neumann [08:12]: Yeah, for sure. Yeah. And I didn’t want to kind of go go into the value thing too much, but it’s like, yeah, one tip, one problem solved. You know, if, if the world only had too many good Scrum teams, that’d be a wonderful problem. So I’m glad you guys put that out there. Yeah. Um, something that stood out to me, one of the, one of the challenges I think folks get stuck in is trying to come up with the perfect structure for the Scrum team, the perfect agility, et cetera. And one of the things early on you guys talked about was an exercise. It was the 15% solution. So instead of trying to perfect everything that’s going on, you suggested a different approach. Maybe you could share that a little bit.
Ryan Ripley [08:54]: Well, I think this kind of refers back to what you noted earlier, that that we provide some ideas and some structures and some questions, but we’re not super prescriptive, which is kind of weird, right? So we’re, we’re trying to be, we tried to take a consulting approach rather than a, thou shalt do this approach. And you know, this is one of those examples like the 15% solution where, you know, I think so many teams and actually so many people like I get, I get overwhelmed. Like I just, because we teach this stuff doesn’t mean we get it right 100% of the time, you know, and uh, well and we get overwhelmed with these big things. And, and instead of getting overwhelmed with, with these big things, uh, the 15% solution is really about how do we move the needle a little bit in a direction that we think we want to go. And so that 15% solution, liberating structures all about discovering what is your next step that could lead to something impactful instead of trying to plan out the next thousand steps which are going to change as you get feedback anyways. And so we really tried throughout the entire book to make sure that whatever we’re suggesting, whether it’s a question of liberating structure, a new retro format, that it’s just trying to get teams to provoke questions or to do some discovery on your own. It’s like you said Dan, we, we mentioned liberating structures. We do not teach liberating structures. And we mentioned some of these facilitation techniques. This is a journey and, and I’m glad you pointed this out because the book is aimed at the Scrum Master and we take a very, I mean we’re, we’re kind of rough on them. We’re basically saying the anti-patterns in this book exists because you’re not doing your job and it’s a very hard stance. We’re basically saying, guys, it’s time to elevate our game as Scrum Masters and Todd and I are in the same boat. Like we are still learning as Scrum Masters. We’re still honing our craft. We’re still, you know, trying to make sure that we’re showing up when, when we do go into these engagements, you know, as the best possible form of ourselves. And we still get it wrong too. But, but these anti-patterns flow from a Scrum Master who has apathy, who’s not removing organizational impediments, who’s, who’s letting things go. And so we’re trying to give them, you know, it’s almost like a sense of awareness, a sense of we’re constantly learning a sense of, you know, we have to up our games and, and hopefully we’ve given enough information for people to go out to be curious, to leverage that curiosity and to really start learning these skills and practices that, uh, that are going to help them and their teams.
Dan Neumann [11:19]: I love the transparency that you folks have had about, you know, bad Scrum Master stuff that you’ve done. And I recognize myself in some of these, whether it was, you know, as a wet behind the ears Scrum Master who may or may not have insisted the people stand during the daily Scrum, you know, and, and that’s just probably the smallest of my many transgressions as I learned to be better at it and still lots of room to learn for sure.
Ryan Ripley [11:46]: Oh, I the, the book is full of stories where Todd and I have completely blown it where we have made some of the most boneheaded. Um, but we thought that was important too because if we just start preaching proper Scrum or if we’re trying to be holier than thou art or whatever, however we get labeled, that’s not effective. People get turned off by that. And so we, we decided very early on that yes, this is not going to just be a theoretical book. This is going to be a practical book. But we’re going to be transparent and honest about the fact that two people like Todd and I who have been doing thinking or performing Scrum in some form for the past 20 years still screw up and we want that human element to it, right? I mean, we don’t get it right all the time. Every story in there is a failure story of Todd and I as we, we just, yeah, I mean we’re, I’m going to go teach a class next week and I’m going to say something that’s not correct, that I’m going to have to go back and fix and, and that’s a part of life, but we’re trying to incrementally get better as we go and if that message got across and if Scrum Masters realize, Hey, we’re lifelong learners and there’s a lot of, a lot of these impediments are on us, then we are super happy with the outcome of the book.
Dan Neumann [12:54]: Yeah. I loved the one quote in there. What’s the, actually you can, uh, what’s the difference between a Scrum Master and a coach?
Ryan Ripley [13:00]: About $50 an hour? You know what, it’s, it’s a, it’s a, it’s a joke, but it’s not, and I think we’re pretty clear in that, um, that section too that an organization that’s utilizing Scrum really should not have an agile coach. Um, and, and what we’re, we’re not saying fire all of your agile coaches, so people please don’t freak out.
Dan Neumann [13:22]: And, and admittedly as a senior agile coach and my title it agile thought I, I would appreciate it if they didn’t fire all their agile coaches.
Ryan Ripley [13:30]: And we don’t know necessarily mean straight away, but we’re trying to make a very clean point that a Scrum Master fully empowered to perform the role as it was intended is also out coaching in the organization. Absolutely. If this is a Scrum shop, then it would make sense that your, your Scrum Master’s out doing that. Now, if you have, uh, an organization that’s investigating business agility, other frames, other frameworks and methods like Kanban, if they’re doing executive coaching. Agile coaches can make perfect sense. And so please don’t, don’t misinterpret and misread that as fire all the coaches. But what we’re trying to get at is the Scrum Master is a powerful role. It’s a very demanding and difficult role. And if you empower the people who are in that role to, to serve, to have all three levels of service to work in the organization with the dev team and the Product Owner, you might get better outcomes.
Dan Neumann [14:25]: Yeah, the Scrum Master anti-pattern of, and I don’t recall the exact wording there, but essentially the one who sends out the calendar invites to make sure the calendar invites are out or the administrator of the team, that’s often where I see things stop at times and then it’s like, well, we can rotate the Scrum Master also that further knee caps, the uh, the team’s agility.
Ryan Ripley [14:49]: It’s just such a bizarre such a bizarre thing to this role and diminish it to an administrative type of person. And there’s nothing wrong with administrative type people, but when it’s, when I think of a Scrum Master, I mean these are highly paid positions. These are supposed to have an impact on the way that the teams are using Scrum and impact on the way the business views agility. You know, I keep impact, impact, impact. Setting up a calendar invite is not impactful. I mean, it’s interesting when I, I think when Todd and I both do this, when we go into an organization and we’ll, we’ll still occasionally take on, um, you know, these short term Scrum Master gigs, mostly because we love it. You know, training pays the bills. But man, we just miss working with teams and so we’ll go do that from, from time to time. And uh, on day one, they usually set us up with a JIRA account or a Azure DevOps account or a Trek, whatever that the tool is, right? So no bashing tools here, but they’re all great as long as you’re using them to help people to collaborate. So no, no, no. Holy Wars there. But they set us up in the tool and then they tried to set us up in the product that’s being built. And, and by the end of that first day, we’ve both called the DevOps team and we’re like this, you know, deactivate both accounts. I do not need to log into a tool. I do not need to log into the app. As a Scrum Master, my jam is the framework, the team, the relationships with the Product Owner. I’m trying to figure out, you know, how do we amplify value? How do we have an excellent product backlog? How do we express value cleanly through ordering the product, all that stuff that, you know, agile product management that’s really big and difficult and daunting and helping there and what the rest of the organization, finance, legal, HR, security teams, we’re about to disrupt the way you work because as we move faster, we get value out sooner. I mean, whatever the new way of working with that leads to, we’re also kind of, we’re going to have friction with the boundaries of other orgs. And so I’m out there making friends and trying to get them on board and get them, you know, show them what’s coming and Hey, let’s, let’s invite the security team to sprint planning so we don’t blindside them towards the end of a sprint when we need some last minute review, right? Let’s, let’s start working in ways that you know what, in fact, let’s get a security person on our team so that we’re actually cross functional. You know, what could that look like? And so there’s all these things that that I could be doing as a Scrum Master that’s far more interesting and impactful then, well, I’m going to set up the calendar invite so I own all the events and I’m going to order all the food. You know what, your dev team can handle that. They can own it they’re a powerful self organizing unit. Calendar invites are within their scope of, of possible.
Dan Neumann [17:33]: Just recently. Maybe worked with my first admin assistant to a C level person at like at a, on an ongoing basis, over about three weeks. And at first I thought she was going to drive me crazy cause she was asking for details and I, I like to let things emerge and, and um, but I realized as we got talking and she said, you know, her job was to anticipate the needs of her, um, the C level person that she supported. And I think if, if even one thinks about the Scrum Master role that way, their job is to anticipate needs, remove impediments and allow things to flow through. So I thought that was a really, um, she’s a wonderful admin assistant that I thought was going to drive me bonkers at first and she said she only wanted to kill me once over that three weeks. So that wasn’t too bad. That’s not bad. You were talking about the Product Owner role or mentioned the product backlog in passing in your last, um, your last comments there. And one of the things you said that stood out to me in the book was about the backlog being transparent and that that wasn’t equal to visibility. It really meant making sure that the backlog was well understood. And that stood out to me. Can you maybe elaborate on that a little bit?
Ryan Ripley [18:45]: Yeah. So there, there’s this common myth that, Oh, we put the product backlog on the wall, or we’ve given everyone access to the product backlog in JIRA or which I, I don’t mean to pick on any tool, right. We can.
Dan Neumann [18:57]: I mean, that’s okay.
Ryan Ripley [18:58]: All right. All right. You can send all your comments to Dan on at firstname.lastname@example.org. Whichever tool you’re using. We’ll, we figured out how to make best for me, Dan, from an old school, I love three by five cards, painters, tape, post-its, sharpies, and let’s go build a board and make things transparent. But, but to your question, like the product backlog, there’s this horrible myth that, um, if we just post it somewhere, that means it’s transparent and transparency really is whole team understanding. And we get that through refinement. We get that through whole team discussions. We get this through, you know, uh, continued collaboration. And so just because you’ve posted it somewhere, you’ve got a product backlog available. That’s a good step one. Now does the total team understand the overall product division? They understand where this product’s going. Do they understand how a Product Owner is serving a customer through the ordering of the product backlog? You know, have they gone through refinement? Have they talked about these features in a way that they understand the outcome that the Product Owner is, they may not understand exactly how we’re going to do it or how they’re going to get it delivered, but they understand the impact or outcome that that a Product Owner is trying to have. Uh, and so we go through that and once we have those conversations and once we start doing a little bit of the work, you know Woody Zuill has one of the best quotes on the planet, you know, it is through doing the work that we learn about the work we need to do. And are we sharing those learnings every day? Um, are we, you know, are we in a daily Scrum tracking our progress towards our Sprint goal? Are we updating our, our product backlog and sprint review? Are we continually enhancing, refining and sharing our understanding of this product? That to me is transparency, not just putting something up on a wall. Does that make sense?
Dan Neumann [20:46]: It does make sense. So in it’s going beyond making sure that it’s visible, it’s making sure that it’s also understood.
Ryan Ripley [20:53]: That’s, yeah, visible is just step one. I mean a Product Owner has to show up with some kind of product backlog that they’re ready to, to refine and speak to and that it hopefully represents this future vision of our product. But man, that’s step one. Now we’ve got, you know, it’s a much bigger investment in whole team collaboration.
Dan Neumann [21:14]: And one of those places for that whole team to collaborate around. The product backlog that you talk about was in the backlog. Chapter five is about backlog, if I recall right. And it was about ruthlessly deleting things from the product backlog. There’s an activity to essentially go through and figure out what, what must be in the product to release it and then verifying that with your team and if you find something to pull out, get rid of it.
Ryan Ripley [21:41]: Well, I, so I do this keynote and uh, it’s a fun keynote. I go to these Scrum conferences and I’ll ask a question. I’m all right. Everybody put your hand up if you have a product backlog. And so at a Scrum conference, that’s really, that’s a bizarre, it’s a, it’s a silly question that people laugh and they put their hand up. All right, cool. So keep your hand up. If you have a product backlog item that’s older than a month, I’m like, Oh, of course we do. Ha ha. And the hands stay up three months, six months, a year, and then, you know, everyone gets serious. They’re like, Oh, he’s not going to stop counting until the hands are all down the record’s nine years.
Dan Neumann [22:15]: Impressive.
Ryan Ripley [22:17]: I mean, it was, I was stunned. Usually it gets to three or four years and people kind of tap out and we move on. Right. I was stunned. This guy had his hand up for a nine year old, nine year old PBI. And I’m like, you know what, let’s bring up the lights, get him a mic, let’s find out what this, and we get a microphone to him and he’s excited. Like he’s won something. And I’m like, no, no, no, there’s no prize here. We’re going to figure out what’s nine years old cause I’ve never, I mean two or three years is the previous winner here. And it turned out it was a financial industry, um, a main frame change that they were still planning on doing nine years later. And he was adamant that no, we have to do this change. And finally I said, sir, it’s been nine years and you’re still fine. And he was like, Oh, it was like a little light bulb. And that one’s definitely prime for deletion. But I think we, we treat these product backlogs like inventory. Like we’re just going to store every, every idea possible. And when you look at these sprawling product backlogs with a thousand items on them, how could we possibly understand the vision of a product with a thousand product backlog items on it. How could we possibly know upfront that we’re going to do a thousand things? Like if we’re doing our sprint review correctly, we’re going to get amazing feedback from our customers, stakeholders, users about the new needs that they have because the market’s changed. The world is complex, things are dynamic, change is constant, and so we’re going to learn better and newer ideas. Every single sprint. Those ideas are going to push down all of that upfront stuff that we thought we needed, like how could we ever possibly wrap the cognitive load? Just keep that straight in your head is just insane and so you know, we go through this activity as you mentioned then let’s get it down to six months worth of stuff, maybe three months. If you really want to go work, go crazy. Give your dev team some space. Like Dan, if I gave you a thousand tasks that you had to finish over the course of two years, there’s no light at the end of that tunnel. That’s you just turn it. What really gets crazy is these teams turn into backlog lumberjacks, they just start chopping. That’s Shaw’s comment or quote about about feature factory teams and there’s chop through this work. Never understanding why they’re doing it, not connected to a customer, not sure if it’s aligned with the business or market need and we just get teams lost and yeah, keep those product backlogs. I love the word delete. I love the word delete. I love a Product Owner who’s willing to say, you know what? I thought this was a clever idea. We got some market feedback. It turns out we’re not going to build this feature. Let’s get it off of here. Let’s not talk about it anymore. And the worst thing, Dan, the worst thing that’s going to happen, right? If that idea really was good, the worst case scenario here it comes back, right? You’re going to hear about it again and go, Oh, that was not a good deletion. I’m glad it’s back. Let’s go execute now.
Dan Neumann [24:59]: I love it and you’re right. If it’s a good idea, it’ll come back. And the backlog, often it’s described as the requirements for the system. I think that’s where some of this hoarding takes place. It’s because we’re, I think teams are used to a business requirements document that’s long and you’re done when you check all the boxes. And so when the backlog’s talked about as the requirements for the system, I think it, it really becomes that that laundry list of things or the forest of trees that have to be chopped down or inventory to turn out. I think that’s a a dangerous model. I just, it seems like it’s ingrained in the way the backlog gets talked about.
Ryan Ripley [25:39]: So let’s just shift the language a little bit. Let’s just say it’s a forecast of things that we think we need to do in order to meet our product vision and the goals that we have around the investments we’re making for this product. And just like any other forecast, it will change, right? So last night I was watching the or earlier yesterday watching the weather. Cause I, you know, I’m curious about what’s going to happen here cause I might have to travel some time this week. Actually I will have, we travel all the time, don’t we?
Dan Neumann [26:06]: Well there’s not really public transportation where we are. So yeah.
Ryan Ripley [26:11]: Well flights are tricky with a lot of snow. And so I’m watching the weather and it turns out, you know, the original forecast for this, uh, snow storm that came through that’s going to end here in a few hours is three to six inches of snow. I look outside, there’s about an inch or two on the ground here. They were a little bit off. It was a forecast. Right? And so just like the weather, our product backlogs are a forecast of what we believe we need to have, what we believe we could do to meet our product vision and the goals. Uh, our sprint backlog is a of what we think we’re going to do in a sprint, not a commitment, you know, shifting the language a bit, I think impacts the behavior around these things.
Dan Neumann [26:51]: Absolutely. And that commitment to deliver a certain specific set of product backlog items in a sprint, uh, is one of the anti-patterns you’d pointed out. And I’ve been guilty of that one. Um, you know, go back to 2000, whatever nine when I got introduced to Scrum, right? It was like, okay, we bring in some product backlog items. Okay, team, are we committing to this? And then, Oh my God, you didn’t get those done like bad team.
Ryan Ripley [27:15]: We, we’ve all done it and we’ve all made that mistake around commitment. We’ve all, yeah, I’m sure we’ve got a story. I know we’ve got a story in the book where we, um, we took commitment too far and we had to ratchet that back and figure out what’s the next best thing to do for teams. And you know, we live and learn, man. And that’s the, that’s why we, that’s why Ken and Jeff brilliantly put the retrospective at the end of every sprint. You know, what did we learn here? What are we going to do better? What can we try next? And the learning is continuous and we’re always getting better. I will go off and work with a company next week on Scrum and I will say something that’s not quite right and we’re going to have to figure that out and, or I’ll do something completely stupid. Like I, I still to this day, Dan, I go into companies and every once in awhile I’ll be the bull in the China shop where I’m just gotta do this and change that and I just go nuts and I’m like, I’ll get in my car and I’m like, dummy, you just freaked everybody out. You’re going to have to go back tomorrow and apologize and slow down. And, and I go and you’d always, you do that and you’d go back and say, everybody, I’m sorry I got way ahead of ourselves or at way ahead of myself. Why don’t we just try this one thing? And everyone’s like, Ooh, thank goodness he’s not crazy and we move on. But we still, I mean, we all still do that, right?
Dan Neumann [28:32]: Definitely. And, and that’s where shifting the conversation to things like a forecast or for sprint planning to have a sprint goal that you hold sacred as opposed to a commitment to a bunch of backlog items. Uh, and then retrospecting for what does or doesn’t work. Um, one of the things, I don’t know if you’ve encountered this is just feeling like you have to “do” things. So like you said, the bull in the China shop, you know, change, change, change. Well, I, you know, sometimes people who are working with coaches externally or even internally, they want lots of changes. They want to see activity, they want to see things happening and sometimes those changes just need time to bake in and make sure that we’re going to get the actual result we intended to.
Ryan Ripley [29:16]: Yeah. I’m not a big fan of, of multiple changes in, in flight at once. I mean, most of the places that that Todd and I have visited the, their first impulse is to use waterfall to implement agile. And I’ve never, I mean, if they’re, they’re paying us a lot of money to do classes, to teach them not to do waterfall yet we’re going to use waterfall for our agile implementation. Yes, it’s so bizarre. But let’s use Scrum to implement Scrum. Right? Let’s say that we don’t win when a developer says done and when a product person says done, it means two different things. Cool. So let’s just create a definition of done that’s, that’s wholly understood and accepted organizationally and let’s just do that for a few months. Let’s see if we can actually deliver a done increment. If we can’t, Hey, maybe a daily Scrum would help us actually gauge our progress towards getting to that done increment. Let’s pick that tool up for the next few months and, but then let’s get really good at it and make sure it’s not a status report and make sure that we’re practicing self organization and getting all those benefits and a few months later, Hey, you know what, a cleaner sprint planning with some refinement could be useful. Let’s learn that. And over the course of a year or two, let’s really understand the why behind the framework, let’s understand, you know, the benefits, the impacts of doing these things. And let’s really team level up because guess what? Teamwork is a skill, right? And most teams today don’t work together. They are loosely associated group of people who take their work to their note, to their own corners. They come back close to the end of a sprint, pray it all integrates and they try to release, right? Let’s actually learn, like if we have nine people on a team, let’s only pull three or four pieces of work in and let’s really get collaborative. Let’s work together. Let’s learn how to do that. Let’s learn how to deliver and deploy and get product out together. And that takes time as well. And so enjoy that process, enjoy that ride. It’s, it’s, it’s a, it’s a journey of exploration. It’s a journey of introspection. It’s a journey of, of discovery. And it is so much fun if you allow it to unfold like that.
Dan Neumann [31:13]: Man, I’m, I’m inspired now. I want to go do something. Um, but before we do that, that’s all right. We’re done now. But I do want to end on one other observation on the book and that is the Scrum values make repeated occurrences through there. And I think that’s a really important point and we’d love you to amplify that.
Ryan Ripley [31:36]: Yeah. So it’s actually rare to crack open a Scrum book and actually see someone amplify the values. And again, this was one of those early discussions about how there’s no need for an intro to Scrum book on the market. There’s no need, right? So there, Ken and Jeff have written plenty of intro to Scrum books. Um, we’re good there. But who’s actually, who’s actually explained how the Scrum values change behavior now, who’s actually gone in, in depth on the practical side of using the framework, but how the Scrum values without them, every practice that we recommend becomes rote. You know, every practice that we recommend becomes mechanical. But if you bring those values back in, you’re honoring the human side of the work. You know, you’re, you’re showing, you’re giving almost a mini framework of behavior that people can rely on. You know, focus, openness, commitment, courage and respect. If you, if we bring those forward correctly. Um, I think great things happen with teams, with people, with interactions. Um, it just brings life to this framework that that far too often is interpreted in a legalistic way that’s done mechanically. Um, the liberator’s. So Barry and Chris over in the Netherlands, they call it zombie Scrum. I totally agree. Zombies just, you know, it’s action, it’s movement, they eat the occasional brain, there’s no values there, there’s no system of, of behavior there. It’s just automatic, um, primal type of type of motivations. And it’s, these values are so important and we just, we decided early that the values will be at the center of the book and this Scrum Master, especially if they live the values, if they actually show those behaviors and actions, they can be inspirational to their teams. They can show teams how to just show up a little better. And I think when that happens, when the values are present, I think really good work and, and honestly, agility, uh, become possible.
Dan Neumann [33:26]: For sure. No thank you to you and Todd for the contribution to the community through the book. Sure. Fantastic. Thanks for joining me to talk about it today.
Ryan Ripley [33:36]: Hey, anytime buddy. I’m happy to do this. It’s uh, it’s always nice. It’s, it’s, it’s great to get to chat with another Hoosier.
Dan Neumann [33:45]: I’m more of a Michigan guy, not the university, the state.
Ryan Ripley [33:49]: All right.
Dan Neumann [33:49]: Yeah, I’m a Michigan state guy. Actually got my Spartans sweatshirt on here this morning. Great for podcasting. I, if somebody just clicked hang up on the podcast, if they were a Michigan fan and hopefully I’ll get more Spartans joining.
Ryan Ripley [34:03]: I’m a Purdue guy, but respect. We’re good.
Dan Neumann [34:07]: Hey. Um, I am sure you are also bringing in new thoughts into your head. What’s, uh, what books are you reading as part of or book are you reading as part of your continuous learning journey?
Ryan Ripley [34:19]: You know, I, I read just a bizarre array of books. Um, right now I’m reading Only Joking by Jimmy Carr. So Jimmy Carter is a British comedian and he actually wrote this book with Lucy Grieves about the science of laughter and white jokes work. And, and I, and I’m just fascinated by language and I, and I love the, the one liner and the ability to, to surprise people with a twist of a phrase. And, and so it’s just a, it’s been a really fun read. Um, and so this is one of those kinds of bizarre books you wouldn’t expect. Um, but I really like it. So I, I mean if people are interested in language, if they like the idea of, of why jokes work and, and things like that, Only Joking by Jimmy Carr is a what’s on my desk right now.
Dan Neumann [35:01]: Outstanding. Yeah. And really thinking about how the brain works, how people works is a really critical skill for folks that are, you know, working with other humans, especially when it comes to trying to change behaviors.
Ryan Ripley [35:14]: Well, I think about what we do is for a living, Dan, like we are paid to talk, like my kids ask me all the time, daddy, what do you do when you go to work? And honestly, it’s talk and it’s talk, talk. Some would say talk too much. Um, but if, so, I think it, when we’re in that space and we’re, we’re technically performers, well we’re doing a training class. It’s a two day performance of material that we have hopefully earned the to say that we’ve done that. We understand at a very high level, um, understanding how your language impacts people is really important. Right? I think, um, languages, I mean it’s how we share ideas. And so if I can use language in a way that keeps people entertained but also educated, if I can use language to elevate people and not put them down, um, I think that’s a, that’s a worthwhile investment.
Dan Neumann [35:59]: Outstanding. Well, I am glad for the contribution and the continuous learning and thank you for joining.
Ryan Ripley [36:06]: Hey, thank you for, for having, uh, having me. This as a, like I said, it’s just a great opportunity to share these ideas and I hope people get value out of the book. Um, if you, if you get the book, you know, it’s on Amazon, it’s at pragprog. Um, send me a tweet @RyanRipley. Let me know what you think of the book. You know, Todd and I, you know, we’re, we’re Scrum guys at heart and so we’ve put an increment of product out into the world and now we’re trying to see what the feedback is. Do people like it? Is it useful? Have we helped a team do something different? And, uh, we would love to hear those stories if you have them.
Dan Neumann [36:38]: Love it. And we’ll be sure to put the links to all those places in the show notes.
Ryan Ripley [36:43]: Cool. Thanks man.
Dan Neumann [36:43]: Hey, thank you Ryan.
Outro [36:46]: This has been the Agile Coaches’ Corner podcast brought to you by AgileThought. The views, opinions, and information expressed in this podcast are solely those of the hosts and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.