{"id":162,"date":"2006-06-01T16:06:51","date_gmt":"2006-06-01T23:06:51","guid":{"rendered":"http:\/\/www.redmonk.com\/cote\/wp\/?p=162"},"modified":"2006-06-01T16:06:51","modified_gmt":"2006-06-01T23:06:51","slug":"a-crack-at-describing-successful-distributed-agile-teams","status":"publish","type":"post","link":"https:\/\/redmonk.com\/cote\/2006\/06\/01\/a-crack-at-describing-successful-distributed-agile-teams\/","title":{"rendered":"A Crack at Describing Successful, Distributed Agile Teams"},"content":{"rendered":"

I’ve always enjoyed papers that Jeff Sutherland authors or co-authors. And the title heavy “Adaptive Engineering of Large Software Projects with Distributed\/Outsourced Teams”<\/a> doesn’t disappoint. The paper dissects how one company SirciDynix managed to achieve a high level of Scrummyness with global dispersed teams that were half off-shored (with StarSoft).<\/p>\n

The Team<\/h2>\n

A description of the team:<\/p>\n

There are 30 team members in North America and 26 team members in St.
\nPetersburg on this project. The St. Petersburg team has one project leader, 3 technical
\nteam leaders, 18 developers, 1 test lead, and 3 testers.<\/p><\/blockquote>\n

The Mechanics<\/h2>\n

Each team is comprised of members from each locale: half the team was in one time zone, while the other half was in another. My expectations would be that spreading teams across geographies doesn’t work, but apparently it worked in this instance.<\/p>\n

Emailing Status<\/h3>\n

The split teams required two stand-up meetings each day: one for the local sub-teams, and one for the whole team. And interesting twist is that people submitted their statuses by email ahead of time instead of reeling them off in the meeting.<\/p>\n

That may seem like a minor detail, but large companies who are figuring out Scrum often get embroiled in political jibber-jabber instead of doing what makes sense. So, that practice, minor as it may seem, documented as working for a Scrum thought-leader helps clear up the afore mentioned j-j.<\/p>\n

Keeping Management Close<\/h3>\n

Another interesting aspect was that management for the teams, including architecture and product owners, was primarily clustered in one locale. Scrum-of-Scrum meetings were held once a week for the ScrumMasters and Architects. Here are the details:<\/p>\n

ScrumMasters are all in Provo, Utah or Waterloo, Canada, and meet in a Scrum of
\nScrums every Monday morning. Here work is coordinated across teams. Architects are
\ndirectly allocated to production Scrum teams and all located in Utah. An Architecture
\ngroup also meets on Monday after the Scrum of Scrums meeting and controls the
\ndirection of the project architecture through the Scrum meetings. A Product Owner
\nresident in Utah is assigned to each Scrum team. A chief Product Owner meets
\nregularly with all Product Owners to assure coordination of requirements.\n<\/p><\/blockquote>\n

I like that arrangement, as it’s often management and other mid-level turf-battles that hold things up. So, getting the people with authority to make things happen all in one room, getting coffee and lunch with each other, and otherwise getting a tight feedback loop between them looks
\nmoney.<\/p>\n

Tribalism Prevention<\/h3>\n

I’m most interested in the aspect of putting all the managers together in one place. In addition to the turf-battle prevention above, one theory off the top of my head is that having all the managers in one place allows them to act like a team, which in turn allows all the developers and QA to act like a team.<\/p>\n

This is opposed to having the managers spread out geographically, such that Manager A is part of the St. Petersburg Tribe, while Manager B is part of the Utah tribe. In that case, in the same way that the positive effects behaving like a team would trickle down, the negative effects of geo-tribalism trickle down to the developers.<\/p>\n

Other Interesting Items<\/h2>\n