Johanna Rothman On Going From Chaos to Successful Distributed Agile Teams (Scaling Tech Podcast Ep12)

Jan 24, 2023 | Agile, Team Management

Distributed teams are a necessity in modern software development, but it’s not easy! In this episode, Arin and David speak with Johanna Rothman, who is also known as the Pragmatic Manager. She is a very well know Agile Management Consultant and author of 19 books on Product Management, Product Development, and even Personal Development. In today’s episode of the Scaling Tech Podcast, we’ll be focused on her book, “From Chaos to Successful Agile Distributed Teams: Collaborate to Deliver!” She will share best practices on building successful distributed agile teams, as well as the traps to avoid.

Johanna talks about how to maintain agility and a learning cycle despite working around the world, team overlaps, the importance of measuring cycle team regardless of methodology, and encourages listeners to assume best intentions when working in a globally distributed team.

If you lead a distributed agile team, or are a member of one, then you won’t want to miss this episode!

You can learn more about her at jrothman.com and by signing up for her Pragmatic Manager Newsletter.

Note: There were sound issues with Arin’s mic in the beginning of this episode which we could not fix in the editing process unfortunately. Please pardon that distortion, it is worst in the beginning and the rest of the episode is much better. We have it fixed for the upcoming episodes!

Listen on Spotify
Listen on Apple Podcasts

Watch the video:
Show notes with links to jump ahead are below

Show Notes from Episode 12 – Johanna Rothman On Going From Chaos to Successful Distributed Agile Teams (Scaling Tech Podcast Ep12)
Timestamp links will open that part of the show in YouTube in a new window

  • 0:00 Arin and David begin by talking about some travel that David recently did, around Latin America, including meeting up with our team in Panama. While he was traveling, a construction crew was remodeling the bathroom in his home, which leads to a funny conversation about how the project went very poorly and now his toilet faces the wrong direction. This was an example of a failure of a remote project.
  • 6:25 Arin introduces Johanna: Johanna Rothman is the Pragmatic Manager, a very well know Agile Management Consultant and author of 19 books on Product Management, Product Development, and even Personal Development. In today’s episode of the Scaling Tech Podcast, we’ll be focused on her book “From Chaos to Successful Agile Distributed Teams: Collaborate to Deliver!” You can learn more about her at jrothman.com and by signing up for her Pragmatic Manager Newsletter.
  • 7:00 The interview begins! Arin brings up how agile methodologies used to discourage distributed teams, and asks Johanna when she changed her mind about remote teams. Johanna notes that at that time, the technology was not as good and so she did not advocate remote work of any time. At that time, the focus on offshoring was about going to teams very far away, with 12 hours of difference, and it was not collaborative.
  • 9:25 By the 2010-2012 timeframe, Johanna realized that she needed to change her opinion and advice around remote teams. She began doing remote workshops for the first time. At the Agile 2017 conference she noticed that no one was talking about how to do agile in remote distributed teams, and so began writing about it.
  • 10:45 Arin talks about how he and David first started to see agile nearshore teams in 2011, and initially Arin was also skeptical of truly remote work. Arin initially advocated for an office in Costa Rica, but eventually as they expanded their team beyond Costa Rica, and David convinced him that they could be completely distributed.
  • 12:00 David talks about how at that time credibility was based on an office with a nice desk, to show you were a serious business. He learned in his early business attempts before AgilityFeat that the expense of an office was counterproductive to a new business. So he learned to be more lean. The great transition for us at AgilityFeat was when we brought in our first team member from Argentina, and realized we could work well across larger timezones. That was an eye opening experience.
  • 15:00 Johanna talks about the different types of distributed teams and common patterns that her co-author Mark named. Nebula teams are where everyone is remote from each other. Co-located teams are those that are within 30 meters of each other (you could be remote simply by being in different buildings on a large corporate campus). Satellite teams are when most people are co-located, and just a few are remote. Cluster teams are those where there are separate clusters of co-located teams (ie, teams in different cities.)
  • 17:15 David talks about how AgilityFeat’s progression as a company was exactly what Johanna described. By default our teams are nebula, by accident we have some clusters because we happened to find people in a few specific cities.
  • 18:30 Arin talks about how one area we have intentionally clustered in our team is Panama City, where our testing group is. This was helpful so the team there could have a lab of mobile devices to test with. How do you see companies decide on these patterns? Is it conscious at all?
  • 19:40 Johanna agrees that testers are a good place to have a cluster, so they can have a lab of devices and a built in community of practice for testing. But developers should be invited into that community too! Having clusters of certain roles can be very helpful. Most of the time when companies talk about hybrid, they really mean Satellite. People have to come in a certain number of days/week, but they still don’t do a good job of facilitating for the remote team members and so they get lost in a meeting.
  • 21:55 Johanna talks about cluster teams being more reliable than Satellite teams because everyone knows where they are. In Satellite teams, the location changes all the time and it can be harder to coordinate schedules. Satellites are the hardest kind to make very collaborative.
  • 23:05 What is the ideal way to design a remote team? Johanna says that senior leadership should not impose work conditions on the team. Let the teams create working agreements, and workshop on those items that require the most collaboration (ie, story writing) and decide how to do that remotely. The team gets to decide when they need to be in person, and what times of day work best for them.
  • 25:45 David points out how Johanna is stressing that collaboration is needed in particular moments the most. Developers like to work alone for much of the time, but there are specific timeframes they really need to collaborate in some form – remotely or in person. That collaboration should be intense so we get the most value from it, and then can go back to our work. Collaboration is expensive, but brings a lot of value and so we must make time for it.
  • 27:50 Johanna talks about how she has remotely pair-written multiple books now, and pariticipated in mob and ensemble programmings sessions. Those sessions are great, but her personal limit is about 5 hours before it’s exhausting. Your mind can only focus for so long in that setting, and then you need breaks too. There’s nothing wrong with taking a nap or a walk in the workday after one of those sessions!
  • 29:45 We need to think about when we work alone, and when we collaborate. Johanna mentions Dan Pink’s book “When” which talks about how our biorhythms work throughout the day. What types of things do you need to do first thing in the morning? How do you power through an afternoon slump in energy? We are each unique in those things.
  • 31:00 David mentions a book titled “Eat that Frog”, and the premise is that the first thing you do each day should be a difficult task, so that the rest of your day goes very nicely. Arin talks about doing the task first which he’s been avoiding. Johanna brings it home by saying that collaborative distributed teams need to decide on the one thing they will do the next day, so they can decide how to attack that work.
  • 33:20 Arin asks Johanna about the powers of overlap, which she mentions in her book and is one area that management can dictate. Johanna likes teams with at least 4 hours of overlap. The reason distributed teams have a bad rap is because in the early 2000’s, well meaning managers thought the wage cost was the defining factor in what a project costs. It turns out that it’s not, cycle time is the determining factor. Johanna talks about teams that she worked with, one of the worst had a product manager on the US West Coast, an Architect in China.
  • 36:45 Arin brings up “Follow the Sun”, and a quote from Johanna’s book that he particularly liked: “Follow the Sun is anti-agile. It is anti-learning … Follow the Sun assumes a factory approach to product development. Software is a learning and collaborative activity, not factory work.” Johanna emphasizes that any type of product development is about the learning cycle, a manager can call any collection of people a team … but if they don’t work together in a collaborative fashion then they are not a team. Too often distributed teams do not actually share a common goal and so it’s very difficult to incorporate learning.
  • 39:30 Follow the Sun can work in a support model, as long as the cases are well documented if the issue cannot be fixed within the work day and have to be passed across timezones. Johanna talks about how hospital nurses do a handoff between shifts, often with the patient in the room so they are part of the handoff. It was only 10 minutes but it was very useful for the patient, and a form of “follow the sun” in the same room. But this is a service type of agreement, not a product development style of activity.
  • 41:30 David adds that if the task to be handed off is easily describable, then the handoff can be made easier, and allows the other party to execute that task. If it’s not describable and easily handed off, then it’s probably not suitable for follow the sun.
  • 43:00 Johanna emphasizes that if support people do need to collaborate to complete tasks, then that 4 hour overlap becomes crucial across teams. A support model should not be 3 shifts of 8 hours, that would not allow for handoffs. Johanna also points out that four shifts would allow for overlap, or 10 hour shifts are needed (with higher pay) to allow for coverage.
  • 45:40 Does it matter if you do Scrum or Kanban in a distributed team? Johanna says it doesn’t matter as long as you have a project rhythm. Be attentive to start/end times of a sprint across timezones, because the timebox of Scrum makes it harder across widely distributed teams. A cadence can work across any timezone though, and so a flow version of agility is important, she cares more about the value stream and cycle time measurement more than the actual method you use. The possible delays in a distributed team pop up all the time, and so measuring cycle time will help make those visible so you can smooth out your product development.
  • 48:30 David notes that Johanna frequently talks about “traps” in her book – what are the most common traps you see in distributed teams. Johanna listed dozens in the book, but the biggest trap may be that people think they can just adopt agile practices without actually adapting them. Do you need a standup if you are collaborating throughout the day sufficiently? The main question is really just how do you move any individual piece of work to “done”? You can’t just assume teams will work the same way remotely that they did in person, so adapting them becomes very important. People want the recipe too much for agility, but recipes are anti-agile.
  • 51:30 When you are starting agile methods for the first time and remote, what do you need to do? Johanna talks about working with senior leadership to reduce Work in Progress (WIP). No team can succeed if you are piling on more WIP constantly, reducing WIP is the first thing that Johanna does with her teams. Focus on making things a little better each week.
  • 53:30 Johanna notes that organizations focus too much on resource efficiency, and not enough time on workflow efficiency. How do you work at all levels to make collaboration happen? Need to reward that as well as specific individual work. David notes how important it is to reduce WIP and how mind-blowing it is when you realize that is the best way to increase throughput.
  • 56:30 Arin and Johanna share what they found most interesting to close the conversation. (David’s video failed so he did not add to this part) Arin really enjoyed the comment about cycle time being more important than hourly rate – the phrasing of that is very valuable and resonates with Arin and his experience over the last decade. Johanna leaves listeners with the importance of assuming good intention – Assume everyone in your distributed team wants to do the best job they can. What would be the way that we can structure this team to best honor the work of the team and assume good intention across cultures and timezones.
  • 1:00:00 To learn more about Johanna’s work, all of her content and books are at jrothman.com!

Links from Episode 12 – Johanna Rothman On Going From Chaos to Successful Distributed Agile Teams