Scaling, Part 2

November 3, 2013

Here are some additional patterns to consider when Scaling.

For now, consider that I am using a narrow definition of scaling, to mean, collocated teams working together on one product in a fairly tight way.

1. Upfront Work.

To over-simplify, if we create any product, we plan, we build, we release. That is the simplest pattern.

And, especially with ‘greenfield’ products, we have some ‘upfront work’ along with the planning. This is true even with one Team. I call that work I-A-D. Infrastructure, Architecture, and Design. There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots of variations for how people are doing this work currently.

There is so much to say about I-A-D. Let me say only a few things here.

One, keep it small, mainly small in duration, by comparison to building the first MVP. It is so easy to ‘take-off’ 6 months to do perfect architecture, as an example.

Two, it must be tested incrementally. That is, the IAD work must be ‘tested’ incrementally. All knowledge work should be tested quickly after the knowledge is created. And re-tested and re-tested.

Three, we always want to minimize the scaling, but I think with ‘large work’ we must accept that we need some ‘scaling.’ Some additional patterns to make it work. And it has to be discussed and documented more. Everyone needs to understand how it works.

Four, we want ‘everyone’ in the 3 scaling teams to know ‘everything.’ Including, about the I-A-D. Well, as soon as I say that, you see our dilemma. Getting all 21 people on the same page about the I-A-D is a ‘knowledge management’ nightmare. But, as soon as we have scaling, that’s what we want. Using common sense, do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).

Ok, for today I feel I have said enough. Good people, with common sense, can execute ideas. But it is true many of us need more detailed patterns, even for only 3 teams. More on that later.

2. Coordination of Sprint start and end dates

In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).

Why? Well, they have to be coordinated together. In part, this means that they must receive feedback together. Then use this feedback together.

Yes, we must understand that this pattern, as much as it helps, also presents problems. How do you actually do it? What if the same person needs to be in 3 meetings at the same time? Etc, etc. Still, it seems to be the better pattern.

Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the least.

3. Changes to Sprint Planning Meeting

As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. You have roughly 25-30 people in one meeting, and a meeting that size always sucks.

So, what to do?

Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no ‘outside’ influences. Also, having a whole day meeting with 25-30 people is challenging.

The usual solution is to compromise. Spend part of the day as a Group. Part in individual Teams. I like starting as a whole Group. And ending as a whole Group. Maybe a middle whole Group meeting where you review the stories selected for each Team.

4. Changes to Sprint Review

As soon as we scale, we want to have the Sprint Reviews for each Team on the same day. Someone says: “How can we do that? We need the same people, or many of the same people in every Sprint Review?” This usually is a correct observation.

So, use common sense. There are many similar answers, but I’ll suggest what my colleague Catherine Louis calls the Science Fair approach. You probably did this as a kid. Each kid or team had a table in a large room, maybe the cafeteria. All the parents would file in over 2 hours, and the judges too, and look at each of the ‘exhibits’ or ‘experiments’ and go back and forth.

That is the idea.

Each Team continuously demos its features at a separate table. The CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn’t), and deciding how to give the best feedback.

In fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it ‘means’.

As you can see, doing this well requires some skill and experience. Imagine the self-organization that also takes place each time and in ways that cannot be predicted. People will see issues and identify inter-relationships that could not have been anticipated beforehand.

In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach. It has problems, but it pays dividends.

We also recommend that each Team have a short ‘review’ discussion. Have a whole Group ‘review’ discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.

If only scaling were simpler! For that matter, people! You know, if we could only get rid of those pesky customers, things would get a lot better very quickly!

That reminds me of the most important advice about scaling: KISS. Or, as Einstein perfectly expressed it: “All things should be made as simple as possible, and not simpler.”