If you never heard of Spotify Engineering Culture please take 30’ to watch both videos (part 1 and part 2) and then come back. I won’t explain the entire methodology in this post, I couldn’t do it as good as Henrik Kniberg in that videos.
I always repeat myself when I talk about this:
“You can’t copy/paste a methodology, it needs to adapt to your reality and not otherwise”
Those are great videos and Spotify is really good in agile, but don’t expect you to do the same and have exactly the same results, there are as many realities as teams.
I will start with some points I discovered in my experience adapting this methodology, hoping it can be helpful if you want to begin the same journey.
Scaling agile. “Scaling” comes from scale
Don’t try to use this if you are a couple of teams with 10-20 developers. This methodology is for scale, otherwise you will face a lot of unnecessary overcharge to you teams. Don’t mount a structure thinked for a team of a hundred with twenty, I’m sure there are other scaled agile frameworks that will fit you better.
Squads are feature-oriented cross-functional teams, this mean you will need any number of different skillsets in a Squad so they can fulfill their objectives.
If you are working with component-based teams (backend, frontend, design) you’ll need to reorganize and it will take more people.
You will need to assign at least 1 of each skillset to a squad, 1 backend, 1 frontend, 1 squad leader, 1 product owner, 1 designer and so on. And you need to avoid having people in multiple squads, for example the same designer serving three squads. Why? Because you are generating dependencies, and it’s difficult to prioritize work between squads that have totally different objectives.
When you are lack of people, there are two possible solutions:
- Hire more people
- Have less priorities
So if you feel your squads will be incomplete or people is taking multiple roles in multiple squads, consider to have less squads and less priorities, It’s better to do less but well. Remember: “Jack of all trades master of none”.
One step at a time
If you aren’t familiar with Lean and don’t embrace its principles, you need to know that changing your leaders mindset will be a big challenge. This methodology is made for high performance teams that go through objectives.
For that you’ll need:
- Good skills and experience setting goals and objectives
- Talented professionals you can trust in and rely them achievement of your goals
- Trust the guys of point (2) and let them do their work 🙂
As I see it, Squadification is a really evolved “agile mindset” methodology. Don’t go this way if you aren’t agile at all. Try small steps first, have some scrum teams, let them learn to be self-organized, push the continuous improvement with retrospectives, and only after you feel comfortable with agile, make the next step.
An example from my own experience was a big problem we had with quality.
The Lean Principle #2 stands: Build quality In.
But our teams weren’t really following this principle, we had lack of test coverage, don’t even did continuous integration in some platforms, the code was a mess, refactor, pair programming, code reviews and other agile practices were isolated spontaneous events and not habits.
So, we form the squads, separate the component based teams, and the quality goes to hell, tech debt started to increase and we don’t even know how to start tackling it. The problem was we were scaling to a lean methodology without accomplishing its second principle.
I repeat, be sure you embrace agile and lean principles before going this way, if not, start with that first, one step at a time.
Loss of economies of scale
As the framework proposes, you will separate teams in squads that will function as small lean-startups but, you’re still a big company, aren’t you? Beware of losing synergy between people that do the same things, otherwise you will have between others:
- Differents solutions for the same problem
- Poor quality solutions
- Same problems appearing again and again
- Long painful learning curves
Yes, squads are the main unit of work in this framework, but it is a matrix organization, don’t forget chapters and guilds, empower them, use your size as an advantage and enforce communication to flow between them.