In 2008, we were pretty much a Scrum company ... however, a few years later, we had grown into a bunch of teams and we found that some of the standard Scrum practices were actually getting in the way. Rules are a good start, then break them when needed. We decided that Agile matters more than Scrum.
Autonomy means the squad decides what to build, how to build it, and how to work together while doing it. One consequence of autonomy is that we have very little standardization. When people ask things like which code editor do you use or how do you plan, the answer is mostly depends on which squad. Some do Scrum sprints, others do Kanban ... it's really up to each squad. Instead of formal standards we have a strong culture of cross-pollination; when enough squads use a specific practice or tool, such as git, that becomes the path of least resistance, and other squads tend to pick the same tool.
Why is autonomy so important? Well, because it's motivating and motivated people build better stuff.
-- from Spotify Engineering Culture (Part 1) by Henrik Kniberg (0:30-4:40)
Instead of blindly following Scrum dogma, I advise you to analyse the problems you and your company face daily. Reason about them. Consider applying Agile and Lean principles to them. Experiment to see what works for you and what doesn't.
After feeling isolated and alone in resisting the Scrum imposition, reading Spotify's story has cheered me up. I've become more hopeful that things will change, that over time more folks will come to see the benefits of greater team autonomy.
Autonomy and Alignment
It's kind of like a jazz band, although each musician is autonomous and plays his own instrument, they listen to each other and focus on the whole song together. That's how great music is created. So our goal is loosely coupled but tightly aligned squads.
Down here is low alignment and low autonomy, a micromanagement culture, no high level purpose, just shut up and follow orders. High alignment and high autonomy means leaders focus on what problem to solve but let the teams figure out how to solve it. Alignment enables autonomy.
-- from Spotify Engineering Culture (Part 1) by Henrik Kniberg (3:20-3:50)
For high autonomy to work, you need high alignment. With low alignment, teams simply do whatever they want, with each team going off in a different direction.
Specialists vs Generalists
Each system is owned by one squad. But we have an internal open source model and our culture is more about sharing than owning. Suppose squad one here needs something done in system B and squad two knows that code best, they'll typically ask squad two to do it. However, if squad two doesn't have time, then squad one doesn't necessarily need to wait. Instead they're welcome to go ahead and edit the code themselves and then ask squad two to review the changes. So anyone can edit code but we have a culture of peer code review. This improves quality and spreads knowledge. Over time we've evolved design guidelines, code standards, and other things to reduce engineering friction, but only when badly needed.
-- from Spotify Engineering Culture (Part 1) by Henrik Kniberg (5:10-6:00)
The basic unit of development is the squad. Because each squad sticks with one mission and one part of the product for a long time, they can really become experts in that area. A tribe is a collection of squads that work in related areas. The chapter is your small family of people having similar skills and working within the same general competency area (e.g. QA or Web Development), within the same tribe. As a squad member, my chapter lead is my formal line manager, a servant leader, focusing on coaching and mentoring me as an engineer, so I can switch squads without getting a new manager. A guild is a more organic and wide-reaching "community of interest", a group of people that want to share knowledge, tools, code, and practices. Chapters are always local to a tribe, while a guild usually cuts across the whole organization. Some examples are: the web technology guild, the tester guild, the agile coach guild. Anyone can join or leave a guild at any time. Most organizational charts are an illusion, so our main focus is community rather than hierarchical structure.
-- from Scaling Agile @ Spotify (with Tribes, Squads, Chapters and Guilds) (pdf) by Henrik Kniberg & Anders Ivarsson and Spotify Engineering Culture (Part 1) by Henrik Kniberg (7:30-8:50)
Alistair Cockburn (one of the founding fathers of agile software development) visited Spotify and said "Nice - I've been looking for someone to implement this matrix format since 1992 :) so it is really welcome to see"
-- from Scaling Agile @ Spotify (with Tribes, Squads, Chapters and Guilds) (pdf) by Henrik Kniberg & Anders Ivarsson
In learning more about Spotify, I was also glad to learn how they deal with specialization. You see, this tricky topic has been a chronic nuisance for us, for a number of reasons.
First, code quality. New code written by a generalist, and reviewed by a generalist, is a long term code quality nightmare. Can you imagine what Perl code written by a ten-year Java veteran with a few days of Perl experience looks like? I can because I've seen it. There have been times when I've opened up a Perl file and rolled on the floor laughing because it was clear that whoever wrote it had no understanding of Perl at all.
Second, employee engagement. Though many programmers are happy to become generalists, a significant minority (including me) are deeply dissatisfied with that role. I derive much more job satisfaction from doing an expert job in something I deeply understand than from "cargo-culting" some code that seems to kinda work even though I lack a deep understanding of why. I find that dissatisfying. I do not want to write Java code that causes my Java expert colleague to roll on the floor laughing.
Another problem is that system architecture can be compromised if nobody focuses on the integrity of the system as a whole. To mitigate this risk, Spotify have a "System Owner" role. All systems have a system owner, or a pair of system owners (one with a developer perspective and one with an operations perspective is common). They further have a chief architect role, someone who coordinates work on high-level architectural issues that cut across multiple systems.
Healthy Culture Heals Broken Process
Trust is more important than control. Agile at scale requires trust at scale. And that means no politics. It also means no fear. Fear doesn't just kill trust, it kills innovation because if failure gets punished people won't dare try new things.
-- from Spotify Engineering Culture (Part 1) by Henrik Kniberg (12:40-13:00)
We focus on motivation, community and trust rather than structure and control. Healthy Culture Heals Broken Process.
-- from Spotify Engineering Culture (Part 2) by Henrik Kniberg (0:40-0:50, 12:00-12:30)
I've seen first hand how a healthy organisational culture of good communication and continuous improvement can effectively solve process problems.
I've also seen first hand how a culture of fear and an over-emphasis on control and structure can harm innovation.
We aim to make mistakes faster than anyone else. Continuous improvement, driven from below and supported from above. Failure must be non-lethal and with a "limited blast radius". Lean startup principles: think it, build it, ship it, tweak it. The biggest risk is building the wrong thing. Release first to a small percentage of users, then use A/B testing, then gradually roll out to the rest of the world. Impact is more important than velocity. Innovation more important than predictability.
-- from Spotify Engineering Culture (Part 2) by Henrik Kniberg (2:00-)
These are some of the ideas used by Spotify to build and release product. Since there is enough in this installment already, I'll postpone a discussion of Lean startup and related ideas to a new series of articles.
Related PM Nodes
- Nobody Expects the Agile Imposition (Part I): Meta Process
- Nobody Expects the Agile Imposition (Part II): The Office
- Nobody Expects the Agile Imposition (Part III): People
- Nobody Expects the Agile Imposition (Part IV): Teamwork
- Nobody Expects the Agile Imposition (Part V): Meetings
- Nobody Expects the Agile Imposition (Part VI): Architecture
- Nobody Expects the Agile Imposition (Part VII): Metrics
- Nobody Expects the Agile Imposition (Part VIII): Software Craftsmanship
- Building the Right Thing (Part I): Pretotyping
- Spotify Engineering Culture (Part 1) by Henrik Kniberg
- Spotify Engineering Culture (Part 2) by Henrik Kniberg
- Scaling Agile @ Spotify (with Tribes, Squads, Chapters and Guilds) (pdf) by Henrik Kniberg & Anders Ivarsson
- Kanban and Scrum - Making the Most of Both minibook by Henrik Kniberg and Mattias Skarin
- The February Revolution by Gojko Adzic, Mary Poppendieck et al)
- Lean stuff by Mary Poppendieck
- Do Specialists Outperform Generalists on an Agile Team?
- Generalizing Specialists
- Specialists vs Generalists J.D.Meier blog
- T-shaped skills by Kenny Rubin
- T-shaped skills in every area of your life
- Lean startup (wikipedia)
- A/B testing (wikipedia)
- Micromanagement (wikipedia)
- Matrix management (wikipedia)
|Replies are listed 'Best First'.|
Re: Nobody Expects the Agile Imposition (Part IX): Culture
by mr_mischief (Monsignor) on Jun 22, 2015 at 06:33 UTC
Re: Nobody Expects the Agile Imposition (Part IX): Culture
by Your Mother (Archbishop) on Jun 20, 2015 at 19:29 UTC
|A reply falls below the community's threshold of quality. You may see it by logging in.|