Copy-Paste Culture

WeAreNotSpotifyAt Agile Israel conference, I was recruited to a “Hit The Experts” panel on engineering practices. Ok, I didn’t put too much of a fight.

Most of the questions were not of the engineering nature, though. One of the questions went like this:

We’ve adapted the Spotify model, and now there’s no specialization, expectations from testers to write code, and from developers to tests are high, what do you do?

That’s a very big question, one that many are wrestling with. Expectations need to be negotiated. Testers code should be held to some standard (hopefully as high as expected from the programmers code). Developers should understand testability, and test their code.

That was what my original answer, anyway.

Instead, when it was my turn, I had a question to the audience instead.

“Does anyone here develop internet music application?”

No one raised their hand. So I continued:

“No? Well, maybe the Spotify model may not work for you.”

The room was so silent, you could here a pin drop.

One size does NOT fit all

The Spotify model is very attractive in its premise of organization culture and knowledge sharing, and like every successful model (scrum, anyone?) everyone wants to adapt it.

And like many models, it may not fit everyone. Hey, it didn’t even fit Spotify, because it took them years to get there, sometimes accidentally. and they continue to adapt it to their current state.

It fits them. It may not fit everyone.

Copying the ceremonies, roles, and names will not copy the culture. Sorry.

What you can do, is find out what model works for you. Continuously modify, improve it, experiment and learn.

You can bet the model you get will fit your organization better than any other model.

Share Button

2 comments on “Copy-Paste Culture”

  1. Yuval yeret Reply

    As the one who recruited You to that panel (a nobrainer choice really…) I’m so glad that was your answer!
    Totally agreed.
    In an earlier panel about scaling a similar question came up in the scaling landscape panel and I answered in a similar way. Versatile people in versatile feature teams is really great. We agile people all love to see it. But it doesn’t always work. And even if it might the economic/social cost/risk for such a transition might be too much to bear for a business.

    That is why I believe the important point about Spotify, SAFe, LeSS and others is to remember the principles when copy pasting.
    And I’m glad that the actual case studies in the conference were mostly examples of thinking being applied along the way rather than blind copycats.

    As a side note even on that panel I participated in Sagi Smolarski mentioned that even in Spotify there are specialiZed infrastructure/client squads that have deeper more specialized knowledge in an area and have the mission of supporting/enabling the feature squads to deliver.
    The problem we have is with people who don’t even take copy pasting seriously. If you’re going to do it, at least watch the movie a couple of times and have a good understanding of the model. Spotify is more than squads chapters and tribes 🙂

  2. Steve Reply

    Even if you were developing an internet music application, cut-and-paste does not work. For a well known and well analyzed example, look at General Motor’s attempts to cut and paste Toyota’s process.

    Nevertheless, Spotify’s (and Toyota’s) result is a worthy goal. You cannot get there via command-and-control. Cut-and-paste by the decision makers is just a form of command-and-control. If a company wants to attain the goals of lean/agile, it must evolve organically to stick. Doing it overnight just will not work. The path will be different for different cultures, contexts and most pressing problems.

    Find somebody knowledgable to facilitate the path. Vanilla Scrum for just one or two projects is a good place to start.

Leave a Reply

%d bloggers like this: