Spotify engineering culture

A very nice video from Spotify to explain their culture. They do agile is large scale, many of their practices and principle are nice to follow

Part 1

spotify move away from scrum

Difficult to run multiple team scrum, they make the scrum rules optional.

  • Rules are a good start, then break them when needed
  • Principles > Practices

Autonomous squads

Small fully functional team. Each team have a short term goal, decide what to build and how do build, but still need to follow company’s big picture

  • Each team have less than 8 ppl
  • Loosely coupled, tightly aligned squads

Alignment vs autonomy

Autonomy does not mean no alignment.

  • Leader need to comunicate what problem needs to be solved. And why
  • Squads collaborate with each other to find the best solution

Standards in Spotify

No formal standards on tools and practise. When the tools is good, our team will pick up to save time. This become an informal standard

Internal open-source model

The repo is not read only, other team can fire pull request

  • Avoid the situation that squad 1 keep waiting squad 2
  • Peer code review improve code quality

People is more important than everything

  • Even every team have to figure out solution by themselves, others team are willing to help
  • Focus on motivation

Organization

Community > Structure

  • Tribe: Group squads into tribes
  • Chapter: Members with the same function in the same tribes.
    • Coaching and mentoring is happen inside chapters.
    • Members can change squads without changing manager (as they are still in the same chapter)
  • Guild: Member share the same interest
    • For knowledge sharing
    • Feel free to join and leave

Small and frequent releases

  • Make release easy
  • Make release often
  • Make release small

Self-service model

Support team does not serve squad, but enable + support

Release trains + feature toggles

Even uncompleted feature is released but hidden

  • This can discover integration problem early

Trust > Control

Agile at scale requires trust at scale

Part 2

Fail fast, learn and improve fast

  • Build a fail friendly environment
    • Failure recovery > failure avoidance
    • Learn from failure and take action to improve
  • Limit the affect from failure
    • Via decoupled architecture
    • Roll out gradual rollout
      • Only a small potion of user affected in a short preiod of time

Lean startup method

  1. Idea/ problem
  2. Narrative prototypes
  3. Build MVP
  4. Release
  5. Analyze data
  6. Tweak
  7. Go back to 4

Impact > velocity

A feature is done only when impact can be seen

Innovation > Predictability

100% predictability = 0% of innovation

10% Hack Time

Do experiment, try new idea.

Experiment friendly culture

Test both options and use data to make decision

  • What’s the hypothesis?
  • What did we learn?
  • What will we try next?
  • Keep the things work, dump the things does not

Minimize the need for Big Project

  • Big project = big risk
  • Break big project into small
  • If the benfits out weight the risk, go ahead
    • Visual progress
    • Daily sync
    • Weekly Demo

Culture and Agile mindset balance the company between chaos and bureaucracy

Toyota improvement kata

This help to company solving the new problems, even new solution introduce new problems.

  • Now / Problem
  • Definition of awesome
    • State the ideal world even it is not realistic. It can keep our target clear.
  • Next target condition
    • A step closer to the ideal world
  • Next action to move forward

Healthy culture heals broken process