This week, Dan Neumann is joined by his regular guest and co-host, Sam Falco. Together, they’re exploring the topic of agility and some of the early decisions that either create difficulties or opportunities as organizations are moving towards agility.
The decisions that you make early on with your organization can strain you in ways that are unforeseen. It’s one of the reasons why agile coaches and leaders often say: “Don’t make a lot of decisions about your product up-front until you get some data back.” In this conversation, Dan and Sam highlight the key differences between the decisions that are made up-front that can impede a team in the long term vs. the decisions that can help move an organization forward in the right direction.
- Why you shouldn’t make major decisions up-front:
- Making a lot of decisions (or major decisions) up-front can often strain you in ways that are unforeseen
- You shouldn’t make many decisions about your product up-front until you get some data back
- i.e. If you build your entire architecture platform before you deliver any business features, you’re constraining yourself becuase you’ve built a lot of things that may never get used
- The same goes for organizational design (if you make too many decisions about how you’re going to “do agile”, you’ll experience constraints later on
- Agility is suited for conditions of high uncertainty, so when you try to apply predictive thinking to an evolutionary approach, you’ll run into many challenges
- Decisions that are made up-front that can impede a team in the long term:
- Avoid rework (it is sometimes needed/important to revisit decisions you’ve made in the past and fix them)
- i.e. If the bone that you broke when you were 10 healed wrong, you’re going to have to break it again to fix it — the same goes for some of the decisions you make in your organization (i.e. re-platforming)
- Solution: Take on an experimental mindset and ask, “What would it look like to intentionally take on some rework?”
- The key thing to say to clients that are resisting rework would be: “Rework for the sake of rework is bad. But, look at the value you can get and make a good decision based on that.”
- Dedicated individuals on a team vs. shared resources across many teams
- “We have to have people on multiple teams because we’ve got so much going on.” That’s a problem in itself — limit your work in progress; you’ve got too much going on
- Solution: Stop saying, “We can’t do that,” and instead start asking, “How can we?”
- Another team-oriented decision that can cause problems later is a component team vs. feature teams
- It is better to all work together on the same thing and get it done rather than handing it off from team-to-team
- Having one person do two roles (i.e. they’re the Scrum Master and the Product Owner)
- If someone is trying to balance two roles they won’t do either well
- Solution: Take a look at the roles and make sure that they’re being filled in a way that gives a person a chance to be effective
- “Scrum has too many meetings”
- Solution: Have everyone attend the same meetings which will eliminate additional meetings for separate teams — transparency and communication are key
- New Scrum teams using the thinking of, “Let’s just put all of the items into the backlog, and then we will work the backlog until it is empty.”
- This comes from a place of not trusting or understanding incremental delivery
- Avoid rework (it is sometimes needed/important to revisit decisions you’ve made in the past and fix them)
- Key takeaways and final tips:
- Apply a systems-thinking pattern and an experimental mindset
- Abandon the illusion that we can predict the future and that we can control the outcome
- Having a forecast of where you’re going is valuable but it is important to realize that it is not certain
Mentioned in this Episode:
- AgileThought.com/events — Visit for AgileThought’s upcoming virtual events & RSVP!
- “Console Wars: Sega, Nintendo, and the Battle that Defined a Generation”, by Blake J. Harris
- “26 Marathons: What I Learned About Faith, Identity, Running, and Life from My Marathon Career, by Meb Keflezighi with Scott Douglas
Transcript [This transcript is auto-generated and may not be completely accurate in its depiction of the English language or rules of grammar.]
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:17] I have an exciting opportunity. I want to share. Coming up on February 25th, we will be hosting a digital velocity summit. This thought leadership event focused on accelerating innovation is designed for anyone looking to build a state of continuous adaptation, empower their teams to accelerate how they work and deliver value to their organization. With sessions geared for people interested in AI, data analytics, agile, and cultivating innovation in their organization. Our guest panelists and agile thought leaders will share their perspectives during dynamic discussions. Join us on Thursday, February 25th at 11:00 AM Eastern time for this virtual event, go to agile thought.com/events today to learn more and RSVP.
Dan Neumann: [01:04] Welcome to this episode of the Agile Coaches’ Corner. I’m Dan Neumann and happy to be joined today by regular host and guest Sam Falco.
Sam Falco: [01:13] I’m happy to be back on the show.
Dan Neumann: [01:14] Co-founder all those titles. Yeah. Yeah. And I’m so happy. 2021. We’re going to be a couple of weeks in here and I think the people who are lending 2020 with, Oh, it can’t get any worse.
Sam Falco: [01:30] I feel pretty optimistic about 2021. I’m just eager to be vaccinated, of course. And uh, Oh, I am such an extrovert. So, uh, it has been a little difficult for me to be not out. And I think that, um, man, as soon as I am, as soon as it is safe, I am going to practically live in a bar someplace and just like, just talk to strangers.
Dan Neumann: [01:54] I love it. I love it. Just, uh, they need a virtual bar to talk to strangers. So it’s kind of like a podcast. Um, but no, I I’m looking forward to 2021 as well, so far so good from a personally, the topic we want to explore today though, is, is about agility. And some of the decisions that can be made early on when organizations are moving towards agility and how those, uh, create some difficulties or some opportunities as, as they move forward. And of course, I don’t know, maybe it was my Lutheran minister. I always focused on the difficulty part. Like I think that was just how our family worked. Like, what’s the problems? How do we fix those? And so that German Lutheran thing comes through well, because you know, if the stuff’s working well, let’s just focus on fixing things. Yeah. But, um, you know, I think we see that a lot of times with, with clients and as we’re brought in, there are a lot of choices to be made, how the teams are formed, how the work is formed, uh, the environment in which the teams are operating that have impacts long-term.
Sam Falco: [03:02] Yeah, the, the decisions that you make now quite often, uh, constrain you in ways that are unforeseen and unforeseeable. And it’s one of the reasons why we often say don’t make a lot of decisions about your product upfront until you get some data back. Because if you try to do something like build your entire architecture platform before you deliver any business features, well, you’ve just constrained yourself. You’ve built a lot of things that may never get used. And organizational design is exactly the same way. So when we come into a client, I mean, often they’ve already made a lot of decisions about how they’re going to do agile. Uh, there’s air quotes around that do agile as if it’s just a set of practices they can put in place and go and they don’t have to change the way they think about it. We talk about the mindset an awful lot, but it really is important to think about that. And that impacts how we’re gonna, how we’re going to move forward.
Dan Neumann: [04:06] I think one of the reasons I see people wanting that plan is when organizations are exploring agility often it’s from a stance of highly predictive I’ll pick on gantt charts, right? There’s a camp chart for, there’s a PowerPoint with four easy steps to get from A to B and it’s highly predictive. And they’re looking for that same type of certainty as they are trying to embrace agility, which is well-suited for conditions of high uncertainty. And so they’re looking to apply predictive thinking to a kind of evolutionary approach.
Sam Falco: [04:43] Yeah. And I think it comes from partly a misconception about what agile is and they think agile is again, a set of practices. That means we’ll get our stuff faster. Well, let’s talk about what getting stuff faster really means because it’s, it’s not just do all the work faster. So I think you said the phrase embrace agility and I don’t think they are. I think they are thinking we have a new project management methodology that we can just slap in place and everything will be fine. We don’t have to change the way we think about the work. We just have to change the way we organize the work. And so that’s where some of those decisions get made really early without considering the entire system that they’re about to embark on.
Dan Neumann: [05:38] I agree. It, it has, it’s a thinking thing and for fear of knocking us off track, I’m going to share this one anyway. Um, and w you can bring it back. If I, if I follow it up.
Sam Falco: [05:47] Oh, I have to be the adult now?
Dan Neumann: [05:50] You’re going to be the big boy here in this conversation. Okay. It was a conversation about rework and, uh, the team was talking about a particular feature, uh, getting, getting titles for some products that somebody has an a in a CRM standpoint, Hey, let’s, let’s let’s know what products the customer has so that potentially we could sell more products to them cross selling. Great. There’s tremendous value in that. And as the team was doing it, there was another highly complex process that could give you that for free, but it’s going to take time, months licensing a third-party product, building it in, and then, uh, it, God knows what complexities hiding there, but in the spirit of avoiding rework, you’ve got these two tensions. Do you wait for the solution later? The more complex one that’ll give you this thing for free, or do you invest some much smaller amount of time capture the business value and then do the rework later? And it started me thinking about costs of delay. If you put in the lowbrow solution that generates revenue now for one, two, three months, you’ve got tremendous value there. And yes, you might sink a day to a week of rework, but in the meantime, you’ve captured value. In waterfall, we would absolutely go for the big bang longterm ultimate solution in an agile mindset. You might capture that value early rework and then capture more value at differently later.
Sam Falco: [07:20] I think that does tie in directly to what we’re talking about, which, which is the idea that decisions we make now will constrain us later. And this is the same mindset it’s that we don’t want to do rework because once we’ve made a decision, we never want to have to revisit it. We just want to move forward. Well, sometimes you have to go revisit the decision you made in the past and fix things to use a painful analogy. If the bone that you broke, when you were 10 has healed wrong, they’re going to have to rebreak the bone. Hopefully we don’t make decisions that are that painful, but sometimes I’ve come into organizations where they have, they’ll tell you, Oh, we are three years into our agile journey. We’re almost transformed. Like there’s an end state, which right away tells you, Oh, there’s a problem. And you look around and see all of these practices that have been put in place to essentially accommodate an old way of thinking. But given an agile polish, you know, uh, an agile stain over top of this, and, um, I’ve been doing some woodworking lately, just getting wood, uh, standing, you can put a coat of stain on a crappy piece of wood, and maybe you can make it look good. It wasn’t the best analogy, but you know, we’ll move on.
Dan Neumann: [08:52] Well, I liked, so the rework thing we talking about to kind of tie it back in, we do have to rebreak the bones. Sometimes that’s called replatforming when, when your platform is, has become fragile and there’s too much, uh, in ability to update it, a re-platform is essentially that breaking the bone again, thing. Right.
Sam Falco: [09:12] And the problem though, is that often you’ve seen this, well, we’re going to replatform. We’re going to, we’re going to gather all the requirements for our platform into one massive backlog. And then we’re going to guard against scope creep, and we’re going to chunk it up into sprints, and we’re going to build exactly the same thing. We’re just not going to make any of the mistakes we made last time. No. Okay. First of all, yes you are. But even if you avoid those, you’re going to make all new mistakes and then not learn from them. It’s not about avoiding mistakes. It’s about recognizing that we’re human. We’re going to make mistakes. We’re human. We can’t foresee the future. And so we need to constantly be looking at what we’ve built is that right? Do we need to make some changes?
Dan Neumann: [09:56] So the, the mindset of avoiding rework is one of those decisions that’s made upfront that, that can impede a team in the longterm. And the, what might we do about that would be, I think, taking on an experimental mindset or more of a systems thinking and say, what would it look like to intentionally take on some rework because there is value to be captured and shifting that mindset around rework.
Sam Falco: [10:23] Yeah. I think you’ve pointed out the key thing that we would want to say to clients who are resisting the idea is that well, rework for the sake of rework, no, that’s bad. If we’re not getting any value out of it, but look at the value you can get and make a good decision based on that. Um, yeah. Yeah. I had something else, but it’s gone.
Dan Neumann: [10:47] That’s okay. That, that happens too. Um, also with teams. So speaking of teams, uh, dedicated individuals on a team versus shared resources across many teams, and I’ll do the radio commentary, the eyes just rolled.
Sam Falco: [11:07] Yeah. You see this all the time. Well, we have to have people on multiple teams because we’ve got so much going on. Okay. Well, first of all, there’s a problem limits your work in progress. You’ve got too much going on. You’re your organization does not need 135 projects in progress when you’ve got, you know, 30 teams. Um, but more to the point. Yeah. Do you have to do that one organization? I went into, they had that, that attitude and they kept saying, well, we can’t change things. So I said, if you can’t change things and you won’t change things. So stop saying that, start saying, how could we change this? And the person who had brought us in seized on like a terrier with just, I mean, he was the champion of that particular idea. He would hear people say, we can’t stop saying that. How can we, and, and it worked. I mean, they started, it took a while and they still had a lot of work to do when, when my engagement ended. But the idea was oh right, stop thinking. We can’t revisit earlier decisions, stop thinking. We can’t change things because we’re all about changing things. We have to change things because what we’re doing, isn’t working. So stop saying we can’t and stop saying, how could we.
Dan Neumann: [12:31] Yeah. So then, uh, how could we with the dedicated teams versus quote, shared resources, uh, one of the things that I’ve encouraged people to, and I didn’t bend to this idea, you know, maybe you have a team of people that are dedicated to a backlog. And if you have to co-mingle that backlog with a couple of different products, worth of backlog items, maybe that’s an option and I’ll, uh, I’m waiting for the Scrum chain or back of the hand here. When I say that
Sam Falco: [12:59] Actually with the new Scrum guide where we have a product goal, it’s in the product backlog and the rest of the product backlog emerges from that helps with focus. That being said, we have to start somewhere. And maybe if we, if we think that it’s valuable to get people thinking along the lines of we are a team and all we focus on is the stuff that we have in our product backlog start, maybe start there. All right, we’re going to form a team and this sprint, you’re going to work on this problem in the next sprint. You’re going to work on another. And we, we hope that in the future, or we do this with the intent that in the future, we’re going to move towards one product, one product backlog, one team. I mean, multiple teams can work on a product backlog, but you know what I mean, each team is only working on one product backlog, even if they’re working in conjunction with other teams on that same product backlog.
Dan Neumann: [13:55] Yeah. Cause I think of your scenario where you’ve got more projects than teams and, uh, I, uh, in a non consulting life, I was at a place where I think we had two projects per developer. It was ridiculous. I mean, we just, uh, and, and the core portfolio got analyzed every week and gosh, nothing was moving. You have two projects per person. Right. Of course nothing’s moving. Right. And then the questions become what, what stops, because really it stopped anyway. You’re just not saying it stopped. And what do you want to push through to, like I said, limit work in process and improve delivery cadences. Right, right. Right.
Sam Falco: [14:34] And another team oriented decision that gets made that can cause problems later is component teams versus feature teams. And while most frameworks don’t specify, I say, I don’t know. There may be one that specifies you must do feature teams, but I’m not aware of any. We’re certainly bias towards everybody worked together on the same thing and get it done rather than handed off from team to team. I was hired by an organization long before I joined AgileThought. I was a full-time employee. And I came in and they said, well, we’ve been doing this for three years. And they had feature teams, excuse me. They had component teams, meaning they had a database team. They had a front end team, et cetera, et cetera. And they were slow as molasses. Now it was faster than what they’d been doing before, but not by much. And I said, maybe part of the problem is that we need to have feature teams. And they said, Oh, well the consultants who helped us set up three years ago, that’s what they recommended. We decided not to. And that that decision had ossified. And she change that pattern was going to be very costly. They were going to have to re evaluate job titles. They were going to handle all these other things that came along with that. Meanwhile, coincidentally, they had a group that had been three component teams that decided to merge. There are 15 people on this team and I thought, well, that’s too big for scrum team. But fortunately I kept my mouth shut because they actually had like the daily Scrum figured out and they were working together collaboratively and man, and they were going really fast. And people said, well, they’re rockstars. Nope. They were, yes, they were good at what they did. But they were working in this way that I was saying maybe the rest of the organization, we can’t, we can’t became a camp, different, different company, obviously,
Dan Neumann: [16:37] Actually. So the component versus the feature DMC, when you have the component teams, you have so many dependencies, so much, um, so much connection and sequencing and cross team coordination, um, that, that it really can slow things down.
Sam Falco: [16:54] Yeah. And they had incentivized a bunch of behaviors based on the way they had constructed their teams. So that was another way in which the early decision was making things more difficult for them to change because well, now we have to dismantle a compensation structure and an incentive structure and people aren’t going to like that because now you’re messing with bonuses, you’re messing with money. And that creates chaos and uncertainty.
Dan Neumann: [17:19] As you touched on the bonuses and the compensation structure, that’s another decision that’s been made long ago in history for some of these companies too, and, and absolutely can affect the ability for teams to deliver. So yeah, I’ve, I’ve had a scenario where two product owners were incented to sell their individual products, but they had a shared team. So yeah. So let me tell how pulled the team was and how unable to get a single backlog that everybody agreed to because literally somebody’s paycheck was going to get impacted by things that got delivered versus not delivered across. So that’s, that’s a tougher one and it’s nothing the teams can change unless of course, those two POS decided to share that revenue in some kind of lens or gentleman’s agreement, but that’s way beyond their control.
Sam Falco: [18:13] Right. Or they decide, okay, we’re going to point out how stupid this is and push for change and roles. So you just allowed me to segue into another decision that, uh, that people make.
Dan Neumann: [18:28] And I just, I, uh, I, I just dropped my pen and my coffee. So that’s, that’s how 2021’s going for me.
Sam Falco: [18:40] So roles, um, that decisions are made that, um, all right, we’re going to make someone a scrum master, but they’re still going to have to do their old job. And I hear this referred to, as I have my day job, and then I have this job now you’ve given someone two things to do, and now they’re not going to be able to do either one of them. Well, um, or we’re going to, we’re going to have a scrum master and a product on there, and they’re going to be the same person. Congratulations. You just reinvented project manager. Um, you haven’t actually changed anything, but then later on, it becomes harder to make the change and people start blaming, Oh, well, agile doesn’t work. Scrum master is just, all they do is schedule meetings. And what we do, we really need that. Well, if we’re not actually making space for the new way of thinking new way of working, then we’re not getting anywhere.
Dan Neumann: [19:38] And when you have the roles filled in effectively, and I think rotating them, you know, is one of those nobody, really most football teams don’t rotate the quarterback, or if it’s European or they don’t rotate the, the goalkeeper, you know, as, as they go through, because it’s a very special, a used role and, and, you know, rotating, it’s going to screw things up royally. And so, um, you don’t give somebody time to master the craft and to really understand it when these things start rotating, right?
Sam Falco: [20:11] And to, to your point about soccer, I have actually seen where a goalkeeper gets red carded, a team is out of substitution. So they just have to make a defender. The goalkeeper, it usually doesn’t end well doesn’t end.
Dan Neumann: [20:38] So needing to really look critically at those roles and make sure that they’re being filled in a way that gives that person a chance to be effective enough capacity. And maybe those other roles that, you know, you said, congratulations, you’ve reinvented the project manager, looking at the desires that a project manager might fill in a Scrum world and saying, okay, which of these now become the responsibility of the scrum master, which may be go to the product owner, which are developer responsibilities using the new Scrum guides term of developer. It’s everybody else who isn’t the PO or the Scrum Master. Um, and then maybe there’s some stuff left over that really does need a project manager, but, but not just taking the old roles trance saying, okay, we have a Scrum Master that kind of looks like a project manager. So congratulations. You do all this PM stuff.
Sam Falco: [21:34] Yeah. Yeah. The company I was hired into, again, as a Scrum Master and this Oh, and here are all of the things you need to be doing. And it was all classic project management, filling out these forms, making sure this got done. And while much of that did need to be done much of it. Didn’t much of it was if we just leveraged Scrum, we don’t need quite as much overhead, but we, we haven’t adopted a new way of thinking. Once again, it’s just a, it’s a project management methodology and we’re going to just do things the same way we used to do. But now we have new titles.
Dan Neumann: [22:14] Speaking of overhead, let’s talk about meetings.
Sam Falco: [22:17] Oh yeah. We talked about this in one of the episodes or maybe it was a trainer talk episode. Does Scrum have too many meetings? And that’s a complaint we hear all the time. Right. Because we don’t meetings. Yeah. We don’t peel away into the other things we still have. Okay. What’s the value of doing sprint review because we have to repeat all this information at the steering committee meeting next week. Maybe you don’t need the steering committee meeting. Maybe they should come to, to the sprint review and get their questions answered there, et cetera. Yeah. No, and I, uh, I had that,
Dan Neumann: [22:51] Oh, face, uh, almost like, because one of the reasons I’ve heard that the steering committee meeting can’t go away as well. You know, there there’s things that are talked about in the steering committee that can’t be talked about in front of the team. And so what about, what about the openness part of Scrum or for the team?
Sam Falco: [23:09] Yeah. Right. And I’ve heard people know that openness is fine for the team. Oh, no. It has to go both ways. If, if you have transparency into the scrum teams workings, but the scrum team does not have transparency into the organization’s workings. That’s not transparency. That’s a panopticon that is.
Dan Neumann: [23:29] I got to look that one up in the dictionary.
Sam Falco: [23:31] Uh, it’s the idea that, you know, you, everything you do can be seen by someone else who is watching you, observing you, um, very much the like prison pods are often designed.
Dan Neumann: [23:45] Oh, very interesting. Yeah. Um, I think, I think the grocery store that I go to with their one way mirror or the managers said, or the security team is yeah. You know? Yeah. Yeah. I walked down the liquor aisle and the little alarm goes off on the monitor to remind me that they’re watching me as I look for beer. So, okay. Now I understand what panopticon is. So thank you very much. Um, but, but you’re right. It’s it’s, do we really have openness or do we just have a new way of reporting and, and massaging messaging and gosh, maybe it would be helpful for stakeholders to, um, see some uncertainty at the team or to hear about the difficulties and vice versa for the team to know where the uncertainty lies in the vision and the roadmap.
Sam Falco: [24:34] One of the things that I find is that, Oh, we don’t want to talk about this with the team. Well, I think that if you, if the team understands what you’re spending, I think that helps them understand, well, we’ve got to make sure we’re delivering value for that, but making this, this opaque, no, you get paid and we’re not going to tell you anything about how we decide that or anything, because that’ll give us control instead of saying here’s, here’s the situation. Here’s the, the funding we have for this project teams and teams might even say, you’re spending that much on this. There’s more valuable stuff we could do.
Dan Neumann: [25:12] Yeah. I, to just, uh, pretty flashback then to the rework conversation. If somebody were to say this low brow, less sophisticated approach could generate a hundred thousand dollars this year for us, I would guess that the development team members would go, yeah, that’s worth of work. Well, that’s worth a week of rework. And maybe it’s more, I have no idea if the financial, which is part of the difficulty, we’re not talking in terms of dollars. We’re just talking in terms of backlog items with names. So yes, in a vacuum, let’s avoid rework in transparency where we know how much money we could make with this little bit of rework. Yeah. Let’s go get that. Yeah. Yeah.
Sam Falco: [25:55] I watched the Product Owner at one company I worked for just really hammer home that each product backlog item needed to be valuable. He would express that at sprint review, he asked the developers as they were talking about and demonstrating themselves to raise the issue of value. Here’s why we did this. Here’s the value we were expecting to get out of it. So stakeholders then A) understood that developers weren’t just doing stuff because they thought it was cool. They, they understood the value they were intending to get. And by opening up that dialogue, if the team had missed the value somehow or misunderstood, the value stakeholders could say, Oh no, no, that’s not what we meant. Or sometimes, Oh, Hey, we hadn’t even thought of it as producing value in that way. That’s great. And that gave them new ideas.
Dan Neumann: [26:49] And that’s a way to talk about things like technical stories. I hear that phrase, not a big fan of that phrase. Um, if you are doing something for business continuity, disaster recovery, you’re mirroring things from different locations. You are having a fail over test. If you start talking about, if the system goes down, it costs us millions. We did this backend thing. That’s not real sexy. And we can’t really show it to you live in the Sprint Review. Maybe you could, if your fail over really works, maybe just fire that bad boy off, right. If you aren’t willing to, then the question is, why not? Maybe it doesn’t actually work, but I digress. But if you can start talking about this thing has legitimate value. Even though there isn’t a UI component to, it changes the conversation tremendously.
Sam Falco: [27:34] We had to spend time updating our architecture because there’s an upgrade to this component coming and we wanted to do it now. So we didn’t have to do it last minute. That changes things from why are you working on stuff I don’t care about? Well, here’s why you should care about it.
Dan Neumann: [27:51] Let’s talk about backlogs. So as we, since we’re talking about works, sure we’re talking about work. So I’m not sure that was even an English sentence, but all the works, um, requirements, documents, all the stuff we thought we could think of. And of course it never was. That’s why their rigorous change management processes were in place in waterfall world. And I think I see a lot of new scrum teams and using the old thinking of let’s just put all the items into the backlog and then we will work the backlog until it is empty. Yeah.
Sam Falco: [28:27] Yeah. There’s like bunch of stuff going on in there. One thing I have noticed is that, especially when it becomes stakeholders saying, we need to get all the requirements is they don’t trust, incremental iterative delivery yet. They don’t understand it. And so they’re still thinking, well, I’m not going to get anything and for a year and a half or however long it’s going to be. And sometimes we’re even doing it that way. Well, yeah, we’re going to have sprints. We’re going to have sprint reviews. We’re not going to release until we have all this stuff done. Well. Yeah. Well, if you, aren’t going to get a release for a year and a half, you’re going to ask for everything you think you possibly might want and champion all of it being in there, whether you know, that it’s necessary or not, because, because we’re going to be guarding against scope creep. And if I don’t get it in there now I might not ever get it. Whereas if we know that we’re going to get a valuable, useful increment, every sprint, all right. Yes. I can mention that. I want this and maybe even goes in the backlog, but I’m not going to be so antsy that or what happens if I think of something new or I, or a, didn’t say something we can hold that. We can know that. Well, when I think of something new, I can bring it up in a sprint as, Hey, this would be a neat thing. Is it valuable to do? And we can talk about it then, and I might get it in two sprints or we might decide it’s not worth putting in the product backlog that’s okay.
Dan Neumann: [29:51] Yep. And not, you know, when, when there’s enough value, maybe the value of the product atrophies or the value of enhancing the product attributes over time, stop investing in it. Maybe it’s time to that new, the new shiny thing.
Sam Falco: [30:06] Right. We can maintain the product, but at some point cut the tail and put that team on some other product, some other effort that is going to yield even more value for the time and money that we’re spending.
Dan Neumann: [30:18] Wonderful. So to put a little bow on this episode and declare victory, I think there’s been a theme of apply, applying a systems, thinking pattern, applying experimentation to it.
Sam Falco: [30:32] Yes. And just abandon that illusion that we can predict the future and that we can control once we’ve made our prediction, we can’t. And we need to admit that that’s just not possible.
Dan Neumann: [30:47] At the same time predictions, valuable, having a forecast of where we think we’re going is valuable. But realizing that that is, is not a certainty, a determinant thing.
Sam Falco: [31:00] Just because we have spoken, it does not mean it’s coming into existence, that this is what we were hoping for now. But in a little while longer, we may realize that wasn’t where we wanted to go in the first place, or that was great. But now we don’t want to go there anymore. It’s fine.
Dan Neumann: [31:17] Yeah. No, that’s wonderful. So thank you for exploring that. And usually I would ask you what you’re reading, but I’m just going to tell you what I’m reading.
Dan Neumann: [31:30] I am listening to a book about, um, the console Wars between Sega and Nintendo, which is interesting. I’m not through it yet. Uh, but what I did actually finish listening to is a book called 26 marathons. Uh, the marathoners name is Meb because a lot of people I might be pushing Keflezighi is his last name. He’s Eritrean, he’s an American, but he’s an Eritrean heritage. His father apparently walked 200 miles, um, to go get to a place where he could get the family from Eritrea to the United States. So, wow. You know, Meb’s a boss marathoner, but like kudos to his dad for hoofing at 200 miles in a very, um, nasty climate. But anyway, it’s a book, it’s basically a lessons from each of his 26 professional marathons. And it’s easy to think that professional marathoners have it figured out. And it’s just really interesting to see the learnings that he has from each of the events that he then can use for, um, in most cases, improvements in future, uh, races that he’s done. And, uh, some of his setbacks too. And so I just think of, of course, by my interest in running, but then with teams and the need to inspect and adapt and to look at what’s happening, what was successful, what wasn’t successful, what strategies might we want to apply? Just kind of interesting to see that happening in a, in a very different setting. Very cool. All right, well, so there you go. Any, any people looking at inspection and adaptation in marathons, there’s, there’s a framework there. So thanks Sam for grabbing some time here with me.
Sam Falco: [33:10] You’re welcome. Talk to you soon.
Outro: [33:14] 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.