Scale down!

In some situations you feel forced to scale. We recommend: Scale down.

George Harrison has a nice song called “Cheer Down!” which is a play on the idea of “cheer up!”

Similarly, in my opinion, too many people want to scale up and create more and more layers and add complexity to scaling. This is not good, usually, in my opinion. Let’s back up.

What is scaling?

Well, the word is used many ways, so let me be clear. I mean putting three or four teams together to work on one product where the coupling is fairly tight.

Another definition of scaling is organizing a large department or group to all do Agile. Say, taking 300 people and organizing them all as (independent) Agile teams. Well, most of them as independent Agile teams. I want to call this ‘wider Agile adoption’ or at least something different. It is important and it has issues, but independent Agile teams do not have the same problems and issues as scaled teams (by my definition of scaling).

Does scaling help?

Brooks’ Law: “Adding manpower to a late software makes it later.” See wikipedia.

To me, Brooks’ Law should give us pause. Why do we assume that scaling helps? Do we have any proof?

I find that almost always, the related managers assume scaling will help and then never check later whether scaling (or maybe more other factors) caused the effort to be late, low quality and not what the customer wanted.

You know of course of the heavy evidence that large projects are unsuccessful, and when do they do scaling (in Waterfall or Agile)? On large projects!

Let us at least mention: Agile, if done professionally, will help you more with large projects. Large projects are harder, for lots of reasons. Agile will not eliminate that ‘hardness,’ but Agile will enable you all to manage better and adapt faster to all the changes and learning that naturally happen as you do a larger project.

So, recommendations:

• Do not assume scaling will help — examine that assumption.
• Test, after the fact, whether it helped you. Always your company and your situation needs at least some evidence, and that will help you make better decisions going forward.

Comment: So, I hope it is clear. I am skeptical of scaling, but I am not 100% against it.

The Dream Team option

Recommendation:

• Consider the Dream Team option.

So, what do I mean?

We just had the Rio Olympics. Some of you know about the Dream Team in basketball, the 1992 team in the Barcelona Olympics. It was the first team with NBA players and included Michael Jordan (and many other famous players, if you know basketball).

So, the idea is simply to take your best seven players (if they will play together as a team) and form a Dream Team, and then tell everyone else to get the heck out of the way.

If the work is really important, it might be worth buying a Dream Team, or, in any case, this might be your best solution, considering time-to-market, quality, high business value, and cost. Yes, probably not the lowest in cost, but of course that was not important — what is important is the ratio of benefit to cost (the ROI).

Note that in the Wikipedia article it speaks of the Bermuda plan. As phrased there, you send 90% of the people to Bermuda and let the remaining 10% do the project. This, of course, is very similar to what we call the Dream Team approach.

KISS. Keep It Stupid Simple.

Set Up for Success

The next key idea is that the people must be set up for success.

One thing is that they should be OK at the basics of Agile. They need to be able to at least crawl at the basics, as a team, before you ask them to do something more complex (to scale).

There are many things about the basics that each team should be able to do decently. We cannot cover them all today, but let’s mention three we have mentioned before: The team doesn’t suck, the Product Backlog doesn’t suck and the Done-Done doesn’t suck. We talked about this in an earlier post.

Recommendation:

• Not: The team sucks, the Product Backlog sucks and the Done, Done sucks at least.

Team. You have a good, stable, dedicated team. That means everyone is 100% dedicated (it shocks me that I must spell this out.) They are all team players, and they have the basics of working together as a team.

Product Backlog. You have a Product Backlog that goes out for a reasonable time (six months?). The stories are decent, and include all the work the team will do. The stories at the top are small enough so that you have 8+ stories going into the Sprint, and they are all about equal in size. For those who don’t know why, just trust me that it makes everything better.

Done-Done. The team reliably gets its stories done-done. That is, they are ‘completed’ in the Sprint according to a professional DOD (Definition of Done). This must include, of course, professional testing by professional testers, all the bugs identified must be fixed and re-tested, and everything must be green. Well, it is an open question how much you have done integration-regression testing — some, I assume — and of course the DOD has more than that, but those things are included.

Continuous Integration. It is truly unprofessional to start to scale if you have crappy continuous integration. If you have that many coders, you need to know multiple times per day that everything at least builds together, or does not, but at least you know and you do some sort of automated ‘smoke test’ (a.k.a. ‘sanity test’ or some similar name) multiple times per day. Why? Because the bad news does not get better with age.

Scale Down.

Our last recommendation is fore-shadowed by the title of the blog post.

Keep the scaling simple. Put three or maybe four teams together at a time. Learn how to do that much. Do NOT make it more complicated than that, until you get get that much scaling to work well and that will take you, your culture and the team a good while to do well.

So, recommendation:

• Scale down. That is, do not put more than three or four teams together.

When you feel accomplished at that (scaling with three or four teams together) then consider making things more complex to deal with your next one or two most important problems.

 

« « Spotify Scaling Model || 9/11 » »