Agile Lifecycles for Geographically Distributed Teams, Part 1

I’ve been working with geographically distributed and dispersed teams for the past couple of years. Some of them on quite large programs, some of them reasonably small. What they all have in common is that they all want to transition to agile.

Most of them start this way: someone takes a Scrum class, gets all excited. This is good. Then reality hits. Scrum is meant for collocated geographically cross-functional teams. Uh oh.

Almost all of these teams are separated by function: the developers are in one place, the testers are in another, the business analysts are in a third place, the project managers are in a fourth places, and if there are product owners (or what passes for product owners) they are often in a fifth location. It’s not uncommon for every single function of the team to be separate from every other member of the team. So, the teams don’t fit the Scrum criteria. Uh oh.

Since Scrum has so much brand recognition, these people think if they can’t do Scrum, they can’t do Agile. Nope, not so. What they need to do is start from the values and principles of the Agile Manifesto, and go from there. They create their own lifecycle, and their very own brand of Agile.

When I worked with one client, that client thought they could extend their iteration. Nope, if anything, that means you keep the iterations even shorter, because you need more frequent feedback when no one is in the same place. Well, there were words. And more words. But, if you start from the values, you see that short iterations are the way to go if you want to be agile. Otherwise, you get staged delivery, which is a lovely lifecycle, but not agile.

I’m blogging a series of examples. Please don’t ask me why the people ended up in these locations. I have no idea. All I know is that’s where the people are.

Example 1: Using a Project Manager With Iterations, Silo’d Teams

One IT organization has teams with developers in the Ukraine, testers in India, product managers and project managers in the UK, and enterprise architecture and corporate management in the eastern US.

This organization moved to two-week iterations. The developers were 3.5 hours ahead of the testers, which was not terrible. This organization had these problems:

  1. The product managers had to learn to be product owners and write stories that were small enough to finish inside one iteration.
  2. The enterprise architects had to stop dictating the architecture without features to hang off the architecture.
  3. The developers and testers had to learn to implement by feature so the architects could help the team see the evolving architecture.

This organization had a ton of command-and-control to start. The project managers needed to facilitate the teams, not control them. The architects needed to help the teams see how to organize the product, not to tell the developers what to do. The testers needed to not be order-takers, as in taking orders from the developers.

You might ask why the organization wanted to move to agile. Senior management wanted agile because the releases got longer and longer and longer, and could not accommodate change. Agile was a complete cultural shift. The two-week iterations, along with an agile roadmap of features helped a lot.

The pilot project team consisted of the developers, testers, a product manager, and a project manager. The team rejected the enterprise architect as a member of the team because the architect refused to write code.

Release planning: The project manager and the product manager do an initial cut at release planning as a strawman and presented it to the team. “Can you do this? What do you think?”

Iteration planning: The team does iteration planning together, making sure every story is either small, medium, or large, where a large story can be done by the entire team in fewer than three days. The team makes sure they get every started story to done at the end of the iteration.

Daily commitment: The team does a daily checkin, not a standup. They timebox the checkin to 15 minutes. They ask these questions:

  • What did you complete and with whom yesterday? (reinforces the idea that people work together)
  • What are you working on and with whom today?
  • What are your impediments?

The project manager who acts as a servant leader, not a command/controller manages the impediments.

The pilot project has two experienced agile people: the project manager and a developer. Both act as servant leaders.

Measurements: burnup charts, impediment charts

The pilot team has been together for six months now, and is successful. This is not Scrum. It’s not Kanban. It’s agile and it’s working. They are ready to start another project team, working by attraction.

(Want to learn to work more effectively on your geographically distributed team? Join Shane Hastie and me in a workshop April 17-18, 2012.)

5 Comments

  1. Johanna, thanks for the post and your example of this distributed team. I like the idea of applying the agile values and principles with care not to call it Scrum, or Kanban.

    A recent program of mine had development in Belaruse, testing and the scrum master in Chicago, and product owner and business analysts in Toronto. The three biggest challenges were timezones, language, and ownership.

    Timezones are what they are and this team eventually figured out a way to minimize overall impact on the team for the various meetings. It was the language challenge that really surprised us. With the exception of the scrum master, everyone else on the team was NOT a native English speaker, even though this was the language of the team and the only common language among members. The difference in languages would have been less of an issue with co-location where whiteboard and hand gestures add significant richness to conversations. But with a distributed team that was relying mostly on phone conversations and Livemeeting, it was a big challenge.

    The other difficulat issue was ownership. All team members were trained in agile and all professed to be adopting agile principles and values. But there were signs that team members didn’t fully understand or own the work. The developers in particular wanted to be told specifically what was needed, rather than working collaboratively with the product owner. They were also reluctant to speak up at the meetings and often had to be prompted to provide their answers to the 3 standup questions.

    After 6 months of working together, the performance of this distributed team got a lot better. But it was a lot more challenging than it would have been had they all been located in one place.

    It reminds me of what Craig Larman and Bas Vodde said about large, multi-site, offshore development in their book “Scaling Lean & Agile Development”:
    Don’t do it.

    I look forward to your next examples.

    Kind regards,
    Anthony

    Reply
  2. Johanna,

    Thank you. There are times I worry that scrum’s dominance of the software side of agile is a detractor to growth. If the model doesn’t fit, many just walk away.

    I’m a firm believer in starting agile at the values and principles level and engaging at the management and team interface first. As you said, it’s a cultural shift from command and control to team.

    Best, Joel

    Reply
  3. You are so spot on with the stuff you publish. I’ve been doing and being agile for 6+ years now (mostly ThoughtWorks, now LeanDog) and I have suffered from the dogmatic approaches from colleagues and predecessor trainers and coaches that my clients have hired. “Thou shalt break stories into tasks” is just one example. I consider myself a pragmatic agilist (or maybe, in Ron Paul terms … an agile constitutionalist – focused on the ideals of the agile manifesto over the implementations in the branded approaches). Your writings are very much in line with my thinking on these topics. Thank you for articulating them. I’d love to practice with you some day.

    Reply
    • Adrian, thank you for the compliment. I hope to meet you and maybe we can figure out a way to collaborate. — Johanna

      Reply
  4. Really enjoying this series on distributed agile teams.

    Curious about specifically in what sense is this implementation not Scrum. There are consistent timeboxed iterations, a daily “standup”, burndown. Is it bec there are additional proj managers? Or (wasn’t stated whether they have them) no retrospectives or product backlog?

    Reply

Trackbacks/Pingbacks

  1. Agile Lifecycles for Geographically Distributed Teams, Part 1 - PM Hut - [...] The original article can be found at: http://www.jrothman.com/blog/mpd/2012/01/agile-lifecycles-for-geographically-distributed-teams-part-... [...]

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>