Patrick Steyaert
Transcript
Shall we start? Okay.
So who was in class's talk just before this one?
Great. So I'm going to build on that a little bit.
It's quite funny that it was scheduled one behind the other, because I'll continue a little bit on some of the themes that Klaas introduced. But there's going to also be some differences. So while Klaas is looking a little bit more upwards, which is the... The natural thing that we tend to do, I'm going to look a little bit more sideways.
So just as a test whether you've paid attention at Klaus'talk, a little quiz.
So suppose that at an organizational level, really not at a team level, but at an organizational level, you've been able to
increase your delivery rate substantially, reduce your lead time substantially, and all the while improving your quality.
Agile initiative. Would that be considered a success?
No.
Well, for most organizations, this would be a success. But still, people are nodding no. Why not?
Yes. So we might have become faster at delivering the wrong thing, right?
Yes.
Yes, well, not entirely. But let me explain. Let me explain. So this would be aspects of an agile development initiative, right? Even if we do it at scale, we would be talking about improving our agile development. And as Klaus already introduced, we're not talking about people, companies today, organizations today are not just looking at agile development. They're looking at an agile business. So work starts much earlier. It starts with the user, with your business, with your customer.
So we're looking for business agility, we're not looking for a local optimization in your little or large silo of IT or development or engineering. We're looking at the end-to-end value stream.
Now, in order to understand this business agility concept a little bit, because This term has been kicked around a little bit the last couple of years. So what do I mean with this? And in order to be able to explain that, I need to take... One step back. So how do we deliver agility today? What is our main way of delivering agility today?
It's through agile methods, right? Through lean and agile methods. That's the main way that we introduce agility in organizations. So starting somewhere like, I don't know, 20 years ago with methods like XP and Scrum. And even before there were some methods. So starting with XP Scrum and then
some Cambrian explosion, with a new wave of methods that each tend to focus, strangely enough, to one particular aspect of agility.
So, GAMMAN focuses more on balance and flow,
The methods, self-managing methods in terms of holacracy, sociocracy, methods that really focus on the organizational part, on the people and the interactions. And then methods like Lean Startup that really focus on the learning part, iterative learning, dealing with uncertainty.
Strangely enough, that second generation of agile methods seem to focus each on one particular aspect of agility. So there seems to be a specialization going on.
So what does this bring us? In terms of business agility, what does this bring us? Well, it does bring us quite some good things. If we look at the flow perspective, moving from focusing on keeping the hands busy to meeting, being better to meet the customer demand.
So that's like the CAMMAN perspective. In terms of learning, so the lean startup perspective, not focusing on outputs, but focusing on outcomes. And then in terms of the organizational perspective, not really the division of labor and command and control, but focusing on self-managing teams. So it does bring us... the core ingredients of what you would call business agility.
But what we don't see, or... Kind of what we do see is these islands of agility, right? So we do have the ingredients, we do have the ingredients, but they seem to live all on their little islands.
And not just like different communities that each live in their little silo, but also in organizations we do see that. So this part of the organization is doing Kanban and Scrum within a safe context, and then maybe the incubator or the digital platform part is doing Lean Startup, And the business is doing holacracy or some form of sociocracy or self-management.
And then you go into a workshop and then you have different parts of the organization there and you need to be able to talk to all of them. Now this is quite far removed from business agility, right? We've got these little islands of agility across the organization. And what we're missing... What we're not seeing is the blue ocean surrounding those.
Islands of agility, which are still filled with the relics of the past, right? The relics of 20th century management.
Relics like division of labor, command and control. The dominant thinking is still a very deterministic, reductionistic type of thinking. And we see the relics of that.
We're not connecting those islands. Especially upstream, where we have things like phase gates, portfolio, portfolio, portfolio is not a flow, it's a stock. It's a static view.
So we're still seeing those relics which kind of hamper us in our thinking about really becoming agile as an entire organization.
So what are some of the symptoms that you might recognize?
So one symptom is, especially in this divide between the business and then the delivery side of things, where we're becoming much more agile on the delivery side, so our cadence of delivery is picking up. Now, if our cadence on the demand side, where we have to make quite some decisions, and the decision-making process still has this cadence of, like, three-monthly, quarterly, or even yearly, the yearly budgeting round, You're creating quite a big gap between those two. You're creating quite a big mismatch between the demand side and the delivery side. Yes, we are able to deliver. We have a cadence of three monthly or weekly, two weekly or even daily delivery. But our decision-making process is still a decision-making process of a yearly decision-making process, yearly budgeting around.
So, an effect that you might see as a result of that, because of this very slow decision making process on the demand side, is that your demand is like
fluctuating quite heavily.
We see this seasonal fluctuation. All the work is released in the organization at the beginning of the year. And at the end of the year, we need to spend our budgets.
So we see this big fluctuation in demand.
On the delivery side, we're saying, like, guys, we don't have any work. And then suddenly,
we have like tons of work. So we alternate between periods where we're overburdened and periods where we need to look around and say like, what work can we do? We're starved from work.
And especially because there's this mindset of The demand fluctuates and we need to adapt our capability to that fluctuating demand. We need to scale up because our demand is getting higher and we need to scale down because our demand is getting lower. So how do we cope with that? With that, like this need for scaling up capability and scaling down capability.
We open a can of developers. New developers.
New people.
And then when we don't need those people anymore, what do we do?
We release the knowledge, right? Because it walks out of the door. So a lot of waste.
And then maybe most importantly, we end up with suboptimal value creation.
We tend to under deliver on high risk, high value demand. So we tend to
not be able to cope very well with or deliver very well against high value initiatives, but high value where the value might be uncertain. And I'll explain a little bit why in a second.
But just to reference classes, talk again. Remember the big upstream where we need to make a lot of decisions? Well, high value, high risk items tend to get stuck in there. They take a long time to get started.
And so they get stuck in there. So we're very slow at the lead times for them are very long. And not only that, once they get started, we have a hard time. I'm in delivering them because of scaling up, for example.
So we see organizations or I see organizations that are pretty much under delivering on high value, high risk demand and then over delivering on low value, low risk demand because in periods of starvation, what do we do? We start working on that type of demand. And on the other side, you also see organizations that are just like, they're focusing on the high value, high risk items, and there's no delivery on the low value, low risk demand. So in the end, our value delivery is quite suboptimal.
So, I think...
Upstream is kind of the most important part of the process. Yes, we need to look at the delivery side and improve our capability to deliver. Yes, we need to do that.
And we need to do that at scale.
Coordinating multiple teams and so on and so forth. But most of the gains today in most organizations are not there. They're in the upstream. In making sure that you make the right choices upstream, that you shape the demand, and that you're focusing on the right things at the right time. So most of the games can be made upstream.
So we need to look at the whole. We need to look at the end-to-end flow, not just optimizing one part, optimizing the end-to-end flow from beginning to end. Now this is where I disagree with my previous speaker. But most of the gains today in most organizations are not there. They're in the upstream. In making sure that you make the right choices upstream, that you shape the demand.
And that you're focusing on the right things at the right time. So most of the games can be made upstream.
So we need to look at the whole. We need to look at the end-to-end flow, not just optimizing one part, optimizing the end-to-end flow from beginning to end. Now this is where I disagree with my previous speaker. I don't think the upstream is simple. I think actually it requires quite some attention. It requires quite some attention. So what are the challenges upstream? What are the challenges in managing the demand? Now this is what typically people will think about as the challenge upstream. It's really the challenge of making a selection, right?
At the top end of the upstream, we think about it as like this funnel. And at the top end of the funnel, we got all these opportunities, all this demand coming in. And then we need to kind of make some selection because the bottom end of the funnel is like this little pipeline, and we always have more demand than we can deliver, so there's this little pipeline that is the bottleneck in terms of delivering. So selection is conceived as the big challenge there. I think that's... A wrong picture.
If this would be our challenge, then it would be that easy. I think the challenge is way deeper than that. So let me explain.
So one part of the challenge is overcoming friction.
So the previous slide showed this funnel and making selection in the funnel. And this gives us the picture that selection is like We put all the alternatives next to each other, we score them somehow, and we evaluate them one against the other. Right? Okay? And that's selection. But the reality is that these initiatives, these opportunities, the demand, doesn't come in. All together. They come in, one week you have one opportunity, second week you don't have any opportunity, the third week you have three opportunities, They come in very unevenly. Right? So how do you make a selection when the demand is coming in like in a very uneven way? How do you make a selection then?
What do we do to do that? We batch our opportunities together. We do a yearly budgeting round to batch them together so that we can make a selection. But you know what happens if we batch them together?
We get this big mismatch between the demand side and the delivery side. We get this huge fluctuation of demand. Which is not what we want. So the real challenge for me is that downstream, on the delivery side, here, in this little pipeline here, we know by now that it's best organized around a very stable and even flow. That's what we've discovered by now, I think. So it's best that we have a stable incoming stream of work and that the team can organize itself around a very stable incoming stream of work. But you know what? At the top, On the demand side, on the opportunity side, it's very uneven. It comes in whenever it comes in. And the challenge for the upstream is... is to overcome that gap, to overcome the gap between a very fluctuating incoming demand and a stable stream towards your delivery.
And that challenge is even made worse or made more difficult because in between we need to make those decisions. And those decisions typically require people higher up in the hierarchy. So people that are not so available or people in the business, people that are not necessarily instantly available. So again, that even makes the fluctuation of the demand even worse.
So that's one part of the challenge, and I think a main part of the challenge. How do you overcome that gap, that friction?
Another part is obviously managing uncertainty.
Now I think by now we do have some conception of how to deal with that.
Managing uncertainty in the sense that not all demand is equal. Some demand is maybe some lower value, but with that lower value comes higher certainty.
Right? Low but high certain, low value but highly certain, or low risk. That's some demand. Other demand is much higher value, higher potential. value, but consequently also higher uncertainty.
So those are different types of value and they require different ways of treating them.
But I think by now this is quite well established. Low value, low uncertainty, low uncertainty especially.
We can just immediately commit to executing them. So this is a one-step process. If you're talking about high uncertainty or low certainty, you need to have a multi-step process, right? So rather than immediately committing, we say we're going to do an initial, we take an option on the value, and then we exercise that option in terms of
a commitment, right? So this is the whole thinking about, like as an example, MVP thinking. We first develop a minimum viable product. That's our option. Based on the results, we scale. So that's a two-step process. Again, in the upstream, we need to manage that uncertainty and see which route are we going to take. And then finally, oh, finally,
I think a more mindset problem is the mindset problem of order taking that we need to overcome. So we do quite a few upstream workshops. And at the end of the workshop, there might still people be left that say, yeah, but in the end, if the customer asks, we need to deliver. Okay? So somehow we've managed to establish an order-taking mindset in organizations. And so the fact that you can actually shape the demand, the fact that not all demand is irrefutable, is quite a big obstacle to overcome. That if there's slow demand from the customer, you can actually influence the customer to create more demand. And on the other hand, if the demand is high, you can actually influence the customer in terms of lowering the demand or changing the demand in a way that is better suited to deliver. So it's a two-sided coin. It's not only improving the capability to deliver, But also the customer has an incentive to shape the demand so that we make better use of our delivery capability.
So it's a two-sided coin.
And I think that mindset is... is still quite a big challenge to establish.
Okay, so that's kind of the theory. Let's look at a concrete example.
So, starting point. So this is a KEMAN system.
For an IT maintenance team.
And so as you can see very typically, so here we're in a situation that we have a visualization, a board for upstream as well as downstream. But the CAMMAM part is really only here. So we only have a real Kanban system on the delivery side. Here we have visualization, but not a real Kanban system yet. So what do I mean by that? Here we're controlling the work in progress, we're managing the flow. We're controlling the work in progress, so we have WIP constraints in place. We're managing the lead times, and so on. Here, this part, and actually this part, We're Just visualizing what is there.
This part is heavily influenced by the users. It's the user acceptance testing. So that's why it's not constrained, because we can't constrain the users. This part, likewise.
So, emergent agility.
So, in this case, unlike what Klaus showed, we actually have quite some improvement.
So we can call it a success in the sense that we see our lead times being halved by means of the Kanban system.
Lead times were halved, our throughput slightly increased. If you look at, this is a cumulative flow diagram, so if you look at the delivery line, which is this line here, you see it curling up a little bit, meaning that our delivery rate is slightly increasing. And actually there's indications also that the quality was also actually improving. Success?
Yeah? So, success. That's what the team also found. That's what they reported to their customers, which is the business partners.
So that's what they found also. Up until the point where you talk with some of the business users, And they say like, yes, Patrick, this is fine.
We're convinced that the team is doing its best to improve and we see the results of that.
But you know what? For us, The clock doesn't start ticking when the team starts working on it. The clock starts ticking when we issue the request.
So at the same time, the manager of the team comes, talks to you and says like, yeah, Patrick, we're now better at delivering, but I'm not convinced that we're delivering the right stuff.
So, in terms of climbing our mountain towards business agility, yes, we've made this first step, and I think an important step, but it's only one step.
What do you see? So, yes, we've improved this part of the flow. But what do you see in the end wind flow? What do you see upstream?
Well, there's at least one noticeable thing on the board here.
Right? There's one noticeable thing on the board here in the upstream is we've got a bubble in our pipeline.
We've got a bubble in our pipeline. So we've got what I call a barbell flow. A barbell flow is like the barbell. And the weight is... At the opposite ends and nothing in the middle. So we've got a barbell flow. In the sense that we've got quite some items working, waiting, sorry, waiting in our inventory or our backlog, just in front of the point where we commit. So this is the upstream. Here's our commitment point where we commit to the work. And here's the delivery. So just in front of the commitment point, We have a big batch of work waiting.
Then in the actual upstream process we don't have any work and then we see quite some work stuck early in the process. Now if you look closer you will see that a lot of this is low value, low
And then a lot of this is high value, high risk. So what is happening here is we have a decision making process at certain points in the upstream. And what is happening is the low value, low risk encounters little friction in that upstream.
There's little discussion on the low value, low risk. Yes, it's low value, low risk, we approve. Low priority, but we've analyzed it, we've estimated it, we approve it, done.
Where do we see the discussion? Where do we see a lot of friction? Obviously in the high value, high risk items. And they get stuck very early on in the upstream.
So what happens when they get stuck in the upstream? And they get stuck very early on in the upstream.
So what happens when they get stuck in the upstream? These high value, high risk items. And people are discussing them. There are different opinions between the stakeholders. What do you think will happen at a certain point in time?
Higher management calls and says like, you need to do it now.
So the team keeps itself busy, because we need to keep the hands busy. The team keeps itself busy. So they start this low value, low risk work, and then at a certain point in time, There's an intervention from higher up saying this initiative is becoming urgent, you really need to do it now. So high value requests that got stuck early on are expedited through the upstream. Even if the work is not prepared or not well analyzed, we need to start doing it.
And we need to commit it on top of the work that was already committed by the team.
So yes, the team will do its best to keep to its WIP constraints. But you will see that they will start working at their maximum WIP.
So in the end, we have a very uneven, because of this dynamics at the upstream, we have a very uneven downstream flow where there's times where the team needs to invent work and times where the team is overloaded by a lot of work.
So, the end result is very long customer lead times. So how does this explain the long customer lead times? So our system lead times are becoming shorter and more stable, but the end-to-end customer lead times, the lead time from starting a request and actually delivering it are quite long. And the reason is of course the low value items that get stuck before the commitment point.
They stay there and they age there. Some of them die there.
So their lead times become long.
And lead times of high value, high risks are also long because they are stuck early on in the process.
So overall, very high customer lead times. Happy customer? Not really. Not really.
So, the specific upstream challenge that we had in this case is
all demand needs to be analyzed and responded to in priority. And in order to determine priority, we need to analyze them. And the more that we analyze them to determine the priority,
the longer the upstream lead time becomes.
Decision making causes the delay, especially for high value items. And in the end, we have a large backlog of aging low value demand. And then the high value demand needs to be expedited in and rushed in because it got stuck.
So, we need to do something about this. We need to do something about this.
So to deal with starvation, so the periods where the team doesn't have any work, there's just an established technique out there coming from logistics.
So they established this technique in order to make sure in the warehouse that you're never out of parts is to establish order points.
So an order point is, so suppose that this is the work items that you have or the inventory that you have.
That inventory will go down because you deliver.
That inventory will go down because you deliver.
If it goes down below a certain point, below the order point, what do you do? You order so that you have, again, sufficient work items ready to be delivered.
And where do you establish that order point? Well, you establish that if the lead time for ordering is this long, you want to make sure that you establish, you order just in time so that it doesn't go below a certain safety stock. Okay? So in plain terms, this means that suppose that you're downstream team is delivering five work items per week okay and it takes two weeks in the upstream to get a work item ready yeah where do you put your order point Yeah, somewhere a little bit above 10. So that at all times, You can survive for two weeks. The downstream team can survive always for two weeks. It always has sufficient backlog for two weeks that it can continue to work for two weeks. Okay? That's your order point.
So that's one part of it, order points.
Avoiding starvation. Other part of it is managing the uncertainty. So in the process that was established, all requests need to be analyzed by the team.
And there was no differentiation between requests that had more uncertainty and requests that had less uncertainty.
So we established a new way of working where we differentiate between requests that have high uncertainty and requests that have little uncertainty. Requests that have little uncertainty, we capture the demands and we immediately analyze them.
We immediately analyze them. So there's no step in between. For high uncertainty, or low certainty, we capture the demand. We first make sure with a team,
with a collection of stakeholders and then the right people from the delivery. We make sure that we have a correct understanding of what is needed without going into detail. So this is a synthesis step before we actually do the analysis. So we have a two-step process.
So we manage the uncertainty in the upstream. And then finally, we implement a system of triage. So this is quite a core concept to upstream. I know that quite a few people use the word triage as a synonym to selection. But it's not a synonym to selection. It's really something different.
So triage like in a field hospital or like in an emergency part of the hospital, right? Also in a field hospital or in an emergency, the demand is way higher than the delivery, than the capability to deliver. And so how do we cope with that? So we color our requests. The requests are colored in terms of black, Black means we don't think this is a valid demand. So it needs to be escalated. The decision making needs to be escalated. It's not a valid demand. In a field hospital, black has a different meaning, but it's more like this will not survive the process.
So in our case, we don't think this will survive our process, so we need to escalate the decision. Red is if we act now, we can rescue the patient, but we need to act now. So red means all hands on deck. We need to expedite the requests. The house is on fire.
So the interesting part is between the yellow and the green ones. So yellow means this is potentially a high value item, but also a high risk item. So this is an item that potentially might get stuck in the upstream. So we need to influence the timing here, because we know that if we're not influencing the timing, if we're not proactive on this item, it will stay stuck in the upstream up until it will get expedited.
So we are actually taking care of our customer. The customer might issue a request and then forget about it or not take action on it up until the point where it becomes urgent for the customer and then it gets expedited. So what we're doing is we're going to be proactive to our customer and say we need to work on this. It's like preparing a presentation for a conference. If you wait until the last moment, you don't have enough time to incubate your ideas. You don't have enough time to let ideas ripe. So what do you do? You're going to be proactive. You start. In time, but you commit late. So you're going to be preemptive on those items.
The green items. So these are the items that previously got stuck in front of the commitment point. So these are the items that got stuck in our backlog. We've done the analysis, we've done the scoring, we've evaluated them, and then they're sitting there.
So what do we do with the green items?
We're not even looking at them. We just classify them as green. So this is the patient that comes into the emergency room and says, like, ooh, I'm dying. I have a cut in my... in my finger and I need to see the specialist right now So this patient gets a green armband, okay? And they're not even going to start any type of diagnosis. They're just gonna say, you go sit in the waiting room,
And you might sit there for three, four, five, six hours.
Is that funny for the patient? No.
But it's in order to make sure that everybody is served in the optimal way.
So the green items, they'll stay on really early backlog, as far upstream as possible. We just triage them and that's it. When do we start treating them? When we have time, when we have capacity. So we pull them in when we have capacity.
So in combination, you need to take all these elements together in combination. This gives us an upstream Kanban system.
So an upstream Kanban system where you have order points. In order to make sure that the team is always presented with the right mix of work. In this case, we have an order point for high-risk items, high-value, high-risk items, and an order point... Oops. Oi, oi, oi.
Sorry. And an order point for low value, low risk items, because we want to allocate capacity to the team in terms of making sure that they're always working on at least one high value, high risk item, but also that they always have available some low value, low risk items to pull from, so that we have a good balance in the value that we're creating.
So we have order points in the upstream. We have triage early on, and the triage is not just a selection, but it's really a routing through the upstream.
Yellow items are routed through a longer process where we have a two-step commit. So that we don't commit immediately, but that we can have a commitment based on a very lightweight process first, before we do the full commitment.
And we are preemptive about them, so they're kind of a little bit pushed into the upstream.
And then we have the green items that completely skip this two-step process that go immediately into analysis. And those we are just pulling in as we need them. We're pulling them in when...
not reaching our order point.
So the order point gives focus to the team.
I've had several teams that actually, when the order point is not fulfilled, they put a big sticker
on the backlog with a skeleton saying starvation.
As a clear signal to the upstream to say we need to have work. We need to have work. We need to have the right type of work.
So it's a clear signal to collaborate in order to make sure that we have the right type of work at the right moment.
So now we're shaping the demand. Now we're shaping the demand. We're not just taking orders. If needed, downstream people that are to the right side of the board come help upstream if there's a danger of starvation. So we really have a focus point to shape the demand and not just take the demand as is.
So, in our mountain climbing towards business agility, are we there yet?
Clearly we've made a step forward, from order taking to shaping demand. Might not be there yet entirely.
Despite the order points despite the DDH, the business users still may have this push mindset.
So while in the team we have established work in progress limits, constraints, that creates a pull mindset in the team, we still have a customer that has a push mindset. In the sense of pushing requests in on this side of the board and not pulling work out on that side of the board. So one complaint of the team is the customer is there to request new work, but if we need help, To finish the work, they're not available to help us.
So we still have a push mindset on the customer side.
So how do we cope with this? A very simple mechanism, a customer cam man. So customer cam man is the different business
groups get kind of money, they get Camman tokens, and they need Camman tokens to start a request. So everybody can issue a request, that's not a problem, but if you want a request to be processed, you need a Camman token as a customer.
When do they get their Kanban token back?
when the request is finished.
Okay, when the request is finished. Now this obviously puts the, or involves engaging the customer in the end-to-end process, because if the customer wants to start a new request, a previous request needs to be finished.
This doesn't mean that the customer can only have one request, they can have multiple requests depending on the number of CAMMAN tokens that the customer has. So now we're promoting collaboration not only in the team, we're facilitating collaboration between the team and the customer.
So are we there yet?
So we're moving from order taking to shaping the demand to collaborating with the customer.
Are we there yet?
Well, maybe not entirely.
And I'm going to skip very quickly through this, because somebody in the background is saying. So I'm going to quickly skip through this. Obviously, we still need to cope with uncertainty at a deeper level, uncertainty in terms of viability, feasibility, desirability of what we're building. So here we're talking about not just a feedback loop within the team or a feedback loop within the organization, but we're talking about the feedback loop coming back from real customers, real users into the team and how do you cope with that. So this is all about the learning process around uncertainty. Again, and I'm not going to go in detail, we can talk about CAMMAN systems that support that process. This is the entire area of discovery CAMMAN.
So Discovery Camp, it's really about supporting the learning process, managing experiments, managing observations, managing the strategic decision loop, in the end managing uncertainty.
Firing on all cylinders.
So now we're talking about business agility in terms of really firing on all cylinders. Not having these separate cylinders where in one part of the organization we focus on flow, in another part of the organization we focus on learning, and in the third part of the organization we're focusing on the organization. Now we're talking about really the interaction between those. So with upstream cam man, you can't read it very well in the blue part there, upstream cam man focusing on going from meeting demand to shaping demand.
Customer CamMan on the right hand side, in terms of not just collaboration in the team, but collaboration with your customers.
And then Discovery CamMan in terms of focus on learning.
So CamMan systems that really cover all three aspects of business agility.
There's a free e-book that you can download from the LKU site, which kind of covers the material that I've covered in this presentation. Focuses on the upstream CAMMAN. Really focuses on the upstream CAMMAN, less so on Discovery CAMMAN.
With this, I want to thank you.