Sharing our experience of self-organizing teams

The Rangers program was started in 2006 using a rigid process, based on the Microsoft Solutions Framework (MSF). Our journey of continuous experimentation was triggered in 2007 while exploring the Agile Manifesto. We were asked to unblock a large team of 30+ engineers, divided into a development and a quality assurance team. They were not communicating and no-one appeared to have an understanding of the overall state of the project. After dog-fooding the “daily scrums” event ceremony the two teams became one collaborating unit, discussing, analysing, and resolving its challenges as a team. We documented the experience using a fun to read science fiction eBook (free).

We evolved from MSF, Scrum, and Ruck, sharing our learning in another eBook. We learned that our program was based on living organism with different operating requirements and methods. Imposing a hard process was holding the teams back. During 2015 we began to experiment with self-organized teams, with amazing results. In 2009 we had 2 PMs, 200+ Rangers, and were working on 5 concurrent projects. After introducing self-organized teams, we had 0.5 PM, 100 active Rangers, and were working on 10 concurrent projects, delivering continuous value.

Find the supporting presentation here.

Yesterday, Rui and I presented our journey and learnings at the Regional Scrum Gathering event, in Porto.

Here’s a crisp summary of the working model and tools we discussed.

Summary of working model we discussed today

1. We’re based on part-time volunteers, each investing an average of 1.75h of family time per week.
2. We’re working with the full-time Visual Studio TFS and Team Services engineering teams (product group).
3. Our 1 to 10 teams are cross-functional, autonomous, self-organising, and each using its own goal and DoD, aligned with our overall program mission, vision, and goals.
4. We’re using the same sprint name and 3-week cadence as the product group.
5. The Ranger PM is responsible to normalise the vocabularies and set expectations used when communicating with the product group and Rangers.
6. Ideas received from the community (you) and the product group are triaged and captured on the Scrum based backlog of the Rangers.
7. The Ranger backlog is synchronised with the TFS/VSTS backlog of the Ranger team.
8. It’s important to highlight that (4), (5), and (7) result in the product group seeing the Rangers as just another one their engineering teams, and the Ranger teams feeling empowered and part of the product group.

Summary of tools we discussed today

The tools discussion was short and sweat. One of our goals is to continuously dogfood Team Services, using the planning, build, and release services, and rubbing a little DevOps on all our pipelines. The self-organising teams, however, are free to chose their development tools, and the tasks within each build and release definition, demonstrating the support for “any tool on any platform”.

Key learning’s top date

Finally, we shared our key learnings (so far):

• A community with a common vision nurtures vibrant teams
• Teams that identify themselves with their “process” produce more
• Given the chance, teams will define their “process” and commit to it
• Being involved in decision making fuels energy and commitment
• Autonomous teams are more passionate and likely to succeed
• DevOps enables and focuses teams
• Program Manager is key to enable, connect, and encourage teams
• Small energetic “teams” deliver more value than a larger “group”

Share your thoughts and ideas with us!