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 talked about the Spotify success story.
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 1000 people in 28 countries. The usual response of companies in this situation is to cut back on some of the agile practices and try to reduce overhead through traditional management.
This trend is also shown by common scaling frameworks that are currently 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 compelling – solution: they first ask what is causing the problems with growth and arrive at the issues
- Interdependence between teams
- Procedures start to get in the way
- Connecting learning and the work in the organization
- Leadership and culture that enable, not limit
Dependence and autonomy
An actively pursued goal is the reduction of handovers and mutual waiting. To this end, practices have been developed in which
- Team autonomy: a team has a very high degree of freedom to shape 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 that team in time.
- Just the necessary standardization: for example, the has found that the version control 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 you need 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, the Scrum processes partly merge into more advanced practices.
Teams become autonomous “squads” that group themselves 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.
A prerequisite for this kind of self-directed creative work is a strong focus on a culture that supports and reinforces it. Thus, the top management sees its main task in introducing the right questions into 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 codebase 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.