Johanna Rothman & Mark Kilby on Their Book From Chaos to Successful Distributed Agile Teams

Show Notes

• 00:00 Shane: Good day, folks. This is Shane Hastie for the infoQ Engineering Culture podcast. I'm at Agile 2019 and I've got the privilege of sitting down with Johanna Rothman and Mark Kilby. Johanna, mark, welcome. Good to see you both.
• 00:18 Johanna: It's so nice to see you. Thank you.
• 00:20 Mark: Wonderful. Thanks for having us here, Shane.
• 00:22 Shane: Now, you two recently released a book From Chaos to Successful Distributed Agile Teams. Before we get deep into the book though, let's take two steps back and, who are you and why are you talking about distributed teams?
• 00:38 Mark: I'll jump into that one first. So, I have been using agile practices since some of the first books came out, but I always had this problem that I could never be in the same place as my teams, which really caused me anx for many years.
• 00:54 But then I realized there was some things I could do to try to make connections and try to help the teams inspect and adapt and really to try to get the teams to connect with each other and their stakeholders, even if they were dispersed. I thought I was the ugly stepchild of agile for a long time, but then I realized, well, there's many people that that are put in this situation where they cannot  I have a collocated team, and that's when I started presenting about it and then bumped into my future, or my now current, co-author of the book. As we started comparing notes on these.
• 01:28 Johanna: And you and I had actually collaborated on several workshops and presentations about geographically distributed agile teams in the past.
• 01:38 And more and more of my clients were trying to collaborate over very long distances and very few hours. And I said, there has to be a better way to do this. So, at agile 2017 was that when it was?
• 01:55 Mark: The very last day of that conference. 
• 01:57 Johanna: Well, we were walking to the last session and I said to Mark, "you see anything useful?" And he said, "not really."
• 02:07 I said, "you want to write a book?" He said, "yeah".
• 02:12 Mark: Actually I paused for half a millisecond because I'd heard so many terrible things about going through the book writing process, but with the opportunity to pair with Johanna and having worked with her, I took one of her writing classes and have an a chance to collaborate on that.
• 02:29 I went: this will be fun. And it has been. It's been an absolute joy.
• 02:33 Johanna: Yes. We have laughed.
• 02:34 Mark: We laughed a lot while writing.
• 02:37 Johanna: I think that we had perturbations, but I don't think we ever cried during anything.
• 02:42 Mark: No. Nothing to cry over.
• 02:44 Johanna: Yes. We didn't lose anything, so it was fine.
• 02:47 Shane: And you did this as a distributed team.
• 02:49 Johanna: We pair, wrote the entire book
• 02:51 Mark: Every line in that book was written together synchronously.
• 02:54 Johanna: Yes.
• 02:55 Shane: From different locations.
• 02:56 Mark: Different locations and not always in the same time zone. So, we are both in the U S East coast time zone normally, but sometimes Johanna travels, sometimes I travel. We basically use the principles of our book to write the book, right?
• 03:12 Shane: What makes a successful distributed team
• 03:17 Mark: There's essentially three mindsets that we first talk about. So, one is just being willing to experiment and getting into that simple experiments. Not a huge one, not a bunch at the same time, but doing one simple experiment at a time to see if we change this, would it make our collaboration a little easier? Can we connect with our stakeholders? Things like that.
• 03:42 Johanna: And the next one is about communication and collaboration; that if you focus on how can we use our communication modalities, is that the right word, to collaborate better, we are much more likely to succeed.
• 03:58 Mark: And then the last, and this is where we see many people get tripped up, is they try to take those collocated practices and apply it in distributed settings.  Which is why some people are up at 2:00 AM or 3:00 AM for a standup call or planning, and it's just ridiculous. What we did is we went back to the principals and said, okay, what are the principals telling us we need to have in place to deliver value, to collaborate effectively? To make sure that we are having a sustainable pace as a distributed team?
• 04:30 And that's why we went back to those principles and then evolved them into our eight principles for distributed teams..
• 04:39 Shane: So can we just run through what are those eight principles.
• 04:43 Johanna: Sure, the first one is the whole notion of establishing acceptable hours of overlap. If you do not have at least four hours of overlap, we don't see how you can really use an agile approach, which is so insane.
• 04:58 You can be a team, you can work on a project, you can work on a product, but an agile approach with all of the collaboration and the culture changes. We just don't see it.
• 05:09 Mark: And then the next one is transparency. So one of the traps that teams fall into is if you have distributed team members, everyone gets their little piece of work, their story, and then hides in their micro silo and does their thing.
• 05:24 So instead it's more about, are you being transparent about what's happening within the team, but also are you being transparent about what's happening across the teams? If you have a larger initiative or even more so across your organization, because if you understand more about what your customers are experiencing and that's getting shared throughout the organization, each team can adapt appropriately.
• 05:48 Johanna: And the third one is that business of continuous improvement, preferably with experiments. I am very big on experiments as opposed to let's try something, but even let's try something, there might be some value in that. But if you're not experimenting and inspecting and adapting on a regular basis, we actually don't think that you're really an agile team, where you're not living up to the principles, the agile principles and the lean principles. Cause you're not seeing the whole, for the lean principles.
• 06:22 Mark: And so another principle is, can you create a resilient culture through taking a more holistic approach in how you communicate? So, in that case, it's not just communicating about the work, but do your teams feel comfortable talking a little bit about their personal context and even their personal goals?
• 06:43 Because then you have a sense of when they might be in or out or when they might be available. If there's a family member that might be ill or something. Can the rest of the team adjust for that? Can they be resilient? But also in understanding each other's personal goals, can we shift the work so that people can learn and achieve some of those goals?
• 07:04 So maybe a backend developer wants to pick up some front end techniques?
• 07:08 Johanna: Not okay. No, no,
• 07:10 Mark: no, no, no, no, no. Well, we do that. We do that, we do that. And I know you disagree with that, but some of ours; do not necessarily to try to be a front end developer, but just to say, okay, I want to better understand what the front end developers are dealing with.
• 07:25 Johanna: See, those are really nice people
• 07:29 Mark: I work with very nice people
• 07:30 Johanna: I know you do as an old back end developer. Yes. Okay.
• 07:38 Mark: And we don't agree on everything, as you see
• 07:40 Johanna: It just kills me every time you say that. I know it's true.
• 07:43 Mark: I know. I get the eye roll, which your listeners are not going to see that.
• 07:47 Johanna: Yes, but it's true. I am eye rolling.  One of the things I really like is assuming good intention as a principal because I find that it's so easy to misunderstand each other when we only use asynchronous communication, and that leads to all kinds of issues in the team and in the work. Do you want to do communication?
• 08:08 Mark: Pervasive communication.
• 08:10 So in that one, especially with distributed teams, you'll get into situations where something important is transmitted once and then lost in the ether. So has there been an important pivot in some of the work of a product and did the product owner, product manager, whoever the leader was, just send it out one way and expect that everyone immediately understands it.
• 08:33 Or in a distributed environment, you might have to send it out a few different ways. So in the organization I'm in, sometimes some of those important information start off with a blog post from that senior executive, he will then a couple of days later, have our normal all hands meeting where he talks about it, allows for some questions and then realizing in a distributed environment, we do have a few introverts.
• 08:58 He provides some easier channels through some chat channels, and he has some ask me anything sessions later in smaller groups where people can come back and ask him, okay, what is it about this change that we need to understand? So it's providing those multiple ways of people to understand what is this important change and how does it impact our work.
• 09:18 The flip side of that is taking it too far, where the important message is drowned out by thousands of pull requests and everything else. So watching for that as well.
• 09:28 Johanna: Yes. The next principle I find so important is to create a real project rhythm, and this is not about iterations specifically. I often find that a distributed team might need a cadence of demos that might be different, not every two weeks, and if you don't have enough hours of overlap, I'm not sure when you can say where the iteration starts and ends.
• 09:53 Right? When does it really starting and end? But if you have a cadence and you say, at 10:00 AM Eastern time, we will do this for the people who can be there and we'll record it. And then at 5:00 PM Eastern time, sorry, I'm in Eastern, so I think in Eastern time, either we'll do the same thing or we will do something different for the people who can then participate that way. And that allows you to have a cadence of retrospectives, of demos, of planning, however you do it, of whatever you need. And that's what will help a team actually collaborate as a team.
• 10:32 Mark: And then the last one is defaulting to collaboration because we see so many distributed team members, again, kind of getting in their micro silos.
• 10:42 And how do you encourage more continuous collaboration, especially if you have those hours of overlap. So as an example, we recently formed a team that they're all in the same time zone. So they decided to go with scrum because that works well when you're all in the same time zone and they connect so well that they will do their five 10 minute stand up and then they'll usually spend about 60 to 90 minutes after that basically doing mob programming.
• 11:12 So they enjoy each other's company. They enjoy solving problems together, and so they'll warn any visitors that come in, in their stand up, the standup will be short, but if you stay on for the whole time, you might be here for two hours, but they have become known as the unplanned team because product management has realized they collaborate so well this way, that anything that pops up on the portfolio that was unexpected, they can usually route to this team and they'll take on the work and get it done quickly.
• 11:43 Shane: Why is it the distributed teams seem to be becoming the norm for organizations today?
• 11:50 Johanna: So there's a couple of reasons. Years ago, a senior executive said to me, I want to be able to hire smart people anywhere they are in the world, and he's right up to a point. The problem is if you hire one smart person in China, one smart person in India, one smart person in Israel, one smart person in Germany, one smart person in France, I could continue, but this is an actual team. Well, they call themselves a team, and then of course, all of the US time zones. So having people collaborate where they have expertise is really good, right? People might not want to move to where they are. You have plenty of stories of somebody who was really valuable, whose spouse got moved somewhere.  So the spouse moved with them. There are a lot of really good reasons. There are some bad reasons, and that is to save money on salary. Cause then almost never saves you money on salary. But people are smart all over the world. And why would we not want them as a part of our organizations?
• 13:02 Mark: As part of that being smart is if you are hiring smart people, then allow them to apply that in multiple ways.
• 13:10 So my teams have a lot of choice in how they set up their meetings, set up their process. They have myself and a couple of other coaches in my organization to help them with that, but we tell them upfront, we're going to get you the point where you own your process and that means you figure out your hours of overlap.
• 13:31 So the, you can tell when each other can be the most effective and be the most responsive to collaboration. And so with that, we tend to form smaller teams. So we go on that smaller side of the seven plus or minus two because it's much easier for the team of five to figure out those overlaps than a team of 12.
• 13:52 Shane: We know in the agile environment the importance of individuals and interactions over processes and tools, but for distributed teams, tools become important.
• 14:06 Mark: Yes, they become important, but they still should not drive our interactions. And there's some tools that are out there that can be quite flexible in how they're used and others that are very structured in how the collaboration should proceed.
• 14:23 I tend to shy away from those highly structured ones because, as we have all seen, especially like in a retrospective, sometimes something will come up and you might make need to take the retrospective on a 90 degree turn and you might have to go somewhere else. And a tool that kind of forces you down a path makes it very difficult.
• 14:43 So as I mentioned in my talk yesterday, every team should have a tool box and they should be able to choose what tools they pull out of there to accomplish their work. Now, certainly there would probably be some standardization, like do you standardize on, you know, JIRA, Rally or things like that, but I try to have our teams have a collection of tools, especially for collaboration.
• 15:09 Johanna: And by that you mean audio. Video. Right? Any meeting that does not include video as a default is probably not sufficient for a distributed team. And one more point about the boards: it's fine if the organization decides this is our tool vendor. It's not fine if they decide this is what every teams board needs to look like.
• 15:34 Mark: Yes, the teams  have control of the boards.
• 15:37 Johanna: They need to control the boards. Yes.
• 15:39 Shane: You mentioned the importance of video. You mentioned the importance of flexibility in terms of the, the control of the boards. What are some of the other important tooling characteristics that people need to consider?
• 15:53 Mark: So for many of our meeting tools, there is chat built into those tools. I don't use those. Instead, I find every distributed team usually has some sort of dedicated team chat channel, so why not use that in a meeting to allow people to ask questions if they can't break in on the conversation or to let the rest of the team know that, Oh, I'm having issues. I'm trying to reconnect. But really what I find the value is there's a lot of conversation that happens in the chat, and if you have that in a meeting tool, as soon as the meeting gets shut down, that chat goes away. Even if there's a chat log, nobody ever saves it in a useful place, or nobody ever looks at it again.
• 16:43 But if it's in the normal teams chat channel, if there was important dialogue that happened in chat, the team has that history where they normally talk. And so I always encourage teams, use that as your back channel. Another important thing is, and this goes back to the toolbox concept, is we try to provide a couple of different collaboration tools.
• 17:05 So the, each team might have Zoom and Google meet, so if one service goes down, they're in their back channel already said, okay, we're going to switch to this other meeting. Most of my teams do that in under 30 seconds, so they almost lose no time in a meeting if one tool goes down because they can pull something else out of the toolbox and go right back into their meeting.
• 17:25 It's almost like getting bumped out of the conference room, you know? How do you find a new space to meet.
• 17:30 Johanna: Yes. But you're not wandering the halls,
• 17:32 Mark: You're not wandering the halls, looking for an admin.
• 17:36 Shane: So, we've looked at the principles, the importance of tooling. What are some of the other tips and hints for success?
• 17:43 Johanna: So, one of the things that a lot of new to agile teams don't realize is that the more they collaborate as a team, the more they pair or swarm or mob, the more they keep their work in progress limits very low, the faster their throughput. So one of the things we did, we have a whole chapter about avoiding the chaos and we show a whole bunch of value stream maps.
• 18:09 If a team could somehow look at their value stream and say, where does the work go, first of all, how much is above the line in the work part? How much is below the line in the wait part? And then think about how much flow efficiency do we have? Are we working as resources? I hate that word, or are we working as a team  in flow efficiency.
• 18:33 Every organization is different. I'm not going to say you need to aim for this kind of a thing or that kind of thing. I will say that as an agile team, the more collaborative we are, the more we work in flow of some variety, where we keep our WIO low and we understand our value stream, the more likely we are to succeed.
• 18:56 So the tip is. Make a value stream map of your team of the last couple of features or stories or whatever it was, and see what your cycle time is
• 19:06 Mark: And then how can you reduce those delays, which usually plague a distributed team.
• 19:12 Johanna: Yes, so one of the things that I started to promote several years ago is instead of the teams starting from the product owner, hands stories to the team, which is a horrible thing anyway, the team should collaborate on what the stories are with the product owner. So you actually have the conversation there. Once you understand what you're going to do for the next bit of time, start the work from the East, right? If the East most person is the first person to touch that work, not the last person.
• 19:44 So what I often see, at least in the US is that most of the team is somewhere in the US, there might be a European person, and then there's the lone tester in India. I feel for that person because they almost always feel as if the work gets dumped on them. But instead, if the tester can say, what do we need to do for ATTD?
• 20:07 What do we need to do for possibly TDD or BDD, right, all of the DD's, which is driven development. And we can say if that person actually approaches the work first, we might actually have a really good idea of what to do for the development, what to do for the design, what to do for the user interface, all of this stuff based on what that tester has done
• 20:33 Shane: And the inverse.   What are the common mistakes that organizations make and how do they avoid them?
• 20:41 Mark: Well, we have a long list of traps in the book. Yes. So every chapter in the book has some traps and suggestions on how to either avoid or get out of those traps. There are many, maybe some from the leadership part of the chapter will be good.
• 21:00 Johanna: So one of the interesting things about an agile team, especially a distributed team, is that the leaders need to model the same behaviours as the team. So if you have leaders who do not have sufficient hours of overlap with their team, or with all the teams, how can they actually lead the teams? We don't quite see that.
• 21:23 And I see this a lot where the base of the corporation is in one country, and I'm based in the US so I see this a lot in US-based organizations and they are supposedly responsible to serve all these teams all over the world, but they don't have any hours of overlap. One thing we actually said in the book is that it's important to get people face to face, together at regular intervals actually, and especially the fewer hours of overlap, the more important it is to get people together. And that would be an ideal time, right? If you want to, as a leader, not just go to all of your teams, but to bring them all together, you guys call those meetups.
• 22:08 Mark: So we actually do several things here. So we have our annual meetups where everyone in the product group comes together for essentially a week, especially with our international travellers, and this is run as an open space, so it's whoever shows up are definitely the right people, and they build the agenda each day on what are the problems we're facing? What are the ideas? And you'll usually see the first day a divergence of conversations and then by the second day you start seeing the ideas starting to converge and seeing sort of a prioritization emerge. This last time we had over 200, 'cause it wasn't just engineers, it was also support. It was sales engineers.
• 22:50 So we tried to get business representatives and marketing in there as well. Also, when we have larger initiatives that span multiple teams we'll bring them together. And it might be we rent a space and pull in some whiteboards and say, or flip charts and say, okay, we need to map out, you know, what are the ideas? How are we going to put this together? And they'll kind of put together a rough roadmap of that.
• 23:14 And, so there's actually a third concept, and this came from our senior VP, said, if you are traveling in any area where you know people from the company are at, you are welcome to take them out to lunch, dinner and send me the bill, and just so no matter where you are at, you can build connections with other people in the company.
• 23:36 Johanna: So one of the things we had talked about in our paper in our workshops is that notion of breaking bread, that is so important to eat with people because it's such a social opportunity. I believe that there's the same thing in Fearless Change, right? If you want people to collaborate together having a meal, is there a really good thing.
• 23:59 Mark: Yes. Well, and for our meetups, it's not only having a meal, but having social activities driven by the individuals.  So, for instance, we have a big board game community within our organization, and so this year we provided them lots of board game tables and the hotel staff actually got a little irritated because they didn't want to quit until like one in the morning and it's like, okay guys, we have an early start, we gotta shut this one down. But it strengthened all those people that were across multiple teams,
• 24:29 And there's business value in that, because in those special interest groups, we have now completely run by individual team members, it's not leaders doing this, you build connections across the company so that when you form new initiatives and new teams, they already know each other.  They already know side interest a little bit about family. So there was a connection there already and it's been much easier to form new teams that way.
• 24:53 Shane: Bring the people together and let them share the space and share food.  weird, it's a very hippie kind of thing.
• 25:03 Johanna: Especially since we're here at the Agile 2019 conference where we are sharing space and sharing food and building relationships that will then last throughout the year. Yes. Or hopefully more than for the year.
• 25:19 Shane: Any advice for leaders or team members.
• 25:23 Johanna: So I'll take the leader part of it, at least for now, and feel free to chime in. I think it's really important not to put too much structure on the teams. If you really want to make distributed agile teams work, you have to trust the people on the team.
• 25:39 You have to tell them the results that you want, and the results are not velocity or any nonsense like that. Results are product results or something that affects the customer in some way, right? Those kinds of results and then provide enough tooling for the team to create their own agile environment and team environment, right?
• 26:00 Don't skimp on the tooling. Give everybody licenses, this is still a pet peeve of mine, and encourage people, especially if they have long commute times, to see if you can't create an environment for them at home where they feel comfortable working so that they have the option of extending their times to something that feels reasonable for them, but they're not spending an hour everyday commuting. We have seen team members where if they didn't have to commute for an hour or an hour and a half every day, they could actually have a lot more overlap with the rest of the team.
• 26:39 Some of them live in areas where they do not have adequate Wi-Fi, right? Internet is just not going to be there phone is not there. It's only in the business centre that they have that. But if anything you can do to help, you might think is a leader, that's a very significant capital cost -  it turns out it will save you an enormous amount of money on the cost of delay and on the cycle time for everything that the team does.
• 27:08 Mark: And for the team members, it's actually not terribly different from the co-located teams. I often say, I realize you have expertise in this technical area or several technical areas, but if you don't try to understand a little bit about what the business is trying to accomplish, what you build may be completely useless.
• 27:27 Don't fall into that trap. Right. And even more so with distributed teams if they don't have those connections. So, if you're a team member that doesn't see your product owner very often, you might want to say something about that, Hey, we'd love for you to join us in this meeting, or just come sit with us in the stand up, and that way if we have a couple of questions that day, we can bounce it off you. Or maybe that product owner can offer an ask me anything session every once in awhile, which might be useful for the teams. We've done that as well.
• 27:57 Shane: Really interesting stuff. What else is going on?
• 28:00 Mark: Oh my. So, the book is available in print and electronic forms everywhere, but the next project will be getting an audio book, which a few people asked us about here at the conference, and Johanna has been poking me on that one,
• 28:18 Johanna: Poor Mark - I've poked him a lot
• 28:21 Mark: But also, we realize we can't fly everywhere to teach the material. So, we're putting together some online courses. So, there's one available now. You can get to it in the resources section of Johanna's site, or my site, one course is up now, which is essentially the three mindset shifts, some of the basic principles and team types. The second course, which we'll also be working on right after the conference, we have it outlined, but we haven't started recording. We'll be focusing more for the team and the team leaders going deeper on that, and that's not just video content and worksheets, but also some lab time with us.
• 28:59 And then. The third one will be for those leaders who are setting up those environments that support this distributed team. And we're considering a fourth, but we'll see how the first couple do.
• 29:10 Shane: And if our listeners want to continue the conversation, where do they find you?
• 29:15 Mark: So they can certainly visit my website, markkilby.com M A R K K I L B Y. Blog posts there,  articles and pointers to all the talks and courses and everything. I'm on Twitter as M Kilby, K, I, L, B, Y, and also you can find me on LinkedIn
• 29:35 Johanna: And I'm jrothman.com because back when I got a URL, I did not need my first name and. I'm on LinkedIn, I'm on Twitter and everything is on my website. I have a ton of stuff.
• 29:49 Shane: Johanna, Mark - thanks very much. It's been great to catch up.
• 29:51 Johanna: Thank you.
• 29:52 Mark: Thanks, Shane

Mentioned

• Agile 2019
• From Chaos to Successful Distributed Agile Teams book
• Lessons Learned Teaching Distributed Teams
• Fearless Change
• Mark’s website
• Johanna’s website
• Mark on Twitter
• Johanna on Twitter