In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is shaking things up. He’ll be answering some of the frequently asked questions that often come up in his work, as well as some miscellaneous questions on Quora on the themes of agile and Scrum.
In his coaching, Dan often finds that there are a lot of misconceptions, questions or themes that continuously come up. Throughout this podcast, he’s hoping that the selected questions today will add some value to your own practice. Some of the questions include: “What resources would be good reading for an agile Scrum Master,” “What is a road map in agile,” “In practice, does waterfall planning ever accurately predict (or guarantee) completion dates for tasks and projects,” and more.
Intro: [00:03] Welcome to the 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 this episode of the Agile Coaches’ Corner. I am your host Dan Neumann and I appreciate that you’re taking some time out of your day to listen. Typically I have a co collaborator who joins me for these episodes and today we’re doing something a little bit different. What I’ll be doing today is taking some of the questions that have been posed either to me as I go through the course of my work or in a lot of cases those questions that have come up on Quora that I thought would be worth addressing as part of this podcast. As part of the coaching, I find that a lot of times there are either common misconceptions or questions or themes that keep recurring and so I’m hoping that the ones I’ve selected from here will add some value for you. So these are going to be agile and or Scrum related questions.
Dan Neumann: [01:09] So kicking it off, there’s a question that Alex Shaw posted on Quora, this is what resources would be good reading for an agile Scrum Master? So I’m going to start with some of my favorite books. The first book that I ever read as an agile coach. Well I wasn’t an agile coach at that point? I was a Scrum Master. Let’s face it. The big boss said, Hey, we’re going to go do this agile thing and we’re going to be following a Scrum Framework and two weeks sprints. And honestly that was about the end of our training. So in the spirit of self study, I went and got the book called, Agile Project Management with Scrum by Ken Schwaber. And for me, I picked that up back in about 2006, so it’s not a new book per se, but the lessons in there are still valuable. It’s a fairly thin book. It’s a pretty quick read. It has a lot of anecdotes in it about experiences with Scrum on agile project. And so for me as a brand new practitioner of Scrum where there wasn’t any formal training at all, I just found that agile project management with Scrum was a really approachable book. So go ahead, pick that up. Try to understand, especially as you’re shifting from maybe a traditional project management waterfall predictive method to an iterative method with Scrum that’s embracing agile values and principles. Go check that one out.
Dan Neumann: [02:46] The second book I would recommend, which really isn’t a book per se, but I would just really say anything that Mike Cohn has written, you should read that. For me, he communicates very clearly, he has a lot of common sense in the way he communicates. So whether it’s the mountain goat software blog or traditional print books like agile estimating and planning, I would say go pick those up and consume them. He has lots of wisdom in those books and it’s very approachable. It’s not overly sophisticated writing and just wonderful stuff. And when I went to get my certified Scrum Master Training, Mike was the person who delivered that training and I don’t know, for me that was just one of the first agile professionals I interacted with and I found tremendous value in those. So writings by Mike Cohn, especially agile estimating and planning really good stuff. And then Mike collaborated really closely with Kenny Rubin on a lot of things and Kenny Rubin has published a book called essential Scrum, which is also a good read. Lots of practical tips, nice diagrams in there. Go ahead and pick that one up too. If you do read all those books, you’re going to be reading for awhile. That’s okay. I’d be remiss if I didn’t suggest of course, that you listen to this podcast for suggestions about agile and Scrum. If you have questions that you’re specifically interested in, go ahead and tweet them to us with the #AgileThoughtPodcast or email it to us with firstname.lastname@example.org and we’ll see if we can’t work them into a show. The last thing I think is really important is, you know, you ask what resources are good reading for a Scrum Master? I would say whatever reading is going to help you address challenges that your team is having. If you’ve got a team that’s struggling with conflict management or is struggling with conflict, go pick up a book on conflict management. There’s a book called the five dysfunctions of the team, which was then followed up by overcoming the five dysfunctions of the team and the second book that overcoming one gives a lot of practical tips on how you might go about approaching the dysfunctions of a team. If you’re really interested in building your skills as a coach and it really taking more of a coaching stance. The book by Lisa Adkins on coaching agile teams is a fantastic read.
Dan Neumann: [05:27] What are the opportunities for Scrum Masters to really help their teams is in facilitating effective retrospectives. Esther Derby and Diana Larson wrote a book called agile retrospectives making good teams great, and in there they have a nice five-step framework that we’ve talked about in a previous podcast. So if you want to, you can go back and listen to that, and then really applying that framework and seeking out some innovative ways to approach retrospectives. What you don’t want to do is have your team get really bored with good, bad, do different or some kind of other recurring theme that gets really kind of stale and teams get tired of following it. So what you want to do is take different perspectives on it, take different approaches, and really give people something that energizes their brain and so that they really start interacting with the retrospective. It’s a fantastic opportunity for continuous improvement and I think just a huge opportunity for Scrum Masters to really add tremendous value is by facilitating really good retrospectives. And Esther and Diana did a great job of building on the work of some of the folks that came before them and really turning it into something that applies well within the Scrum Framework. So I have that as kind of a must read in one of those touchstone books. So whatever you do as a Scrum Master, just keep learning. There are some tips that other people will give you and yep, that’s fantastic. Hopefully some of the ones that I’ve provided to you here are valuable, but really just whatever is pulling your passion, whether it is something along the lines of, of conflict resolution or whether it’s in road mapping for products or whether it’s within leadership or how incentives are helpful or harmful to teams. Just really embrace a continuous learning mindset and you’ll do fine as a Scrum Master.
Dan Neumann: [07:32] While we’re on the topic of Scrum, let’s talk about the Product Owner role. There was a question that was posed, can a Product Owner change a sprint backlog any day? So I think there’s, there’s a lot behind that and it’s a little tough to get to the specific context of that question. It was asked by Mohammad and the Product Owners role is to optimize the product backlog for value. And so the Product Owner is really thinking about who the stakeholders are, who the customers are, and are responsible for that product backlog being effectively ordered to optimize value that the Scrum team’s going to deliver. And then every sprint starts off with the Scrum team and the Product Owner and the Scrum Master participating in the sprint planning event and so in sprint planning the team is collaborating with the Product Owner. They are figuring out which parts of the product backlog they want to include in the sprint scope to help deliver on a sprint goal that’s been identified and as part of that sprint planning they are creating a sprint backlog which often looks like the product backlog items and some of the activities that are needed to deliver those product backlog items and so a lot of tools have captured this essence and they will have things like stories in the product backlog and the team will plan a story and identify the tasks that are going to be needed to deliver on that product backlog item. Of course, some of those are just generally accepted Scrum practices and really Scrum says, hey, you have a product backlog, you’re planning an increment in sprint planning. You want to achieve a sprint goal and do enough planning that you have confidence that you’re going to be able to deliver on that sprint goal. Really establishing a forecast. So the sprint backlog is that collection of product backlog items and activities to deliver on that. The sprint backlog is the domain of the development team in Scrum and so the Product Owner hopefully is participating during the sprint in terms of clarifying acceptance criteria. They’re answering questions that the Scrum team has, they’re inspecting the increment as it’s being delivered throughout the sprint, but really the activities to deliver on the sprint goal are the domain of the development team and I would not expect a Product Owner to be changing the sprint backlog day in and day out or on particular days within the sprint. I think this might be an interesting question for some of the Scrum trainers that we have in our organization to weigh in on with further, further comments, but really the Product Owner’s role is in the product backlog and to accept items as they are being delivered in the sprint and to clarify questions and to really make sure that sprint goal is achieved and yes, I would be amazed if the sprint backlog doesn’t change throughout the sprint, but that would really be done in collaboration with the Scrum team. Always keeping the sprint goal in mind.
Dan Neumann: [11:16] For those of you that are listening and are maybe curious to see a write up of these questions, what we’re going to do is post links to the original questions as part of the show notes. You can find those at agilethought.com/podcast and we will also put a transcript of this answer into those questions as well as on our website so you can follow the links and see where the original questions came from and perhaps see what conversations were started based on them. There’s a question by somebody named Maxim and the question was what is a roadmap in agile? For me this gets me to thinking about agile versus other methods, and a roadmap is really just a plan for how to get from one point to another. You know, I can think of when I was much younger, people in the car had a physical Atlas and it showed the different paths and if you are driving from Michigan to Florida, you would take a look at that and you would say, okay, we’re going to kind of generally follow interstate 75 and we’re going to go down South through Toledo and then eventually through Atlanta and on your way down to to Florida. And so you’d have a general feel for how you’re going to get from point A to point B. The difference in my mind between waterfall and agile approaches is in waterfall, we would pretend that we knew exactly how we were going to get from point A to point B and we knew exactly when or we pretended to know exactly when we would arrive at different points along the way. And in a waterfall world or a predictive or a plan driven approach, I think those are all synonymous. We would really be upset and struggle with any change to the plan. So if we weren’t where we thought we were going to be 10 hours into the drive, there is some kind of replanning event and it was heavy weights and people were kind of berated for being off track. Agile methods are those that are aligned with the four values and the 12 principles as identified in the Agile Manifesto. And so part of that mindset or that approach is really realizing that we’re not able to predict the future to a high degree of certainty, very specifically, and that we need to respond to change. So as you’re going down the road, metaphorically, you may encounter roadblocks that slow you down, you may have unplanned stops, maybe you find some kind of cool roadside attraction and you decide to stop there and invest some time and energy in that as opposed to continuing down the plan that you had initially laid out. So we still have roadmaps in agile. And for me the biggest shift in mindset is really acknowledging that there’s a lot of uncertainty in creating software. We’re doing things hopefully that have never been done before. If we’re reinventing the wheel, we’re wasting time. So in instances where you can buy a solution, you should do that. But if we are creating a solution, we’re doing something that hasn’t been done before and there’s a lot of uncertainty in that. We’re trying new technologies, we’re seeing how users react to different features that we build in different ways we present it to them. And that creates a lot of uncertainty, so realize that our roadmap agile is going to have some uncertainty in it. We should be talking about the destination in terms of ranges, so that might be the range of dates when we’re going to achieve our goal or that can be a range of capabilities that we expect to have by a particular date. In highly predictive approaches. We had a very specific plan with a single number for the budget. We had a single date in mind and we had a very fixed set of capabilities and as we think about agile roadmaps or roadmaps that are applicable in this state of high uncertainty, if we can start thinking in ranges, that will go a long ways towards having a really accurate forecast and by accurate, accurate within a range. You know we’re going to be delivering in the month of November, not November 15th at noon, and we’re going to be delivering these capabilities. And the degree to which those are more or less sophisticated implementations may vary. But at least we’re then starting to talk about things that we’re confident in. Like we’re confident we will deliver in November or we’re confident we’ll deliver this capability. It might not be as fast as we initially hoped, but it’s going to be fast enough to be accep table. And so again, thinking in ranges with roadmaps in agile.
Dan Neumann: [16:20] So the last piece I want to touch on as part of this episode is a question that was posed by Allen and it says in practice, does waterfall planning ever accurately predict or guarantee completion dates for tasks or projects? Oh, that’s a loaded question. Does waterfall ever accurately predict? Well, I’m just gonna go out there and because there’s such a definitive, does it ever, I’m going to say yes. There are times when waterfall or highly predictive planning can accurately predict completion dates for tasks or projects. The scenarios are the conditions under which that happens tend to be those that have a high degree of certainty about the capabilities that are needed. And there’s a lot of certainty about the technology that’s used and the people who are going to do it. And often it’s something that we’ve done a number of times before. So if you have a team that’s done a particular type of development before with technology that they’re using again and really well understood requirements. And also typically these are smaller projects. Waterfall can accurately predict dates for tasks and projects. The problem is that as there’s more uncertainty around the technology as there’s less certainty around exactly what the customers want and as there’s less certainty about the team, the individuals as groups of people involved get larger and larger, that’s where waterfall planning breaks down and that’s where an inspect and adapt mindset, that’s where feedback loops, that’s where embracing the fact that change will happen becomes much more valuable in methods that are agile. So that’s where Scrum can be super valuable with iterative feedback loops. That’s where in extreme programming, that onsite customer really engaging with the development team to give that feedback, that’s where those things become super valuable. And so yes, a waterfall can work and it’s under these more obvious conditions where we have a lot of certainty, but when we start to move away from those, that’s where agile methods with their feedback loops, responding to change, collaborating with customers and inspecting and adapting and continuously improving. That’s where you get tremendous value out of those efforts. So I hope that’s helpful. I thought we’d take some time and just answer some of those questions that are pretty common and we just happened to come across them in Quora here. If you have a question that you’re interested in, please do email that to us at email@example.com or tweet it with the #AgileThoughtPodcast. And now we get to the part of the podcast where I typically ask the collaborator that I have what they’re reading and what’s really got them inspired. Since it’s just me, you get to hear what I’ve been reading. I’m on a little bit of a Kanban bent these days and really trying to grow along that edge and get a little more precise in the way that I talk about Kanban and the two books that I’m currently consuming that are helping me along that path are Essential Kanban Condensed by David Anderson and Andy Carmichael. It weighs in at a Oh under a hundred printed pages and is available as a free PDF for those who want to go get the free version. It’s just a few bucks. If you want to get the print version, which is handy if you’re, you know, inclined to mark it up with a pen and a highlighter and those types of things like I am, um, it doesn’t have a lot of elaboration. You know, it’s not one of those 500 pages of your life, you’ll never get back kind of books, but it’s super precise in the way that it talks about Kanban, both in principle and in practice. And uh, that’s been one of the things that’s kept me learning lately. And then Dominica Degrandis’ book on exposing time theft to optimize work. And flow. Again, that’s also not a particularly thick book. It’s just a little under 200 pages and she goes through and talks about the time thieves, so she has a metaphor that she, she follows in there and how to expose the loss of effectiveness and the loss of time by using Kanban methods. So a couple of things on Kanban there and I’ve got some other little bits that I’m picking up around Kanban. Again, to try and sharpen the way that I talk about that method and that is what I’m reading and would highly encourage you if you’re interested in Kanban, go ahead and pick those couple books up and see if you don’t learn a few things. Until next time, thanks for listening.
Outro: [21:11] 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 for this episode and other firstname.lastname@example.org/podcast.
Contact us to share the challenges you’re facing and learn more about the solutions we offer to help you achieve your goals. Our job is to solve your problems with expertly crafted software solutions and real world training.
For a better experience on the web, please upgrade to a modern browser.