Descaling Organizations for Scaling Agile – Part 2

Squads, Tribes, Chapters and Guilds
The company Spotify offers a fascinating model to grow without losing the benefits of being small. Spotify has kept an agile mindset despite having scaled to over 30 teams across 3 cities. This model has gained a lot of popularity in the agile community.
The nomenclature “squads, tribes, chapters and guilds” indicates the resemblance of the proposed structure more with communities than corporations. We have already seen the advantages offered by communities over corporations in this earlier posting.
You can read more about the Spotify model here.

Self Organizing Organizations
Success with Fedex Day got Trade Me, a New Zealand company with 80 people in their engineering team, thinking, “What if we allowed people to organize themselves and do what they wanted to do all the time?” Further inspired by the Spotify model, they decided to let people choose what they wanted to do. They had product owners define 11 work streams for which 11 Squads were formed by allowing employees to choose the squad they wanted to join. They limited the size of each squad to 3 to 7 members. They also ensured that each squad was required to be self-sufficient and co-located.
This unique social experiment inspired and empowered people to self-select. This resulted in stable, focused teams that delivered better. People were happy, as they got an opportunity to do what they wanted with whom they wanted. Read more about this experiment here.
T-Shaped Skills
Decentralization and distributed decision-making demands cross functional skills. These changes also demand new skills as covered in this earlier posting. Augusto Evangelisti shared his experience building an extremely cross-functional team with each member acquiring skills in all functions. T-shaped skills are characterized by deep skills in one functional area like QA and breadth of knowledge in other functional areas like development, product management and operations. For cross skilling: communication, curiosity, respect and empathy are more important than technical skills. No one works alone in these teams. For example, at least three people work on writing a user story. Shared activities made people more accountable and resulted in better quality – 0 bugs, 3X efficiency, shared understanding of goals and mutual trust.
Mob Programming
Woody Zuill shared his experience at Hunter Industries, where he is running their engineering team, using what he calls “the mob programming model” for the last 3 years. The team members self-selected as they were attracted to work together due to awesomeness of the vision. The whole team always worked on the same task whether it was a development, testing or deployment task. That way developers got to think like testers and testers got to think like IT operations. Overall interaction improved which brought in more kindness, consideration and respect. No one was blocked waiting for inputs as all the concerned members were in the same room. There was only one computer and two projectors. The person at the computer worked as the driver and all others worked as navigators. You can see a video of the team here.
The fact that Hunter Industries is supporting this model makes it evident that it must be working. Best requirements, architecture and design emerge from self-organizing teams. There’s no duplication of code resulting from two developers independently working on similar code in their cubicles. No duplication means less code and low technical debt.
DevOps is a cultural change
In a session by Pete Cheslock, the same thoughts were reiterated in a different context. DevOps often gets mistaken for a practice that can be implemented by appointing a few “DevOps Engineers” and buying a set of tools to do continuous integration and delivery. The bigger point gets missed out. DevOps is a cultural and professional movement. You can’t solve social and cultural issues with tools. It’s a journey. No need to hurry to get everyone there today. We need to get everyone’s buy in. It’s a slow process. We have to actively cultivate trust and learning. We have to allow teams to fail and learn. We need to march with a conviction that the direction is right.