I received a question: do you believe scrum and agility can be scaled and what’s the best approach to it? And then the follow-up to the question was maybe a framework that is already familiar to the masses like LeSS, SAFe Nexus.

I want to walk through each of these, first of all, I just want to talk about pathology that seems to be going on with scaling. The first thing is that the first rule of scaling is not to scale, but to try and get the best people in your group together to figure out what they need to do. That’s the first thing.

The second thing is there seems to be a kind of a disease with product owners, we seem to be growing product owners like flowers, popping up everywhere. I have great respect for the people who are acting in product owner roles, but let’s say you’re a product owner on one team and the highest value item that’s in your team that you’re working on is 3 million US dollars.

But let’s say there’s another product owner within the same group. And the item that they’re working on right now is actually worth $30 million and they can’t even afford to work on the $29 million item. Meanwhile, the first product owner that I talked about a while ago is thinking about going on to the $2.5 million item.

This is the disease in scaling where product owners have their own little dominion, and they have their own little backlog and they don’t see that they’re not contributing the highest value from the company or the organization perspective.

That’s a real problem with most of the patterns that we’re going to talk about today.

It’s something that really disturbs me. I’m going to use a bit of bad language, I heard a wonderful expression recently, but there are a few scaling patterns that are a kind of a piss in your pants solution as in, if you already have hundreds and thousands of product owners, you can put these patterns in, but it is a piss in your pants solution. It’s not really good.

So let’s walk through some of these patterns cause I was asked do I believe they can be scaled? So the first thing is what people generally mean by scaling is they got many people working together or many teams working together and how could they all figure out how they want to work together on the product?

And there were two patterns that say on one hand that they are scaling patterns, but on the other hand that they are de-scaling patterns because de-scaling is about simplifying and not about adding on more stuff, not about looking for something that’s built out in complete, looking for something that’s barely sufficient that gets you started and you can add more stuff later on if you want to kind of thing.

I do have an article on this, by the way, it’s called mirror mirror on the wall, who is the most and I won’t say anymore. That article has been out there since September, 2018. It was updated a few months ago.

I need to add ‘unfix’, Jurgen Appelo’s new pattern. And I need to add flight levels to that article, but today I’m going to talk about LeSS, disciplined agile, scrum with scale, SAFe, Nexus. And what I called Spotify/ ING and flight levels. We’re just going to have a cursory look at these because each of these is a training class in itself. Could be between two and four days of training on each of these things.

LeSS — Large Scale Scrum

So if you just look at LeSS, if I was to look at one slogan for it, if you like, it’s one product backlog with a learning focus, LeSS stands for large scale scrum with a little ‘e’ in the middle. As for adaptive product groups, I mean, it’s not what agility is all about, adapting to what’s going on in the market but so many companies really lost their way and they think it’s better, faster, cheaper, but LeSS is about adaptive product groups, it’s about learning and they’ve got real peer-reviewed case studies. It’s very difficult to get a case study published there. It’s like really difficult and I’ve tried five times, I’m still not there.

I have applied LeSS principles in many places but I’ve struggled to implement it. So it’s very difficult to implement. But it’s got this nice blend of principles and rules and, the idea of self designing teams, you don’t have to use self designing teams. You can evolve the whole group. That’s another approach. If you do, you have self designing teams that kind of go with flipping the system, 50 people at a time, it’s an expression flip the system, you have kind of informed consent, bringing maybe 50 people through, get them all trained up, all that kind of thing. You might find out at the end of the training that maybe only 35 of those people actually want to be part of it. And because LeSS is based on volunteering, so there’s no problem there. The 15, you stay where you are, we’ll treat you (your work) as a dependency, even if we desperately need you, because we prefer people who are in there to really want to do this.

LeSS is about simplifying by stripping complicatedness away.

So if you see some process that’s meh , it’s about stripping those away. And actually what’s really nice about LeSS, ‘manager’ is an optional role. And if you have them, the view is that they’re more impactful than scrum masters in removing impediments and then simplifying, which I quite like.

In LeSS, they use communities as such to preserve the legacy organization. That’s probably not the right way to say, but you don’t want to throw out the baby with the bath water. If you had an analysis group, an architecture group, development group, testing group, maybe you’d have communities for those , so they still have a place to go if you like to talk about those kind of concerns. Even if you decide not to do LeSS, my opinion is it’s a very good thing to learn, to understand what maybe mistakes you could avoid. I read the three books and I went to Bas Vodde’s class a few years ago and my head was exploding. It was a fantastic workshop and I was glad to see someone else had the same comments this week, someone else who went to his training in Manchester.

I actually wrote a blog post, 50 light bulb moments, five zero, after training, with Bas Vodde. It’s amazing. But it does rely on long-term co-located, multidisciplinary, end to end, what I call a slice of cake teams.

I think the whole feature team thing has become misunderstood. So I talk about layer of cake teams, like front-end, middleware back-end and slice of cake teams kind of cutting down through that. So LeSS demands if you like that you have cake teams so It’s a big step.

You can evolve towards it. You could treat the framework as an evolution, and then use the principles to guide you. That’s what I do. But you can also use it as a framework and then use that as your starting point to move along and always using the principles to move forward. Very good thing to do, to understand maybe what most people fall into, growing product owners like flowers like I mentioned earlier

Disciplined Agile

Then there’s disciplined agile, which I’m only including, because it’s so well-known, but I really think it’s rubbish. It’s ‘practical’ and in the books I was disappointed with the author’s ‘but in the real world’, ‘but in the real world’ and all this kind of stuff, making excuses almost everywhere, all over the book about why you can’t be agile and why you can’t be lean. It’s a buffet so pick what you want and guideline oriented. And what I noticed when I was working in a major oil company, nearly 10 years ago when I was an enterprise agile coach, they’re writing kind of a guide for how we could implement agility in the whole company. I realized that two thirds of people need rules. So disciplined agile is a set of guidelines so you can just basically drive a truck through it.

 

Drive by, is what I would say that’s my personal opinion about disciplined agile, it is owned by PMI now, which is the only reason why I’m including it because PMI is a huge organization, but I would quite honestly just drive by disciplined agile. Some good ideas in there but so compromised, it’s not useful in my opinion.

Scrum at Scale

Then there’s scrum at scale. One of the things I like about scrum with scale is it’s got an exec scrum team. So the executive team uses scrum and they’ve got this how cycles, so they do have product owners growing like flowers. So we got product owner, we got chief product owner, chief chief product owner and all this kind of thing.

 

 

And it’s got a how cycle or a prioritization refinement, the what cycle. And then the how cycle is the scrum masters. Then you got scrum of scrum masters, scrum with scrum of scrum masters master and so on. And then there is eventually this kind of executive action team as well, where they try to remove impediments.

So it’s really nice from the point of view of getting problems fixed. What I don’t like about it is that it just, it’s the ‘piss in the pants’ solution that I talked about earlier. It’s scrum-ish, which is surprising because Jeff Sutherland as co-author, of the scrum guide it does rely on a product owner per team and hierarchy of those. And interestingly Henrik Kniberg, a very respected guy. He says that the original Spotify video, that’s an instance of scrum at scale. It surprised me. I really like Henrik’s work. Take that at face value.

SAFe — Scaled Agile Framework

Then there’s SAFe, scaled agile framework. I’m not a fan of SAFe, I’m not a fan of scrum with scale either as you probably picked up, but some of these approaches are useful when the organization just, they’re just so far away from lean agile that some people say you can use it as a Trojan horse and you can get started and so on.

 

But I used to think that, I don’t think that anymore. It’s very popular. It’s build-out, it’s got everything in there. It’s got lean agile in a box, which I don’t mean in a complimentary way. It relies heavily on training and there’s a real low barrier to entry for most trainers so you could have been doing program management all your life. And then you go on a four day class and now you can teach the class as well. Even though you might not have that much agile experience, you do have to pass a test to be fair and all that. You could basically reinvent yourself. If you are going to use SAFe, I would say, there are some very good people I respect in the SAFe space.

So use someone that is highly recommended, maybe there’s some SPC who’s highly recommended or an SPC trainer. They’re like the top gun if you like of the SAFe community and I’ve seen some very good people going through there. So try to use really good practitioners. It’s got different scales, so you’ve got the essential version and there’s the large solution, there’s portfolio and there’s the full solution, I believe.

And they keep updating, which is nice. So they’re being agile about the framework. I’m just not a fan of it. And if a company asks me to use it, I just run, I ask someone else that I respect to go in and do it instead. It just tramples on all of my values really and a really corrupt scrum as well.

I wrote an article a few years ago when is SAFe safe? Probably if you use Kanban, if you do proper Kanban within the team, it just messes up, scrum master is not a coordinating role. Full stop.

Nexus

Then there is nexus. So nexus is probably the simplest pattern of them all. And I believe it is culture agnostic, and it’s almost method agnostic.

I’ve used this in a variety of cultures, even cultures where it’s very difficult to be agile let’s put it that way. It’s designed to deal with layer of cake teams, and let’s be honest, most teams in the world are layer of cake teams. It’s simple. It’s flexible. It’s like LeSS’ little sibling.

I compared nexus and LeSS, a few years ago and Bas, he said nexus is like LeSS’ little brother, which is actually a compliment because before that wouldn’t have been said. And it’s a big improvement on scrum of scrums. So each event in nexus has a purpose, so there’s nexus sprint, the nexus daily scrum, the nexus sprint review, the nexus sprint retrospective. Unlike scrum of scrums where, people turn up and they don’t know why they’re there, are they for impediments or for dependencies? Are they for status reporting, even who goes like the different patterns disagree on who should go.

The decent patterns in my opinion, would send people who are doing the work. We call those people developers in scrum. That doesn’t mean they’re software developers. We just call them developers in scrum, but you could use nexus for Kanban teams. That was in my first case study back in 2015, just a couple of months after it came out, I had Kanban lean startup and the scrum teams using the nexus patterns.

It’s a very nice pattern. And you can evolve away to slice of cake teams over time. There’s also nexus plus because the downside of nexus is it only goes up to 9 teams. But you could have a nexus plus integration team. So a nexus of a Nexus kind of thing.

And so you’d have a nexus for each work stream, and then you’d have nexus plus integration team integrating between those, what I love about nexus , one product backlog, one product owner. It doesn’t grow product owners like flowers. So far the patterns I’ve been talking about, I’d be looking at either LeSS or nexus as a kind of the North star, if you like probably LeSS as the North star. And then Nexus maybe as a way of getting there.

Spotify/ING

Then there’s Spotify/ ING. They didn’t copy Spotify. I think they were very considered in terms of how they applied the approach in ING is my understanding I’m going to put them together for now. And I would say it’s very popular, very simple. It’s usually corrupted. It’s usually just a re-labeling, it’s been hijacked by the consulting firms. And in my opinion, they just put in SAFe in Spotify clothing. I’m not saying that SAFe is the worst thing in the world. I’m not a fan of it. But my sense is they’re trying to avoid sending fees off to scale agile framework and they’re just pretending its Spotify, but it’s actually SAFe under the hood. That’s my opinion. It is culture agnostic, and I believe it’s almost method agnostic because it gets corrupted. It’s something I avoid, it also grows product owners like flowers, which is something I mentioned earlier on.

Flight Levels

 

There’s another pattern called flight levels, which has been around for a while, but it’s been gathering steam really in the last few years. And the idea is that you have like a flight level one, flight level two, flight level three.

And so the flight level one would be like your operational boards if you like. You could be doing scrum, you could be doing Kanban, you could be just doing work or whatever, and your teams will have whatever boards they have. But I’m not sure if you’ve noticed that when teams are working together on a product, sometimes there’s a kind of a dependency chain. There’s boards that link to each other and things like that, or maybe they don’t link to each other, maybe that’s the problem.

So flight level two, it doesn’t give you a template or anything like that, but it gives you a way of thinking to discover: could you come up with some collaboration or coordination boards from an end to end point of view, you could look at how the value was getting through, how are you delivering value in your product or your value stream or your service or whatever it is.

And so you can see where the work is getting stuck. So maybe there’s 10 teams involved in the whole value stream. And there’s two teams in particular that seem to be congested. It’s not a reflection of those teams, there’s always a bottleneck, if there was no bottleneck we’d have unlimited capacity.

So let’s not be hard on the people, but you’d see where work is getting stuck. It might not even be a bottleneck. It might be just about, there’s some dysfunction there that maybe we need to deal with and so on. So I think that’s really nice, the flight level two idea of seeing the bigger picture of how work is flowing through the entire value stream, not just sub-optimally, how is the team doing, going faster, doing some other approach at a team level, but actually making no difference because the work is still taking three months to deliver. So I really like that.

There’s also flight level three, which is where you connect the strategy and you prioritize work and you connect the strategy with the reality of the work that’s going on. And this is something I’m applying in one of my clients at the moment, and I really like this, I’m starting to fall in love with it.

Some people say it’s just like SAFe. It’s got similarities, but it doesn’t prescribe, it doesn’t say, do this, do that, you know have a big picture and you have all these things and abracadabra, everything will be great. It actually takes a more kind of principled approach I would say.

And it really is about flow. And of course, strategy doesn’t always flow, but you need to learn more about that at a flight levels class, but you can see what’s going on. You could see your capacity in real time. I really like it. So in summary I love LeSS. I think it’s great. I think disciplined agile sucks, I think scrum with scale socks, I think SAFe sucks.

I really like nexus. I feel sad about the Spotify/ ING thing. I don’t know how well it’s going in Spotify and ING. Now, maybe they’re doing fabulous things in there, but I don’t like when companies borrow from that, they basically corrupt it, which is kind of sad. And I really love flight levels.

So they’d be three patterns that I would look at. If you want to be really authentic about your agility you can also have no pattern at all. And you can just go back to principles. And the very first thing I said in this talk today is that the first tool of scaling is not to scale actually, just to get the best people to figure out.

This is all my own personal opinion.

https://linktr.ee/johncolemanxagility - social and podcast links
https://linkpop.com/orderlydisruption - order training from right here