Can a Scrum Master Handle Multiple Teams

Podcast Ep. 130: Can a Scrum Master Handle Multiple Teams?

Can a Scrum Master Handle Multiple Teams
Share on facebook
Share on twitter
Share on linkedin
Share on email

Episode Description:

In this episode, Sam and Dan take a deep dive into a fantastic listener question, “What happens in a scaling environment with the Scrum Master?”

What happens when you have one Scrum Master with many teams or many teams and multiple Scrum Masters? With the Scrum Guide not explicitly providing guidance on this topic, Dan and Sam explore the realities of focusing on multiple teams as a Scrum Master, whether or not a Scrum Master can or should handle multiple teams, and real-world examples of scenarios they have seen play out with both. They also discuss the risks and challenges that come along with multiple Scrum Masters coordinating across many teams and share their advice on increasing communication and helping your teams (and organization) understand Scrum.


Listen on Apple Podcasts

Key Takeaways

  • Can a Scrum Master handle multiple teams?
    • With so much on your plate as a Scrum Master, it is ideal to only handle on team at a time (especially if they’re very early on in their Scrum journey; they’re going to need a lot of your attention and focus)
    • It is possible to handle multiple teams but it is dependent on how far they are into their Scrum journey (if one of them is far along and another is newer, it is far easier to manage multiple)
    • It doesn’t make sense to split a Scrum Master’s attention between multiple teams if they are all start-ups
    • As a Scrum Master, you are already splitting your attention between your team and the organization (in helping them use Scrum effectively) — dividing your attention even further between teams can spread you too thin
    • If you are acting as more of an Agile Coach with less focus on the organization, it may be possible to handle multiple teams
    • An ideal scenario would be to have a Scrum Master master per team in the organization and have them coordinate and communicate across these teams
    • Note: In order to be a great Scrum Master, you need to look beyond limiting your role to organizing meetings, enforcing timeboxes, and responding to the impediments people explicitly report (reference Michael James’ Scrum Master Checklist to see the full breadth of what you could be doing in your role as a Scrum Master [if you have the time and capacity])
  • Advice for multiple Scrum Masters coordinating across multiple teams:
    • Have a Scrum Master Community of Practice — make sure that the Scrum Masters are meeting regularly to discuss what’s going on in their teams
      • When a Community of Practice is successfully implemented, you can exchange new ideas which can really help the agility of the teams and the entire organization
      • You can work together on the common challenges you are all facing and rally together to figure out solutions
      • Your understanding of Scrum and your ability to help teams will grown exponentially
      • A cautionary word about establishing a Community of Practice: You may not get outside ideas as easily, which can develop a sense of “group think”
    • Be sure to seek outside ideas — always ask: “What are we not doing? And what can we learn from the broader community?” (Try attending conferences, events, or webinars)
      • Get outside of your organization’s four walls whether that be through podcasts, books, or other resources — always be open to grow
  • The risks of Scrum Masters coordinating across too many teams:
    • The teams may struggle to understand the need for Scrum itself (the “why” behind Scrum becomes lost when Scrum Masters cannot spend enough time with a single team) which leads to dysfunctional behavior
      • Being commanded to do things for the sake of doing them rather than “We need to do Scrum to deliver well” leads teams to become disengaged
    • Simply finding the time to do Sprint Planning together and coordinate the teams
  • Closing thoughts and key takeaways:
    • The Scrum Master will help your team be effective and stay effective
    • By having a Scrum Master focus on one team, they can better help them integrate with the larger organization
    • If you need to have multiple teams per Scrum Master, try to have some balance (in that not all of their teams are new or old)

Mentioned in this Episode:

 
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:16] Welcome to this episode of the Agile Coaches’ Corner podcast. I’m your host, Dan Neumann, and joined today by Sam Falco, a regular contributor and a longtime colleague here at AgileThought. Thanks for joining Sam.

Sam Falco: [00:30] Always a pleasure, Dan, how’s it going?

Dan Neumann: [00:32] It’s going fantastic.

Sam Falco: [00:34] Like we didn’t just spend like 15 minutes talking about how it’s going before we got on the air.

Dan Neumann: [00:38] Well, I mean, sure. There’s the, there’s the stuff in the world is not going fantastic, but uh, you know, I actually got to go to a client site. It was pretty exciting. It was like, there wasn’t a pandemic.

Sam Falco: [00:50] Yeah. I got my second COVID shot on Tuesday and I had planned to take Tuesday and Wednesday off so that I could recover in case I had a reaction. Boy, am I glad I did? I didn’t have an extreme reaction, but I was just fatigued. I mean, stupidly so like where I, I did decide, okay, I’m going to make a run to Lowe’s for something I was going to need. And then I’m almost downtown St. Pete going on, wait a minute. Where was I going?

Dan Neumann: [01:19] That’s just age.

Sam Falco: [01:22] Thanks a lot.

Dan Neumann: [01:23] Yeah, you’re welcome. No, I had a similar, uh, I took many naps the day after, but check that box. Got the, got the COVID shot thing. So, uh, hopefully lots of people are doing that so we can get back to a little bit more normalcy. We have a fairly standing invitation in the podcast for folks to email us with questions to podcast@agilethought.com. That’s also paired with the invitation to submit reviews of the podcast. So, um, we’ll again, reiterate the desire. If you are enjoying the podcast, go ahead and shoot us a review and maybe share it with some colleagues. But we have a question that is going to be the focus of today’s episode.

Sam Falco: [02:00] Yeah. This question comes from, I’m not sure if she wants me to say her name and company online. So I’ll just say on the side of no, as far as we’ll go, Amy, thank you for the question. And her question was, um, around what happens in a scaling environment with the Scrum Master. We’ve talked about scaling the teams. We’ve talked about the fact that in Scrum, you have one product owner. So while some of the scaling tools and frameworks introduce multiple layers of product owner, that’s not pure Scrum, but even those don’t really talk about what do you do with a Scrum Master in a scaled environment? So let’s talk about what happens when you have one Scrum Master, many teams are just many teams and multiple Scrum Masters.

Dan Neumann: [02:46] So I flipped through the Scrum guide again, doesn’t give guidance.

Sam Falco: [02:50] It does not. It does not. It doesn’t even say you have to have one Scrum Master per team. Um, it does not say that one Scrum Master must support one and only one team. Rather than one team should only have one Scrum Master or should only need one Scrum Master.

Dan Neumann: [03:09] Yeah. And there’s a lot of conventional wisdom, you know, pull the string. The Scrum people say Scrum Master can only do one team. It’s a little dolls, pull the string and they, you know, the sounds come out. So there’s, there’s conventional wisdom around a Scrum Master, a team.

Sam Falco: [03:26] There is conversely, there are also, and I’ve been in a lot of organizations that why do I need a Scrum Master for each team? Because, and this a director I worked with actually said, this well, all you do is schedule meetings. And, um, I had to take several deep breaths.

Dan Neumann: [03:43] A little, little tear to your eye. Just kind of rolling down the cheek.

Sam Falco: [03:47]
No sadness. Sadness is not the, uh, the emotion I was feeling.

Dan Neumann: [03:51]
It was rage. Uh, our next episode will be on dealing with emotions, intense situations anyway. You can schedule meetings for like 20 Scrum teams. If that’s all you’re doing.

Sam Falco: [04:11] If that’s all you’re doing, but if you are really fulfilling the role of a Scrum Master and doing all of the things that a Scrum Master ought to be doing, coaching, teaching, helping communications between Scrum team and the rest of the organization, or even within the Scrum team, you’ve got a lot on your plate. Can you really handle multiple teams? Now, the most common wisdom that I hear, and I’ve even said this in my PSM classes is that a Scrum Master could probably handle multiple teams, but there’s always a caveat and that gets lost. So what often comes out of that is people say, Oh, Sam said that a Scrum Master should be able to handle three teams. Well, I said, I have successfully handled three teams beyond that things start to break down. But when I successfully handled three teams, one was so far along in its Scrum journey that they didn’t really need me very often. Another was fairly far along and needed some and one was just starting up and needed me a lot of the time. And looking back on it, I have to say it probably would’ve been better for that team if I had been able to devote my full attention to them for a while, rather than 70% of my time.

Dan Neumann: [05:27]
Thinking through kind of some of those scenarios, um, one of the go-to artifacts, and we’ll put a link to it in the show notes at podcast@agilethought.com is the email. The website is agilethought.com/podcast. Um, so we’ll put a link to the show notes there. And it’s, uh, what is called a Scrum Master checklist that Michael James authored at least a decade ago by now. So not new, but it does a nice job of giving a bunch of things the Scrum Master could do if they had time. And so I like that as a way for Scrum Masters to go, am I fulfilling this role very completely in all the ways that maybe the Scrum guide would advocate for it in good Scrum would advocate for so definitely would encourage people to look there. And then if they find they do have capacity and the organization is asking them to do multiple teams, it’s contextual. If you have two startup teams and a dumpster fire for a backlog, it’s probably not going to work, just split a Scrum Masters attention into multiple teams. And so that’s what you were describing. It was one very mature team, one middle of the road, one new one. And that new one, might’ve got a short shrift a little bit, right? How much you need to just share your time.

Sam Falco: [06:51] Yeah. And also keeping in mind that part of the Scrum Master accountability and that, that role, uh, we sort of starting to use those terms interchangeably now after the 2020 update to the Scrum guide is not just focusing on the team. You are supposed to be helping the organization. So think of it that way. You’re already splitting your attention, your coaching, your Scrum team. You may be helping your product owner understand how best to manage a product backlog. And you’re also supposed to be helping the organization understand how to use Scrum effectively. That’s a lot, that’s a lot to juggle and too often, what happens is the Scrum Master gets pushed into you just work with the team. We have an agile coach who will do all the other stuff. And speaking as someone who has been an agile coach, I appreciate the work, but a Scrum Master is an agile coach or can be an agile coach, uh, and should be able to handle that sort of thing. And if you peg them down to just, you only work with your team, that’s all you do. Then you’re missing out on what a Scrum Master can bring to you. But in that case, a Scrum Master might be able to handle multiple teams because they’re not dealing with the organizational issues that the agile coach, so to speak is handling, but let’s pretend we’re in a scaled environment. We’ve got, let’s say five teams. And we have each team has a Scrum Master. Hooray. That’s like, that’s a great scenario, but then they need to coordinate their activities as well, because you might get one Scrum Master that says has a one approach. And another Scrum Master has a different approach. And we want to talk about those things, those approaches, and find out what works across the organization. And honestly what works for one team might not work for another. On the other hand, when one team comes up with a really spiffy new practice, we want to be able to communicate that across teams and try it.

Dan Neumann: [09:02] Sam, in your five team hypothetical scenario. I’m curious if it matters the degree to which they are all contributing to one product, or if it’s five teams of maybe what their own individual products does, the, uh, the need for in the method of coordination vary the way you see it in those. If the scenario is one way versus the other.

Sam Falco: [09:22] I would think so. I was thinking specifically about five teams on one product. If you have five different teams on different products, there’s still a need to talk about, well, what do you do with your teams? How do you best help them? What are some organizational challenges? We’re all having, whether it’s we meaning just a Scrum Masters or we meaning us teams in a scaled where we’re all working on the same product. I think that becomes even more important because what one team does may affect another team’s ability to deliver does, if that makes sense.

Dan Neumann: [10:03] It does. And so to, to maybe try and get a specific example in a program of work, five teams, all pulling towards the same thing. If you have five different Scrum Masters, trying to fulfill their responsibility of coaching the organization about Scrum, it would help if there’s some consistency, you know, the same thing and some coherence when they’re different, it still makes sense of why they’re different about how they talk to the organization and try to engage in this program of delivery. So, uh, mechanisms, uh, Sam, that you would recommend for, uh, a program with multiple Scrum Masters, all trying to, you know, coach, if you will.

Sam Falco: [10:42] The most common thing I have seen used is to have a Scrum Master community of practice, make sure that these X number of Scrum Masters are meeting regularly to discuss here’s what’s going on with me and my team here are some successes. Here are the struggles I’m having, because you can get insight from your colleagues in order to challenge the way you’re thinking. So I’ve seen that done well, I’ve seen it when it’s done poorly. It doesn’t really help. Um, there was one organization I was at where they said we have a Scrum Master community of practice. And it was someone who had been designated the lead to Scrum Master dictating to all of us. This is how you shall behave, uh, which didn’t really work.

Dan Neumann: [11:27] Like a dysfunctional PMO.

Sam Falco: [11:29] Pretty Much, uh, which that organization also happened to have.

Dan Neumann: [11:36] Smelled it. Yeah, exactly.

Sam Falco: [11:38] Um, but I think even within that dysfunctional area, there were some, there were some benefits we got out of it, mostly because I’m, I got a big mouth on me and I would speak up and say, well, that’s great that that works for your team. Is that really the, what do we really want to standardize that? So if you have some folks in that situation who are brave or just crazy stupid, uh, and willing to speak up like that, then you can get some benefits out of that. But when it’s done well, and more often than not, I’ve seen that it does evolve to something that works well. You get some really interesting exchange of ideas. You get new ideas that emerge out of five brains that no one brain would have come up with on its own. And it can really help the agility of the teams and the agility of the entire organization grow and thrive.

Dan Neumann: [12:38] And so the Scrum Master community of practice could be within a program exclusively. I’ve also seen that done in the five teams with their own products model, as well, less need maybe to create alignment when each team has their own product, it’s still a really good venue for sharing ideas, hearing other people’s ideas. And, and cross-pollinating across the organization for, for things that are working or common challenges that may be all the teams could rally around.

Sam Falco: [13:08] Absolutely. Um, when I first discovered the Tampa Bay, Scrum Master’s Guild, which is a community of practice for the Tampa Bay area and Scrum my understanding of Scrum, my ability to help teams grew exponentially. And so any good community of practice can give you that. One danger that I see when it’s a company saying we’re going to have our own community practice is they don’t get outside ideas as easily. And so there becomes a, you can get a sense of group thinking. All of the knowledge we need is inside these four walls. We don’t need to go outside to the point where people are discouraged from going to conferences, for example, um, we don’t want you going out and sharing proprietary information and you don’t need to go anywhere else. So be aware of that tendency always be looking for what, what aren’t we doing? What aren’t we experiencing here that we can learn from the broader Scrum community?

Dan Neumann: [14:27] It’s interesting to see some of the challenges that do come up, especially with internal communities of practice, where, like you said, it’s, um, maybe the, the Scrum Master group that’s, there has only been from that organization, or somebody from an outside organization comes in with a very different set of experiences around Scrum and that can be disruptive in a good or sometimes a challenging, you know, not so kind of way, uh, as well. So definitely loved the idea of getting outside of the organization’s four walls, whether it’s podcast listening, you know, shameless plug or whether that’s, like you said, you found value in this Tampa Bay Scrum Masters Guild, uh, myself, I got engaged with the Chicago agile community for a period of time, although life happened and that doesn’t happen as much anymore, but really a great opportunity to grow. So let’s, um, we’ve talked about a couple different scenarios. Maybe we could talk about the risks of Scrum Masters being across many teams, multiple teams, or multiple to the point where it becomes too many. What, what are some of the things that might get dropped or become a problem.

Sam Falco: [15:45] I can see a challenge I’ve experienced. This is the teams don’t understand the need for Scrum itself. The first place where I encountered this, where they just kept throwing team after team, after team at me, there, wasn’t a sense of why we’re doing Scrum. We’re doing Scrum because the CTO said we have to, and that led to lots of dysfunctional behavior. Like why do we do a daily Scrum? Well, because Scrum says we have to, and not really an understanding of what we’re supposed to be getting out of this. And so Scrum became a drudgery. I actually had a, an entire Scrum team revolt against Sprint Planning. When the CTO said, you’re not spending enough time on sprint planning. And that’s the reason why you’re not delivering it certainly had a factor in it, but said, you will schedule a sprint planning meeting for four hours and you will sit there for four hours and do your sprint planning. And the entire team said the hell we will.

Dan Neumann: [16:53] Um, no, that was, uh, I do know the word that is apparently the threshold word on Apple. We’ll skip it. And that we have not crossed that boundary yet. All right. Um, 120 something episodes at this point, we only have one bleep and it was probably a little over aggressive, maybe bonus points to whoever can email us who got bleeped. I know, I know employees of AgileThought are not eligible for this contest. Anyway. Um,

Sam Falco: [17:27] The team just revolted, they said, we’re not doing this,

Dan Neumann: [17:30] Treated them like a child says, you’re going to, you will do the thing, you know, go sit in the corner or eat your peas. You don’t leave the table till the peas are eaten. Right. And, uh, yeah, I could see the revolt. Yeah.

Sam Falco: [17:42] And I was sympathetic with them. I had one of the team members tell me, well, I’m not coming and what are you going to do about it? I said, that’s, I’m not authorized to make you do anything that is between you and your manager at this point. Um, I’ll just tell you, I’ve been told to do this. And if we finish inside of four hours, these were two week sprints. I’m not gonna make you sit there. So come or don’t. And, um, well I want to go down too far in that rabbit hole, but the idea was the dysfunction was this being commanded to do things for the sake of doing them rather than because we need to use Scrum to deliver well was a big problem. Um, because teams just didn’t understand why they were doing it because they never saw their Scrum Master, except the Scrum Master is expected to run the daily Scrum. And so we went in and we said, what are you doing? And that of course meant we had multiple, I was going to daily, Scrum, then another daily Scrum, then another daily Scrum, then another daily Scrum and the teams were not getting really any value out of it. Ironically, what was happening was after I left one daily Scrum, they would then figure out what they needed to do today. So they were getting that benefit out of it, but it still was not a healthy environment.

Dan Neumann: [19:01] One challenge I ran into when I had a couple of teams as a Scrum Master was simply finding time. And these two teams coordinated on the same product, simply finding time to do sprint planning together, you know, to experience, uh, sprint planning, scales to, you know, roughly not more than four hours. Um, what we chose to do with there happened to be two rooms that had one of those accordion style dividers between it. So they planned at the same time, there was a little bit of, uh, coordination at the beginning. Hey, generally, where are we going? And then the teams split did their sprint planning and myself as Scrum Master and the product owner would literally sit at the gap in the accordion wall. I could be accessible to both teams visibly and audibly and could kind of float between. So that was one of the techniques I did doesn’t scale to three or four teams, certainly, but, well, I guess you could do big room planning that way, and maybe it scales to a degree, but I’m curious your thoughts on the mechanics of things like sprint planning when you’ve got multiple teams as a Scrum Master and they have to happen about the same time.

Sam Falco: [20:06] Right? Well remember that the Scrum Master doesn’t have to run these events just needs to make sure that the teams understand how to use them well. So being able to float back and forth within them, but again, if, if a team really needs their Scrum Master, especially new teams, they’re getting, they’re getting short changed as a result of that sort of thing. In that situation, I would really like to see a Scrum Master who can sit and focus on this team, help them. And then yes, if, Oh, we didn’t realize we’re going to need team Wolf for this, to do this thing. And they haven’t even selected into the sprint, go run over there and help coordinate with that Scrum Master and then go drag the product owner into it as well. A thing that’s getting left out here. I don’t want to go too far off on this tangent, but remember that we are trying to build teams that are self managing, meaning they should be able to answer a lot of these questions on their own. They should understand the product deeply, not necessarily as deeply as the product owner, obviously, but understand the product, the users, what they’re trying to accomplish. So they should be able to make a lot of decisions on their own. And that’s why in a good, healthy, Scrum environment or a good, healthy scaled Scrum environment, one product owner and multiple teams can work because the product owner says, here’s what I need. You all have got this, come to me, if you have questions.

Dan Neumann: [21:33] And so the Scrum Master then is being responsible for the Scrum framework being, doing what being done well and helping teams learn how to be self managing can facilitate that Scrum Masters scaling, if you will splitting attention then with a couple different efforts.

Sam Falco: [21:52] So I, I saw at one place, there was the lead Scrum Master I talked about earlier, but they said, well, we have, they were using a chief product owner with product owners on the team hierarchy. Let’s create a chief Scrum Master and Scrum Masters on the team. And the chief Scrum Master essentially functioned as an agile coach, did more organizational things and help to the Scrum Masters coordinate, I suppose, that can work. But it very quickly didn’t in this particular organization because that chief of Scrum Master then also had a lot of managerial responsibilities of writing reviews and, and whatnot. And it, it, it just became a traditional hierarchical reporting structure and it didn’t help the team. The teams coordinate didn’t help. The Scrum Masters really coordinate any better than a community of practice would have.

Dan Neumann: [22:47] That’s interesting. Think about a chief Scrum Master role and what a functional one could look like because they don’t really have a Scrum team unless the like a program team would be, you know, their Scrum team essentially.

Sam Falco: [23:03] Right. Nexus has the nexus integration team that it’s accountability is helping the teams coordinate their work and making sure the teams know how to integrate their work. Excuse me, not coordinate. They don’t do the integration work. They just are the experts who do that. And the nexus integration team has its own Scrum Master that helps them use Scrum and use nexus. Well that’s Scrum Master. The nexus guide says may be a Scrum Master from another team, from one of the teams within the nexus. Um, this, the nexus guide gives the guidance that the, if you’re a member of the nexus integration team, the work of that team takes precedence over any other team you’re on. So in that case, you have a Scrum Master who’s on the, the nexus integration team that Scrum Masters Scrum team may suffer because that Scrum Master is focused elsewhere. So once again, I would, I would say that although the nexus guy says that’s okay, I wouldn’t do it. Unless again, you had a Scrum team that was super, uh, fluent in Scrum and had been doing it for a long time together.

Dan Neumann: [24:14] Sam, thanks for diving in and talking through some of the facets of this question we had about scaling the Scrum Master. What closing thoughts do you have?

Sam Falco: [24:25] Remember that the Scrum Master is an invaluable part of the Scrum team. Do not try to shortchange your teams in order to save a little money. Oh, we don’t have to pay three Scrum Masters. We’ll pay one Scrum Master to do three teams. That’s probably thinking in a, um, to what’s the word stingy miserly fashion,

Dan Neumann: [24:48] Literally a little two efficiency might save a penny. You lose a pound. Exactly.

Sam Falco: [24:55] The Scrum Master will help your team be effective, help them stay effective. And by having that one focus, single focus, this is my team. These are the folks that I am helping integrate with the larger organization. When the Scrum Master goes to the larger organization, they have, they have a team in mind to help. If you need to have multiple teams per Scrum Master, try to have some balance, such that the Scrum Masters teams aren’t all new or the Scrum Masters teams, aren’t all old hands, try to mix it up. Uh, so that the Scrum Master can pay attention to those who really need a lot of, a lot of the Scrum Masters attention. I’m trying not to gender the Scrum Master here. So that’s what I’m saying, the Scrum Master over and over again. Um, but still be available to the more fluent or mature team.

Dan Neumann: [25:51] That sounds awesome. Thank you, Sam. At the end, we typically talk about what we’ve been reading.

Sam Falco: [25:58] And I saw on Twitter that you have been reading.

Dan Neumann: [26:01] I done picked up a piece of paper and I read it. I, I, uh, I, you and I recorded an episode on what is agile, a few episodes back. So would encourage people to do that. You applied your history degree to teaching about some of the facets that were preceded agility. Uh, so we talked about Frederick Winslow, Winslow Taylor, and you mentioned a paper by Dr. Winston Royce, uh, called managing the development of large software systems written in 1970, which was kind of, as I understand the place that the waterfall thing came from. Yeah. And, and so I thought I would go read through that and it was pretty interesting. It was very gendered. First of all, tying back to you’re trying not to gender the he for sure. And I, you know, uh, it was definitely gendered, but what struck me as a couple of things that are still extremely applicable today. So he talked even in this paper, so he had the waterfall picture and then talked about five caveats to why that is a problem and some of the costs of rework and things. So that, that was pretty cool. He talked about five modifications you could make to that very simple waterfall to try to be more effective, create some feedback loops. Uh, that was interesting. He goes on to say, Oh, by the way, customers don’t want to pay for this management stuff. 50 years later, that’s still true. Uh, and then one of the fixes in there that really caught my attention was, Oh, by the way, you should engage your customer in, in, in his case, it’s three points multiple times, but at three distinct points, so that you’re getting the buy-in before you ship the product. And I’m like, yep, that’s still true in a different way. But, uh, so it was interesting to kind of, um, you know, flip through, it’s only about 11 pages, 10 pages, some pretty big pictures in there. So I actually got, I got through it.

Sam Falco: [28:11] You’re not only read it. You comprehended.

Dan Neumann: [28:14] I comprehended parts of it enough to tweet a couple of things. So it was a, it was a pretty interesting read. And, um, so folks who want to kind of see what was actually said in this paper that, uh, is responsible for them, the waterfall stuff. Uh, it’s pretty good read. We’ll put a link in the show notes to the Tripoli publication that was scanned. Yeah. Nice. Yeah. How about you Sam?

Sam Falco: [28:38] Well, I’m just coming back from some time off and I did not read anything agile. I went back to the history degree. I’ve got a, a fiction project in mind that has to do with the old West. I’m not sure it’s actually going to fly, but I’ve been doing some research for that. And so I read one book and I started a second. I read a book called the legacy of conquest, the unbroken past of the American West. This was fascinating because it’s not a blow by blow history of the westward expansion, but just points out. Here’s a trend that was true in the 1840s. And here’s how it is still affecting us today. That’s a day in the book being the 1990s. But even then you see some of that presence in our world today, things like the, the Bundy’s takeover of the, the wildlife refuge, a couple of years back stems from an attitude that that many people going West had, that the federal government should subsidize what we’re doing and then stay off our backs, not actually require anything in return for it. And I saw some attitudes that permeate the software development world since it is so heavily Silicon Valley coming out of that. So that was fascinating. And then when I finished that, I just started reading a book called the dead March, a history of the Mexican American war. And, this is something that gets really light touch in most American history survey class. It’s the thing that happened, but Mexico’s side of it is not really touched on at all. And this is a fascinating story of two nascent republics, both of which are assuming that the other country is at first a sister Republic, but then when the goal’s collide very quickly turning on each other more, more so the, the US and then Mexico, and coming to blows in what they both assumed would be a quick and easy victory. And this is of course, endemic throughout history. People say, Oh, it’s going to be an easy war. And then it drags on for many years. So it’s been fascinating to see the, the assumptions and thought processes of both sets of leaders on either side of this war, that, that lid leads to a really stupid conflict that could easily have been avoided.

Dan Neumann: [30:54] And it’s interesting. It makes me think of a different scenarios in the business world, where you have these two stakeholders who feel like are, our priorities are aligned until they’re not. And you know, what kind of dysfunction comes out of there. So, interesting. Well, I’ll look forward to hearing more about that from you. Until next time. Ciao.

Outro: [31:17] 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 episodes at agilethought.com/podcast.

Stay Up-To-Date