Scaling Workshop – New thoughts

August 23, 2014

David Muldoon and I just had a new Scaling workshop in Montreal. Two days talking about scaling, and solving problems.

One quick observation

Scaling is ugly. That is, scaling is always a compromise.

We talked about the ideal state; what would we ideally want things to be like. One way of expressing part of that: We want to have 5 teams (of 7 people each) work together in such a way that ‘everyone knows everything’, and we are completely in sync from top to bottom. And we want this communication to happen at zero cost and in zero time. We want this because we want to work fast and effectively and with high quality. …Of course, this ideal state could never exist, but at least we see the trade-offs more clearly.

First, we hope we get that in a single Scrum team, and if we play Scrum well, I think we can. It is hard, but we can, to an impressive degree. Not at zero cost, but at a very reasonable cost.

But to get this with 36 people (5 x 7, plus the Chief Product Owner) is hard. There is additional communication overhead, and we almost always start leaving people out of conversations. In part, because it is so messy to have a conversation (or meeting) with more than 7 people.

What is the overhead to scale? Well, honestly I have not looked at the data in a while, and I think we need better data, but I think the cost is quite high. 20, maybe 30% of productivity is lost. Very likely more. In any case, we have to be honest….with scaling more raw energy of the people is dissipated ‘into thin air’ as we might say. We have to accept that, but we also want, within reason and in the context of other values too, to minimize that dissipation of energy.

Scaling is messy.

To be fair, we can still be very effective in scaling sometimes, but it is much harder.

A second thought.

Each scaling situation is different. I was again struck by this. Yes, some of the problems are similar from one situation to the next, but the solutions you need to bring are different, at least to some degree.

For example, in one situation, a company is trying to rebuild a large legacy core system (a huge payroll system). The original system took, they think, 5 years to build with many people. The problem: How to take 5 teams and rebuild it in 2 years, and deliver it incrementally over those two years (in part, to mitigate the risk of a big bang delivery).

In another situation, the problem was different. Here we had a growing company that is innovating, and changing. How do we get evenness of flow so that the 3 ‘departments’ (or areas)….Inception, Build, Transition each have an even amount of work to do in such a way that the highest Business Value stuff is delivered quickly to customers, no matter how big each release might be? By inception, they meant identifying good ideas sufficiently to move to Build. Build meant, in simple terms, coding and testing and getting to a minimum viable product that was done, done, done. Transition meant taking a (newly built) product and delivering and installing it at many (say 35) customers.

Describing how the solutions for these two situations were different is too much to address today. But the first thing is to recognize how different the problems are.

A third thought.

Implementation is key. We must implement scaling patterns iteratively and incrementally. This was clear to everyone, and clear in all situations. The meaning of implemented varied, because of the different political situations, from situation to situation. But in general we should, indeed must, implement scaling iteratively and incrementally.

Why? One was the cost and the related approval for each part. For example, in one situation, it became clear that each of the 5 teams needs a Product Owner and we need a CPO (chief product owner). But, they only have one PO now (for 3 teams). [They are adding 2 teams.] There is no ‘open requisition’ for 5 new POs. So, the feasible way to implement this was: add one PO now. A bit later, get approval for another PO. And so on.

Another reason. Whenever you add something to scaling you must get the right people, and usually to some degree ‘all of them’, to agree to the change. To get it done, then to learn how to use the change effectively. It is easier for ‘all of them’ to agree to the changes iteratively and incrementally. The changes are easier to implement iteratively and incrementally. And you can manage the process of becoming professional in the use of each change better if each change is fairly small.

There are other factors, depending on the situation, but one of the bigger risks is with a ‘big bang’ implementation of scaling changes.

A fourth thought.

I continue to learn about scaling. I think we all do.

Slightly related to this: We have or should have a strong bias toward KISS. Keep it stupid simple. Keep it maybe somewhat simpler than it ‘needs to be’. Why? Because we have so much complexity already that we are almost stopped in our tracks, and the more complexity we add to the scaling part, it makes things harder.

What do I mean by harder? Communication is not as good. We get confused. Everyone in the scaled group does not understand how we are scaling well enough. Hence, they do not use the official scaling as effectively, and resort to doing nothing or to communicating in a personal or informal way (which often can run counter to what is happening in official channels).

But back to the learning. Let me give two examples. My colleague Dave has a bias toward 1 week sprints, and I have a bias toward 2 week Sprints. Maybe better to say: I think getting most teams to do 1 week sprints well is harder than getting them to do 2 week sprints. And that 3 or 4 week sprints are only rarely good ideas (eg, useful only in a few situations).

So, that is a small difference between us, and we both knew about it. I think it arises mainly from different experiences (different specific situations), and that we fundamentally agree on the principles (eg, the value of fast feedback, that one must save one’s political capital for the most important changes, etc).

But, even though Dave and I have been talking about scaling frequently for years now, we discovered a new difference in this workshop.

Dave likes to talk about ‘grooming’ as one meeting, and a big grooming meeting of many hours, maybe even a whole day in a Sprint. He has good reasons for this preference.

I like to talk about those activities as ‘the red zone’ (versus the ‘black zone’ of doing the ‘real work’ of … in very simple terms, coding and testing). In the red zone we do grooming and we do longer term release plan refactoring. I like to call all of the red zone ‘release plan refactoring’ and make it clear how connected the ‘grooming before the next sprint’ and the ‘pre-planning’ (as people often call it), are directly connected to the black zone, and to the longer term release plan refactoring. And, for reasons I won’t explain fully here, I therefore do not define the contents of the red zone as strongly in other ways, but do usually propose at least two shorter meetings over a 2 week sprint, about one hour each. So, in simple terms, more meetings but overall less time ‘all together’… or at least less time where we ‘require’ that we be together.

Dave and I had talked about these different views some. But what became clear is how, for one situation, we were suggesting notably different options for the client to consider in scaling. And they each had value. They each made a different compromise about the different things we might try to optimize. This was very interesting.

One key idea we discussed is the typical pattern of ‘group to individual team to group’ in Sprint Planning. This is of course a typical pattern one finds all over the place with scaling. We need to discuss X at the group level first, then we need to discuss it at the team level to get into the details, then we need to bring back the learnings from the team level, and discuss again at the group level.

Concluding thought

I was very pleased with this 2 day workshop. The people wanted us to explain scaling, and all the different ideas ‘out there’ about it. While of course there are a huge number of ideas out there, and it would take days and days to cover them ‘fully’, we gave them a decent summary in a time box.

And we talked about specific situations, and specific small patterns that might address the specific high-priority problems. And we talked about the implementation issues for implementing those patterns (eg, the politics of getting approval or buy-in). And to enough detail that I felt they had enough to go do it. These became not just abstract suggestions, but rather tangible do-able action items.

So, I felt (and I think the attendees felt) that it was a very successful workshop. It was fun for me to work with them.