Squadification. Scaling agile with Spotify’s Framework

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

Drawings.png

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:

  1. Hire more people
  2. 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

Drawings (2)

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:

  1. Good skills and experience setting goals and objectives
  2. Talented professionals you can trust in and rely them achievement of your goals
  3. 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

Drawings (1).png

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, tribes and guilds, empower them, use your size as an advantage and enforce communication to flow between them.

Slicing the Elephant. Good tips to divide work in small deliverables.

As you may know one of the Agile principles is “early and continuous delivery of valuable software”. Now, one of the major challenges I’ve seen in the attempt to accomplish this, is how to break entire features into smaller deliverable parts in each sprint or iteration (or any name you have for small periods of time).

The concept is easy and you can find it all around the internet, I really like the “Skateboard metaphor” by Henrik Kniberg:

Making-sense-of-MVP-.jpg

I think we all understand the concept but the problem come when we want to put it in practice.

Force to think in patterns:

Both in software and product development or similar domains, you can apply patterns to divide the work, force you to think in them when you have to slice a feature and you may get very good results. You can even print and take them with you to every backlog refinement session or meeting.

Here you have a few ones that are pretty common in every software/product:

#1 Slice into different actions

Create, read, update, delete, list. Yes, the same design patterns you apply in software development are useful here. Slice big business items managing features into small parts by different action:

Lets use a library system as example.

As a librarian I want to manage books on the system…

You can slice it in:

  1. As a librarian I want to create books on the system.
  2. As a librarian I want to update books on the system.
  3. As a librarian I want to delete books on the system.
  4. As a librarian I want to list books on the system.

#2 Slice by different options

As a library user I want to search books so that I can find them in the shelfs…

This is easy, typically we’re going to make the user’s life great (or we think so) and give him 20 differents options to find the book.

Or we can slice it in:

  1. As a library user I want to search book by name so that I can find them…
  2. As a library user I want to search book by author so that I can find them…
  3. As a library user I want to search book by date so that I can find them…
  4. As a library user I want to search book by code so that I can find them…

#3 Slice using business rules

In almost all products we’ll have a bunch of business rules that describes variations in the use cases.

As a library user I want to borrow some books and take them home…

But… The librarian has to ask the user for his identification.

If the user is foreign he needs to show passport and proof of domicile, if not, he can’t borrow the book.

As a native library user I want to borrow some books and take them home

(The system doesn’t support foreign users yet)

As a foreign library user I want to borrow some books and take them home

#4 Basic Flow First

All of us want a solution that considers every possible flow of the product but this can take lots of time without delivering nothing, so… split them and tackle down the basic first and leave alternate flows for later.

As a library user I want to borrow some books and get them delivered at home…

It would be great to deliver books, but you need to get user address, account, contact info, preferred delivery date and so on. Go the basic first:

As a library user I want to borrow some books and pick them up at the library

As a library user I want to insert an address and get books delivered

As a library user I want to have an address book so that I can pick them from there later

#5 Leave the “fantasy” for later

Start with basic user interactions and leave the fancy stuff for later.

As a library user I want to save my personal data

Leave validations for later, animations for later, fancy error messages for later, etc. Just give the user a simple form and let him save his data.

I hope these few tips help you, please give me feedback or write another patterns/strategies you use! You will find several other patterns that will apply your business, look for them, write them down and train yourself to slice the elephant in every feature you develop.

I strongly recommend Alistair Cockburn’s Elephant Carpaccio workshop to introduce people this concept and put it in practice.

Suggest not Command. An effective way to introduce ideas.

Both as an agile coach or agile team facilitator, I’ve found myself trying to drive change throw organizations, teams and people. Even in any managing role you often needs to introduce your ideas to people.

If you are in a managing role, the most common way is to command. Sometimes people will obey you without problems, others people won’t like it because they think your’s is a bad idea, they don’t understand your basis, they feel like pawns with no decision power or simply they don’t want to do it.

I think is much better to suggest your ideas and I guarantee you will not only get people to follow them but also getting better results than expected. Here are some techniques that went well for me:

“Pain Driven Facilitation”

The first time I heard this term was from Alan Cyment and I realised that I was doing it without naming it.

The concept is simple, introduce you ideas to people when they need it (when they explicitly express they need it), this stands for “pain”, people have a problem, they know it, and they are asking you for help, that is the moment to propose your idea and they will embrace it..

But… what if they never ask? What if I know they have a problem but they don’t?…

Retrospectives! They are a powerful tool to make people come over their problems and raise needs to solve them. Most times you won’t even need to give them the solution, they will came to it, or even to a better one. Also, if you are who facilitates the retrospective, you can choose carefully the dynamic to guide people directly to the problem you are seeing, but that is material for another post.

Wrapping up, let’s say you are a Scrum Master and you want to introduce Story Points estimation over ideal hours, don’t just command people to change the way they estimate, do a retrospective and drive people to the problem:

– We are failing our estimates every sprint!

This task takes Bob half the time it’s taken me!

I had to refactor everything and it tooks me twice the time!

That’s the pain, that’s where you talk them about Story Points and suggest to try it, and then retrospective again to see if it worked.

“That’s a good idea!”

The other tip is a bit tricky, but it has worked for me sometimes. It consist on driving people to have the same idea you have, and then boost it as “That’s a good idea!”. People will always embrace better their own ideas that other’s and they will be much more motivated to carry them out.

To do this, just present the problem and plant the question:

How can we resolve the problem with the ?

I wonder what can we do about can we find another way?

Then discuss and tweak people ideas until getting a good result.

Using the same example as before, you are the Scrum Master and your team is failing estimates because they always estimates according to the technical leader´s (Bob) opinion, in order of his expertise.

Plant the problem:

Hey guys! Bob is very quick but his estimates are half the time it takes most of us to do the same. What can we do? We need more accurate estimations.

Open debate and they will throw a bunch of ideas:

– Alice: We can add some points to Bob’s original estimates…

– John: We can say our estimates “in secret” all at the same time, so we don’t get influenced by Bob..

– You: That’s a good idea John!

Tweak it a little and you may have introduced Planning Poker to your team as a “John’s idea”.