In the Agile 2014 conference we heard many speakers echo the same signal – “Lets descale the organization instead of scaling agile”. There’s an increasing realization that instituting new models like scrum of scrums to force fit agile processes to corporate hierarchies isn’t going to work. Models are rigid and linear whereas human systems are non-linear and need more flexibility. We need to take a hard look at restructuring our organizations to become less siloed and hierarchical.
Many frameworks are proposed. The fact that there are so many makes the magnitude of the challenge evident.
- Scrum-of-Scrum (SoS)
- Large Scale Scrum (LeSS, Larman/Vodde)
- Scaled Agile Framework (SAFe, Leffingwell)
- Disciplined Agile Delivery (DAD, Ambler/Lines)
- Spotify “Model” (Kniberg)
- Scrum at Scale (Sutherland, scruminc.com), meta framework
The Agile 2014 conference can be viewed as the watershed year where everyone agreed that its not about framework – Its about Culture.
Descale your organization
Change in culture needs enterprises to stop paying politics tax. Politics tax is defined as the time spent on CYA. We need to allow people to choose to unleash their potential and stop fearing failure. Fear results in lies and lies result in mistrust. We need to build fail safe relationships.
Olaf Lewitz in his passionate appeal proposed a very simple manifesto “We value people”
Rounabouts Vs Traffic Signals
In an earlier posting I had mentioned that we need distributed decision-making in more decentralized and flatter structures to deal with rising Business VUCA . Bjarte Bogsnes echoed the same thoughts. We need Theory Y organizations to deal with business VUCA. We need to trust our people instead of controlling them with rules and policies. Rules and policies require monitoring and enforcement. Like traffic signals- a rule based system is often inefficient. Roundabouts are self regulating value based system. A roundabout trusts users and demands self-discipline and its scalable.
Budgets force decisions to be taken too high up and too early. Budgets often lead to people spending money even when there’s no need just because they have the budget. Some of them do so to avoid losing the budget next year if they don’t spend it this year. Expense allocation should be need based. We should trust people to spend only what is needed and not have them ask for a budget. Read more about Bjarte Bogsnes’ presentation here.
Squads,Tribes,Chapters and Guilds
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 from 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 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. E.g. 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.
Woody Zuil shared his experience at Hunter Industries where he is running their engineering team using what he calls as 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.