At the Global Scrum Gathering in Paris, France, Henrik Kniberg kicked off the first day with his opening keynote. He was speaking about how culture overcomes process – whether you want to or not.

Kniberg defined culture are the stuff that people do without noticing it. When people carry their bodies to the Daily Stand-up just because the ScrumMaster tells them, that is process. When people get to the Daily Stand-up because that is how we do software development around, then that is culture. Kniberg explained that an Agile culture leads to better products and happier employees. In the end, we end up in a better world. (I missed some unicorns at this point.) Kniberg described how fragile Agile is. He showed the story from the Swedish police which he wrote about in Lean and Agile from the trachnes. They started a project to build a software for the officers on the streets. They introduced Agile & Lean, a gradual rollout, real users were involved, bottom-up decision making, value-driven and a suitable tech platform. The project ended in a media success with happy users and a happy team. Even they won an CIO award in the end. Skip forward a few years, and the project was overtaken by the surrounding organization. They implemented waterfall with big-bang rollouts, and an inappropriate tech platform. Real users were no longer involved, and decisions were made in a top-down manner. Overall they changed from value- to cost-driven. It was a media disaster with furious users and furious team members. This is how you can burn one billion euros, Kniberg concluded. Kniberg continued with the story of Spotify to show a positive example of a great culture. Even though Spotify doubles their employee numbers, they have industry’s top-notch employee happiness. Why? Kniberg explained the Shu-Ha-Ri model. At Shu-level you follow the rules, at Ha level you start to adapt the rules as you see fit, at Ri-level you ignore the rules. Kniberg cited Scrumbutophobia, that is the fear of doing Scrum wrong. The pre-valent symptom for Scrumbutophobia is a Scrum implementation being stuck in the Shu-level focusing on the practices alone, rather than the principles. For Spotify, Kniberg explained that they focused on five principles from the Agile world, these are Continuous Improvement, Iterative development, trust, simplicity, and servant leadership. However, they found a sixth principle that had great impact: autonomous teams. In Spotify teams are called squads. Autonomous squads follow a mission, are small, and co-located. Squads organize themselves and have full end-to-end resposibility for the stuff they build – from design to commit to deploy to maintenance. Each squad has a mission. Within the scope of its mission, a squad is empowered to decide what to build, how to build it, and how to work together while doing it. Spotify steers the autonomy of squads with their mission. The broader the mission, the more autonomy the squad has. Kniberg cited Pink from his book Drive that motivation comes from autonomy, master and purpose. That is why autonomy has such a large role at Spotify. Squads follow the guideline to be autonomous, but don’t suboptimize. Kniberg showed some examples from their office how they get this in place, like hang-out areas for cross-squad collaboration, sprint demos and open discussions. Kniberg continued by explaining the relationship between autonomy and alignment. He explained with a 2×2 matrix that high autonomy and high alignment lead to an innovative organization, and collaborative culture rather than conformance or people diverting into different directions. One way they applied that at Spotify was to measure dependencies between squads by asking the people. All squads at Spotify own their own quality, they sit together, have a mission, and a ProductOwner in their team. They also follow an Agile approach. Most squads do retrospectives, have a physical taskboard, do demos. Most squads also either use Scrum, or Kanban, or both, and have an Agile Coach alongside with Daily Stand-Up meetings. Some squads rely on estimates, and measure their velocity. Some also have Scrum of Scrums meetings, and maintain burn-up or burn-down charts. Kniberg showed an example from their happiness survey. The email contained the results from the latest happiness survey: 91% happy, 4% not happy. Instead of putting up how remarkable that is, the email stated that this is not sufficient for them, and if you happen to be among the 4% of the people being unhappy, please get in touch. This is how you nurture a happiness culture. Kniberg continued with concepts that I had heard at other Spotify talks before. If you happen to be at a conference with some Spotify talk, I recommend going there. To me it did not have too much to do with culture, but more with how they cared about their people. Kniberg explained how the concept of tribes combines squads, and how chapters came into play at a certain point of scaling. Kniberg showed the vicious cycle of most release processes in place. Releasing is hard, so you release seldom. Because you pile up so much stuff to release, releasing it becomes hard, of course, and this is where the vicious cycle closes. On the other hand, if you make releasing easy, you release more often automatically. One way Spotify achieves this is by decoupling as much as possible. Kniberg continued with the importance or trust. He explained how fear can kill motivation. He cited a CEO from some other large company that said

The reward for doing a good job today is having a job tomorrow.

Of course, such a culture leads to fear, and blaming. Instead Kniberg showed how important failure is for learning. Citing facebook’s “move fast, and break things” is something you need to build inside your culture. At Spotify they have retrospectives and post-mortems focused not on blaming but on learning. They also have blog entries on their internal blog starting with “how we shot ourselves in the foot” that expose that learning to the larger organization, and keep the blaming out the door. One thing that helps with this is to have a limited blast radius for all the components. If something goes wrong, not the whole platform goes down, but just the single piece that squad is responsible for. Of course the squad then knows they need to fix that immediately. Kniberg continued on why value & impact is more important than velocity. He explained how Spotify embodied the Lean Startup cycle in their culture. They start with an idea or problem. They build a narrative and a prototype to solve the problem. Then they build a minimal viable product, which they deploy, and analyze data to learn quickly. Kniberg showed a continuum between predictability and innovation. He put waterfall methodologies on the end with the predictability. Typically Scrum lies on the middle of that continuum. Kniberg stated that Scrum at Spotify lies more on the innovation side than typical Scrum implementations. They unleash innovation with hack days, and hack weeks which may take up to 10% of employee time. Kniberg paraphrased empirical process improvement mind-set that experiments & data are mote important than discussions and opinions. In an experiment-friendly culture, for example, when deciding between Tool A or Tool B, you try both, and compare them after some time, and then make the decision. Kniberg described that at Spotify they got rid of meetings that were useless for them. They also don’t have PMO & PM roles, time reporting, hand-offs, acceptance test phase, task estimates, and all the other things you may find at other corporations. Instead they decised to keep retrospective, daily standups, google docs, git, and go to conferences. Kniberg also showed how the put improvement boards and the “Definition of Awesome” in place with multiple Kanban boards for improvements where you could zoom into a ticket to follow the whole improvement process, and the experiments they ran before. Kniberg cited lessons they learned from big projects. The first mantra is to avoid big projects whenever possible. If you can’t avoid them, then sync daily to resolve squad dependencies, and demo your product weekly in order to evaluate the integrated product. Kniberg described that they also ran a big experiment: a personal bonus system. They found out it doesn’t work since it was a large failure. Another bit experiment Spotify ran was a tech-wide hackweek. One whole week everyone in tech (300 people) could build whatever they wanted, with whomever they wanted, in however way they wanted. They also had a demo & party on Friday. It was a large success. Kniberg continued how to spread and nurture the culture. They have dedicated roles for culture and improvement. There are Agile coaches for some squads alongside with the People Operations team that focuses on the culture. They together form the Agile coaching community. One element to grow their culture is that every new employee is sent on a boot camp for one week. After that week, they put software into production in their second week, and demo it. Another example in Spotify’s culture are social groups, like board games, movie visits, and so on. Kniberg concluded with their pain point. They have unstable squads, which means new squads are formed regularly anew, or new people come into the squad restarting the whole team building, eventually. Also, scaling breaks stuff all the time so that yesterday’s “brilliant solution” is today’s impediment. Cross-timezone collaboration and technical debt are two other points Kniberg mentioned. But, Spotify found out that culture has a healing effect. Although all these points seem painful, they do not last for long at Spotify. A lot from Kniberg’s talk reminded me about the Spotify talk I heard at Agile 2013. I also could see things at it-agile that we struggle with, and that work for us. I think I can take some of the factors like alignment and autonomy back to implement them in our company.