Since my career change to a Director of Agile Coaches in early December 2019, I’ve subscribed to Agile podcasts to keep my finger on the pulse of what’s going on in the Agile community. One of my favorites has been Agile Amped. They interview people that work in Agile transformation consultancies and other thought leaders in this space.
A recent episode piqued my interest, as my current company has been experimenting with a transition toward the “Spotify Model“. The hour-long podcast episode is a Q&A session with Evan Campbell, an Agile transformation consultant, who has been called in to help companies who blindly copied the Spotify model and were left wondering why it didn’t work. I listened with interest to ensure my company wasn’t about to go down the same blind alley.
I was relieved to find that my Agile philosophies are very much aligned with Evan’s. It’s helped me understand why some parts of the model are working at my company, and why we’re experiencing some of the same “why aren’t we moving faster” problems caused by high coupling due to squad/team dependencies. I already see ways where we can inspect and adapt to build the model that will help us achieve our goals.
I write executive summaries on my weekly posts, but the episode had so many salient points, I wanted to enumerate them in a longer format.
- It’s ill-advised to implement the model as it was originally published. It was an over-simplification of a desired future state. Plus, they ended up evolving beyond that. Even Spotify has stated as much.
- This is the bandwagon effect, or worse, a cargo cult.
- Agile mindset means embracing…
- Continuing adaptation
- Evolution
- Experimentation
- Data-driven validated learning
- Improvement for greater fitness
- Performance
- The Agile mindset applies to the whole org — not just product — and you’re never done.
- It’s a fallacy to copy/paste, as Spotify is not like most companies (a small, Swedish app/dev music service).
- Goal: To have performant software delivery teams using good Extreme Programming practices, decoupled architecture, low levels of tech debt, automated testing, with CI/CD pipelines that allow them to deliver faster.
- Break organizational dependencies. (This is The Goal and The Phoenix Project.)
- Understand the frameworks — Lean, LeSS, SAFe, Nexus, Spotify, etc. — and consider those your toolset. Apply tools to known problems; don’t just implement everything because some facilitator told you to. Do those tools help optimize the problem you actually have? By all means, learn from the Spotify model.
- Have people on the team report to same manager so you align outcomes and incentives instead of having them report to the chapter/department. The latter locally optimizes for the silo that sub-optimizes value delivery. The functional silo optimizes for career paths, skill development, and quality/consistency. Remember we’re here to deliver value to the customer; but those other things are important, so make a Community of Practice (CoP) instead of hard-line reporting. A CoP can create a center of excellence around functional excellence. You need authority/budgets/time to make CoPs successful.
- Conway’s Law: dysfunctions of how we communicate as an org will be reflected in the product we develop
- If you copy/paste, it’s just reflecting that you’re not an Agile culture in the first place. Culture is a tough aspect of transformation management; you can’t just alter the culture. You need changes in leadership behavior (what we reward/celebrate/reinforce).
- You can start with the Spotify model as a template, but the organization isn’t static. Also, you can’t just change people’s labels (department = chapter, team = squad) and call yourself done.
- Evan Campbell has been in many Agile transformations, digital transformations, and DevOps transformations where people installed the Spotify model because people were sold that this alone would yield tremendous improvements in the org. Most of these are failing.
- There’s a healthy debate among Agile coaches whether Scrum is really helpful, or whether continuous flow is better. Does the iteration of a sprint commitment help/hurt a team? High-delivery teams that can get value to production daily (or multiple times per day) transcend the need for Scrum because they’ve demonstrated maturity.
- The common configuration of a “dev manager” is flawed, as it combines the 1) personnel manager (human care and feeding), 2) project manager (keep things on-time, on-budget), and 3) contributor to design and architecture. It is impossible to be successful at all three things. Instead, the dev manager should own number 1, let the high-performing team handle number 2, and put number 3 on a dev-lead role or CoP.
- OKRs for the product manager are related to outcomes that are tracing the business impacts. Let the team evaluate themselves with different OKRs because they’re in the weeds with each other day to day unlike the product manager.
- OKRs need to be different at the VP, PM, and Scrum Master level — don’t just copy/paste (cascade down) those either. What’s in your sphere of control given the strategy/vision for the org? Have that conversation with your manager.
- Metrics that are useful to execs are from the Toyota Production System: cycle time, lead time, throughput.
- Do not tie OKRs to your performance/reward system (e.g., https://www.15five.com/blog/okr-process-compensation/).
- CoPs are usually underinvested. They need leadership, room to grow (i.e., slack in the team’s delivery obligation schedule), budget for events and training, and latitude to creatively augment the skillsets and career pathing of the people in them.