In today’s Agile Coaches’ Corner podcast episode, host Dan Neumann is joined by Sam Falco once again! Sam is Dan’s colleague at AgileThought and is an agile coach and Certified Scrum Professional with an extensive background leading agile development teams.
In a previous episode, Sam and Dan discussed games and why Scrum works for people from a gaming-standpoint and helps drive engagement. In this episode, they’re discussing empirical process control and how it makes Scrum work from a getting-things-done standpoint.
Sam shares some of the lessons he has learned as a Scrum master (both early and later in his career) and gives examples from his work. He also explains the benefits of empirical process control; how transparency is built; how Scrum events support transparency, inspection, and adaptation; and how to inspect and adapt in meaningful, healthy ways.
Like what you heard? Check out our podcast page for more episodes full of interesting discussions, agile insights, and helpful resources.
Intro: [00:03] Welcome to Agile Coaches’ Corner by AgileThoughts, the podcast, the practitioners and leaders seeking advice to refine the way they work and they have the past to better outcomes. Now here’s your host, coach and agile experts. Dan Neumann.
Dan Neumann: [00:16] Welcome to this episode of Agile coaches corner. I’m your host Dan Neumann, and I’m excited today to be joined by Sam Falco, a colleague of mine here at AgileThought.
Sam Falco: [00:26] Hey Dan. A long time. No see.
Dan Neumann: [00:28] Indeed before we get into a discussion of Scrum and empirical process control, just the official reminder, the opinions here are mine and Sam’s and not necessarily those of AgileThought, other people or other organizations. So now we’ve got that and if you have a topic you’d like us to discuss, you can tweet it to us with the #AgileThoughtPodcast or email it to podcast@AgileThought.com. Alrighty. In a previous episode, Sam, we discussed games and kind of why Scrum works for people from a gaming standpoint. So there’s a goal, there’s rules, there’s feedback, and it’s voluntary participation.
Sam Falco: [01:12] Right? It drives engagement. So people who get involved in a Scrum team of very quickly become a really high performing in a very short amount of time. They, uh, they, they dig what they’re doing in a, in a whole new way.
Dan Neumann: [01:25] So it’s all well and good that we have people digging what they do, but we’ve got a business to run and, you know, digging work isn’t the be all end all. It’s, it’s, I think it’s really important. But, uh, let’s talk about something really inspiring like empirical process control.
Sam Falco: [01:43] Well, so that is, uh, empiricism is what makes Scrum work from a, uh, getting things done standpoint. If the, the gamification of work is what makes people get excited about it. The fact that we are transparent about what we’re doing and inspect and adapt with short feedback loops is, is why it works.
Dan Neumann: [02:08] I think that’s one of the biggest drawbacks, the lack of that. It’s one of the biggest drawbacks to when I was managing projects in a more traditional approach. You know, we would respond to a proposal, um, which is a giant guessing game, you know, because you’re, you’re putting a boundary on this one, you know absolutely the least about it. And you’re setting the budget, you’re setting the staffing, you’re setting the timeframe and making all sorts of assumptions that you can’t validate. Right. And then you drive to that number for the rest of the project, however long or short it might be. So there’s very, there’s some inspection and adaptation, but there’s the, the feedback seems to be lacking.
Sam Falco: [02:49] Yeah. Well the feedback loop is really long. Yeah in one of those types of projects. Um Hm. And in addition, there’s inspection and adaption, but there may not be the, the level of, of having all of the data that you need to make good decisions. As you said, you’re making all these decisions up front when you don’t have any information. And then a lot of times in those sorts of projects, uh, issues get buried. We, we go from stage to stage and it’s not until we get all the way to the end that we find out that an assumption was badly made. And, and we’ve, we’ve uh, yeah, made some grievous errors of spending a couple of years or longer building something that isn’t gonna be fit for purpose. So an example, I mean, it, this happened to me in my early, in my software career, I was working for a company. Uh, we were building up product for a major pharmaceutical company and they, we had this enormous requirements document. This is a, before we had heard of agile, agile was, was new at that point because this happened in about 2004 to 2006. Actually, I think it was a little longer than that. But we have this enormous requirements document. We assumed we could build what they wanted. We got all the way to the end and they were constantly, you know, paying for the development portion of it. And then the big pay was to come at the end, but we got done with it and it didn’t do what they wanted it to do. It didn’t serve their purpose. They hadn’t realized that that’s not what they wanted. And they said, Yep, we’re not buying this. And the company almost went bankrupt because we’d been counting on this enormous payout from a deep pockets pharmaceutical manufacturing company. We’ve made all these assumptions up front and they were not true.
Dan Neumann: [04:30] And that’s where I see the delivery of a product increment and having the opportunity to inspect that increment every sprint and adapt the product backlog based on the feedback or based on any changes that maybe have happened in the market. Maybe the requirements were valid when you created them, but things might be changing as in the market.
Sam Falco: [04:53] Right. And if we had, yeah, and if we had shown them after a short period of time, a piece of the software, they might’ve said, Oh God, that looks horrible. Uh, that’s just never going to do. And we could have, we could have changed and they would have gotten something valuable for the money they spent. And you know, we would not have had the financial issues we had. We ended up getting bought by someone we were about to partner with who was like, well, you’re going to go bankrupt. We need that technology so we’ll just buy you. And things turned out okay in the end because of that company right after that acquisition. Adopted Scrum. Yeah. And that was how I got introduced to Scrum was, hey, you’re going to do this new thing. And they sent a, that model, the company’s model was to have managers be the Scrum master, the development team managers be the Scrum master so I sent my manager off to Scrum master training. He came back and he said, I don’t think managers should be Scrum masters, at least not in this organization. At least not with us because you guys have been reporting to me and I don’t want it you to report to me anymore. That’s not what this is about. Uh, so his name is Tim Ham and I’m still in touch with him from time to time and I thank him every time we talk because he gave me this wonderful career by saying, I don’t think I want to be Scrum master. Do you want to try it? I said sure, I’ll try anything once. And uh, the rest is history.
Dan Neumann: [06:11] I’m curious if that person you were referring to understood that having a Scrum master in a power position, like a manager realize the impact that potentially has on the transparency the team is willing to have with him.
Sam Falco: [06:28] I think it, it did, he specifically said that, uh, because of the power relationship that basically for starters, the daily Scrum would turn into a or would never get out of the stage of, of being, you know, we report to him cause we’d been doing standups, uh, where we, you know, basically reported to him and he saw what was going to happen with that. And, and he, whoever his training was with, I don’t know who his trainer was, apparently had stressed that pretty, pretty well. Oh, it’s possible that he figured it out on his own. But, um, that was, that was a concern of his, he wanted this to work. And so I became the Scrum master and I was horrible at it for a long time, but I adapted my own behavior and uh, and performance and, and, and slowly got better at it.
Dan Neumann: [07:20] You’d alluded to some of the feedback you got from your team in one of our earlier episodes where you were getting maybe a little too creative in the retrospective and it was, um, it kinda knocking people off kilter.
Sam Falco: [07:32] Yeah. Sadly, that was later in my career was not an earlier now I was a later mistake. Uh, no, my mistake, one of my mistakes early on was just being command and control. I, as a Scrum master, I thought I had to, uh, make sure you answer all of the three questions and make sure you answer them in order. And then we’re done. And it didn’t occurred to me that this was a, an inspect and adapt meeting where we’re looking at the sprint plan and the sprint goal and are we gonna make it? And if not, what can we do to fix that up? Um, fortunately, um, Tim was there too, observe my, uh, my behavior and he would give me some notes and the team, we give me feedback, hey, knock it off sometimes in much harsher language, but we’d, we’d been together for a while. We could be brutally honest with each other.
Dan Neumann: [08:24] For me, the, one of the biggest perspective changes on the daily Scrum is to really view it as that opportunity to do a micro planning session. Because you’re right, the, some of the, the three questions thing, the Scrum guides now talking about, hey, how are we tracking towards the progress on the sprint goal? And really that’s the focus of that daily Scrum is kind of a micro planning to focus on getting to that goal. And it’s not for the product is not for the Scrum master. They’re optional participants in that. Um, but it, it’s getting the transparency inspection and adaptation in the daily Scrum as a bit of a planning item.
Sam Falco: [09:05] And, um, same, same team. My first team, uh, we, we’d gotten into a pretty good rhythm. I didn’t, I was also a QA lead, so I was at the daily Scrum, but I didn’t always put on my Scrum master hat. I didn’t need to after a while, but one day the product owner was attending because we often had questions for him and we’re doing the three questions and we get done. He says, I got a question. What the hell are you guys talking about? I have no idea because everybody would answer the three questions, but it wasn’t about necessarily the same story. It wasn’t in the right sequence necessarily. And it really wasn’t obvious what all of that meant. So we brought that into the next retrospective, hey, how can we make the daily Scrum? Because other team members said, you know, I’m not getting that much out of this either. Uh, and so we brought into the retrospective and we did away with the three questions and we started going, uh, top right to left, uh, to, to bottom left basically on the, on our board and saying, what are the tasks that are almost done? What’s going on with those? Where’s this story at? And discussing it in story terms, we still kept it to the time box, but everybody walked away from that meeting knowing what it was going to take to get the stories that we had in progress done quickly so that we can move on to the next few. And we also did not start every story on the first day of the sprint, which a lot of, uh, beginning Scrum teams will do. Every story’s in progress and we’ll, you’re not making a whole lot of progress on any of them.
Dan Neumann: [10:35] The transparency to what it takes to do the work is one of those pieces where I see teams sometimes falter, so they, they may have tasks that look like, well, I’m building it. Okay, that’s great. That’s great that you’re building it. Could you be more specific about what it is that you’re building? What, what, what are actually the steps? And then I find as they create more transparency around that, impediments all of a sudden become visible. Oh well I’m waiting on so and so. Or, um, maybe there’s an area that they’re struggling with and really could use some help. And so I’m, I’m building it or I’m working at it as, as a task is not really creating the transparency that allows for the inspection and the adaptation.
Sam Falco: [11:20] Yeah. A lot of teams struggle with that. And I mean, it can be tedious to sit down in your sprint planning meeting and task out the bulk of your stories, or at least the ones you’re going to get started on soon. I get it. You know, it’s, it’s not exactly the most fun thing to do, but it, it is necessary. Uh, and some engineer’s balk at it because, well, we have to put hours on it and they feel like they’re being measured or judged on that. So if you’re fortunate, you can get an agreement with management, listen, don’t look at their hours or they don’t have to put hours on as long as the tasks are broken down in small enough pieces that you can see movement or that they can see movement and understand what they’re doing. Um, but yeah, it’s um, yeah, it’s really important to have, again, that transparency and transparency doesn’t mean we have to know every single thing. Everything isn’t knowable, but we need to know enough about what we’re doing. We need to know the, the right information about what we’re doing.
Dan Neumann: [12:15] Okay. I want to throw the referee flag just in case you know, Becky listens to this and wants to bust us again, so, estimating for, for those who weren’t listening to the episode where I tripped over whether velocities are in the Scrum guide or not, I got busted by a colleague. So I really appreciate that feedback loop. But estimating and ours is not in the Scrum guide.
Sam Falco: [12:38] But estimation is. One of the characteristics have a product backlog item according to the Scrum guy is an estimate. This is a description, an estimate, order, there’s one more. I’m drawing a blank. Becky will fill us in, we love you Becky, but estimate is one of the characteristics of items in the product backlog. It doesn’t say what that estimate means. It doesn’t say it has to be a FIBONACCI number assigned through poker, uh, through a planning poker. Ah, but there does need to be an estimate because part of the transparency that Scrum is trying to provide is so that at any point the product owner can give some sort of forecast of when we’ll be done or when the release will be done or when it’ll be ready to release. And what Scrum saying is you need some way of making that measurable.
Dan Neumann: [13:29] I was thinking specifically of the task though, not the product backlog item, but don’t
Sam Falco: [13:33] Oh yes. Yup. Yeah.
Dan Neumann: [13:35] So yes, I love sized backlog items of some kind of forecasting. Super Valuable. Otherwise it’s hard to inspect and adapt on how you’re doing towards some higher level things beyond the sprint. But then in the sprint, yeah, what are the tasks? How do we get enough so that we have confidence that our sprint goal is achievable. And then that we know where we’re going for the first few days of the sprint towards that, towards that sprint call. So, um, yeah, if estimates helped for that, that’s fantastic. I tend to like seeing some kind of estimate on, on, on tasks with teams because I find that generally it’s pretty helpful.
Sam Falco: [14:11] Yeah. And what the, what the Scrum guide says about that is that tasks are that, the backlog items that are chosen to be in the sprint are decomposed into tasks, uh, usually a of about one day or less. So it’s not a sign and hours estimate to it, but your tasks should be granular enough that you can see movement on a day to day basis. Uh, and that helps, again, I keep saying transparency, uh, but it helps with the whole team to be able to see what we’re doing. But also when you make the sprint plan, when you, when you make that, uh, that, that the sprint backlog, being able to break things down in that fashion demonstrates that you have a clear idea of what you’re doing. The product owner can look at that and say, okay, I’m pretty sure I communicated what I want clearly. If the tasks on a PBI are coding 32 hours, testing 16 hours, there’s no transparency there into, well what are you going to do? It’s not that we’re asking the product backlog order to approve the, the, the plan or anything. We just to be able to understand it and be comfortable that the development team should be able to explain how we’re going to get started doing the work.
Dan Neumann: [15:24] And that movement of items avoids what I saw as a dysfunction. A lot of times in traditional approaches where we’re 95% done, oh, you know what, two weeks later, three weeks later, we’re still 95% done over 95 and a half, you know? Yeah. Nice. False precision. Yeah. We talked about a few different types of transparency, so around the, the issues that people are maybe encountering around the product and then around the work in the sprint and it gets me thinking of like what other types of transparency are helpful. One for me, uh, is where one team maybe has a dependency on another or sometimes they’re, they’re hidden. And making those transparent can really help us do more effective planning, more effective collaboration.
Sam Falco: [16:22] Yeah. Especially in scaling. It’s so critical because the number one problem when you’re, when you’re operating with multiple Scrum teams in the same, out of the same backlog on the same product is that they get in each other’s way, uh, that they, they, they, there are dependencies that slow them down. So communicating, that’s why in the Nexus, uh, scaling framework, for example, refinement goes from being, uh, an ongoing activity that happens throughout the sprint and takes, you know, it’s, it’s, it’s a meeting. It’s, you got to do this and it’s all about identifying those dependencies and Scrum at scale has a similar concept, so it is less of safe. Uh, you have to identify those things. And again, it’s all about being able to see the work ahead of you.
Dan Neumann: [17:08] Then that falls on the product owner’s shoulders as being responsible for a prioritized product backlog, optimized for value, but also then creating some of that notion of, Oh, here’s a thing coming up on the horizon for our sprints and we ought to be talking to team x or team y. So yes, we want to minimize the dependencies and we can do that by inspecting and adapting, looking at how the teams are structured, where the work is flowing, but also then being more transparent when there are dependencies so that we can start getting ducks lined up. What other types of transparency or what other types of artifacts have you seen be valuable to make transparent?
Sam Falco: [18:04] Um, well, I mean the increment itself is a huge aspect of transparency, um, and having it be high quality. Um, one of the things that gets lost in discussion of technical debt, there’s this attitude, oh, we’ll just, it’s just technical debt. We’ll put it in the backlog. Okay, great. But the fact that you’ve got this technical debt or, or, or defects that are, that are hiding it means you don’t have transparency about the actual state of the product. You can’t make good decisions about releasing it or not releasing it because you don’t, you don’t actually know what landmines are hidden in there. So we, we create this euphemism technical debt and then there’s all these things, oh, it sort of like you can go into debt to buy a house and that’s okay because you have a plan. Like, okay, that’s an interesting metaphor, but there’s not a one to one mapping between those types of debt. Uh, so we get carried away with, with masking what’s really going on. And technical debt is a form of a lack of transparency.
Dan Neumann: [19:09] As I think of that, there are ways to try to create transparency to the technical debt. So there, there’s tooling that can look at the complexity of the code that’s growing where dead code is. I think there’s some tools that can create transparency to the technical debt.
Sam Falco: [19:24] Yeah. And I’m not saying that technical debt should never exist. Um, there, there may well be a reason like we got to get this out to market, we’re going to miss a market window and we know there’s some problems and okay, but we’re going to have a plan to, to do those. But what happens is too often technical debt just is, it’s just some stuff we don’t worry about it. Um, and so what I like to see is if a team, it has to make a decision about that during sprint review that should be discussed. So we’ll have the, the demo of the product, we’ll talk about what we did and what we didn’t do. And part of what we did and didn’t do is we didn’t do these things and they have generated technical debt and stakeholders need to be aware that it’s there, uh, and the cost of it. So the potential cost of it, the potential cost of not fixing it, um, and the opportunity costs that’s involved in forging ahead with something else and leaving that technical debt just sitting there like a time bomb because okay, well it’s because what often happens is, well we we need to develop new features that’s going to put, you know, customers bring customers in so the technical debt gets forgotten. And I think it’s because of a lack of transparency. We, we turn the sprint review into just the demo. Okay, we maybe we get feedback, that’s great, but we’re not talking about all of the other things that are involved in a sprint review. And I think a huge failing on, I mean even mature Scrum teams I’ve seen make that mistake.
Dan Neumann: [20:53] I want to come back and continue that conversation on sprint review in just a second. The technical debt to me, I know, I feel like a lot of times teams just want the recipe. Tell me what do we do about technical debt? And, and for me, something like technical debt is walking the line between there’s a, an agile principle of, you know, we want to maximize the amount of work not done. There’s also one of continuous attention to technical excellence is going to enhance your agility, right? And then from a business standpoint, you know, if you want to talk about lean startup and things like that, you know, we want to realize value in the market and start capturing that as soon as possible. So there isn’t like a, you know, pull the string and the doll tells me what to do with your technical debt. It’s really be explicit about it, be transparent. We wanted to get this feature working. It’s not as performant as we want to or it’s not as flexible or it’s not as whatever. Here’s why we made that choice and what do we want to do about, about paying that off. And yeah, going after the new shiny feature isn’t necessarily the best thing to do. You do want to address those limitations in the system. So definitely not a, if this then that.
Sam Falco: [22:04] I did not mean to imply that it was.
Dan Neumann: [22:06] Oh, I’m not sure you did. I just, I feel like a lot of times people want that kind of basic rule. You alluded to sprint reviews as a demo is one of those anti patterns. And I think that’s unfortunately common. And I, I wondered to what degree that’s because there’s a concern about creating more transparency and actually getting feedback.
Sam Falco: [22:34] Um, I don’t know. I, I think that to some extent, maybe, maybe in some places it’s a lack of understanding of what that’s about to begin with people hear the demo. Uh, and, and that’s exciting to see stuff in action and they forget that there’s some other stuff that needs to be done. Um, in, in one organization I was, was in, uh, I came in and the first team that they asked me to do, they did a sprint review. Of course they called it sprint demo. They did it in 30 minutes. They were doing six weeks sprints, which was actually the first thing I needed to work with them on. Yeah. Uh, and, and when I said fine,
Dan Neumann: [23:17] Since we’re on, since we’re on audio on, I just made a funny face. And that was yeah, that was what Sam was laughing at.
Sam Falco: [23:24] So they had this habit now of 30 minutes of they would demo some stuff and that was it. And it was a Herculean effort to get them to do anything else. Oh. And they also recorded it because stakeholders couldn’t actually attend because everybody was so busy. So it was really, really problematic. And I did a sneaky thing. I made sure that a stakeholder who was invited but never showed up. And I warned the team this was going to happen. I said, I’m going to make sure that the stakeholder is present to see this working. So be forewarned, um, and they did not apparently believe me and they were surprised because they, they had, um, they had cut some corners and the stakeholders specifically asked does it do x? And there was just this dead silence and I remember one of the developers just just staring at me like he was going to cut me after work. Maybe not even wait that long, but I’m like, Hey, I told you I was going to do this and this was going to happen. And I warned them several times during the course of the sprint because I don’t want to be doing sneaky things behind their backs. I say sneaky, but ah, no, I had to be transparent with them about what I was going to do and why.
Dan Neumann: [24:49] And so what was the concern about the question that, who, like what do you think created ill feelings maybe for that developer with that question?
Sam Falco: [24:58] I think, uh, I’m trying to remember back cause it’s been a, it’s been a few years, but I think it was an acceptance criteria that had been just ignored, not even negotiate with the product. No, we’re just not going to do this and we’ll, we’ll, and you’ll love you, you know, the phrase is coming next we’ll roll to the next sprint.
Dan Neumann: [25:17] Nice. No, no.
Sam Falco: [25:21] And so I think he felt like I was, I had set him up even though again, I had warned them this was going to happen. You need to be prepared. And we had talked about if you can’t get something done then your product owner needs to know about it because the product owner should not be surprised by anything. Uh, and the product owner should be able to manage stakeholder expectations and instead it was just sweep it under the rug. And because they were used to nobody asking questions at a sprint demo because they just ran through the checklist of things that they had done. Um, they weren’t, they weren’t used to getting the questions and then they would just do it in the next sprint.
Dan Neumann: [25:57] Yeah. I feel like the sprint review when it is a demo really is not fostering transparency. And something I’ve started doing with teams is taking the seven or eight bullets out of the Scrum guide and summarizing those to make sure that in the sprint review we’re touching on the product owners explaining what was done and what’s not been done. The teams actually discussing what went well during the sprint and what they did to overcome some of the challenges they ran into and going through that list. So we kind of have it as a little cheat sheet so that we aren’t, we’re very explicitly not making it just a demo.
Sam Falco: [26:34] Yeah. Yeah. I worked with a product owner, um, at, at another company entirely and she had never done that herself. And I came in, um, I said, tell me how you’re, and then of course the calendar invite said sprint demo. And I said, tell me how this goes. And she said, well, you know what happens to the sprint demo. I said, I don’t know what happens in your sprint demos. Um, tell me what happens. So she says, okay, so it’s just a sprint demo. Um, how do you, have you had any, any training? And she said, no, she just had this dumped on her. So I went abroad to Scrum guide, showed her what a sprint review was supposed to be and she turned pink. I can’t do that. I can’t stand up in front of those people and say that. And I said, we’ll work through it together. And, uh, I coached her extensively during that sprint and we had a script and she sat there in front of all the members and she, uh, she, she held the paper in front of her face so that they can only see from her nose up and she read from it. However, the response from stakeholders who had never been told this before were astonished. Oh, we had no idea. Uh, and, and over the course of the next several sprints, things started happening where when the developer said, we need this tool, well, we’re not just saying it because we want it because it’s a new toy. We need it so that you get what you want. And by talking about those things in the sprint review, stakeholders had some, uh, some urgency to get things done. So again, transparency led to better results because now the stakeholders could make informed decisions about what resources to provide to the Scrum team.
Dan Neumann: [28:16] And I find it curious when teams are willing to talk about issues that are impeding them around the water cooler, but when they get the people who can influence the organization outside the team in the room, it’s crickets. Sometimes they this, this elephant in the room, all of a sudden nobody wants to talk about it. And I found that when they do talk about it, yeah, the stakeholders are usually curious and wants maybe some more specifics on it and are willing to try with the rest of the organization to make that go away. And because they do realize the impact it’s having on their overall outcomes.
Sam Falco: [28:50] Yeah, yeah, absolutely. And I mean a lot of people who’ve been in environments that are toxic, uh, and not safe to say those things because if you say we’re having a problem, it’s your, it’s your fault. And so even in an organization where that’s not the case, people have come from an organization where it is and they are trained to, to hide, that sort of thing. Nobody likes to give bad news because a lot of people react poorly to being told bad news, even if it will help them do better.
Dan Neumann: [29:18] Indeed. So that’s one of the things I find to us doing as coaches is working a lot of times with the people who are going to hear that something isn’t working well and getting them to really be curious about that. Find out how they can help as opposed to saying, well team, you shouldn’t be having that issue. Well they are. That’s the reality. So when you hear the bad news, here are some helpful ways that you could respond to that and be curious and pull for more information.
Sam Falco: [29:44] Absolutely. And that’s a some someplace where the Scrum master can help by helping stakeholders understand how to communicate with the team and what are the most productive ways to do that. Um, especially if there are some shell shocked people or if you stakeholders just didn’t know,
Dan Neumann: [30:03] Right? Yeah. Surprises often are not good. And so if they’re finding out that there’s a surprise, how do we deal with that? Now we’ve got the transparency, how do we inspect in a healthy way and adapt in a meaningful way going forward? Well, Sam, uh, we have talked about the games podcast where we talk about getting people engaged and excited and why the scrum framework does that for, because there’s a goal, there’s rules, there’s feedback and generally voluntary participation. And so then this episode is talking a lot more about some of the ways the Scrum events support the transparency, inspection and adaptation. That’s the “why” Scrum works. Asides from having, having an engaged group is very valuable. And, and then there’s the, the empirical process control part as well.
Sam Falco: [30:53] Yeah. And that builds trust. I mean, one of the reasons that the agile manifesto was written in the first place was because there was so much distrust between business on the one side and IT on the other. And the idea was we should be talking together because we’re all trying to achieve the same thing. We all want to achieve a business objective so that we can get paid. And there’s still a lack of empathy sometimes from one side or the other. But Scrum allows us and actually has these mechanisms. The all of the events are a way to foster communication so that we get that transparency and the sprint review is the place where the business and the Scrum team can really, really come to grips with each other and talk to each other openly and honestly if it’s managed well.
Dan Neumann: [31:38] Fantastic. We’re going to leave it there for the sake of the time box. Okay. I am curious if you’ve been reading anything that’s got to particularly inspired these days.
Sam Falco: [31:48] I have. Um, I um, have been reading, rereading Jeff Patton’s “User Story mapping.” It’s a story mapping is a skill that I have not gotten to use a lot, but I uh, in my current coaching engagement coming, I’m gonna need it essentially. Uh, so I thought I should reread that. Um, that’s been my, my business read and actually got some, some new insights into that process. I went chapter five talks about his exercise, where you do what you did this morning to get ready for, for work and you do a story map. And I’d never actually done the exercise. So I did it. And Wow. It opened my eyes to how to, how to explain this to other people. And then the other thing that happened was I write fiction as a hobby and I’m struggling with the novel I’m working on right now. And all of a sudden it hit me. Oh my God, I can do a story map. And there was the whole, and I saw partly way through it. I’m getting there. So it’s going to be good for my, my, uh, my software development career and it also be good for my writing. Uh, so that’s my major read right now. How about you?
Dan Neumann: [33:06] You’re doing stories, story mapping?
Sam Falco: [33:08] Story, story mapping. Yeah. Okay.
Dan Neumann: [33:10] Uh, I’ve been buying books but not reading them. Um, so I have “People Wear,” because on a, another episode with Esther Derby, uh, I needed a quote out of the book “People Wear” about the managers quote out of the book.
Sam Falco: [33:41] Oh, neat.
Dan Neumann: [33:42] To make it possible for them to work. So that’s out of “People Wear,” so I got that. And then uh, Oh, I dunno. I think Amazon probably recommended mythical man month. And I mean, I know the, the, the principle of it, it’s like one of those classics. I haven’t read before. I mean I just read “1984” within the last 24 months. So I figured
Sam Falco: [33:58] For the first time, really?
Dan Neumann: [34:00] Yeah. That was my public education. That’s okay. If you judge, it’s part of what makes life fun. Those of you listening can’t see, but I am, I’m pointing. Yes. Well I fit, you know, it kind of made a little bit of a resurgence in the last couple of years and I thought that I have no idea on this episode of Political Agile coaching, haha. So that’s, um, and then the book that I actually did read, it was “Lead True” by Dr. Jeff Thompson and we did an episode with him, um, just a few weeks ago and it’s all about leading with values and letting really sticking to your values and pushes coming to shove, that’s when you test your values. It’s nice to say them or hang them up on a wall, but uh, when stuff gets real is when you need to decide are those actually your values or not?
Sam Falco: [34:58] Yeah, that was a really good podcast. If, uh, if, if people listening now have not heard that, go, go listen to it. It’s, it was really valuable.
Dan Neumann: [35:08] Yeah. CEO Emeritus of Gunderson health systems. It’s a roughly a billion dollar health system in southwest Wisconsin and southeast Minnesota. And um, it was a fortuitous meeting. We sat next to each other on an airplane. Uh, he couldn’t watch the movie that he wanted to because Delta had taken it off their rotation and we had a lovely chat instead.
Sam Falco: [35:28] Awesome.
Dan Neumann: [35:31] With that then I want to thank folks for listening and again, if they have topics they’re interested in hearing us discuss, send an email to firstname.lastname@example.org, thank you.
Sam Falco: [35:40] Take it easy, Dan.
Outro: [35:43] This has been the agile coaches corner podcast brought to you by AgileThought. Get the show notes and other helpful tips from this episode and other episodes at agilethought-staging.ectfh4-liquidwebsites.com/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.