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" 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).
The Team
A description of the team:
There are 30 team members in North America and 26 team members in St.
Petersburg on this project. The St. Petersburg team has one project leader, 3 technical
team leaders, 18 developers, 1 test lead, and 3 testers.
The Mechanics
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.
Emailing Status
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.
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.
Keeping Management Close
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:
ScrumMasters are all in Provo, Utah or Waterloo, Canada, and meet in a Scrum of
Scrums every Monday morning. Here work is coordinated across teams. Architects are
directly allocated to production Scrum teams and all located in Utah. An Architecture
group also meets on Monday after the Scrum of Scrums meeting and controls the
direction of the project architecture through the Scrum meetings. A Product Owner
resident in Utah is assigned to each Scrum team. A chief Product Owner meets
regularly with all Product Owners to assure coordination of requirements.
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
money.
Tribalism Prevention
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.
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.
Other Interesting Items
Check out how detailed the story card is: about one page, single spaced with plenty of bullets and acceptance tests.
Jira is praised as a rich and easy tool for tracking burn down, bugs, and all other metrics.
They had the dreaded 2 week iterations...and note the difficulties they're having getting the testing done. Granted, they don't have enough testers, so it may not be a valid poking point for the 2 vs. 4 week debate.
Worth Looking At
If you're struggling to figure out how to get Agile up and running with distributed development, the paper is worth looking at. It's by no means going to solve your problems, but it'll give you a handful of ideas to drive more tinkering while you're working on making The Big Changes.
Previous Topic
