Episode Description:
In today’s episode of the Agile Coaches’ Corner podcast, host Dan Neumann is joined by Johanna Rothman and Mark Kilby. Johanna Rothman is known as the “Pragmatic Manager” and is the author of 14 books (and counting). Through her management consulting, she helps managers and leaders create projects, teams and organizations that work. Mark Kilby is an agile mentor and coach, playing many roles on the software and product lifecycle stage. His passions include serving servant leaders and building sustainable organizations that bring value to the people inside and outside the organization.
Recently, Mark and Johanna have collaborated on the book, From Chaos to Successful Distributed Agile Teams, that teaches how to create a successful distributed agile team and leave the chaos of virtual teams behind. This fascinating book will also be today’s topic of discussion. Johanna and Mark outline the differences between co-located, distributed and dispersed teams; explain why the distinction between all three is important for agile teams; discuss what an agile team is; discuss key principles for these different types of agile teams; and share nuggets of wisdom for managers of these teams.
Key Takeaways
The distinction between co-located, distributed and dispersed teams; and why it’s important:
- A co-located team is one that is collaborating and communicating in person (one that you can simply walk up to and have a discussion with).
- A distributed team is a group of individuals collaborating and communicating via communication technology (AKA a virtual team).
- A dispersed team is where some team members are in one space together while the rest are in another.
- Mark has a simple way of distinguishing between these types through space analogies:
- A Satellite Team: where the bulk of the team is located but you’ve got a small number of the team that is not co-located with each other.
- The Clusters: where the organization has several clusters of people in different locations (i.e. co-located teams that have to coordinate the work).
- The Nebula: where everybody is distributed and works from different locations to collaborate as a team.
What is a team? And what is key specifically for agile teams?
- A team has a single goal (and one that is small enough to be able to actually collaborate together with) and has interdependent work.
- The team has the capability and the hours of overlap to communicate and check-in with each other so that they have the right understanding of their collective progress and goal.
- The team watches out for each other to make sure they’re collectively working toward their goal.
Key principles that will help your distributed team move towards better agility:
- Hours of overlap are crucial in allowing the teams to truly collaborate.
- Flow efficiency for agile teams.
- The team needs to create tighter bonds with each other.
- Self-organizing and self-managing teams.
- Critical for the teams to decide when the meetings occur and to outline their own working agreements.
Nuggets of wisdom and important qualities to uphold for managers that are leading distributed agile teams:
- The three important mindset shifts for managers (outlined in their book) are: manage for change, emphasize communication and collaboration and use agile principles (not practices).
- Great managers have organizational expertise and understand how to get things done in the organization in order to set up the right environment for the teams.
- Managers support teams in their continued growth.
- Experimentation is key to managing for change.
What is Value Stream Mapping (VSM) and how is it an important tool?
- VSM is a lean management tool that helps visualize the steps that need to be taken from product creation to delivering it to the end-customer.
- It’s especially useful for nebula teams that are completely separated from each other (to be able to see where the work is and how much wait time there is).
Mentioned in this Episode
Johanna and Mark’s Book (and TV Show) Picks:
Transcript
Intro: [00:01] Welcome to 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] Welcome to this episode of the Agile Coaches’ Corner, I am your host Dan Neumann and I’m super excited today to have two people joining me. And so the disclaimer is these opinions are going to be those of myself, Johanna Rothman and Mark Kilby and not those of AgileThought or other organizations or other people. So we are, we’re disclaimed Johanna and Mark.
Johanna Rothman: [00:40] Excellent. I always need a disclaimer.
Mark Kilby: [00:43] Free to fire away.
Dan Neumann: [00:46] Folks who don’t know Joanna Rothman, well know her as the pragmatic manager and author of 14 books and counting. And Mark Kilby is an agile coach and community rebuilder and very recently they’ve collaborated on the book, “From Chaos to Successful Distributed Agile Teams Collaborate to Deliver.” And so that’ll be the topic we’ll be exploring today. Thanks for joining.
Johanna Rothman: [01:08] Thank you for having us.
Mark Kilby: [01:11] Oh Dan, this is a thrill. Glad to be here.
Dan Neumann: [01:13] I’m super excited. So tell me about like, why this topic is really important for you folks to write a book?
Johanna Rothman: [01:21] So I have been working with teams who really wanted to use agile approaches and I’ve been teaching my distributed agile workshop for several years and people were still having trouble. They were not using the principles and they were trying to use approaches, an agile approach that did not work for their particular team. And then I said, Mark Kilby knows a lot about this. I should partner with him. So go ahead Mark.
Mark Kilby: [01:53] So for the last, uh, 15 plus years, I’ve had the opportunity to work with many different agile teams, very few of them co located, uh, luck of the draw the situation ahead, whatever you you want to consider, uh, which used to drive me nuts. And then I remember this funny little phrase called inspect and adapt. It’s like, well, we should have a way to inspect and adapt and try to make this work. There’s, there might be some areas where it can’t, but I think we can. And so that’s what I’ve been doing over the last 15 years. Just trying to figure out, right, what is possible.
Dan Neumann: [02:33] And so that, that type of experience, figuring out what is possible, um, led you to, to get together and try and capture some of the learnings from these experiments then.
Mark Kilby: [02:45] Right. So I, I think our stories fall in two camps. It’s either a group that’s distributed that wants to agile to improve how they collaborate and the others that have become, let’s say, accidentally distributed or been, uh, voluntold, uh, to be distributed. Uh, and maybe they were a prior agile team. So those that have been kind of shoved into unfortunate circumstances is that second group of stories.
Dan Neumann: [03:21] One of the frameworks you introduced in the book was the distinction between Co located distributed and dispersed teams and some research that was indicating you become a non co located team once you can start to bridge this gap of 30 meters or Alistair Cockburn described it as the size of a school bus. And I was hoping maybe you could talk about that distinction and why it’s important.
Johanna Rothman: [03:46] So the, the real issue, um, about the 30 meters or the 45 feet or even just 12 meters away, is that people don’t get up and walk to the other person to collaborate or ask a question. And when they don’t actually collaborate in some way, now they are part of some form of a distributed team. So I was seeing teams where the developers were on floors three, four, and five and the testers were on floor 17 or, uh, over in another building. And they thought that since they were in the same zip code they were co located and they were not.
Mark Kilby: [04:31] Right. How often would those people walk to their colleagues to talk about a problem or or gather or was it even feasible they could find a conference room on the fly to have a ad hoc discussion about a design? Probably never. So they, they had to be treated as a distributed team. They need to think of themselves that way.
Johanna Rothman: [04:53] Well, and Mark, you actually had these words, um, before we started to write the book. So do you want to talk about why you use those words of satellite cluster and Nebula to describe distributed and dispersed?
Mark Kilby: [05:11] Sure. So people get tongue tied with co located, distributed, dispersed. What does it mean? I can’t remember. Uh, and so I was looking for um, a better way to describe some of the patterns I was seeing and uh, being a bit of a space Geek, uh, it occurred to me one day I, I could map some patterns and named them things like a satellite team. So that’s where the bulk of the team is co located. But you’ve got one, two, you have a small number of the team that are not co-located and not co located with each other either. So they might be work at home, they might be some expert or contractor that works in a different location, city time zone. Um, the next one are the clusters which are more common in your larger organizations. So the team might have a cluster of people in one location. So maybe that’s the developers and then a cluster, uh, in another location that might be the testers. And then maybe the product owner is somewhere else along with the a Scrum Master or coach. And maybe those two are separated. But you’ve got small groups co located that need to coordinate on the work at hand. And then the last one, which is becoming more common, it wasn’t so common, uh, I would say five to seven years ago, but the Nebula team, that’s where everybody is distributed. Everyone works out of their homes, uh, and they, they tend to collaborate as a team. And so each of those three types have different considerations as you’re setting up their environment, as they’re talking about working agreements, all kinds of things that vary based on the type of team.
Dan Neumann: [07:04] And I love that you give a little bit of a, a framework in the book for kind of visualizing your team with drawing out the individuals, naming the locations you’ve got strong and weak bonds, kind of solid lines versus dotted lines and really helping visualize what the team distribution is like. And then, you know, not just information for its own sake, but you were saying, how do we set up then an environment and what are our working agreements like for those different types of teams. Can you, can you guys expand on, so once we know what type of team we’re enter, we’ve kind of visualized where we’ve got these tighter or looser relationships, how that helps the team move towards more agility.
Johanna Rothman: [07:45] So a big piece of this is actually when we go into the principles in the book. And the first one is hours of overlap. So I had always talked about times zones and when, when Mark and I first started to work on the book, he said, but you know, some people who really liked to work early and you know, some people are really like to work late. So what’s not their time zone is the hours of overlap with the team. And that’s when I had that eureka moment where you say, Oh yes, that’s exactly the right thing. So, um, when we, when we started to talk about hours of overlap, that’s, that’s when we started to realize it almost does not matter the kind of team you have as long as you don’t have a lot of managers pulling the team members apart. If you have enough hours of overlap now that’s what allows the team to really collaborate.
Dan Neumann: [08:51] And so those hours of overlap being a really critical factor. I, I think one of the folks at AgileThought she’s moved to the west coast, but she is awake for eight o’clock eastern time meetings. You would know her. Oh, I know. I don’t know how she does it. Yeah. I wouldn’t survive that way. But it’s not much different than having somebody located in the upper Midwest eastern time zone and somebody in Tampa from a working agreement standpoint and the mechanics of that.
Mark Kilby: [09:21] Yeah. But, but the question is, is that sustainable for her? If it’s not, that’s a problem. But if she, if she is an early bird, if she gets up early and she’s comfortable with that, that might work. I means, she ends her day earlier. She can spend more time with her family. I don’t know the situation, but that’s the kind of flexibility you need to think about with hours of overlap.
Dan Neumann: [09:41] That makes sense. And then you’d, you’d briefly touched on the danger of managers pulling people on the team. And I don’t for fear of it being a rabbit hole that we go down and don’t come back. I was kind of curious how, if maybe now’s a good time to elaborate on the manager’s role in the ability of the team to establish and follow agile principles and working agreements.
Johanna Rothman: [10:02] So I am a huge believer in flow efficiency for agile teams. As soon as you start to think about resource efficiency, and it does not matter if you have a co located or distributed team, you, you break the bonds that create the adult team. So flow efficiency. So it is what really matters. And when managers start to think about flow efficiency, they often change how they manage and they start to look for more affinity in the team rather than affinity with the given managers.
Dan Neumann: [10:42] So you’re looking for the team to create tighter bonds with each other than with the, the managers to whom they maybe functionally report.
Johanna Rothman: [10:53] Yeah, I mean, yeah. Yeah. We talk a lot about self organizing and self managing teams and I suspect that you, Dan, um, have a similar experience than as I do, which is we talk a lot about it. We don’t see that much of it. And a lot of times it’s because the test manager is trying to manage the work that the tester does and the development manager tries to manage the work that the developer’s doing, et cetera. And that just does not work.
Mark Kilby: [11:27] And uh, to try to tie it all together, um, if the team member is managing their time, if they’re more focused on, on one work stream and one product conversations and working agreements within the team become a little bit easier. So we just talked about hours of overlap. So in the teams that I coach, it’s, it’s critical for the teams to decide when meetings occur, not for somebody outside the team. Uh, so there should not be such a thing as corporate work hours on a distributed team. Like that’s nuts. It just, it won’t work. Uh, but the team should set those core hours and so having to work in agreement around that where the team members can decide on that. But if somebody outside, if a manager is directing their time, there’s no way they can even set that work in agreement, let alone stick with it and be available to their team members when those hours of overlap permit, it’s, it’s, it’s going to pull them further and further away from the team.
Dan Neumann: [12:29] Completely agree with that challenge of of managers and, and pulling at the team a lot of times unintentionally. Um, as organizations go towards this agile thing with self organizing teams, a lot of entities that I’ve seen neglect the middle manager role and helping them understand what will their job be in the future. You know, if the individuals that report to them are on a self organizing team and they screw something up or something gets screwed up, maybe it’s not their fault but something goes sideways. Is that manager now going to be accountable for the team that is quote self organizing that they’re not supposed to be in there meddling with? Um, what is their new role? Is their head on the chopping block? Because you know, I think it was an episode with Esther Derby at one point. A lot of agilists said, oh we, we’re going agile. We don’t need managers anymore. So we leave them in a really bad spot. And so helping managers understand how they can enable distributed agile teams to be successful I think could be super important.
Johanna Rothman: [13:32] Well that, yeah, that’s why we have a whole chapter on it about it.
Dan Neumann: [13:37] Are there a couple of nuggets for these managers who might be listening and either how they can or how the organization can help them with that role?
Johanna Rothman: [13:45] Well, that’s where I think the three mindsets, even that, the beginning of the book really make a difference for managers. So the three mindset shifts are managed for change, emphasize communication and collaboration, and use agile principles, not practices. And that whole chapter actually talks about the mindset and, and the eight principles that we have in the book as applied to managers. So, so many managers really want predictability, which would be lovely. I would love to have predictability in everything I do. I have very little predictability. I know when I’m gonna start and mostly when I’m going to end the day, but that’s kind of the only predictability I have. And I’m a one person company. So if I don’t have enough predictability, how can other people? I just don’t get it. So, um, that’s one of the reasons we, we have the mindsets here that we have the principles that we talk a lot about it and, and, and use the inspect and adapt ideas. And if we, if we encourage and manage for change, now we, we have a real chance of doing a good job.
Mark Kilby: [15:10] Yes. And in some ways their job doesn’t change at all. So you still need somebody who has organizational expertise that understands how to get things done within the organization to set up the right environment for the teams. Do they have the right tooling? Does everyone have access to the tooling? Uh, do they have licenses? Do they have the appropriate training? Uh, along with that, uh, somebody has to plan the startups of, of teams. So who better than the person that understands what, what resources, and I’m talking tools, not people. Um, you know, what resources are available to the teams, uh, to, to come together. What do they need? What training do they need? What support do they need for their initial launch? These are the people they had the subject matter expertise, the organization. They are definitely needed. And as the teams continue in their, their growth and production, what else do they need to, to maybe, you know, take it up to 11 as they say, you know, so, you know, how can the, how can the managers support them in being even more awesome?
Dan Neumann: [16:36] The three mindsets you said manage for change, emphasize communication and collaboration and then principles versus practices. Um, you know, I, I really, I love that things will change. Yeah. I know we have a time box for doing the recording and, and we have a general outline that we’re following and uh, within that we’re kind of exploring and things will change as we go along. So, and then, uh, the communication, collaboration and principles versus practices I think is important. Cause a lot of times framework names aside, there’s a perception that we’re going to go agile and we can grab this framework off the shelf. Look, there’s a book, there’s consultants, there’s a certification, let’s grab it, we’ll shove it down people’s throats and then we’ll be agile. Um, and I like that you’re talking in here more about the principles and the mindset and experimenting then doing the inspect ended up using empiricism to then go forward with the agile.
Mark Kilby: [17:37] Yeah. It’s still a thinking person’s game. So you can’t not assume that you’re going to take something off the shelf and apply it to a distributed team. That would almost be like, I’m going to buy some off the shelf random hardware and launch somebody into space. How well is that going to go? Probably not very well. Uh, so instead you have to study where, where’s the environment I’m launching this team into? Oh, you know, what do they need is as part of that. So we give the principals as guidance and we give many, many stories to show. There’s several different practices that can apply to these principles. And the best thing for you is to think about an experiment on it. Uh, not just apply with vigor. That doesn’t always work well.
Johanna Rothman: [18:26] And we actually, I don’t remember if this story made it into the book. I was working with a team from a very large fortune 50 company, um, where they had senior people in China and junior people in Vietnam, and then a bunch of various people all across Europe. And the product owner was in California and there were other people in the U.S. So it was kind of a large team to begin with and they didn’t have every time zone, but they had so many time zones that they had insufficient hours of overlap and they wanted to use a well known framework. That depends on iterations. So I asked the obvious question, when does the iteration start, when does it end? If you can decide that, sure you can use an iteration based approach, but if you cannot decide when the iteration starts and when it ends, why would you do that to yourselves? And they didn’t, they didn’t have an answer.
Dan Neumann: [19:37] I’m curious about the degree to which they had the autonomy to choose to or not to follow an iteration based approach. Was that something within their purview or…
Johanna Rothman: [19:47] Well, it turned out that when I asked that question, they were then able to ask their managers, when do you want to see demos? And then the Chinese manager said this time and the California people said that time and they didn’t agree. So the team said, you know, until you guys agree, we’re just not going to use iterations we’re going to use flow, we’re going to show our work on a Kanban board and we’re going to, we’re going to keep getting the work done. It turns out that they had to reconfigure the team into two smaller teams with more hours of overlap in each team. And even then they continued to use flow. Not because iterations are bad, but because they could not answer the question, when does it start and when does it end?
Dan Neumann: [20:40] And the hours of overlap seems like there’d would be a major challenge in that scenario. Yup, Yep.
Johanna Rothman: [20:47] And they actually moved to two teams because they didn’t have enough hours if overlap. So they could not really use an agile approach as, as this one large team they could use, they could figure out an agile approach for two smaller teams.
Dan Neumann: [21:04] And that’s a good segway to one of the questions in the book, is agile even the right approach for your team? So the book is about successfully delivering with an agile distributed team or distributed agile team. And maybe agile is not the right approach. So some scenarios in which maybe teams would not be benefiting from agility.
Johanna Rothman: [21:29] So I have heard about follow the sun. Everyone knows I am an old consultant, right? I am in my sixties now I have the gray hair to prove it. Um, I have heard about follow the sun since the 90s, maybe the 80s and it didn’t work in the 80s. It didn’t work in the 90s. Offshoring was a disaster because all the brain power, all of the assets of the knowledge organization were literally offshore and out of time sync with the people who needed the information. Um, we now have the tools so we can collaborate when we can all be awake. But I have, I have yet to see follow the sun work for knowledge work. It works for handing off, right? So, and we’ve, if you’ve, if you’ve ever been in a, in a hospital, you might even have seen the handoff that nurses do. My husband had a very bad bicycle accident several years ago. I was lucky enough to be there when the nurses changed over and they had 15 minute conversations. We might think of them sort of as a stand up, but they were not really a stand up. They were literally a handoff. Patient A needs this. I just did that. Let me reinforce this with the notes in the medical record. That 15 minute conversation, that hand off allowed them to have the continuity of care. That kind of a thing can really work in a, in a software team. And I don’t really think of it as an agile approach.
Mark Kilby: [23:10] Hmm. And I have actually worked with teams like that. So early in my agile career I had teams where they would sometimes have to go on site to deploy and install the software. These particular customers, because of their security concerns, could not have any Internet connection at all. And so you would bring physical media, uh, to, to be installed. And they were usually 12 to 13 hours away during these events. So when that happened, there were handoff points where the deployment team would be installing testing and then they would sync up with the development team back, back home and say, here’s some bugs we found. So the development team would then work on it and then pass solutions back. They could email small snippets or suggest small changes and they would hand off back and forth sometimes for a period of two weeks. They would not go continuously this way. But during deployments, this is, this is when they would do it.
Dan Neumann: [24:17] And I, I know you have a definition, what team means that you use within this book too. So you know, the handoffs in your, your nursing example isn’t, isn’t really a team. Maybe if we’re doing support tickets or infrastructure support global teams following the sun so that somebody’s always awake, making sure the infrastructure’s working. Um, what’s your working definition of team for this context of agile teams?
Johanna Rothman: [24:45] So the way, the way I like to talk about it is a team has a single goal, right? So any, and it has to be small enough to be able to actually collaborate together. They have interdependent work. Um, I believe that we use a definition of teams and make sure that they, every team has this one single goal and they have interdependent work. Is there something I missed, Mark? Maybe I did.
Mark Kilby: [25:18] Nope. I think I think that that’s good. Uh, the thing to keep in mind is sometimes that goal can change. So while if you’re, if you’re working on a product, the vision probably won’t change often, but the focus of the team on how they’re delivering that vision will change. So does the, does the team have the capability and the hours of overlap to communicate and check in with each other that they have the right understanding of when that change is going to occur? Why is this important now? So maybe they’re developing for new market segment or, or there’s some other, uh, event coming up. Let’s say they’re focusing on getting new features out for conference demo. Uh, so does the team understand that change in focus and are they watching for each other on how they can help each other get to that goal?
Dan Neumann: [26:09] So Mark and Johanna, one of the things I really liked about the book is the way it’s structured. So each of the chapters really focuses on a particular aspect of distributed team agility. There’s one about the hours of overlap and then it goes on to the team types, communication, how to set up your workspace, how to cultivate your culture. And it keeps going on. And then each of these chapters has a now try this. I find it really nice to have some really tangible activities that I can go try my teams.
Johanna Rothman: [26:44] So, and we also have traps just before that. Now try this. Cause we, you know, if we hadn’t seen all these anti patterns then we would not have added the traps. But we see them and people, you know, people only we have the benefit of, um, I get to see a lot of various clients. Mark gets to see a lot of various teams. We have this perspective of kind of looking across where a lot of teams get to see their stuff. And I don’t really mean in a silo, but they don’t really get to see how they might look or might work compared to other teams. So when you, when you look at the various traps, you can say, oh wait a minute we do that. That’s not such a good idea. Maybe we should experiment with it now try this. And one of the things we, when the huge problem we have with the now try this is, is how to frame, just a few now try this’s.
Dan Neumann: [27:55] Because there are an abundance of things to try.
Johanna Rothman: [27:58] Yeah, we had a lot to suggest.
Mark Kilby: [28:02] Yeah. Well and also as you might remember Dan, for the big, from the very beginning of the book, we talk about the three mindset shifts and that that one of managing for change experimentation is, is key to that. So that’s probably one of the best things anyone can do is start off with small experiments, get the team involved, see what they are willing and not willing to experiment with. Try some small things, make sure you have a, a time where you’re going to say done. I’ve seen some teams where they just run their experiments forever and they don’t really go back and reflect, that’s not as useful. But if you kind of pick a point where you can say, okay, we’re going to take a look at where we are now with the experiment. Did we prove what we intended to prove? Like around hours of overlap and maybe shifting our schedules a little bit to be more comfortable for us and allowing more collaboration. How did that work out? Uh, so experimentation is built into the book with the now try this. So the idea is you can set up your own experiments to try the ideas in each of the chapters.
Dan Neumann: [29:10] That’s very cool. And it, coincidentally enough, we have an episode with Adam Ulery on the experimental mindset and the importance of that in agile teams. So if people are looking to dive a little deeper on that, we’ll do a little plug for that right now. But I love the fact that you’re talking about doing experimentation and one of the techniques he introduces value stream mapping. And I think we talked a little bit too before we clicked the record button, like this is a really important aspect, the value stream mapping piece, an important tool for getting started. Can you elaborate on that?
Johanna Rothman: [29:47] When we, um, when we first started to write the book, I actually thought, oh, only people within sufficient hours of overlap would need a value stream map to see where their work flows and doesn’t flow what’s the work time and the wait time? And then I actually started to work with a Nebula team that’s all dispersed in one time zone. And I thought, holy Moly, these people need a value stream map also. So I think especially when we are separated from each other, it’s so hard to see where is the work and how much wait time do we have. So that, that was really a key. And I think that Mark, how often did we iterate on here’s how to draw a value stream map? First we had a very complex map and then we reorganized it. And Yeah, I think we, we iterated on that part a lot.
Mark Kilby: [30:53] A few times and, and we had many stories that we could tie to this. Some of them we had to pull out of the book or the book would have been a huge, uh, maybe, maybe there’s a workbook in the future, I don’t know. But uh, but the, the key is using, using the value stream map to see what is the actual time that it takes to do certain steps in your workflow and what is the time that the work just sits. And for remote teams, that can be an enormous amount of time if they’re not paying attention. Uh, and, and managers need to see this too, especially as they start looking at who do I pull together for a team? Uh, you know, if, if there’s day, two days, sometimes week long gaps and in work sitting round, I bet that’s not going to be a very agile team.
Dan Neumann: [31:43] Yeah. And I like that you iterated on the value stream map because as a consumer it was pretty easy to see the picture. I, you know, I’m not going to have to go buy a software tool to go do the value stream map. I think I could, I think I could muddle my way through that so that um, it was nice that I could draw it on a napkin.
Mark Kilby: [32:02] Yeah, you could put it in front of your camera so you can share with your team. Very simple tool.
Dan Neumann: [32:07] Absolutely, yes. That’s been done before. And the other thing I think you touched on briefly, the book’s not huge, so just over 300 pages, very consumable, you know, even for a guy like me that reads a really slow, I love that aspect of it.
Johanna Rothman: [32:25] Thank you. We worked really hard to make that book readable.
Dan Neumann: [32:29] That’s outstanding.
Mark Kilby: [32:31] Thank you. Yeah.
Dan Neumann: [32:33] Well, thank you for sharing so much about the distributed agile teams. Um, I know you’re the books on lean pub and of course it’s on Amazon.
Johanna Rothman: [32:41] Oh, it’s everywhere. Fine books are sold. Every pits everywhere. Yup. You can buy it all over the world in print and ebook. Yep. It’s everywhere.
Dan Neumann: [32:51] That’s outstanding. Good. It’s nice and portable that way. One of the things we ask folks at the end typically is what they’re reading that maybe has them inspired or, you know, sometimes it’s something somebody who’s watched or listened to, but I’m curious kind of what’s piquing your interest from a continuous learning journey right now?
Mark Kilby: [33:09] So I’ve been a fan of the, uh, the Amazon prime series, “Man in the High Castle.” And if you haven’t seen that, I, I don’t want, I don’t want to give away spoilers, but it’s, it’s about an alternate history. Um, so, uh, print this way. What happened? What happens if the Nazis had won World War II? So the reason I find this inspiring is I sometimes think about teams and organizations that have invested a lot in certain ways of working. Um, and I wonder, wow, what kind of alternative histories could they have written if they just experimented?
Dan Neumann: [33:52] Oh, interesting. Instead of pushing all the chips into the middle of the table and then, you know, they’re stuck with it, with the sunk cost. And that’s interesting. Yeah.
Mark Kilby: [34:02] And add a lot of rigor and, and rule following and yeah.
Dan Neumann: [34:08] Yeah. And roles and policies and you know, titles and, yeah. Oh, that’s interesting. Okay. Well my son’s asked me if I’ve watched that. I haven’t yet, but I might have to give that one a shot. So thanks for, thanks Mark.
Johanna Rothman: [34:20] Yeah, I think I’m going to have to watch it. I’ll also, yeah, so I am, um, I am almost releasing my management, my modern management made easy triad and I’ve been reading all about theory x and theory y and Deming and um, accounting for slavery. It turns out resource efficiency is based on slavery management. Oh, by, yes. Cost accounting for humans is based on slavery. Caitlin Rosenthal wrote “Accounting for Slavery.” And if you are not horrified, you should be. So it’s astonishing. So I’m reading all these, um, management books and of course, um, you know, I am, maybe you don’t know, I’m, I’m learning how to write fiction also. So I’m reading a ton of mysteries and a ton of romance and a ton of science fiction. Um, so yeah. And yeah, I am reading short stories for feedback, right. So I’ve been, I’ve sold half a dozen short stories now, so it’s time to, to write more.
Mark Kilby: [35:40] I was gonna say you’re writing output is impossible to keep up with.
Johanna Rothman: [35:42] I don’t think keeping up is the answer. I think we all find our own writing rhythm and, and that’s, that’s what we do.
Dan Neumann: [35:54] Your rhythm, your rhythm is very impressive.
Johanna Rothman: [35:58] Well, thank you.
Mark Kilby: [35:59] Yeah. I could say, I can safely say I’ve seen glimpses and it’s high frequency.
Dan Neumann: [36:05] Amazing. Well, so we’ve got everything from “Man in the High Castle” fiction to “Accounting for Slavery,” which sounds pretty dark and, and um, then fiction writing. So. Okay. That’s a good stuff. Yeah. Wow.
Johanna Rothman: [36:18] Well, I also just, I also just finished “Educated,” by Tara Westover, which I should have been kind of uplifting, but for me it was kind of dark also. So yeah, that’s why I’m reading a bunch of romance now as a palate cleanser because I need my happily ever after.
Dan Neumann: [36:36] So educated is a nonfiction then I’m assuming based on that.
Johanna Rothman: [36:41] Yeah, it’s nonfiction. It’s a memoir.
Dan Neumann: [36:43] Yeah. Well, good. Well, my, my continuous learning journey was your book and so that was recently consumed. I don’t know what’s going to be next, but learning about the distributed agile teams and the way you guys wrote about it made it really approachable, I thought was very helpful for the community. So thanks for doing that.
Johanna Rothman: [37:01] Thank you.
Mark Kilby: [37:02] Thanks Dan,
Dan Neumann: [37:03] And thanks for joining me here. All right, we’ll talk again soon.
Mark Kilby: [37:06] Thank you for having us. Thanks.
Outro: [37:10] This has been the Agile Coaches’ Corner Podcast brought to you by AgileThought and get the show notes and other helpful tips from this episode and other episodes at agilethought.com/podcast.
