Christophe Achouiantz
Transcript
This session is about how to lift your command system from good enough to great. It's basically the last session in this room, which means that I have the pleasure to kind of tie together everything that has been said before. And I think you will recognize some of the stuff I speak about here, some of the themes I speak about here, in stuff that you heard before in different keynotes, like from Jim and Henrik and other sessions.
What I love about this kind of conference is that you get inspired. You kind of catch a lot of different tools and techniques and basically toys, stuff you're really excited about. And the next day, tomorrow, oh yeah, I'm going to implement all this cool stuff. It's going to be great. The team is going to be amazed. The customer is going to be amazed too because it's going to be so great. So you're full of energy and you go back to the team and you want to explain. This is what you're going to do now. And then the team is like, it made so much sense at the conference. And you get there and explain it to them. And then they kind of don't get it. They try to push it anyway. Don't you see it's the greatest thing? And they don't get it because they're kind of missing some links here.
Basically, they're telling you, you know what, why do we always try to do new stuff? Why do we always try to improve? Isn't it good enough now?
Isn't it good enough? And what they're missing, I guess, is how does that, whatever you're coming with, making sense in the context? What I mean is that how is that going to make the customer, does that make us awesome to the customer? How does that improve our service? How does that make our Kanban better or Scrum or whatever better at delivering this service? So you're missing this thread thread. It's not clear at least. And that makes it very hard for you to try to convince the team to do something better.
So in this session I'm going to share some very simple tools. Actually the tools I like best are the ones that are so simple because they trigger a discussion. Going to discuss, engage team members, engage the customer, engage the stakeholders in actually doing things in a better way. So it's very simple tools and you'll see they're actually based on storytelling. There was some other session today about storytelling. So here's just a very simple template to actually be able to do that.
So we'll see that doing that will actually go on the quest.
My name is Christophe Assurance. I'm French and speaking in English. It's kind of strange. The only reason why is that I've been living in Sweden 18 years and I never spoke a little canva in French. So I'm afraid it will sound like Van Damme or you know, it will be too difficult and too long. So English is probably better.
I've been working with Canban basically eight years, practicing it eight years in different companies as a consultant first and then
lately at Sandvik IT and Sandvik is a big major engineering company in Sweden.
And there I actually had the opportunity to help a lot of teams. So I helped, I don't know, 70 plus different teams to start using Kanban and maintain Kanban, sustaining it to improve themselves to actually deliver better services. And doing that actually wrote this field guide, how to install Kanban in the team.
It's a very simple technique, it's a static method to do that. And I guess it's quite... I think it's 4,000 downloads so far, and I have no feedback. But every time I go to conferences, oh my God, I'm using your stuff, this is great.
And actually I got an award for that this year. I'm very honored to have got the Brickle Care Award this year for all the things with this field guide.
And what I'm going to talk about is kind of a continuation of this. You know, installing CAN bands, extending it, and then you get into this good enough story here. What is that?
So is your camera sticking good enough? I'm going to explain very shortly in a moment what I mean with good enough. But why does that, I mean, isn't it good enough, good enough?
Why bother with this good enough stuff? The thing with good enough is that it's okay for a while. But very quickly, especially in our context where everything goes much and much faster all the time, everything just goes past value.
Other people doing similar things.
Not only if you're on, of course, a company creating products, but also if you're, you know, internal IT. Internal IT, you can be outsourced if you're just good enough. So good enough is you don't want to be there. You want to go beyond good enough.
Why do I care? I care because I think the saddest type of waste that I can see is the potential that is unused. You have a lot of potential for greatness in all these teams, and then they don't use that because, you know, it's difficult.
So what I mean is good enough. This is what I've seen in the 70 plus teams I've been coaching. So you give the gift of Kanban to a team. By the way, when I say a team, It can be a service team, cross-functional team, it could be a project, it could be an application management team, it could be whatever, people getting together to provide a service, right? That's a study team. So we give the gift of Kanban to a team and they improve, all of them, very quickly. Because they start to work together, they start to understand the work, they start to understand what makes sense, what can be prioritized over other things.
They start to get focused and getting this focus they tend to get less stress. Basically you get into this sustainability agenda in Canada. It makes sense to them. It's helping each individual team member to actually get better. So it makes sense. They're improving their capability rather quickly. But then three things happen when you get to a certain level. Some teams just collapse. About 10% of the team have started to collapse. Basically, it's teams that have conflicts, teams that are not teams. Actually, I should have never started them. So now I have a stronger filter to filter out these teams. But you know, it happens.
Then the majority of the teams get stuck in this good enough path. It's about 70%. Good enough passes that You know, it helped them. They don't see a motivation of improving even more, even further. You know, I have more focus, I have less stress, therefore it's good enough for me.
And then some teams, and this is really interesting of course, are actually improving all the time.
It's about 20% of the team I've seen doing that.
And it's interesting, why do they do that?
It turns out that they often have a manager or a leader that is really engaged with the team. I think it's Jim Benson that was speaking about that, to create a culture of continuous curiosity. That's what is happening here. These managers are really curious. They are really asking questions. Why is that? Why can't we do this? And why do we see this here? And isn't that some waste? Or is that blocking something? And actually challenging the team to improve this way. So this curiosity they actually have and asking around is creating attention. Attention for change. Attention for improvement. So you have this constant motion in these teams. The Kanban board is dynamic. It's not static. It's not like in good enough where it cannot get... Style and british, it's changing all the time, right? They are actually changing policies, the recalons can come and go and such.
So I want you to get there. I want you to be on the road here, in motion. Motion, again, can relate to all the talks that we had yesterday, for instance, is the best anti-fragile medicine. If you're moving, you're always adapting to your environment. That's when you succeed. That's when you become great. You should be there, you should be in motion, you should be the 20% that actually are improving all the time.
So, why is that 70% are getting stuck? Actually, it has to do with energy.
If we follow this energy, analogy for a moment. This is how I see it. This is a monolith called Kanban Quantum's mechanic. There are basically three levels of energy in Kanban, how we see it. The first one again, it is sustainability agenda. For the team, I understand what's needed for me. Using Kanban makes it better. The next level, it requires of course much more energy to get there, is the value delivery agenda, where you actually have focus on the customer. You try to solve hard problems, answer hard questions. When is that? How much of it, etc.
And actually the next level of course is the last agenda for Kanban, is the survivability agenda, more like a long term. More like, yeah, how do we adapt so that we actually are in business even in three, four year time. So the thing is that the teams that are good enough are stuck in this sustainability agenda level and they require more energy to get up there. And one way to get it, as we've seen it, is to have these managers giving energy. They are giving their own energy.
So a solution here would be to only have great leaders. You know, put Steve Jobs in every team, then you will get a fantastic experience for the customer. Well, I know this may not be feasible for everyone, and certainly it will require, it's actually dependent on heroic. And heroic is not, is actually very fragile, it's not anti-fragile. So we want to do another thing.
The other way to do it, of course, is to fix the system. Here, everything I've shown you is in the enterprise context. Enterprise context is big companies, it's like 3,000 employees or more, and of course it's slow, it has a hierarchy, things are done in a certain way. And in this specific context, you have a lot that is impeding that energy. So this is the kind of drain, the energy drain you have in the enterprise.
This is coming actually from a blog post from David Anderson in the 1st of November, rather recently. This is his take on what's impeaching the team to be great in the enterprise. It has to do with creating this pool. So you have, for instance, not facing customers directly. Just taking orders, etc. I can actually add more to this list. Perhaps missing focus, try to do too many things at the same time. Missing some kind of service structure, service thinking in the company so that you don't have people engaged at the service level. etc. Etc. Etc.
So this talk is not about fixing all of this, because this is a long list and it's probably another talk. But there is one thing we can do that is complementary to fixing this issue here, that is actually required for us to fix that.
To get this energy here for change. What I would like to do is to create an emotional attractor.
What's happening here is that you want to create, you want to change fuel. Instead of having this normal fuel that is based on analytics, on system thinking, on scientific method, etc., that very mathematical fuel, To get to this high energy level, you need another type of fuel, which is emotional fuel. You need to create a bigger picture, a goal. You need to create an horizon that is exciting. You need to create depths that actually are needed to lift the team from the day-to-day work to actually look at something else. So the team is not just hacking, the team is actually solving a bigger problem. It's normal fuel that is based on analytics, on system thinking, on scientific method, etc. That very mathematical fuel. To get to this high energy level, you need another type of fuel, which is emotional fuel. You need to create a bigger picture, a goal. You need to create an horizon that is exciting. You need to create depths that actually are needed to lift the team from the day-to-day work to actually look at something else. So the team is not just hacking, the team is actually solving a bigger problem.
So how do you do that? Well, dialogue, engaging with the customer, getting them in a room, customer stakeholders. Okay, just this could be hard to do, but you get them in a room and you start to discuss, why are we doing this? What's the point? What's the service we're providing here? How do you see that, dear customer? When do we succeed doing this service? And when we know that, then we can design our common system to actually answer to that. We can have our common systems fit to the service. And then of course we can engage the team in creating this system.
So what I'm after here is in the discussion, creating stories to engage everyone here.
Basically building story, building a world, world building. And a parallel is for me, it is a domain that is really good at doing that, and that's tabletop RPG.
Anyone played tabletop RPG? It's jeu de rôle. Yes, couple of hands, great. Then you're equipped to do that. You know, creating this kind of universe together, sharing stories, this is what we want to do. This is why we want to lift our service.
So there's a lot here to actually get inspired from, from the staples of RPG. I will just take you through a couple of things I found here.
So actually, let's skip for a while the left side brain, you know, very analytic. And let's try to use the right brain, which is more creative. Let's go on a quest together.
You are heroes, right? And you want to go on a quest to truly understand what the customer wants, and you want to solve that for them.
So what this is about, it's not about a boring ERP system, it's about going on a quest, what does the customer need for succeeding with this ERP system?
So if you're going to quest, you need to make it clear what is it we want. So of course you need a map, right?
And you are here somewhere. And the world is full of dangers.
Customers that are lost, customers that are upset, or technical deaths, whatever. And of course you try to get somewhere else. That's your goal. So we need to define this goal, the goal of a quest.
And somehow, of course, you have done a journey already. You come from somewhere else. That's interesting to know where you come from. We come back to that in a moment.
And then of course you have this journey. You will actually go through a lot of dangers and perils. to get to your goal.
So using this table of RPG models, so to say, I got inspired by these character sheets. You have these sheets of defining the characters or the villains and such. And let's create a sheet for our service.
This is an example. This is how it could look like. This is the service sheet.
But for those that are familiar with this, it is very much inspired from the FATE RPG system. Anyway, the point with this thing is to engage in a conversation with the customer to find out when do we succeed in delivering service. We're going to go through the sheet in a short moment. To define fitness of purpose, when are we fit to purpose with the service. Because when you have this very clear, this fitness of purpose for the service, then you can understand how does the common system we have, what qualities of the common system we have must have to sustain that service, to succeed with that.
All right, so what do we have here? Service name, of course, then a high concept. High concept is a short summary of what this thing is about. Is it an e-commerce solution? Is it an ERP system?
When you ask the customer, it tends to be very fluffy. And here is just condensate. What are we speaking about? Very simple.
Then you have the purpose. Who needs the service to do what? Who are the customers? Who pays for that? What's the value delivery?
You probably have some trouble. You already know from the beginning that, you know what, we probably get into trouble because here we have some risk, you know, from the beginning that needs to be mitigated.
As you can see here, I'm just recording this. But what's happening is that when you are discussing this with the customer, you actually, in a workshop, I'm going to go through that in a short moment, you actually can get that very clearly.
The last part, is the fitness criteria. When do we succeed with the service? So you have up to four. Four is kind of too much already, but according to the customer, what aspects make the service fit the purpose? It could be an aspect of quality, of performance, of cost, whatever. Stuff that matters for the customer.
And of course, once you define that, you should define also how to measure that. So, concretely measure or quantify using fact and data how well the fitness criteria is fulfilled.
Finally, you have this current capability here, and it's a quick way to actually understand how much,
how acceptable is this, the current state of that witnessing criteria.
This helps to discuss the pain threshold with the customers and discover what aspect of service must be improved first.
So again, here we're just recording all this information. We're recording it after we've done a workshop with the customers. And we're using it to later to actually refer to that all the time. It's basically becoming a dashboard where you can follow the service.
So it's a dialogue, it creates focus. Focus that these are the things, the aspect that matters for this service. Forget about all the other things. Right now are the three things that we've defined that are really the most important ones. So start there.
Create alignment of course because when you do that with the customer, the stakeholders, the team, everyone understands that and everyone can follow that all the time.
And finally, call that acceleration. You know what to address to accelerate your Kanban implementation, I would say, to make your Kanban better than good enough. That really matches the needs of the service and the customer.
There is one thing, so the whole thing again, this is actually a whole workshop. You can find more information on my site. There is one thing that's really helping and defining this criteria and this metrics. Something called objective and key result. Anyone heard about that, objective and key result? Yeah, quite many.
I won't go into that too, but you will find that really helpful during the workshops when doing that.
So just an example to give you some idea. This is based on the real stuff.
So we have this whatever business platform. It's a development of an e-commerce platform. And the purpose is to develop new features in order to make information on products for brands A, B, C, and D. Available worldwide and provide shopping service for this product, typical e-commerce platform. The trouble of course is we have four different brands that share the same platform. Understand that there will be some conflicts of interest here, what features will come first, etc. Fitness criteria, for instance, three of them. Platform is stable.
And we measure that by monitoring the availability of shopping service. And the brands really think it's unacceptable at this point. Second, we have a constant flow of cool and new features not seen on competitors'platforms. Of course, you need to be first, to be on the edge. That's really important for our customer here, to have this constant flow of new features. You measure that by the number of cool features that are actually getting out per release. And it kind of sucks at this point. The last one is high delivery precision for new features. The stuff that have deadline Common time, right?
So how do you create that? Okay, yes, sorry. So once you have this, that's defining the service, then you can understand what aspect, what
practices of Kanban you need to implement first to actually answer that. For instance, platform is stable, probably you need to have better policies, a tougher definition of DOM, for instance, during validation.
Constant flow of cool and new features, perhaps we need to have a new cool feature work type with capacity allocation, let's say at least 20% we need to be allocated these new and cool features.
High delivery precision for new features, probably need to introduce some class of service related to that. So all of these requirements, so to say, from the customer help you to design your cam board to actually support that. So you know where to start, you know what matters. So if you go back from the conference, oh, I know how to do capacity allocation, this is great. Well, here you have a technique that helps really improve the service. Makes sense. You can actually sell that to the team in a better way.
How do you do that? Again, this is a workshop usually, for me it's a full day workshop, it can be two days sometimes, if it's a lot of different stakeholders.
I won't go into detail how I do that, but it's basically what I see happening is that when you have everyone in the room, And you bring this shit, shit, sorry.
It's kind of the same. And then you start to engage in discussion, okay, what's the purpose of that? And how do we know we succeed? You have excellent discussions, focused discussion.
So somehow you do that. And then you use it, of course, I would say you use it monthly. That's your dashboard. That's something you bring to the service delivery reviews. So how are we going with your fitness criteria? Well, now it's not sucked anymore. It's kind of good enough in this aspect. So we can take the next one, et cetera, et cetera.
Actually, once you fulfill that, there's three, let's say there are three here. Well, of course, there are three more. So do a new workshop and find new fitness criteria for the service now. So that's the engine here. Never get stuck into good enough. Once you succeed in fulfilling that, the wishes, so to say, of the customer, then of course you do that one more time.
Okay, so now we have our quest. We know our goal. This is where we want to go. We have this fitness criteria to fulfill, and somehow we know how to answer to that using Kanda. But there's one thing that I first ignored it, but I find it very interesting now, is this, your origin story.
Why? You know, origin story is probably the best part of every superhero movie. Then once the origin story is done, then you can quit because it's just something boring. But basically, once you started with Kanban, you probably sold it to your manager as some sort of solution. You know, this is a great tool to help us to do something. And then you made some promises. You made your promises to management that this will help you with certain things, which may be different from the promises you do to the customer, which are reflected in the... the quest that we just spoke about in this fitness criteria.
So here's a tool that I've been using to find out why you started with Kanban and what you've promised to your management. It's basically, this is a template from Jason Little from Lean Change. It's telling a story. This is really storytelling. The story of your Kanban implementation, why you started.
So it's this five different cases in the past.
And then we liked it because
But then one day something happened. And that caused trouble.
Therefore you want change.
So how does that work? In the past, what was the way things were around here before? Before you had a calendar, right? You were doing things like that. And somehow that was okay. There's some aspects of it that were okay. You know, we liked it because, whatever, it affected the way of working and culture, morale, and customer satisfaction. And that caused trouble. Therefore you want change.
So how does that work? In the past, what was the way things were around here before? Before you had a calendar, right? You were doing things like that. And somehow that was okay. There's some aspects of it that were okay. You know, we liked it because, whatever, it affected the way of working on culture, morale, and customer satisfaction.
But then one day something happened. It could be something dramatically happening at once, or gradually something that just sneaked in. But you realize that something happens that changed the way things worked. It was probably becoming worse now. And that causes an impact, an impact on the team, the customer, whatever. So it's really wrong. So we want this change.
So let me give you this example to go back to this e-commerce solution I had showed you before. This is how it looks for them. This is their story. They met together, the team meets together, and design this thing together. So in the past, we were a small development team using Scrum to deliver a ShopPoint solution to one brand.
And then we liked it because we were very close to the brands and we could deliver value each print. The brand trusted us and we trusted them. Ooh, yeah, perfect. Perfect world. But then one day, wow, the company decided to use the platform for all brands. And the brands were on pressure to go all digital, of course. As a result, four brands started to share the same platform. The development team more than doubled in size, and the brands wanted more features faster. Hmm, that sounds like a movie. I know it's action happening here. And that goes well. Slow throughputs of new features, lower quality, high technical depth. As a result, the brand are thinking to move development and operation somewhere else. And more of a story point system is being used to demonstrate that we are not cost efficient.
You probably, I don't know if you recognize that, but it's kind of a very common story, I would say. So what do we want to do now? Well, now we want to introduce Kanban to the system to simplify the development process and increase trust towards brand.
That is how they sold Kanban to management. They want to use Kanban because we're in this situation. And we think this will help us. So basically the promise here is these two things. Simple development process, trust by more transparency.
And then you must act on that. If you ignore this and focus only on the customer, you lose trust. And trust, you need plenty of trust to be able to do what you need to do eventually. To trust political capital, whatever, to remove obstacles, to convince others to come with you, whatever. You need this trust. You need to actually fulfill that before going further.
So again, this is a tool for dialogue, dialogue for change, to make sure that everyone is aligned on this story. And the storytelling makes it a very simple story. It's perhaps very complex, it was fussy, there was a lot of things happening at the same time, but then we sit down together and tell our story, and everyone can buy that, and everyone can actually tell that. This is why we're using Canva.
And again, this is very good for building trust.
Okay, so we know our goal, we know we have this fitness criteria to fulfill, we know how we're going to do that, we have this
origin story, we know what we promised to our different stakeholders, and some are we already here, right? Now it's just for us to get there, to do this journey. And the journey, this is really, it's really, it's not straight.
Things are going to happen and you need to be creative here in how you're going to navigate this land here.
Here you need to have a plan, because now you have a lot of options again. From your quest, you have the option of things to do, from your origin story, yes, different options of things to do. You cannot do everything at the same time.
You cannot simply walk into Mordor. You need to actually do some prioritization here, some good planning.
Of course, one step at a time. This is how you get there. So you need to focus on solving one challenge. Now you have a lot of options, you need to select one, take this one, do it, and then take the next one, right? If you do too many changes at the same time, what will happen is that you don't know if you succeed or even if you fail, what actually made it so.
To be able to do that, I would recommend you to use the improvement quarter. Anyone knowing the, seen the improvement quarter? Yeah, a couple of guys.
This is Mike Rother. It's actually explaining a very, concrete way to go forward attacking a challenge. So the challenge is basically the stuff that you found out in your fitness criteria or a challenge could be one of the promises you made. And of course at the beginning you don't know how to do that. You know, you need to, you know, cost should go down 20% and quality should not be impacted. How do we do that? No idea. Of course you don't have an idea but That's okay. You should take several steps to actually get there. Next target condition.
So you basically discover as you go what's the next right step to do. So it's okay. It's really a quest. You don't know which path you're going to take. You're going to discover that as you go.
So this model is really about experimentation. You try the next step. It doesn't work. It's okay. You can get back.
So I won't go into detail into the improvement card, but it's basically something that's helping you to navigate into this uncertainty, this strange land.
So this is how it could look like. This is your plan. This is how you plan your journey. You have basically two sets of options here. The first one is the promises to fulfill. The second one is one of the goals for your service, the fitness criteria. And using the improvement chart from Microsoft, it basically looks like this. You have the challenge. Development process is transparent.
Then you should of course define when are we done. We're done with that when all demand managers from all brands can access our digital Kanban tool and participate in our daily.
Based on that, you have a next step, a next experiment, next target conditions. All demand managers from all brands participate in all daily. Well, good enough.
So you're trying to try this thing. Try holding a meeting at 12.45. Somehow it works better because in the morning no one is coming. That's a good experiment. That works.
The other one, Gulf Road Service, for instance, the platform is stable, that's our challenge. When are we done? Well, we agree on this KPI, and it should be in balance, we should reach there.
Next target condition, the release do not deter its stability.
That's a good one. How are we going to do that? An experiment here. New policy, run performance tests on lightly built every night.
This may take some time, but that's okay. That's the next step. We really want to reach that.
So yeah, you know, once you've done that, you've made it. You're there, you succeed, you're out of good enough. You are constantly improving, trying to fulfill the right stuff, the right fitness criteria, trying to fulfill the promises that you've made. Actually getting into the right direction. Great alignment and unity of purpose for the whole team.
You clarify the promises you've made, and then you select one challenge and pursue that.
You know, just do it. This is actually very, very, very simple stuff. It's just to create dialogue and discussion.
Basically put everyone in the same room and practice all that together. Create alignment based on that.
And that's it for today. You have a lot of materials on the website. You want to download templates and such, it's all there. And again, this is actually a workshop form, so there's more there to do and to discover for you.