Scale without compromise

or: Culture > Process, culture eats process for breakfast

This blog is the start of a series highlighting the various issues and approaches to scaling agile methods.

Henrik Kniberg gave a very inspiring keynote at the Scrum Gathering in Paris (here are the slides): he shared the success story of Spotify.

Spotifiy is one of the important music streaming providers and Henrik Kniberg is one of the most distinguished Scrum trainers.

Henrik related Spotify’s success story to several other experiences, each of which “burned” huge amounts of money, and pointed out some surprising decisions Spotify made.

First, on the scaling model, Spotify’s workforce is growing at 100 percent per year, and there are currently more than 1,000 people in 28 countries. The usual response of companies in this situation is to scale back some of the agile practices and try to reduce overhead through traditional management.

This trend is also shown by the widespread scaling frameworks that are currently being hotly debated in the agile scene, such as SAFe (Scaled Agile Delivery by Dean Leffingwell) and DAD (Disciplined Agile Delivery by Scott Ambler). More about these two frameworks shortly.

This is first of all a natural reaction: the risk is high and one retreats to “proven”, i.e. familiar territory.

Kniberg and Spotify come up with a completely different – and I think a much more convincing – solution: they first ask what is causing the problems with growth and arrive at the issues of

• Dependency between teams
• Procedures start to get in the way
• Combining learning and the work in the organization
• Leadership and culture that enable, not limit

Dependence and autonomy

An actively pursued goal is to reduce handovers and mutual waiting. For this purpose, practices have been developed in which

• Team autonomy: a team has a very high degree of freedom to design its work. Dependencies (e.g. On the code base) drastically limit this autonomy. Instead of turning the autonomy screw, you actively reduce dependencies.
• Open source principle: a team is allowed to copy and modify code from another team if they don’t get a feature from them in time
• Just the necessary standardization: for example, the has turned out that the version management tool GIT works quite well, so it is used by “most” teams.

Procedures get in the way

When introducing Scrum, I am often asked which parts of Scrum to use. My answer is usually: all of them. The parts that cause pain also expose previous organizational and technical shortcomings and weaknesses. If teams are successful with Scrum, they may well outgrow it. Thus, Scrum processes are partially absorbed into more advanced practices.

Teams become autonomous “squads” grouped into “tribes” (departments). People with the same tasks, e.g. testers, organize themselves crosswise in “Guilds” (communities of practice).

Everything has the overarching goal of reducing dependencies without reducing targeting.

Learning and goal-oriented work

Guilds, tribes, and squads help not only with independent work, but also with “alignment” (alignment enables autonomy) – this idea is in contrast to the scaling approaches mentioned above.

Leadership

A prerequisite for this kind of self-directed creative work is a strong focus on a culture that supports and reinforces it. Thus, top management sees its main task as bringing the right issues to the organization.

The guilds hold regular “un-conferences”, and in the squads, behaviors such as blaming and lack of respect for colleagues are strictly frowned upon.

And the software?!

The question is to what extent this type of organization is efficient and effective. One commonality with other methods stands out: the model of a release train is also used, but implemented with very little overhead: Any feature in the code base that is not yet ready can be decommissioned with a “feature toggle”. So it doesn’t hinder the release from shipping on time. Hence the image of the release train: the train leaves on time – you are there on time or not.