In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by AgileThought colleague and return guest, Sam Falco. Sam is an agile coach and Certified Scrum Professional with an extensive background leading agile and development teams.
Today, Dan and Sam are discussing under-promising and over-delivering: The what-not-to-dos for Scrum Teams, their leaders and the business they work for. Every now and then, when Sam is teaching Scrum or coaching people on Sprint planning, he’ll say, “Select what you think you can do.” However, a lot of new Scrum Teams will bite off more than they can chew because they’re way too optimistic. He often cautions to dial it back and then will hear the phrase in return, “Oh, we get it. Under-promise and over-deliver.” But that is as much of a lie as, “Sure, we can get that done,” and then not delivering. Businesses pick up on this dishonesty and it creates a tumultuous relationship between the development team, the leadership and the business.
Tune in to get Sam’s key insights on how to build trust between the team and the business; the to-dos and not-to-dos for Scrum Teams and leadership; his cautions for new Scrum Teams and leaders; and his advice and actionable steps for building a healthy relationship between the team, the leader and the business.
- “Under-promising and over-delivering” and other unhealthy Scrum Team mentalities perpetrated through the team or through the leadership
- When the business fears that the team is under-committing or sandbagging the estimates, they’ll create stretch goals for the team (which are often helpful)
- Theory X: The belief that people will not perform unless you force them to do so; that workers are lazy, so you have to put systems in place to keep them working
- If the leader is making crazy demands, the team is going to end up over-committing or sandbagging
- What healthy Scrum Teams and leadership looks like
- Theory Y: Assembling together the people who want to help you accomplish your goals, give them the parameters, and then letting them do it
- They have an established Sprint goal
- There is collaboration between the development team and the Product Owner
- The Product Owner and development team are collaborating to come up with product backlog items that are aligned with the Sprint goal
- The leader or business does not drive the team as hard as they can to get as much as they can (which can lead to sandbagging)
- Sam’s cautions to new Scrum Teams and leaders
- New Scrum Teams need time to learn what they can do
- New Scrum Teams tend to overcommit and add way more than they can actually do
- Dial it back a notch as a team—you can always add something later if you find you go through something too fast
- Sam’s principles for successful teams
- Technical excellence enhances agility (if you are always providing a done increment, you are always in a position to release and always in a position to pivot or change direction)
- A professional Scrum Team that really observes agile principles and values will be the most successful at knowing exactly what they can accomplish and being able to deliver on it
- Actionable steps for building a healthy relationship between the team, the leader and the business
- Realistically forecast what you know you can deliver
- If you are on a development team and you’re using Scrum, give honest estimates and have the courage to say, “No, we will not commit to doing more than we can do.”
- Follow the three pillars of Scrum: transparency, inspection and adaptation
- Establish a Sprint goal that is meaningful between the business and the technology team
- Do enough planning during the Sprint planning to build a credible forecast
- The business should be asking for the “what” that they want and as the technology team, give them some alternatives as to “how,” they should collaborate together to figure out the best option
- Have a well-established Definition of Done that everybody understands, agrees and adheres to
- Never sacrifice your quality goals
- Use the “fist to five” to vote on how confident the team feels on accomplishing a set goal
- As you go through the Sprint, be honest with where you’re at
- In Sprint review, discuss how problems were solved as well as the difficulties that were encountered (because stakeholders need to know that this is not magic)
- If you did not deliver, that should be the subject of your Sprint retrospective
Mentioned in this Episode
Sam Falco’s Book Pick:
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’m your host Dan Neumann and I am excited to be joined by Sam Falco, who I would have normally called a co-collaborator, but he corrected me and that collaborator has co in it already. And so now I have a new thing because Sam and I are going to be collaborating on today’s episode.
Sam Falco: [00:35] Thanks for having me, Dan. Sorry, the English degree just comes out sometimes.
Dan Neumann: [00:40] That’s all right. I uh, I can be a little bit pedantic. Just ask EG and IE and I’ll be happy to help you to make this distinction.
Sam Falco: [00:49] And for the record, I wasn’t gonna call you out on the air. You did it yourself.
Dan Neumann: [00:53] That’s all right. So that’s the end of today’s grammar section and on agile topics. You had something, we were talking about off the air and it was the phrase over promise and under deliver or under promise and over deliver. Right? Yeah. Well, so let’s talk about the under promise.
Sam Falco: [01:15] I hear this every now then when I’m, when I’m teaching Scrum or trying to coach people on Sprint planning and I’ll say, you know, select what you think you can do. A lot of beginning Scrum teams, well of course they’ll grab way more than they can actually do cause they’re way too optimistic. And um, and I always caution to dial back and I’ll hear this phrase, Oh, we get it under promise and over deliver. And that is not what I mean because that is just as much a lie as, Oh, sure we can get that done. And then not delivering. It reminded me of, uh, one of the Star Trek movies, Kirk finally twigs to the fact that Scotty’s been, uh, patting his estimates all these years. I don’t remember which movie it was, and he asked him about it. And I don’t know if it was before that or after that, but there was an episode of Star Trek Next Generation where the crew of Picard’s Enterprise rescue Scotty. He was an a transporter buffer, and he and Jordy go head to head and Scotty tells him, you know, let me give you some advice. Starship captains are like children. They want what they want, they want it right now. They want it their way. The trick is just to give them what they need, not what they want. Uh, and Jordy takes issue with that and says, listen, I’ve got to get back to work. I promised this thing would be done in an hour and Scotty wants to know how long would it really take? And Jordy says, an hour. And he’s really frustrated about it. And Scotty is just appalled that you, you’re not going to get a reputation as a miracle worker that way. And I think that really highlights the difference in mindset. The idea of so much of Scotty’s way is under promise and over deliver essentially. Uh, and Jordy is, I’m going to tell you how long something’s gonna take me to do it so that you have faith and trust in me.
Dan Neumann: [02:59] Um, yeah, and I think some of that maybe comes from, or looks at the lack of trust, but you know, when, I know you go back a few iterations of the Scrum guide ago and it used to say something to the effect of commitment in the Sprint planning. And that led to a lot of fear about, uh, potentially over committing. But I also feel like the business often expressed a concern that the team would be under committing or that somehow they’d be sandbagging the estimates and that they would have all this slack. And so we should have stretch goals for them and we should push them to see how much they can do and, and other kind of weird phrases like that.
Sam Falco: [03:42] Yeah. Yeah. And I loath that phrase stretch goals because again, I want a team to say, here’s what we think we can do and do that. And, uh, the other question that comes up or another question that comes up frequently in training as well, what happens if you finish early and you’re just sitting around with nothing to do? And I thought, I’ve never actually seen that. I have seen teams finish stuff a little early, but they’re not sitting around with nothing to do. There’s always something to do. And for the most part, if we’re following that agile principle of assembling our team out of motivated individuals, these are not people who want to sit around and do nothing, right? These are people who are gonna jump in and find something else to do. In fact, at that point, sometimes you have to actually put the brakes on, Whoa, Whoa, Whoa, let’s not, let’s not add too much complexity to the system. That would be really cool, but it’s not the most valuable thing to do right now. But yeah, that’s a, it’s a very, very X style of management. People will not perform unless you force them to do so. And I just don’t see that as the predominant mindset, especially in software development. And I’m sure in other complex knowledge domains, people get into this because they’re interested in it. They want to do that. And if they’re sandbagging, there’s probably another problem. And it may have to do with your leadership style.
Dan Neumann: [05:03] Yes. And I want to go back so lest we speak in code for people who maybe aren’t familiar with theory X and theory Y maybe there’s a chance to just give the CliffsNotes versions of that as, as I understand it I’m not an expert in the area, but my, my uh, pedestrian understanding theory X was the manufacturing mindset, the industrial age, right? So you need to, um, workers are lazy, so you have to put in place systems to keep them working and measure their work and drive them to work harder because they will do as little as possible. Um, and I, you know, in an abusive situation like that, I could definitely see myself as a worker trying to do as little as possible because then it becomes a competition. You can’t make me, Oh yes I can. And we’re having this unhealthy situation to say the least about it. And then theory Y, can you go ahead and expand on that?
Sam Falco: [05:55] Theory Y is a, is much more collaboration driven. I too am not an expert on these things. I know theory X pretty well from having endured much of it for much of my career, whether it was software development or not. But theory Y essentially says the assemble your people who want to help you do something, accomplish some goal and give them the parameters, give them what you’re, what you’re looking for and let them, let them do it. So it predates the agile principles and manifesto. But certainly nothing in the agile principles are new. These are all uh, formulations of old things we’ve known. But uh, that’s, that’s theory Y in a nutshell.
Dan Neumann: [06:40] Yeah. Well and that’s why I gave you theory Y. Um, and you touched on something else important, so thank you for playing along with that. Yeah. Theory Y right? Going for more inspiration and really trying to engage people and their creativity. Agility wasn’t an imagined thing. Where, where a group of folks got together and said, Hey, let’s imagine a new thing. It was like, hey, we are having success collectively doing different things, different frameworks, different processes, different methodologies, yada, yada. And what is it that’s common about those across all these that’s allowing us to have success in agility was what was distilled out of all those successes. So yes, agility predated the manifesto for sure.
Sam Falco: [07:32] Yeah. A lot of people miss that first line in the manifesto that we learned this by doing it and helping others to do it. Not just we dreamed it up. And one place I was at, I was talking about this and someone said, yeah, well they never worked here. Those people never worked in a, in an industry like ours that’s heavily regulated. And I, after I picked my jaw up off the floor, began talking about, you know, the FBI Sentinel project. That’s the, uh, the famous case study for how Scrum delivered in a very short amount of time. Uh, and with the remaining 10% of a budget, all of the features that hadn’t been developed in the previous 10 years and some of the other, these are, these are, there’s no slouch. I mean crystal is at least part of it, is designed for that sort of environment. So the agile manifesto absolutely comes out of experience and a lot of that will build on things that we already knew but weren’t being practiced in the software industry.
Dan Neumann: [08:30] So going back to the premise of under promise and over deliver, that’s certainly not what is being advocated for on a healthy Scrum team in Sprint planning, right? We want to have, we ought to establish a Sprint goal. We want to collaborate with the Product Owner. We want to see the development team and the Product Owner collaborating to come up with product backlog aligned with the Sprint goal that use their capacity wisely. But it’s not a sandbag. It’s not a, let’s drive the team as hard as we can to get as much as we can, allowing it more to emerge.
Sam Falco: [09:09] Right. Allowing it to merge. And especially when you’re beginning new Scrum teams, they need time to figure out what they can do. Cause especially if they’ve been working in the old industrial paradigm where they’re handed some stuff to do and it takes, you know, and, and told this is when it’ll be done and we cut corners maybe that to make that happen and hand it off to the next group. Now we’re being told, “done” no longer means my piece of it is done and I’m pitching it over to somebody else. It’s done means it all works. We don’t know of any more bugs in this. Anything we found, we’ve squashed, uh, it’s ready to go in production or it’s in production with no, no further work needed. And it takes new teams some time to figure out how to do that in a short amount of time. And so they’ll often overcommit, add way more than they think they then, then they actually can do and then find they’re in trouble. So I often caution beginning Scrum teams, dial it back a notch. Uh, you know, you can always add something if you find that you go through it too fast. But to date, I have yet to find a beginning of Scrum team that actually succeeds in going way too fast.
Dan Neumann: [10:21] Yeah, no, I, it’s unusual. And thinking through that one of the, one of the notions behind change is you want to capture, the feeling of success will have success and feel what it’s like to be successful. And success as defined by, in this case, by achieving the Sprint goal and it feels totally different to be like, wow, we got working software completely to the point of being done, a mature definition of done. It’s an increment. It’s potentially shippable. And that was cool. Um, gosh, what’s next? You know, we have some capacity left.
Sam Falco: [10:55] And then you can build on that because you have something that is robust, it’s solid, it’s not going to fall apart the first time someone changes something someplace else. Um, and so another principle comes into play the technical excellence, excellence enhances agility. If you are always providing a done increment, you are always in a position A to release. If the market demands it or the time is right and B, you’re always in a position to pivot, change, change direction because you don’t have to go clean up after yourself. That brings me back actually to Star Trek again. Let’s just torture this metaphor some more and I often imagine so before it became established as a matter of Canon that Scotty was actually, you know, quadrupling his estimates was always Kirk demanding something and Scotty telling him it would take, you know, four hours and then having to patch something together and all I can imagine is what a hacked together mess the Enterprise systems must have been. The technical debt must’ve been enormous until at some point the Enterprise just stopped dead in space and was there for weeks while they tried to figure out what patch of a patch of a patch had caused the dilithium crystals to fracture or whatever.
Dan Neumann: [12:24] I think I saw that episode.
Sam Falco: [12:26] We all did. We all saw it. It happened many times, I’m sure.
Dan Neumann: [12:28] So Scotty was not giving her all she’s got, he really was just giving her most of what she’s got.
Sam Falco: [12:35] Yeah. And he was hacking together the rest. And so there’s a leadership difference there as well. I mean, again, I don’t want to, I don’t want to torture this. Oh yeah, I do. I want to torture it. What I’m saying is I’m not that big of a Trek fan. This may break down on closer analysis, but Kirk is very much that theory X leader who demands the impossible and just expects people to do whatever it takes to get there regardless of whether it’s healthy for them or the or the star ship. Uh, whereas Picard is a professional, he’s asking for professional results and he is, uh, he can rely on his engineering staff to say, this will take an hour and know that, okay, that’s what it’s going to take and make his plans accordingly. Similarly in the business world, if you have a leader who was making crazy demands, well, the team is probably going to overcommit because they don’t feel like they can’t or they’re going to sandbag because they want to make sure that they leave buffers for all of the crazy new demands that are going to come in or the unreasonableness. Whereas a professional Scrum team that really observes the agile principles and those values is going to be pretty good at saying, this is what we can do and actually delivering on that and we’ll get better and better over time.
Dan Neumann: [14:05] Those are very different leadership models. It also makes me wonder, did Captain Kirk intentionally send down the red shirt guy knowing that he was going to get killed because that’d be, right? So we’ve got the sacrificial, you know, we’ve got the scapegoat in retrospective sometimes or in, you know, when, when something doesn’t work. Do we blame QA for the production of bugs? Do we blame the developers? Or do we look at the system and try and figure out, Oh gosh, this, uh, yeah, now we know what the dilithium crystals that ruptured or whatever because the system is flawed. Yeah. And if you would like to fix that, if you’d like to fix our Star Trek metaphors, yeah, tweet them to us with the hashtag #AgileThoughtPodcast.
Sam Falco: [14:48] So the idea is that we want, and our frameworks can give us that Scrum being the one that’s most commonly used. And it doesn’t always end up that way because we have these weird things that we bolt on stretch goals or you know, we’ll, you know, we’ll under commit over deliver, um, which doesn’t always work out in practice because oops, you know, work emerges during the Sprint. You think you under committed, but it didn’t. And so now it’s, it’s bigger than you thought it was. So you have no credibility with the business when you go back to and say, Hey, this is bigger than we thought it was. Uh, well, you know, you’ve always come through in the past. Um, so businesses begin to expect that you are sandbagging. Once they figure it out and you know, they will, they will figure it out. Um, they don’t, they don’t believe it. They don’t believe you anymore. And so that causes them to crack down. So a lot of the bad behavior, bad management, theory X behavior suddenly becomes justified again. Now you’re dealing with someone who is looking over your shoulder wanting updates every day. You’re dealing with someone who wants to know your velocity and I want to know why it’s not increasing 10% every Sprint. Uh, I want to know what each individual’s velocity is so that if we, and I heard this from somebody, I’ll just steal a little velocity from this person and put it on this other team. No, no, no. That’s not how this works. But the problem was, again, it was like, it wasn’t just the development team, the system, the entire system had its flaws. And I think if you are on a development team and you’re using Scrum, your chance to start building trust and making things better is to give honest estimates and have the courage to say, no, we will not commit to doing more than we can do because we are protecting you from the risk of releasing crap or causing problems. Or in some situations you could kill somebody.
Dan Neumann: [16:47] Well, yeah. And that used to be, uh, it always felt like hyperbole that, Oh, you know, whatever. Um, nobody dies if, if the software doesn’t work well. In fact, Boeing has proven no that and now with autonomous vehicles, let’s see, depending on when people are listening to this, uh, the news came out recently that autonomous vehicles aren’t really good at spotting pedestrians, especially children at night. And so there’s a lot of concern about that, that cars are failing the tests and as they’re marketing the features, drivers potentially are becoming less aware of their surroundings, expecting the car to bail them out and that’s not necessarily the case.
Sam Falco: [17:26] But even when lives aren’t at stake, money is, your business or reputation is. And if you get a reputation for every release is crapware uh, and they’ll fix it in the next release. Well it only takes a couple of those cycles before your reputation is seriously damaged in the marketplace. That can cause all sorts of problems leading up to, Hey, we no need this division because we don’t have funding for you. So you’ve just been putting out crapware and now you don’t have a job anymore.
Dan Neumann: [17:57] We have a fixed for that. The three pillars of Scrum, transparency, inspection and adaptation and things like stretch goals or a perception of somebody sandbagging or, or, or, you know, whatever work around all work against transparency. All of a sudden it’s not clear what the business should be expecting or what they should be focusing on preparing for the next Sprint or two at the top of the product backlog. And there’s no ability to inspect and adapt because you don’t know where you’re starting from in the first place.
Sam Falco: [18:31] Um, and that is just a horrible feeling to have someone in the business say, Oh, this looks good at a Sprint review. We’re going to release this. Oh wait, there’s all this other stuff we didn’t tell you about these bugs, uh, that we, that we haven’t been able to fix because we committed too much. Now we’re talking about the opposite end of the spectrum. Obviously here where we’ve committed too much, but it often stems from the same mentality.
Dan Neumann: [18:56] Let’s see if we can give people some actionable things they can do with, with the mindset. So yes, so we want to have a, a forecast. Let’s focus on spring planning, right? That’s my mindset, at least for now. So we want to be able to establish a Sprint goal that is meaningful between the business and the technology team. So collaborating on a meaningful Sprint goal and doing enough planning in Sprint planning that there’s a, a forecast, a credible, credible forecast that here are the things we can do to achieve that Sprint goal, and so you’re doing enough tasks and you’re doing enough designing. You’re talking about the risks and the tradeoffs potentially that may need to happen to achieve that Sprint goal.
Sam Falco: [19:38] Yeah. You should be able to explain how you’re going to work together to achieve the Sprint goal. Um, and I saw, I find it very helpful in just household repair projects to sit down and list out the steps and sometimes I’ll discover, Oh, there’s a tool I don’t have or don’t know where it is and I have to go find it. Or here’s some parts that I need to go get. And sometimes even knowing how long something will take. And those are relatively, I don’t, I hate to say simple because I’m not all that handy, but they are not as complex as software development and so I think it’s even more important in a complex knowledge domain to take a minute to map out a short plan and then inspect and adapt on that plan frequently throughout the life cycle in Scrum with Sprints and anything else throughout the development effort.
Dan Neumann: [20:38] Agreed. One of the things I also like to encourage teams to do along the same vein is if the business, the should be asking for the what that they want. And as a technology team, don’t go ask them also for the how, but give them some alternatives. You know, can you come up with three different how’s? Maybe it’s of degrees of sophistication or degrees of scalability or whatever the case might be. But here’s the, here’s what we can do fast and, and achieve your goal. And here’s some of the risks of that. Here’s a kind of a medium effort solution. Here’s the very high end solution. And really talk about what you can do to achieve the goal and participate with the business and figuring out what the right, how is there. So doing enough planning, explaining how you can achieve the Sprint goal. Bringing some alternatives to the Product Owner or collaborate with the Product Owner in Sprint planning on what those alternatives might be.
Sam Falco: [21:38] And having a good definition of Done that everybody understands and agrees to that you then adhere to. So part of your proposition to the business is here’s the work we’re going to do and it’s going to have this level of quality and at least this level of quality. And again, if you’re promising based on that, you’re going to be a little more, we’re we’re looking for, I think the phrase is accuracy, not precision. We just want to have a reasonable expectation that we’re going to get that done. Uh, but we don’t need to peg it down to the day. Um, but then as soon as you, as the work emerges you understand more about the problem and maybe if you can do more, okay, then that’s great. Let the business know that listen, we think we can do a little more, but never, never sacrifice your quality goals. And I think that’s where people fall down a lot in a Scrum situation where the business system is being too demanding. They’re demanding more and more features, but the team does not necessarily make it clear what the cost of that’s going to be. Here are the corners. We would have to cut to do that. Are you willing to risk the company’s reputation because of this? Or funding?
Dan Neumann: [22:52] I was in a workshop that Dean Leffingwell was leading and one of the memorable things from that was the way he described kind of traditional planning and even agile teams, a lot of times do this. We would plan and give ourselves actually an incredibly low probability of delivering on time because we would, yeah, we’d have a risks list and we’d know we’d articulate the dependencies as best we can, but the way it was planned, actually every thing pretty much had to go right to hit that goal. And so what we want to do is be able to do planning and give our teams a chance to increase the probability of delivering on time or what’s being asked for. And there’s a nice visual, I’ll have to see if I can recreate that. I don’t think it was any intellectual property per se, but it was just a nice visualization of how to go about planning and some of the flaws with, with traditional planning. And that’s where slack comes in. So if there is no slack on the Scrum team within the Sprint, you will not deliver on time. Something will go wrong.
Sam Falco: [23:57] Yeah. One technique that I used to use would be at the end of Sprint planning or towards the end of Sprint planning as they were wrapping up, you know, okay, we think we have the right level of detail of our plan and we have some tasks that we think are accurate. I would say, okay, let’s, let’s do a fist of five and for anybody listening doesn’t know what the fist of five is that you think of a number between one and five and hold your fist in the air. And on the count of three when everybody’s ready, uh, everybody reveals their number and you set up the parameters. So I would say right on a scale of one to five, one being, uh, you know, Oh my God, that’s an iceberg and we’re going to, we’re all going to crash and die in five being rainbows and kittens. How comfortable do you feel that we’re going to be able to hit this goal that we have? And if I got threes or below, then we, okay, what is it you’re seeing that maybe the rest of the group isn’t seeing? If it was just a few threes, it was all threes, what do we need to do to, to dial this back? Um, and if you know, cause all fours and fives. Okay good. We can, we, we’re probably all right because the team did have a pretty good sense of what it can do. And one team that I used that for, I, I mean they basically took it over. They would do that after each PBI they put into it, Oh you know, let’s do, let’s do a quick fist of five. Can we put more in? And then they got really good at delivering what they said they were going to deliver.
Dan Neumann: [25:24] Nice. Yeah. Is it an opportunity then to add work as opposed to, I think triggering that loss aversion where you come up you take the top of the backlog. Maybe you do it, maybe using story points and your historic philosophy. And so you say, Oh, we’ll take the top 30 points of stuff and you start to plan and then he’s like, ah, it feels really tight. Or maybe you won’t make it. And then pulling something out hurts, psychological pain from having to do that as opposed to can we do the first one? Plan it up. Yup. Okay. Yeah. Can we do another one? Yup. Yup, yup. As opposed to well, we were hoping for 10, we’re only getting nine.
Sam Falco: [25:59] Yeah. I think, um, in Thinking Fast and Slow, Daniel Kahneman describes that there’s a, there’s a, and it’s not coming to the top of my mind right now, but there’s a term for that where you set up an expectation and falling short of that it causes psychological distress that, that you’re not getting there. And so don’t, don’t do that to yourself.
Dan Neumann: [26:22] Right? Yeah. Try and avoid that. Um, yeah, because you’re losing, what is it? You losing a dollar hurts more than getting two type of thing.
Sam Falco: [26:35] So I think, um, that’s a way to handle it in Sprint planning. And then as you go through the Sprints, be honest with where you’re at. Um, daily Scrum of course is the last responsible moment, each, each 24 hours to bring up issues. But certainly bringing them up before that if you can. And then I like to have teams talk about in Sprint review how a little bit of how they solve the problem, especially what difficulties did they encounter because stakeholders need to know that. They need to know that this is not magic, that this really does cause people to struggle. And that also that honesty, that transparency of this is difficult work you’re asking us to do. Also can reduce that pressure to, well just add more, just add more, just add more.
Dan Neumann: [27:22] Here’s where the difficulties are lying. Here’s where you know, metaphorically the bodies are buried from a technical debt standpoint. Maybe there’s opportunity to go remove some of those.
Sam Falco: [27:32] Right. And that’s another thing going back to you can always add stuff. So let’s say you get to near the end of the Sprint and you are wrapped up. Well, especially if you’ve been operating in the well, we’ll just roll it forward from Sprint to Sprint previously. Now you have an opportunity. We achieved the Sprint goal. It’s good quality, we’ve got an extra day. Let’s go fix some stuff. Let’s go fix some bugs. We know are in there where we, we know we cut corners and then that also leads to a better relationship with the business. We achieve the Sprint goal by the way, we also fixed these things. Oh, okay, we’re making the product better. And then of course to bring it full cycle. The retrospective, if you did not deliver, that should be the subject of your Sprint retrospective. There’s sometimes a perception that the Sprint retrospective is fluffy time where we just talk about our feelings and well I guess that can be good, but you are there to deliver a product and if you didn’t, let’s talk about what’s in the system that kept you from doing that and how we can maybe do it better next time. And again, over time you start building that trust with the business and it works wonders.
Dan Neumann: [28:37] All right, so we’ve advocated for building trust between the team and the business with a couple of techniques and I think you’re reading something that is about quite the opposite.
Sam Falco: [28:47] Quite the opposite.
Dan Neumann: [28:47] You want to go ahead and share on that one?
Sam Falco: [28:49] Yeah, I’m reading a just finished reading actually last night, a book called Bad Blood by John Carreyrou, and it is the subtitle Secrets and Lies in a Silicon Valley Startup, and it is about Theranose and Elizabeth Holmes. And it is fascinating to me. I festooned my copy with sticky note notes because there was so many things I wanted to remember for later. Mostly as cautionary, do not let this happen to you, type of stories. But the entire enterprise was built on secrecy and deceit, deliberately keeping departments siloed from each other, even if they had to work together on something so that only one person knew what was going on. Um, and then if you did not, if you voiced any concern, uh, apparently according to Carreyrou’s account, Elizabeth Holmes basically decided that meant you were against her and she would turn on you like, and it was just fascinating. The, the phrase I kept seeing, a culture of dishonesty, uh, is, is on one page and a culture of deceit, a culture of secrecy, culture of fear. So it was all of those negative, uh, negative behaviors to the point where towards the end, Theranose was lying overtly lying about its test results so that they would just, Oh, let’s, that’s an outlier piece of data. Let’s throw that out. Oh look, our quality metrics are within the normal parameters. Well, yes, because you threw out the stuff that wasn’t, and it made it look like it was, it was better than it was. And so some people got hurt by that. Some patients were told that, uh, that they were in danger of dying and spent, you know, cancelled a vacation to go to the hospital, yet nothing’s wrong with her. But there were also people who were told, you’re fine. Well, they weren’t fine. Um, it was not as widespread as it could have been because they never expanded that pilot out beyond a few stores in, uh, Arizona with Walgreens. But this was exactly the opposite of what we’re advocating for honesty and what you can do. And, uh, this, in this case, we had a leader who didn’t want to hear honesty. She wanted to hear. Yup, we can do it. We’re going to do that for you.
Dan Neumann: [30:55] Yeah. I don’t think any amount of coaching or Scrumming or anything like that could have solved that problem. I’m just glad to see that it got uncovered, you know, before it got worse than it was.
Sam Falco: [31:06] Yeah. But it’s a fascinating read. I recommend it to anyone who’s interested in just how things can go drastically wrong if you don’t have good values at the core of what you’re doing.
Dan Neumann: [31:16] And do I recall correctly that there might be a couple of movies out on that, maybe one on Netflix, one on Hulu or something like that.
Sam Falco: [31:22] There’s a Netflix one. Um, and I haven’t seen it cause I don’t have Netflix. And then there is one, uh, that I believe is being based specifically on this book that is supposed to come out. Um, I think next year, which will be just in time for the trial to start because both Elizabeth Holmes and her partner, lover, mentor, uh, are also all being, uh, prosecuted for fraud.
Dan Neumann: [31:49] Well, I will have to, I’ll probably catch the Netflix before I read the book. It looked like it was a substantial read. Although very interesting.
Sam Falco: [31:55] It’s a really quick read because, not because it’s simple, but because you just can’t stop. It’s worth reading.
Dan Neumann: [32:02] Okay, I’ll check out. Well, thanks for the collaboration today, Sam.
Sam Falco: [32:06] You’re welcome.
Outro: [32:08] 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 host and the guests and do not necessarily represent those of AgileThought. Get the show notes and other helpful tips for this episode and other episodes at agilethought.com/podcast.