Henrik Kniberg
Transcript
I'm really happy to be here in Paris. And this is a really cool conference and a cool location, a lot of cool people, so give yourselves a hand, I think.
Yes, I'm going to talk a bit about this thing called alignment. And what I mean by that is like teams not running in 15 different directions. Okay? It seems to be a huge challenge with many companies. How many of you are in a multi-team context? You've got multiple teams that have to kind of work together. So, well, that's just about most of you, right? So great.
This is a single team doing something, Agile-ish, Kanban, Scrum, I don't know. This is not rocket science, we've kind of figured it out. You can take pretty much any book on some Agile or Lean framework and just do what it says and you'll be pretty okay. Not like it's a silver bullet, but you'll be pretty okay. You'll be delivering something. So I'm not going to talk about this, but when you got multiple of these things, okay, a little trickier, right? You got to have a bit of cross communication, a bit of synchronization. But what I want to talk about is that, right? Because when you have that, what often happens is that, right? So how many of you recognize that picture? Sounds like, yeah, that's us, right? It's a challenge. And unfortunately, I don't have any answers for you. But thank you very much anyway. And I hope you have a good conference.
I don't have any answers, but I have some examples. And some of those examples might make sense in your context or not. But we'll see.
But this is what I've been dealing with for a bunch of years. And I'm always looking for little tips and tricks and ideas. And I found a few that might be useful.
Because this doesn't scale. All right, I've been looking for a long time for a good metaphor for the problem that happens, and I finally found it a few months ago. So this is the metaphor. Here's a team that is trying to solve a problem. The problem they're trying to solve is we've got to get across this river, right? And then they're building a bridge because they're an autonomous team. They've been tasked with the job of solving this problem. So they came up with this brilliant solution. What they don't know though is that somewhere else in the same building is another team also trying to solve the same problem. So they're aligned, right? They're trying to solve the same problem. Except that the other team is doing that. Right? And they're very happily trying to solve the same problem. And then when they discover each other, they're like, what? What are you guys doing? Wait, we're building a tunnel. We're building a bridge. Wait. And then you get confusion. Right? So that's my kind of mental model of sub-optimization. And it happens when you go overboard with autonomy. Right? We're in the Agile and Lean community, we're big on decentralization, right? It's like, ah, decentralization is good. But when you take things too far, you get these teams that are seemingly making great decisions. locally, but then it just doesn't really fit together. So what do we do about this? Well, here's the answer, right?
It's a common reaction though, right? Common reaction, yeah, I told you this autonomous bullshit doesn't work, right? We gotta have somebody take charge, right? Get the managers back in again. But this is based on what I consider to be like a mistaken assumption.
And it's the notion that alignment and autonomy are like at odds with each other. You kind of have to pick where you want to be on the scale. So either the manager decides or the teams decide, and you have to pick, right, kind of where on that scale.
I find it more useful to think of it as a two-dimensional kind of scale. And I have to be honest, I did not make this up, but I don't remember who I stole it from. So I apologize to whoever I stole this from, this metaphor, right? And if you know who it is, let me know. But anyway, it's a great model, looking at these dimensions separately. Low alignment, low autonomy, micromanagement. Low autonomy means that teams don't get to decide what to work on or how to work on it. They're just told what to do. And they're not told why they're doing it. So there's no alignment. Very boring. Up top left, it's more like we have some kind of high-level purpose. People understand why they're here. We're here to cross the river because of X, right? But then they're also being told how to solve the problem. Build a bridge. High alignment, but still low autonomy. A little bit better, maybe. A little bit more motivating. We can use people's creativity a little bit more. But the nice quadrant is the top right, right? We need to cross the river. Managers, leaders are good at describing the why, why we're here, the context. And then they're letting the teams figure out the how. So you guys figure out the how. So now we unleash creativity, right? We unleash innovation. Lots of good stuff happens.
Bottom right, high autonomy, low alignment. Well, that's when you got all these teams that are just doing whatever they want, whatever seems to make sense from this perspective. And then you get like the poor manager, the leader saying, I hope someone's working on the river problem, but I have no idea. And that's when you get things like the bridge tunnel problem, etc. Just out of curiosity, I realize it might be a sensitive question, but if you're happy to be open here, how many of you feel that the environment, this bottom left here is what feels most familiar, this is what you're kind of living in right now, that environment, hand up.
A few, we got a couple, maybe three. How many of you feel that that's mostly what describes what I see?
Right, so look around, right? That's about maybe 20% of the room. And what about here? You're mostly living in this world.
I was surprisingly few. I saw like two and a half.
I don't mean a half person, I mean a half hand.
And what about down here, the kind of general chaos problem? How many of you live here? Okay, so very mixed, right? Very mixed group. And about half of you didn't even raise your hand, so I don't know where you live.
Maybe it varies. So to me, it's really about how do we find this spot? How do we get here? And alignment is something that enables autonomy. The better you are as a leader, at creating clarity. Why are we here? What problem are we trying to solve? And creating context so that people can see what the heck is going on. The better you are at doing that, the more autonomy you can give out, and teams will use that autonomy in a good way. Does that make sense? So alignment enables autonomy. It's not either or.
I call that aligned autonomy. I know it's a bit of a mouthful, but I can't think of a better term. Anyway, so I'm going to use the metaphor of cooking, right? Because we're in France after all. Food. Cooking to describe what I consider to be some ingredients that increase the likelihood of getting alignment across multiple agile teams. So my assumption now is that you have agile teams of some sort, right? Kanban, Scrum, some combination, I don't know. But basically doing the lean agile thing at the team level, fine. How do we create alignment, right? Some key ingredients. And the first one I've already hinted at, which is a sense of purpose. A clear understanding of, why am I carrying this around? There, stay there.
Shared purpose.
And yeah, you of course already know this probably, but I want to emphasize it because it's really important that we sometimes forget it. I'm going to give some examples from two companies during this talk, Spotify and Lego, not because they're necessarily doing it in a perfect way. They're like any other company. They have good sides, bad sides. I bring it up just because those are the companies that I personally have the most first-hand experience with. It's just to have concrete examples. And what I think is inspiring, if there's one thing these two companies actually do really well, it is purpose. Because at those organizations, especially if you listen to someone like Daniel Ick or Jorgen V. Knutstrop of Lego, They're always emphasizing the purpose. They don't talk so much about the product. They're emphasizing how the product is used, who's using it, what problems that we're trying to solve. And that passion echoes. You notice that people talk about it a lot. Teams talk about it, developers, project managers. It just seems to be kind of like a top-of-mind thing, talking about the problem we're trying to solve, who are the users. At Lego, there's kids running around in the office twice per week. There's people in the teams going out to visit schools. It's just incredible to see this focus on purpose. And that motivates teams, but it also helps them make better decisions.
So purpose. And there's a way to test this. Just ask your buddies or ask a team, like, what are you working on right now? And why? And you'll get interesting types of answers. So if the answer is, well, we're working on X because Sam says it's really important. Like, eh, you know.
Well, maybe that's not too great. Oh, and we're done when Sam is okay with it, right? That doesn't look like a purpose-driven organization to me. If the answer is more like, well, we're working on X because we think it's going to give impact Y, and that matters to the company and our stakeholders because of Z, oh, that's starting to sound more impressive, right? And we're done when the metrics have moved, so they're even measuring it. That's okay, cool. Now it's starting to get interesting. You start seeing dashboards and things like that. This is a way of kind of testing.
Right, so that's one ingredient.
Another key ingredient is transparency. And this won't be news to you either, but I'll give you some examples. Because again, you can have these two teams that have the same shared purpose, but they'll still suboptimize because they don't see what's going on. So transparency.
A lot of companies I bump into kind of look like this. What do you see here?
Nothing.
So the poor developer or the poor designer is sitting in a room kind of like, hmm, wonder what the others are working on. I don't know, I'll just continue working on this ticket that showed up in my Jira flow or Kanban board or whatever, right?
And then if you have a whole organization of that, then you don't have transparency. You'll have a lot of bad stuff hiding in the dark, right? So turn on the lights.
Now, what I think is interesting is it seems to be quite commonplace nowadays teams have these boards, right? Visual boards of various sorts. What I think is interesting at Spotify is actually, because at Spotify we've had the problem of, now we have like 100 teams or so, and we see this problem of sub-optimization, right? And have been trying to do something about it. And one model that has helped us actually is to just go overboard with transparency, especially with like what are the big initiatives that the company wants to work on. So this is, I guess, pretty typical. Like most companies have this concept of what are the company beliefs, where do we want to go and why? What would be some key milestones along the way? For example, achieving X number of active users or being a world-class employer according to whatever. This is pretty typical kind of strategy stuff. But what I think is interesting is that They've made a very strong effort to clarify what we call bets. A bet is kind of like the Spotify equivalent of a project or a work stream. Just some kind of coordinated effort, usually rather big. The small things, the small continuous improvements, those kind of just work the way they work. That's fine. The challenge for us are the bigger things where we need to have more alignment. So we call those bets and we make them very, very, very visible. So they are actually in... Well, they function as an alignment point. So if these three teams all know that we are working on Sony PlayStation integration, that is our current focus. We call that a bet. If all teams know what other teams are working on it, then they'll be more likely to collaborate and talk to each other.
But anyway, these bets are, we have a very low tech solution, it's just a Google spreadsheet. It's a Google spreadsheet called the company bets board. This is how it looked like in June or something this year. Looks kind of like a Kanban thing, right? And that's pretty much what it is. It's a company level Kanban system, kind of. And it's not strictly WIP limited, but implicitly WIP limited, because when we started it, we had too much stuff, and it's gradually been reduced. And now these are the number of cross-company initiatives going on. Roughly. We tweak the column names, but for a period we were using now, next, later, which is a nice simple approach.
But what I think is interesting is that this is visible to everybody. Anybody at the company can just, at one click, see what the heck are we working on.
And if you click on one of these, you get to this brief. It's a Google Doc. Anybody can just see it. And it contains pretty standard stuff like who is the kind of sponsor for this? What are the success metrics? How would we know if this bet panned out correctly? What would the numbers look like? In some cases, things like cost of delay, whatever is relevant to this bet. But the second page is what I think is interesting, a bit different. I haven't seen this at so many other companies. It's something that we call a DIB, D-I-B-B, Data Insight Belief Bet. And what this shows is the kind of logical reasoning behind why are we doing this. So let's rewind a few years. A few years ago, Spotify had the problem of
The data was, look, desktop usage. Spotify Music Player was a desktop product, and desktop usage is going down, and mobile usage was going up, right? Very clear data. And how are we staffed, right? Oops, this many desktop people in this little mobile. It's data. So that's what the left column means. It's just data. And then what insight does this data give us? Well, it gives us insight that mobile is overtaking desktop and that we're in trouble, right?
And what is that? Tell us what is our belief about our company's place in the world because of that. Well, our place in the world is that we need to really become mobile first. That's the belief. And then, okay, well, what are we going to do then? So the bets are kind of the projects or the epics, the things we're going to do. Well, we better hire a bunch of mobile devs, train a bunch of desktop devs into mobile devs, and invest a lot in infrastructure for continuous delivery on mobile and just a lot of stuff, right? What I think is interesting though is that here we see the why. Why are we building this infrastructure? Well, because of that belief which came from that insight, which came from that data. And any of those may be wrong, right? So we put them up there so that they can be criticized and argued around. So we think of it as an argument framework. And as we implement the bets, we get more data, right? And that data gives us new insights. So this is just a way of making the conversation a little bit more focused. So it's not like, I'm working on X because Sam said so. Does that make sense? the projects or the epics, the things we're going to do. Well, we better hire a bunch of mobile devs, train a bunch of desktop devs into mobile devs, and invest a lot in infrastructure for continuous delivery on mobile and just a lot of stuff, right? What I think is interesting, though, is that here we see the why. Why are we building this infrastructure? Well, because of that belief, which came from that insight, which came from that data. And any of those may be wrong, right? So we put them up there so that they can be criticized and argued around. So we think of it as an argument framework. And as we implement the bets, we get more data, right? And that data gives us new insights. So this is just a way of making the conversation a little bit more focused. So it's not like, I'm working on X because Sam said so, right? Does that make sense?
So dim, pretty useful thing.
And you can't, as far as I'm concerned, you can't really avoid this. It's the price you pay when you enable teams to work autonomously. There's so many benefits to autonomy and decentralization. The downside is this. But what you can do is you can detect it. And if you detect it early, it's not a big problem, right? If you notice this happening at the blueprint phase, when you were just talking about what to do, then it's going to be no problem. So early detection of misalignment is really what it's about, not making alignment impossible. Misalignment is going to happen sometimes.
Okay, so how fast can we detect misalignment? And transparency helps. Now let's jump over to Lego.
Different companies just for contrast, right?
What I'm going to talk about there is some tools to detect and solve dependencies. Some of you might recognize this. What is this?
It's actually, it could be anything, it's just a bunch of sticky notes on a wall.
It's actually from Safe Scaled Agile Framework, it's a so-called program board.
But if you think of it as just like any tool, it's a visualization. I call it a dependency board. And what's interesting about it, these are teams. We've got 20 different teams inside the digital solutions part of LEGO, which are the people that build all the digital stuff, website, designer tools, etc. And they had a lot of dependency problems between these teams. So all this does is it visualizes that. So 20 teams and then four upcoming sprints. And just who needs what from whom when, roughly, right? Helps to sort out problems.
The red yarn just shows, the arrow goes from yellow sticky to pink sticky, that's all. So these three teams need that thing from that team first. By visualizing that, those teams are more likely to talk to each other, right? What's interesting though is as you look at this board, you see patterns, right? What's the pattern? I know it's a mess, but what's the pattern?
Something must jump out at you, doesn't it?
Yeah, someone did this, right?
That is a column full of pink stickies. It says corporate IT up there. Right? It turned out that actually the biggest dependencies we had weren't between these teams. The biggest dependencies were to a whole other part of the organization called corporate IT. So we added a column for that to visualize that. And it generated this collective oh shit moment. Like everybody knew about this but now it became very clear. And what started happening is nobody owns this document. Nobody is like trying to maintain it. It's just a marketplace to trigger decentralized behavior. People see it, they talk to each other, and they start optimizing the constraint. Instead of getting angry at CAT, you idiots, you're slowing us down, they realize that this is a real bottleneck situation. We need to think about how to most effectively use that, right? But also think about how can we reduce the bottleneck factor for the future. So both of those things started happening. And now it's actually a lot better because they've invested a lot in things like cloud infrastructure so that teams can procure their own test environments instead of waiting for CIT, things like that. So visualize dependencies so you can optimize them, but then also so you can start removing them over time through technology, through reorganization, through culture, etc.
This is used in day-to-day work inside the office. This is the head office in Bilund, where teams talk about it to kind of follow up on dependencies, things like that. Because when it comes to scaling and alignment, it's really all about dependencies. That's what's going to inform the speed of your project. It's just to what extent can we not get stuck waiting for each other, right?
So back to Spotify, just as a contrast, Spotify tends not to use this kind of thing. They don't have quite as many situations where 20 teams are like totally dependent on each other. But sometimes there are bigger initiatives where teams need to synchronize. So kind of a more typical Spotify version of this is a day-to-day dependency sync. So all the teams that happen to be dependent right now meet every day typically in front of a lightweight tool, just a board like that. And every column is one team and every pink sticky is something that somebody needs from somebody else right now. So it's more a real-time dependency. Who needs what from whom right now? And then they use the daily sync as a kind of a marketplace to resolve who needs to talk to who, like a clearing center. But dependency visualization is one of those kind of, I think, a key transparency things you need if you're going to get alignment. Ideally, you have no dependencies, but probably you do, so why not visualize them?
So that's ingredient number two.
Ready for number three? Yes? Or maybe two is enough.
One more, okay. We'll do three. Feedback loops.
It's not enough to see what's going on. You also need some way of seeing what is the consequence of my actions, right?
Now, if you take any typical kind of agile method and just do what it says, you'll get a series of feedback loops. You get things like unit tests from XP, daily stand-ups from pretty much any method you get, retrospectives, continuous integration. If you do sprints, you have sprint reviews. There's all these feedback loops that kind of come with a package, which is great. That's, I think, one of the success factors why these methods are spreading so fast.
With multiple teams, you just need to add a few more.
You need to add things like cross-team sync, where we talk to each other.
You need things like retrospectives together across multiple teams to talk about how we're going to collaborate effectively across teams. And you need things like the whole product review. We look at the whole thing, how it all fits together, and get feedback on the customer, etc. So just add a few more.
I would say the strongest pattern that I've seen, the most consistent pattern for large efforts, is the notion of an integration cadence. And I find that really powerful because it kind of helps you no matter what your development process is. So maybe this team up here is doing Scrum and they're doing one-week sprints. Maybe they're doing two-week sprints. We have a team over here doing Kanban. We have a team over there doing God knows what, right? They're just, no matter how we're working, we can decide that there is going to be an integration every second week, period. And it's all going to come together and we're going to look at it. Really powerful because that becomes like a forcing function for collaboration. Now teams need to talk to each other because they know that they're going to stand there together in two weeks and it's going to be kind of embarrassing if our stuff doesn't work together. One example of that, at Spotify we normally do it every Friday for bigger initiatives. In the Sony PlayStation integration project, we integrated with Sony, there was like hardware, there's contracts, there's software, all this stuff. The Friday demo was really useful because someone from finance would demonstrate the latest version, the latest draft of the contract. A designer would demonstrate the latest draft of some design, and they would notice that, oh, it's not quite aligned, right? The stuff that's in the contract doesn't fit what we're designing here. We should talk about it. So problems don't get solved at that demo, but they get revealed. And that's the key thing, right? You notice a problem early, then you can solve it before it's too late. It's a really powerful, is it every week? Is it every month? Is it every quarter? Well, that's going to depend on your context, right? How fast moving is your environment? But some kind of integration cadence is super valuable. The more complex your project gets, the more important this gets. So how many of you have something like this in your environment?
Hand up, I'm just curious.
That was surprisingly few. How many of you are in a multi-team development context again? Okay, so you might consider that, right? Again, there's no silver bullet. There's no such thing as a best practice. But this is one of those mostly pretty good practices. All right. Back to Lego, feedback loop, right? We do this thing every second month, this big room planning. And I think of it as alignment as a social event. And it's actually surprisingly powerful. Because in the past we had this army of product owners and product developers and project managers that spent all their time running around synchronizing. They would manage spreadsheets and send emails and call meetings, just running around trying to create synchronization. Well, that's kind of gone away. The people are still there, they're just using their time for more interesting things than just synchronizing people. So how did that happen? Well, the solution was really big room planning. Get everybody together. In our case, it's a single, it's a full day event, happens every two months, and it's about 150 people. About 30 of those are just guests from other parts of LEGO that are really fascinated by this thing. So they come to watch it, and then they get inspired. But anyway, it's Starts with a demo.
Oh, the sound. Can you turn on the sound?
The sound is gone.
It's just a bit of inspiration. Oh, it's just a short video.
Just to give people a sense of what have we delivered during the past two months at LEGO. This is the digital stuff on the website, other tools, et cetera. Reminds people of why we're here. It doesn't replace things like team reviews, team level reviews, it just gives a sense of the whole. But most of the day is really just breakouts. It's just teams doing planning, a little bit long-term planning, not just one sprint or one week or one cycle. They're looking a little bit further ahead. What are the big things that need to happen? And how does that impact those guys? And who do I need to talk to to synchronize that? So it's a synchronization point. This planning would have had to happen anyway, we just happened to do it in the same room at the same time. And you use simple visualization techniques. This is the LEGO Friends people and their planning board. And what shows up there are things like, actually this is actually another theme, but it's a planning board. And it basically shows what problem are we going to solve the next couple of months, what is our focus. So in this case, they want to enable corporate HR to promote jobs at Lego on the new Lego Careers web experience, blah, blah, blah. Or enable Lego House to administer Lego Inside tours. But it's all about kind of the stakeholders, the users, not about deliveries. I call those impact-based objectives. And then some stretch objectives, because obviously we don't know how much we can finish in a couple of months, so we're just guessing. But this gives a sense of, like, the team believes that this is realistic, which is a good starting point. And we've measured this, and we've learned that about 90% of the stuff the teams commit to actually get done, which is really, really good compared to the way it used to be. So now people are a lot more relaxed around commitments, right? It's not a promise. It's not 100%. It's 90%. But it at least gives a sense of, I know roughly who's going to deliver what, when, right?
roughly. We talk about risks and we talk about deliveries. So that's like a very tentative plan for a few weeks ahead, but it's tentative, it's going to change.
And then we have presentation rounds, so teams are presenting to each other, showing here's what we plan to do, what do you plan to do, and oh shit, if you're going to do that, we better do this first. And then they go to the dependency board to synchronize that. So it's just synchronization. And what I noticed was, although developers tend to hate meetings, they like this a lot, because what happens is they solve problems that would have hit them later. So they actually like these. The developers don't think of this as meeting. They think of it as work.
Okay, so just to keep in mind, this is not a batch two-month release thing. It's just a synchronization point. So release happens whenever it needs to happen, which depends on what type of work they're doing. But alignment happens on on and cadence.
So to keep in mind for those people who really hate safe, you can do these things without safe. You don't need the big monster framework to be able to pick whatever practices that fit your environment, right?
Anyway, so that was some examples of feedback loops, right? We're just dipping our toes in some places.
The fourth ingredient that I'd like to add to the soup is clear priorities.
And
What I mean by that is, if you take any organization and you ask the management team, what are all the big projects and initiatives going on, right? And just ask them, just tell me all the big things going on. And you normally get something like, you know, just a bunch of stuff, right? These are all the things going on. And then he asked them, so are they all the same importance? Are they all the same urgency? They're probably going to say no, right? So then you say, well, which ones, you know, can you prioritize this list? And what they'll typically do is say, yeah, yeah, of course we prioritize. We have high, we have medium, and we have low, right? Right. So, done.
Anybody recognize that? Right? Very familiar, right?
So this is also how we used to do things at Spotify until we had this workshop when we finally got tired of it. Like the managers are looking at it, they're like, this doesn't make sense, let's try something different. So we tried something different and it worked so much better so we kept doing that. So that's been a few years now. And the thing we tried that was different was a really wonderful concept called a list. Have you heard of those things? A list?
Right? So what's really cool about a list?
Yeah, a list, there's like, it's vertical. Yeah, there's only one thing that can be on top. It's quite brilliant. I think whoever invented the list should get the Nobel Prize, right?
So what happens if you want to take that one and move to the top? What happens? How we used to do things at Spotify until we had this workshop when we, you know, finally got tired of it. Like the managers are looking at it, they're like, this doesn't make sense, let's try something different. So we tried something different and it worked so much better so we kept doing that. So that's been a few years now. And the thing we tried that was different was a really wonderful concept called a list. Have you heard of those things? A list? Right? So what's really cool about a list?
Yeah, a list, there's like, it's vertical.
When you turn by your name.
Yeah, there's only one thing that can be on top. It's quite brilliant. I think whoever invented the list should get the Nobel Prize, right?
So what happens if you want to take that one and move to the top? What happens?
then this one's no longer on the top, right? It's great. So that's what we did. We just introduced a single stack rank of cross-company initiatives. These are just the big things, right? The teams are iterating on their missions in the meantime, so this doesn't cover everything that's going on, but it covers the big things that cut across different parts of the organization. And you might argue that, but some of these are independent. Like this is mostly HR, and this is mostly finance, right? Why do we have to force rank them? But it turns out that there's always going to be some constraints somewhere, some dependency, some budget that's limited or access to some resource, something. And if everybody knows that this is more important than that right now, it makes it easier to make decisions. So that's how it works. And the guiding question is, if we only can do one of these two, which would it be? This or that one? If one of these would be delayed by a month, which one would we rather have be delayed by a month? If we had to pick, right? It's kind of a cost of delay thinking. I wish I could say that we were super structured and we really had done the math and we had cost of delay on these things. No. A lot of it is just gut feel and discussions. But it's still very helpful. And what helps a lot is that, again, the company beliefs, the North Star goals, it reminds everybody that this is where we want to go in the long term. So in order to get there, you know, which of these would we prefer? Be at the top of the list, which one should move the fastest, right?
Right, so they're stack ranked. Everything is strictly stack ranked. And what we noticed was that this spread. So it started kind of at the executive level, but then it started spreading because other parts of the organization, like infrastructure tribe, were like, oh, that's interesting. If this initiative is the most important for the whole company,
What can we do to support that? What would be our most important contribution to that? Because our stuff isn't on that list, because that list only contains really big, wide things, right? So maybe things like we're going to invest in the cloud. We're going to move all our stuff to the cloud, which is a real-life example, actually. And that's going to be at the top of our list, because that's how we can support the long-term vision of the company. So that would be their version. And marketing, kind of same thing. So we don't force everything to align, but by making it visible we at least increase the odds.
So it's all just a conversation tool, really.
But what I like is the fact that this wasn't mandated, it wasn't pushed out, it was more like other parts of the organization got inspired, they're like, hey, that makes sense, we're going to do similar. And now it's become almost like a de facto standard.
And the idea here, and this is an example of any tool can be misused. You can use a tool like this to kill autonomy, right? Like everyone has to work on this top story, so screw autonomy, right? Now this is more about giving context. So let's say you're in this, let's say we got these three teams. Working on a Sony PlayStation integration. We got those two working on, they're working on the running experience, trying to figure out how Spotify can be a good thing for when you're running. Both are real life examples. This is number one, that's number two, but we're still gonna do both. It's just that when push comes to shove, if one has to be slower, then we'd rather have the running one be slower. Anyway, so over here we have this tools and infrastructure team, and they're trying to figure out what are we going to work on today. Well, now it becomes easier for them because they got all these people pulling at them, but now they'll start by asking the Sony PlayStation people, you know, what's slowing you down? How can we help you? And they'll focus on them while also supporting others, right? So that's kind of just a tool. It's not perfect. It's not as clean and pretty as it looks like in a picture. Things are always going to get a bit messier. But it certainly has helped as a communication tool.
So here's a team or a squad as we like to call them. And there's another squad saying, hey, we need your help, right? And we have someone over there saying, you need to upgrade to this new build server. And we got our backlog and we got Jira tickets coming in and our own crazy ideas. And we got our user testing data. We got A-B test stuff. We got all this data coming in, right? All these impulses. So as a squad, you're still responsible for figuring out how to make best use of your time.
What the bet boards do is they give you context so you can make the decision better. Because we don't want to get to the point where it's up to a manager to make that decision because they don't know either. We want the teams to make decisions, but give them as much context as possible so they can make a better decision. And I guess also to visualize the fact that they've made that decision so other squads know it. So it's never going to be perfect. There is going to be misalignment, but this at least helps us reduce it a little bit, and it helps us detect it earlier when it's happening. All right? Does that make sense? Mostly, yes? Good.
Back to Lego. I told you I'd jump back and forth, right? Back to Lego. We're at this planning event, right? This is a bunch of representatives from a bunch of teams that do mostly infrastructure work. So their job is to make other teams faster so that those teams can delight the customer. Okay? And the question is, what do we need to do to make the other teams faster? Well, there's a bunch of stuff we could do. In the past, every team had their own backlog. We had the search team, had their search backlog, monitoring team had their monitoring backlog, testing infrastructure team had their testing infrastructure backlog, etc. Which doesn't really make sense because what if monitoring is really, really important right now and test infrastructure is pretty much not so important right now? We have what we need. It'd be better if we help those guys, right? So to enable that, we have a single backlog now as input to this alignment event. And it basically, all the product owners and key stakeholders get together before the planning event, and they just have all the arguments. And they decide that, okay, the most sensible sequencing here is that one first, then this one, then this one. And that's input to the alignment event. So when all the teams meet, the priorities have already been agreed upon, and the question is more about tactics. Who's going to do what in which order? So there's argumentation. We'll do these three, and we'll do those, we'll do that, and wait a sec, nobody's doing that one because it's boring, but somebody's got to do it, so let's talk about it, and then you discuss it, right?
So this is pull. From a single backlog.
Some teams prefer to do it digitally, so this is a digital version of that. Single backlog, prioritized. Here's all the teams working on that part of the system, or working on infrastructure in this case. And you literally just grab one there and you pull it like that. And this bar shows your whip load, right, based on yesterday's weather and velocity. So it just gives you a sense of are we totally overcommitting or do we have so slack in the system, right?
Some problems don't get solved though. Sometimes there are problems that just, oh my God, we can't solve this. So during the day we have this management review where all the managers get together and basically have to deal with the stuff that didn't get resolved. We have a really important prioritization constraint. We can't do these two things. One has to go. Which one is it? So they have to make the tough decisions, make the tough calls, and help out. There are some risks that are out of the team's control. And a manager will need to sign up and say, hey, I'll help to figure out how we can get access to the licensing server or whatever it is we need. So by having everybody in the same room and a clear constraint that we have this one day and after that we're done, right? Of course, we'll have meetings and alignment as we go, but the big alignment event happens for them every second month. A bit seldom you might think. We might do it more often in the future. I don't know, right? But anyway, very helpful to be able to deal with problems now and not just trigger a meeting later, right?
So that was an example of some examples of clear priorities. It helps a lot to really force things into a single list. It can change. It's not permanent, right? But it really helps a lot.
So, last ingredient. You still awake? You want one last ingredient, right? And then after that, you get to add your own ingredients, depending on your taste.
Last ingredient is flow, which should be dear to your hearts considering the name of this conference.
And I'm going to illustrate that using a little demo that some of you might have seen because I use it quite often. But I'm going to use it anyway because it's important.
I'm going to illustrate what I mean by flow and unflow.
And for that I need some help, so I'm going to need a Madame Jenny, who is going to take the role of customer. So give her a hand. Madame Jenny, great.
And I'm going to need five volunteers to get up here and keep us company. So five volunteers. I'm not going to do anything horrible to you. Don't worry. We got one.
Yay.
You might think I'm sponsored by Lego, but no.
Okay, so the way this works is that you represent some kind of a team, and you're going to be delivering Lego bricks to Madame Jenny, because she wants Lego, right? She doesn't have any here right now. She wants Lego there. This is our production environment, right? Yes. And all of you have different skills, so we're going to simulate that by having you pass a Lego brick through all ten hands. So I have to pass through all ten hands, and when it has passed through all ten hands, it's considered done. And then you just deliver it, right? And she'll put it into production. Okay? So I'll start over here. Just pass it through all ten hands. All right. Watch them work, right? It's hard work. Yeah. Cool. And deploy. We'll stop there for now, right? Just do one. Cool. Give them a hand. They released, right? Yeah. Cool.
Yeah. Now they're all happy because they don't know what I'm going to do next, right? I'm going to say, here, build this one.
Oh my God, how the heck? This is really, it's got to pass through all 10 hands. You got to pick, you know, yeah, including the left one in your pocket.
There, ooh, got it. Cool, okay. Great, so now they're warmed up, right? They know how to deliver, great, cool.
This time I want you to count because most of you are lean geeks, so we need to measure cycle time here, right? So I want you to count how many seconds does it take. Loud. Okay? Ready? Count.
Seven seconds and a bug. Not all ten hands touched it, right? So that one's a bit buggy, right? Remember, all ten hands have to touch it, including your left one. But now we've baseline the process, right? Seven seconds, cool.
This time I'm going to pause in the middle. So when I say pause, you just freeze. Okay? Right.
Pause. Pause. You don't count when they're paused. They're paused, right? Okay. Now they're paused. And this is what Monsieur David, the manager, sees when he happens to walk by. It's just his snapshot, right, of what he happens to see, right?
And then he... And then he runs off to some meeting, right? So that's just a snapshot. Okay, and then they, you know, play, right? Keep working, right? And then pause. Monsieur Davidis comes back. He opens the door. This is what he sees. What do you think he's thinking?
Yeah, what do you say? Wait, let me get you a mic. We want to hear his comments here. Monsieur David.
Right.
Lazy people. Yeah.
What? Only two is working. Only two is working, right? What are we paying for? So we should do something about this, right? Yeah.
I know this consultant. Yeah, I know a consultant. His name is Dave. Should I call him? Right, I'll call him. So Dave, yeah, you're a consultant, right? You know how to really utilize resources efficiently, right? Yeah, can you come here and see? I have this problem. I'll show you. I'll show you. Just come in and I'll show you. Dave, yeah, great. Thank you. Cool. You see?
I see the problem.
Waste, right? Yeah. So we'll fix this, right? So let's reset the exercise. Thank you. Okay.
Okay, we're going to need some sound now in a moment, okay? So just a sec. Once you're a Dave, it's now going to make sure we keep everybody busy. We want to utilize our resources efficiently so we get banked for the money we pay, right? Okay, ready?
Okay, keep him busy, that's great. We got a lot of, we gotta get to work, pass him around, yeah. Cool, that's great. Oh, there's an available resource. There, there, right. Here's one. Oh Dave, there's one, there's one, yeah. That's cool, okay. All right, we got one there, okay. Cool. Okay.
Pause, pause, freeze, freeze. Cool, okay, we freeze. Now Dave, wait, oh wait, Dave, I'm sorry, I see two hands there with empty hands. We can't have empty hands, yeah, that's great, great, okay. Cool, so Monsieur David, come back here. This guy, Dave, he's amazing, look what he did. Monsieur David, yeah, come here, I'll show you. It's really cool, right?
What do you see?
It's great, right? We fixed the problem.
Maximum efficiency.
Maximum efficiency, yeah. 100% utilization. It's just great.
I didn't get any breaks. The heck? Wait, let me see that. None? Not a single one? The heck? Pause, pause, freeze, freeze. Cool, okay, we freeze. Now Dave, wait, oh wait, Dave, I'm sorry, I see two hands there with empty hands. We can't have empty hands, yeah, that's great, great, okay. Cool, so Monsieur David, come back here. This guy, Dave, he's amazing, look what he did. Monsieur David, yeah, come here, I'll show you. It's really cool, right?
What do you see?
It's great, right? We fixed the problem.
Maximum efficiency.
Maximum efficiency, yeah. 100% utilization. It's just great.
I didn't get any breaks.
The heck? Wait, let me see that. None? Not a single one? The heck? Okay. You've seen this happen before, right? How many of you have seen this problem? Right? Everybody! It's such a common problem. I'm sorry, I'm going to keep using you. Is it okay? Right, okay. Yeah, it's such a common problem. And I think the reason is because at first glance, this does look very good, right? Except that things are moving very slow. So can I ask you to step to here? Because I'm going to show a picture. So if you stand here. And Jenny as well. Yeah, just stand here. And I know this is an old metaphor which is overused, but it's still a very good metaphor that when you have a traffic system that looks like that, right? 100% utilized. Whoever paid for that road, right? Someone paid for it. Might be like, yeah, you know, it was an expensive road. And I'm really glad to see it's fully utilized. Right? Fully utilized expensive road. Except that the purpose of the road is not to be utilized, right? The purpose of the road is to help people get from A to B. And we don't get from A to B if the road is fully utilized. We get from A to B if there is sl And that's because of queuing theory. You can't really get away from that. And in reality, it's actually worse because it's probably going to be more like that, right? And what's interesting is if this is your problem, you've got too much work in the system, you've got fully utilized people, then alignment isn't going to happen. Alignment isn't your problem. You've got to start here. You've got to enable flow. Now, there is this nice trick, right, that we use a lot in this community that addresses this problem. And what is the trick?
Whip limits, yeah? And is it possible to achieve without whip limits?
Whip limit is one way, right? The trick is pull. Have you heard of that? Pull, right? So let's turn this into a pull system. So can we gather all the bricks back here?
Here we go.
All right, now let's turn it into a pool system. So instead of me just throwing in bricks,
I just go like this. So just take one and pass it along and then just take another one, just like you wanted to do before, right?
So what's going on now? What do you see?
You see flow, right? You got, if we just pause, pause for a second. Okay, what's the resource utilization right now, roughly?
Four out of ten hands, roughly. And the key point is I don't care what the resource utilization is because it's just what it needs to be. It's just enough. And stay frozen. We've got Alex Say here. He's got nothing to do right now, right? That's not waste, right? It just means that he's ready. So when that green one comes, he's got it, right? It's going to keep flowing. But if everybody's busy, then when the next brick comes, it's going to have to wait. So we're paying the price of having seemingly idle people, but that means that the work itself is never idle. It just keeps flowing, right? Right, so yeah, keep flowing, right? I'm going to add one more dimension to this. Keep pulling. Now what if I tell you that the red ones are worth 10 times more than the other ones? Watch what happens. Look at that. The same people doing the same amount of work, but it's 10 times more valuable. Pretty cool, right? Otherwise known as agile. You can change priorities. So, yeah, thank you very much. Let's give him a hand for being cross.
Thank you.
Well done.
Human props for the exercises. Thanks a lot for showing up. All right.
So I realize that this is preaching to the choir, right? Lean Kanban France, this is a lean conference, most of you know this stuff, but I still want to emphasize it because if you don't sort this out, forget alignment, right? So you kind of need to start here.
Okay, so that's ingredient number five, flow.
We're done.
Whore.
But wait, what have we not talked about? What's really important we've not talked about for this all to work?
Value is an important aspect, yes. That's another one. The question is really, but wait, wait, wait, wait, wait, wait. Who puts the ingredients in, right? Do they just magically show up, right?
The cook. The leader.
Right? We need leaders.
Experiment with ingredients, see what works, right? Sometimes things work out well, sometimes not quite, right?
Leaders.
See, I've noticed that in our community, in the Agile Lean community, we're big on decentralization. We sometimes like to believe that leaders are not needed, right? I'll get rid of them so we can do the real work instead. I find that to be, I used to believe that myself, but I noticed, especially at Spotify, I've been facilitating a lot of the big kind of retrospectives when we have done something big and then we kind of want to follow up on what did we learn from it. We do retrospectives as we go, but then we also do one at the end. And the common theme is we've gotten better at big projects. We used to suck at it. We've gotten better at it. And the main difference is leadership. Surprise, right? So let's talk a little bit about that. So we're so self-organizing. Yeah, man, who needs leaders? I found that often in the successful efforts, there is a leader somewhere, but sometimes they're hiding, right? Sometimes they call themselves something else. Oh, no, I'm not a leader. I'm just a coach. Right. But you're making sure everybody understands where we're going and why, right? Oh, yeah, of course. Right. So if we look at, like, there's this tendency to believe that leaders are all bad and evil. I call that leader phobia, irrational fear of leaders and leadership. The mistaken belief that all leaders are evil and all leadership is bad, right? Does anybody want to confess to this phobia? I have arachnophobia. I'm scared of spiders, right? I'm scared of leaders.
There are some companies that are often brought up as poster childs of self-organization. Companies that like, well, they don't have any leaders. They don't need any leaders because they're completely self-organizing. Semco, Valve, Zappos, that's often brought up. You read articles about them and they often emphasize the kind of boss-free thing, right? But if you look behind the scenes, kind of carefully behind the scenes, what do you see?
Hmm.
Right? Who's hiding behind the bushes? Well, there are people hiding behind the bushes. Right? There's a guy hiding behind the bushes at Valve. There's a guy hiding behind the bushes at Zappos. Right? Who enabled this self-organization to happen in the first place? Who calls a shot at Valve? It's Gabe. It's his company. He has enabled this. It is because of his blessing that the teams can be self-organizing and not have managers. So it's the interesting paradox of the manager saying, you don't need managers. I'm using my authority to say you don't need my authority, which is kind of interesting.
And if we acknowledge those leaders, I think life gets a bit easier, we get a more honest communication. Plus, I think it's worth, if nothing else, for ethical reasons, to acknowledge people that are doing a good job. What do we call these leaders? Well, that's going to depend. Some call them a chief product owner, some call them a project leader, or a road manager, lead honcho, head honcho, chief benevolent dictator, I don't know. Call it whatever you want, right?
For small efforts, one or two teams, probably not needed, but for something big, Again, complex? Yes, it will be needed. But their job is different from traditional, more kind of hierarchical, top-down leadership. I think of it as it's a person who holds the vision, who holds the picture of where we're going and why. So here we've got a bunch of teams building different parts of this house. The leader is reminding them of how it's all going to fit together, who's going to move in and what they're going to do with it. Plus the leader is putting in place all these things I've talked about, right? Transparency, feedback loops, making sure that stuff is all there so that they can step back.
So it's not the single ringable neck, it's not the one person we want to be able to chop their head off if things go south. It's more like the person who is able to create a shared sense of accountability.
I create an environment where people actually are motivated to care about the product and then result.
And that's hard. That's why these people are needed. It's not me aligning the teams. It's not me running around synchronizing. It's more like me setting up the dependency board or getting people that know that kind of stuff or creating communication forums like the big room planning so that teams can self-align because it's just more effective.
It's not me making decisions. Whenever I have to make a decision, that's a warning sign. Why did it have to come to my table? Instead, I'm creating an environment where teams are able to make decisions on their own, where they have the context they need, they have the courage they need, they have the fail-friendly environment, etc.
And finally, as I illustrated in the exercise, it's definitely not my job to run around focusing on keeping people busy. It's my job to create an environment where people realize that busyness is not a good idea, it's a bad idea. And we want some way to kind of focus on flow instead. So I would be looking at things like putting in whip constraints, putting in pull systems, making work visible, etc. That's what I think of as a kind of good leader in an aligned autonomy context. And it doesn't have to be one person. It can be a pair working together. It can be a trio. At Spotify, we almost always use this kind of combination of someone from a tech perspective, someone with a product perspective, someone with a design perspective, because they're going to see the world in different ways, and we want those three perspectives. So like a mini leadership team. Not in all cases, but typically for bigger initiatives.
So, yeah, to wrap it up, these were some ingredients. It's obviously not a complete recipe for alignment. It's a tricky thing. It's hard. But I'll consider these kind of the basics. Some kind of shared purpose. Some kind of transparency. The more, the better.
Feedback loops at all levels.
Clear priorities, and then a sense of flow.
Yeah. Thank you.