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
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.
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.
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.
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.
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.
This is all my personal opinion.
By John Coleman
Keywords: Agile, Change Management, Management