Romain Couturier
Transcript (Translated)
Hello everyone, my name is Romain Couturier, I am an Agile coach. My main job in life is to help teams implement Agility, mainly in the form of Scrum, and also to work on deploying Kanban.
I had the pleasure of contributing to the latest edition of Laurent Morisseau's book with a chapter on Kanban for Product Owners. And I was born in Lyon. I also live in Lyon, and I am an ambassador for Lyon. So that means every time I go outside of Lyon, I promote my city to invite you to spend a weekend, a week in Lyon, to enjoy the Lyonnais charm. The famous Fourvière Basilica, at the foot of which you will find Vieux-Lyon. Vieux-Lyon, famous for its narrow streets, its charming atmosphere, its gastronomy, the famous Lyonnais gastronomy, since Lyon is the national capital of gastronomy. And try the old 'bouchons,' the quenelles, the 'cervelles de canut,' the 'tabliers de sapeur.'
And you may also have the opportunity to try the other Lyonnais 'bouchons.'
That you may have already... already tasted before, if you have been to the south of France. Below the Fourvière Basilica is the Fourvière tunnel. It is a 'bouchon' (traffic jam) quite characteristic in its presentation. It flows fairly well at night, fairly well during the day. And then there are peak loads. Generally, it's between 6:30 and 8:30 in the morning. In the evening, it starts at 4:30 until 8. A typical property of a 'bouchon,' the Fourvière tunnel is a two-lane road. And obviously, we have... At least 4, 5, 6, 7 lanes well upstream that pour in a lot of trucks, cars, where at some point, exasperated by the property of the 'bouchon,' which generates waiting phenomena, one can observe in this 'bouchon'... A lot of behaviors, you know, the conquerors, those who will play the local strategy, who will switch left, switch right, who will try to squeeze in via the acceleration lane, who will go all the way and then slow down, there are the hurried ones, there are the motorcycles, which will generate what? Well, even more heat and thus accentuate the traffic jam phenomenon.
Absolutely delightful.
So to manage this is a problem in Lyon, but it's also a problem in many cities. At least in Lyon, they have implemented something that didn't necessarily get good press, which is that they reduced the speed limit. The ring road was initially at 110, now it's at 90 km/h. If you ask almost all Lyonnais and people from Saint-Étienne who come to Lyon regularly, if you ask them what they think about the speed reduction, everyone will tell you it's a big mistake.
Nevertheless, we must still note that since they implemented this, we have never had as few pollution peaks as since the speed was reduced.
So it's an interesting impact. So why am I talking about all this in the introduction? Because these mechanisms, these principles, in my daily activities of coaching and implementing Kanban, these real, physical phenomena, of local strategy, of traffic jams, of generating heat, of waiting phenomena, we also find them in a number of environments. I work a lot with IT, but not only. And that's what I'm going to present during this session. A set of feedback and experiences on deploying Kanban in different environments. To understand a little what Kanban has allowed to emerge and to learn.
So, the first step in using Kanban. I started Kanban...
I was very proud, it was already two years ago. It was at Christmas, I remember, because I had bought...
I had bought Christmas ribbon to make my super flow board. You know, the shiny stuff for gift wrapping. And I did a lot of research. I come from the Scrum world, so you know, boards, it's good, post-its, we master that. But I wanted something a little more exotic. And I don't remember the reference, but I came across a form of board that I found very interesting, which was the circular Kanban. At the time, I was a product owner. And so, you see below, that's my product owner board, the business manager. Inside this board, we find features. And I found it super fun to have... It's okay, it is...
Yes, you too, yes, okay.
It was fun, it lasted 15 days, and then like when you start sports, it didn't last longer, so we abandoned it. There is a reason I quickly analyzed when I started to get a little more serious, which was to revisit the question of why this abandonment of Kanban, and I asked myself the fundamental questions, namely what is Kanban?
I revisited the principles that go with it. It's like when you read the Agile Manifesto, you read it in five minutes, but the idea is also to understand what's inside. Kanban comes with its principles, start where you are. Great. The entry ticket is not very complicated. Commit to changing in an incremental and evolutionary way, okay, we are in continuous improvement. Initially respecting current processes, roles, and responsibilities, that's cool, it will allow me to work in environments where I cannot impose changes in roles and organization.
And with acts of leadership at all levels. Okay, we'll see what that gives.
To help us, Kanban also comes with its six practices. Visualize the flow, the whole dimension of visual management. Limit work in progress. We will see that it is not necessarily as simple as it seems.
There have been quite interesting discoveries. Manage and measure the workflow, which raises the question of how we maintain our flow, how we measure it, how we use these indicators. Make management rules explicit.
Not bad, okay. Implement feedback loops, okay, I understand that. Improve collaboratively, great. I come from the Agile world, the individual is at the heart. Let's go! And we start. We start, first experience with a real client. Here, we are in a web agency. And the first thing, when I helped them set up this Kanban, was to revisit a little how they manage. A web agency, for many, works on a person allocation basis, work assigned to individuals. Generally, this allocation should approximate 100%. Obviously, this raises a lot of questions, it's complicated to manage, how to handle all these constraints. I just suggested one thing to them, to change from managing people to managing projects. That is, instead of having rows for people, we will have projects and within these projects, features. This made it possible to highlight, quite simply, the fact that there are projects that are saturated with features, projects that are in functional drought, there are hardly any features to do, and thus the difficulty for people who do not necessarily have the same skills to switch from one project to another.
Still on the theme of how we work as a team, here we are in a service company, the project has been finished for two years, which means they have been doing application maintenance (TMA) for two years, and the project is quite large and the team is quite small, a classic case. And so we find ourselves with a process for managing anomalies, managing evolutions, managing a whole bunch of things. The problem they have in this team, and when we worked on implementing Kanban, the first problem that emerged is
we are not able to work on each other's topics. So, it's true that behind that, seeking continuous improvement, maintaining indicators, practices that are very interesting that you may have seen through this conference, it was complicated because, from the start, the team is just a collection of individuals who do not know how to work together, simply because they do not share the same skills. And so, what does it mean to work as a team when you are on a topic where people do not share the same level of information?
And there, Kanban did not serve to manage the flow, it served to, for now, work on what it means to work as a team, what team spirit means, and then we will resume work on the flow. Today, that is clearly not the priority. In this presentation, I’m showing you overall that we all ramped up in the space of between half a day and two days.
Still within a web agency. I come from the world of agility. In agility, to structure the need, we use the famous user stories, user stories, features for those who are not familiar with the format.
And when I arrived at this web agency,
The entire project was already there—it’s a mobile application that had been mapped out, with lots of screens, lots of things. And the first thing I said to them, with my agile coach benevolence, was, you know what, we’re going to work on user stories. You’ll see, it’s going to be great. Oh, are you sure? Yeah, yeah, yeah, you see, look. It took us days and days and days and days. Well, not me, because I only spent two hours telling her how it should be done. And then afterward, it was her who did the job. Obviously, what did she do? She wrote the user story format, she worked on the definition of done. And then she asked me the question, how do I ensure traceability between what you asked me to do and my thing, my screens? Because with my client, I manage screens.
It doesn’t matter, just keep going with the user stories.
You’ll see, it’s really great. No, it’s not really great, actually. Because when we closed the project, it was indeed interesting. It allowed us to ask questions. Apparently, I arrived with my unit of value, we tell them. No, you’ll see. No, her unit of value was already existing, in fact. It was already displayed on the wall, and it was the screen. If I were to redo this coaching mission, I would do it by establishing a community of value around screens. Because that’s what they worked with in this environment. And that’s what they communicated with.
The common point between these different experiences, and it took me time to understand this, is to re-question what the unit of value that circulates is, what type of request has the highest volume in an environment, in a system.
And with all the teams I work with, I generally have very little time. I have very little time to set up this work base to structure my coaching activity. So we do 5-minute flow construction workshops. It goes really fast.
Take your type of request, what you handle most often.
And we’ll ask ourselves when these requests die and when they are born. And we’ll examine how we’re going to, what activities allow us to go from this birth to this death of the request. Pretty classic, I imagine most of you have already done this exercise. For many people, it’s completely new, and it raises a lot of questions. What’s even more amazing is when you do this with several team members, and you ask each of them to do this exercise, and then you put it all together,
And we realize that it’s not at all the same workflow. After that, we wonder why people have trouble working together. Yes, because first of all, they don’t share the same vision.
Once we’re able to do that, we can go a little further. And we can implement what we’ve seen, the practices and principles that go with it. Here, we’re in an environment, we’re at a software publisher. They have a history, they have applications that have been around for about ten years, which they maintain, and they develop new products. So we implemented everything, we developed, we deployed the state of the art of Camban practices, visualization, demand visualization.
This is a session we did with the development team. We worked with them on the activities that structure their flow. And then I immediately asked them to set limits. Really practical to set. It’s the question of what your limits are when you don’t know them. It’s an eminently complex question, and since then, I’ve completely stopped asking it until we manage to identify the need for limits. Nevertheless, it doesn’t matter, I did it anyway. We define rules. Now, the rules, that’s perhaps the most enjoyable part where it deserves the most facilitation and organization. To properly distribute the word and know the meaning of the words and what we put behind each rule.
Wonderful, wonderful. A particularity of this flow, though, is that just by working with the development team, they went all the way to the end of their dev activity, and they also included in the flow, in their system, the hosting activity. The hosting activity whose mission is to take what is produced by the software and put it into production. ...posed as long as we don't actually reach the need to identify the limits. Nevertheless, it's not a big deal, I did it anyway. We define rules. Now, the rules—this is perhaps the most enjoyable part where it deserves the most facilitation and organization to properly distribute speech and understand the meaning of the words and what we put behind each rule.
Wonderful, wonderful. A particularity of this flow, however, is that just by working with the development team, they went all the way to the end of their dev activity and also included in the flow, in their system,
They included the hosting activity. The hosting activity, whose mission is to retrieve what is produced by the software and put it into production.
And then, quite quickly, we realized that this buffer zone, this queue between dev and hosting, was causing problems and overstocking over time.
So, I inevitably ask them the question: what's happening? The operators don't know how to deploy, blah blah blah. Let's go see the operators. Ah, but the devs don't know about operations. Blah blah blah.
OK.
These were crises that appeared roughly once every 3-4 months. And since we're setting up camp, I suggested they work on this form of continuous improvement. We introduced the practice of daily meetings and invited the hosting service. So what used to happen, let's say, every 3-4 months, Where before they would argue from time to time, now they argued a little bit every day.
Fortunately, they are intelligent people, so it didn't last very long. And the principle is simple. It's always the same thing. It's a communication problem. It's just that there are unspoken things. And the solutions were quite quick. After that, they were able to work on much heavier problems. And here, I direct you to, for example, the conference on continuous delivery, which is the real subject they are working on today. And as long as they haven't addressed this issue, they will have difficulty smoothing their flow.
So, once we set up an environment that allows working with dev and hosting, naturally the salesperson enters the workspace daily, proud of having made a sale, arrives with requests and naturally has to report to their client by telling them when it will be ready. And that's where it becomes great, because we managed to set up these indicators, particularly the cumulative flow diagram, we were able to estimate the time a request spends in the flow, and proudly the team answered, listen, when you come into the room,
you have a 90% chance that we will deliver in 100 days.
One was smiling, and the other wasn't.
And here, we clearly see that Cambon was a bit limiting, too localized in the technical environment. And obviously, this raised a number of questions, because this delay is not acceptable—three and a half months is just crazy.
How do we reduce this delay? And here, it allows us to question the system. And here, we are no longer looking at the system as a flow, but as an organization. And so, we have to recreate bridges with populations where the bridges are more or less defined.
I also work on slightly lighter environments.
For example, one person. You know, sometimes there are teams of one.
I don't know if there are any among you. A team of one is a person who is in a department. There could be 20, there could be 30. The flow works the same way, but they are one. The person is alone. And somewhere, they have a bit of their own bottleneck.
So, I worked with a graphic designer, still in a web agency. When I asked him about his unit of value, he said, 'I don’t work with civil servants, I work with ergonomics tasks.' Ok, no problem, I got the lesson, I made the mistake once, I won’t do it again, we’ll work with your ergonomics tasks. We have these activities in purple, these transition rules. We went very light at first, not overloading the flow at all, just to help structure it. This is a person who has trouble organizing their time. It's normal since they work on many projects, many clients, many ergonomics tasks. And very quickly, we were able to find the bottleneck. So, to help teams find their own bottleneck when I'm not there, it's quite simple. Most bottlenecks, you'll see, there's a pile and right after, there's not much.
Because explaining the theory of constraints, the theory of... They don’t have time for that, they have a real job in life. So, it still has to move forward. Ok, oh, that's funny, your bottleneck is on client validation. What's happening with your clients? Well, you see, nothing is happening.
What could we do so that something happens? They need to validate. Yes, ok. How could you do that? I would need to call them. When can you call them? Can you call them now? Yes. Ok, shall we go? Yes, well, ok, let's go.
Having the courage to pick up the phone wasn't in this person's nature. It's complicated.
And it wasn't necessarily something they wanted to do. Here, the fact that the system tells them 'it is necessary that you do it' gives them a stimulus to do it.
So it allows them to trigger, to step out of their comfort zone when absolutely necessary, always in a secure framework. The idea is also not to harass the client afterward.
Now, the graphic designer isn't alone; he also works with a designer. The designer has another particularity.
The designer's particularity is that they have extremely strong interactions with the developers. In fact, they interact a bit with everyone. Besides, no one really understands the designer's job.
Their designer is always late. They never do things in the right order. When asked to follow an iterative rhythm like Scrum, they never manage to keep their commitments. For demos, it never works.
In fact, when working with them, we realize they are always alone, that they work on design tasks. And that, in fact, they receive a number of requests from many environments. And these constraints, no one has ever seen them. Because we think that...
When Bans helped designers communicate better, since they were in a somewhat conflictual relationship, the idea was to say, 'Ok, but here are the constraints I have.' And so, reinstalling a dialogue with the development team didn't solve the problem, it just helped create a connection. And yesterday, what was said is that when we want to create social bonds, that's really what happens.
So, I also worked with other teams, with the developers. And then I came back a little later. And where are your Kanban boards now? Listen Romain, too much Kanban, we're killing Kanban, we removed the Kanban.
So, what happened? Well, actually, we removed them because we realized we could connect things, and it was a bit of a shame to have one Kanban for the graphic designer, one Kanban for the designer, and then for the devs, when in fact, it all forms a production chain.
So they created... What we don't see is that it's a square wall. So there are 10 meters of flow like this.
You have to walk around to see it.
And in fact, when they implemented it, it also allowed them to ask the question, what is upstream of this? How do all these features flow into a production chain?
They flow in with... Ultimately, it's all projects. These are projects that are divided into units.
And in a web agency with quite a few environments, I meet people who are project managers or responsible for themselves, who have multiple projects, multiple clients. But who also have to work with other managers who also have multiple projects and multiple clients. And the common point among all these people is that they only have one team.
So there is a bottleneck natively on the team.
So we worked on that.
And so, naturally, a portfolio management Kanban emerged. Portfolios don't have projects because the project doesn't exist; rather, they have versions that last from 1 to 3 months. Each Post-it represents a person.
And what's very funny is that we did this workshop for a day, and I present to you the graphic designer we worked with. And you can probably tell from his skeptical look that something is happening on this board. Something that is alarming him. And he's right, because what's happening is that the projects are estimated, A zoning work, ergonomics, design creation, internal testing development, external testing. And what he sees is that just as he has finally managed to stabilize his workflow, he thinks, 'Okay, I can breathe now.' 'Yeah, you can breathe now.' What you're seeing is that you have a tsunami about to hit you.
But today, it's okay.
It's in three months that it won't be okay.
Because you are the bottleneck.
You have the broader bottleneck. So you will take on an even greater workload than you have today. So no matter how much you optimize your graphic design work locally, it won't change that at the systemic level,
you're going to face a deluge, an avalanche of projects. So, a simple question afterward was to say, listen, project managers, this can't go on, so we need to prioritize. Everyone pulling the blanket to their side. At some point, we had to bring in the key master, the manager, ultimately.
The manager who wasn't aware that his system, which was working fine today, was clogging up and heading toward serious difficulties. And in fact, when we asked the manager, when we told him there was more than two years' worth of work,
he simply replied that there were projects that couldn't start, which were on the wish list. Projects that could start later. There are clients we can call.
Ultimately, just by asking the question, we were able to reduce the volume of the tsunami. It doesn't solve the bottleneck problem, but it allows us to limit the inflow.
And this work on portfolio management, when we try to replicate it, for example with the CIO of a clinic group, who has portfolios of applications, bed management, patient management, protocol management in operating rooms, and also has quite few staff. And he struggles to manage all of this. Moreover, when the national strategy, when the national board asks him what the IT roadmap is for the year, the next two years, and the next three years, he has difficulty answering. A day of work on visualization, on reflecting about what a project is? What is a project, ultimately? How does it flow? Who does it involve? This allowed him not to create a team, because he wanted to keep control over his portfolio, but to better manage the actions. And so, for example, not to launch projects. What is already a revolution in itself in this organization is to stop starting and start by finishing. Something we repeat quite often, and which, when implemented, is a bit unnatural and always quite surprising in its effects.
And today, he has switched to an online tool, and it has allowed him to trigger interesting work meetings with his project managers. Because at least he can say, there is this person with this constraint, that person, and so on. Now, how do we reorganize our strategy?
Let's return to the functional domain. Because I work a lot with product managers. They are the ones who are struggling the most today in projects. They have a flow of features to process. And then I arrived at this administration, and when I got to their workspace, I found this. And I told them, 'This is great, you're doing a combo!'
They asked me, 'So what?'
Do Kanban, do flow, how does pull flow work?
Stop your jargon right now, we're managing a project here.
And we need to organize ourselves, so we need to see what happens before release, the specs, the modeling, the study, the stock. Okay, no problem. We won't introduce a somewhat barbaric terminology. Nevertheless, we will use this base to implement everything we've seen. Visualization, transition rules. And so really work to know what the best priorities are, how we can anticipate the deadline, and so on. And like little salmon swimming upstream, we started, obviously, because all problems are at the dev level, as is well known, and we went up like that. Because in fact, we realized that the problems observed at the dev level were not because the devs intentionally produced poor quality. In the end, maybe there were things that happened before. So we went up like that. We went up the chain to the top. And in fact, when we get to the top, we're at the entry level. It's that we're in an administration, and those who make requests,
When we tried to see a bit who was feeding the stock, It's a group of people who see each other quite little, actually, quite rarely, who, when they do see each other, don't decide or decide little, and above all have no awareness of what's happening, that is, the impact and the butterfly effect it can have. So we were able to mobilize a governance meeting. And there, we were able to work with the governance, which was quite revolutionary, since putting in the same room people who come once every six months on projects with developers and the entire team range was completely crazy. And we were able to use the tool to explain to them what was happening, to tell them a story. Their story.
And then we thought, with all the goodwill we had, that thanks to this, they would be able to help us define the right rules, to decide together. Well, they decided not to decide.
And at least, it allowed us to establish that as long as this problem wasn't addressed, and in fact, it required a much greater intervention with other constraints, as long as those decisions weren't made, the project would be in difficulty. It allowed us to lighten the responsibility of the project. So we tried to have a global optimization, but it sent us back to a local optimization. Too bad, never mind.
It's not a big deal. So I talk a lot about software. And then we thought, with all the goodwill we had, that thanks to this, they would be able to help us define the right rules, to decide together. So, they decided not to decide.
And at least, this made it possible to establish that as long as this problem was not addressed—and in fact, it required a much greater intervention with other constraints—as long as those decisions were not made, the project would be in difficulty. This helped lighten the responsibility of the project. So we tried to have a global optimization, but it sent us back to a local optimization. Too bad, so be it.
It's not a big deal. I talk to you a lot about software.
But a business manager doesn’t just have software in their life. They have test campaigns to run, documentation to prepare, contractual management to handle, and plenty of other workflows that take time away from their need-expression activity and working with developers.
Similarly, we held workshops and modeled these processes. We found that the elements, the units of value, were deliverables. A deliverable is great; it’s really easy. There are deliverables that come in and need to go out.
And so, daily, their scope was no longer limited to interfacing with the dev team but also to interfacing with each other to know what they had to manage on a daily basis. So here, we’re really talking about a tool like Kanban to organize their EPO activity.
But in real life, we don’t only have agile teams, unfortunately. In fact, sometimes in large groups like this one, we have a project organization split into front office and back office, with two modes of contracting. A back-office team in agile mode. And we see that some features are floating around a bit everywhere. There are a few in integration, a few in development, a few in the specification phase, and some in stock. There you go, it’s smoothed out over time. And a team, let’s say, with its own cycle.
You can call it whatever you want. Some call it ‘on the fly.’
Others call it the V-cycle. No matter, really. The fact is, they had their own unit. It’s contractual. So it’s non-negotiable. Therefore, the service provider is also committed to respecting this contractual method. So, the work with Kanban wasn’t about trying to change the front-office provider’s team organization but rather, let’s say, to stimulate local stress. To clearly see that the features at the front-office level weren’t progressing. And that the surrounding stress was linked to one single thing: that. And so, perhaps to trigger exchanges between internal teams, the IT department, procurement, the contractual manager, to see how, despite this framework, some forms of flexibility could be considered. Because clearly, it’s stressful to see that you have sticky notes that aren’t moving, while at the back-office level, everything’s great—it’s the good life.
I talk to you a lot about software. I also talk a lot about Kanban with my partner. Which means that when I get home, it’s good when it stops at the doorstep. The sticky notes, Scrum, the method.
She’s an editorial manager. And then, one Friday evening, we close the week.
And she tells me, it’s great because we’re finally going to launch the redesign project. So, we’re going to migrate. I have 450 editorial pieces to migrate from site A to site B.
And I don’t know how to organize myself.
Don’t you have something to help me?
Yes, yes, yes. I have something. Tell me what you’re working on. I work on content. In fact, throughout her speech, it was about content management. If I had even asked her what her unit of value was, she wouldn’t have understood the question because it’s not part of her project culture. So, content, okay, you work on content. What’s the last step? The content is published. What happens before that? It was written, reviewed, it was... And so on, and so on, and we went back up the chain like that. And in five minutes, we created her workflow.
And I wanted her to work in a pull flow, the famous Kanban. Yes, except that the prerequisite for having a pull flow is that there must still be a dynamic flow, meaning there must be a minimum flow of movement in the system. In the public sector, that’s not necessarily the case. So I told her, listen, one day I’ll do a feedback session on Kanban, and I’d like you to take photos once a month.
One photo, one month.
Here, you have six months.
Here, it’s Kanban to give energy to the system.
To avoid getting lost, she doesn’t have time to motivate people to move content forward when others haven’t progressed yet. So, when it comes to pull flow, yes, yes, when you have energy. But in the system, there was very little energy. And this actually allowed her to organize, prioritize her stock, and prioritize what she had to do.
Kanban outside of IT is also Kanban for salespeople. Here, I’m still in a web agency, another one. Small structure, they’re about fifteen people. And the agency director, he has... Development, of course, is important, development. By the way, he didn’t include the column—it’s between signed and pre-production. He has a business to run. He sells applications, he sells modules, he sells plugins. And he has ideas. In fact, his unit of work, his unit of value, is the idea.
And when he explains, the first thing he tells me is, ‘I don’t know, my salesperson is bad.’
We reversed the situation. What are you trying to do with your salesperson? And we visualized his workflow.
In fact, his sales management workflow.
And this allowed us to create discussions about introducing service classes because there were many small projects. And in fact, we realized that the salesperson he was working with, who was just starting out, only had large prospects. And so, he didn’t know how to manage those large prospects. So, the problem wasn’t that the salesperson was bad; it was that the person managing the requests wasn’t the right one.
Realization, change.
And in addition, when I started telling him that for each unit of work, we could assign euros and that he could see a graph in euros of his sales flow, his eyes lit up.
I’ll come back to that later.
Kanban is also for creating a project culture. You know there’s a reform of professional training coming at the beginning of 2015. All training organizations are on high alert right now and are migrating their training catalogs. Here, we’re typically in that situation. There are 450 training courses to migrate, following a protocol.
Okay, so this will go through a structured flow.
We’ll have a stock of training courses that need to go through the flow. If we take the image that the flow is a machine, this transformation machine for these trainings does not exist. We need to create the tools, we need to create the protocols, create the charters, create a set of things. In fact, this allowed us to create a project culture, to create project management, because to move forward even just one training, we need to trigger the creation of the associated tool. We clearly see that we have the process and that we need a machine to run this process. So here, we combined the two: flow management and project management.
And I have a soft spot for this feedback because here, it's really a very small team. And they put their heart and energy into working with their clients, into satisfying their requests. As soon as the phone rings, yes, yes, we start, let's go, we handle the requests. And they struggle to manage because it's chaotic, because they work on 10,000 things at the same time. You know, it's like us when every day, at the end of the day, our head feels like a potato. And we tell ourselves, but we didn't do anything, when in fact, we spent our whole day working. The problem is that we didn't stop switching like that, constantly, constantly. At the individual level, it's already very difficult. At the team level, it's just crazy. And so, what happens? The problem is also that they have a lot of anomalies. Clients call, they are not happy because there are lots of bugs.
So we worked on implementing Camban again, and I asked them to stop, to respect the rules they had set for themselves.
And I warned them. I would say, guys, now you are going to enter a detox phase. Detoxification, you will see, is a period that is a bit painful, a bit complicated. It took three months. Detox from what? Detox from these anomalies.
By respecting their flow, they mainly reintroduced the quality they had always wanted to put at the heart of their system. At the heart of their work and which they promote to their clients.
And where it becomes great is in the last conversation we had, which is that by detoxing, so by no longer generating quality, of... Sorry, no longer generating bugs, anomalies,
Given that they have a business model based on billing for time spent, in fact, they spent less time working for their clients. And we had this fabulous conclusion where we wondered if, in the end, it wasn't necessary to regenerate bugs to maintain the company's viability.
Because clearly, with a Camban and a team as efficient as this, the company is in danger. Fortunately, they opted for option 2. Option 2 is: 'Okay, this is an opportunity to say that now we can ask ourselves questions about renewing our offers.' What can we create? What do we want to do?
Here, we are using Camban to review its business model. So, in this 'Camban for all' session, I thought it would also be a bit delicate if I lectured everyone by explaining what happens with others without explaining what happens with me.
At the beginning, when I explained Camban, you know, the circular Camban, all that, it was a bit like that. That is to say, I was a bit like the shoemaker with the worst shoes. So I worked on my Camban. This is my version from a year and a half ago now. I started quite low-tech, with Post-its, an A3 sheet. I work, I give conferences, I run workshops, I do coaching assignments, training, I teach classes, in short, I try to do quite a few small things. In the end, these are all value units that follow roughly the same process.
And then, when I started, I also had lots of ideas. Lots of things, we tell ourselves we'll do them, but we never actually do them.
At first, I told myself, we'll take it easy with Camban, I won't set any limits.
To see how it goes. For me, it's going rather well. It's going rather well.
So well that at one point, I had too many units, I had this in addition, I had it on a laptop, the Post-its were flying away, so I started to digitize it, meaning I felt the need to switch to a digital tool. I'm in a mobile situation, I need to have access to my information almost all the time. Okay, I use Trello, it's great, it's very simple, it's free, it's lightweight, I have everything I need inside. Cool!
A few weeks later, I tell myself that it's still strange. My Post-its fall, that's normal if they're no longer stuck to the sheet. In fact, they are stuck to the wall. When I step back a bit, I realize that I still have a big pile. Where everyone might think it's the 'to-do' column, I obviously allowed myself, which I never allow with the teams I support, to exceed the column.
No, this is my stock of ongoing finalization.
It's almost finished.
I'm this close, I'm really this close. I'm really this close, but I have quality requirements for my profession, for my interventions. I set rules for myself. Rules that I can't keep.
So it was necessary to face the fact that at some point, there is a reality: when the rules are too heavy, maybe we simply need to purge them, that is, not put pressure on ourselves for things we are not capable of doing and send ourselves a rather negative image. Because after a while, looking at this stage, we said, 'You will never make it.' Yes, I never made it.
So what I did, quite simply, was purge. And the purge is the most difficult moment. That moment when you delete things, it's the same thing, it's a mourning process. We're only talking about Post-its, but it's a real mourning process. It's a real mourning process because we have to accept that these requirements, we are not capable of meeting them today, maybe we will be capable tomorrow. We need to wait until we have better fluidity to be able to satisfy them.
On the days when I work from home, I also discovered personal Camban.
Because in everyday life, there are professional tasks, but there are also private tasks. When I'm at home, I'm used to having, like everyone else, the famous to-do list. At the end of the day, if we only look at the glass half empty, we tell ourselves we didn't do anything, because there's still all that to do. So here, I looked into personal Camban to structure and have the same limited, visualized management over extremely short time intervals to value the work I managed to do and prioritize. It invited me to a rigor I wasn't necessarily used to.
Very structuring. And at one point, I said to myself, wait, there's still a connection. Between the two because I am a company, I have an activity, but ultimately the actions I must take for each of my activities flow directly into my personal Camban.
And I can have a saturated personal Camban and a well-functioning company Camban. The reverse is also true.
This allows me to have a connection. And ultimately, to manage my schizophrenia, to know at what moment I am myself as an independent worker and myself as a person. Since my flow up there, we could be 50, it could be almost the same.
So, I set up my indicators using the statistical tools we know in Kanban, the control chart.
Here, there is about a year and a half of activity. This allows me today to know that on average, a coaching assignment, from start to finish, takes 180 days in lead time.
180 days, that's 6 months. The day I understood that, it really motivated me to take up an activity I'm less comfortable with and that I enjoy a bit less, which is prospecting, sales, anticipation.
And this allows me today to be very attentive to the fact that in a situation that could be going well today, in six months, it could really be a dry spell in terms of flow, and so I could be in... difficulty somewhere. I also set up my cumulative flow diagram, which allows me to see a bit of the different moments in my life as an independent worker. Here, it's the famous purge.
Oh, but I didn't let myself get discouraged. I started again.
This means there are still rules I don't apply to myself and on which I will need to make progress. They are not the same. Clearly, they are not the same.
And I experienced this again earlier with someone. And the real issue is learning to say no and understanding why we say no.
And today, this will be the next step in managing my workflow. It also allows me to discuss with someone I didn’t know, who is the accountant.
And when I started my business, the first question my accountant asked me was about the activity, how’s it going, M. Couturier? I said, very well, thank you. No, but do you have visibility, your pipeline?
Yes, you know, I have energy, I have motivation.
Yes, but that doesn’t generate cash flow.
That really got under my skin.
So, I thought to myself, how can I give myself this visibility? I feel that this question is important, and not just for my accountant—it’s that at some point, I’m going to need it. And ultimately, I thought, wait, from the moment I started setting up the framework, I have different activities, some are paid, others are not. So then, what if I assigned an economic value to each of my requests and, for example, created a cumulative value chart?
That’s not bad. Especially since, in addition, as I have types of requests at different levels, I could visualize what I’ve collected.
What I’ve invoiced. What I’ve produced but not invoiced. Because I can’t invoice it.
What I’m currently producing, what I’ve sold,
what I have in the commercialization phase, and then all the utopian ideas I’ll do, or maybe not. The idea is to also be transparent. Here, I’m showing you my cash flow. It was updated a month and a half ago.
And this allows me to see, for example,
the impact when we lose a tender.
It’s a tool for raising awareness. It’s also a tool to reassure yourself about what will happen tomorrow. It’s also a tool to trigger the right actions. Following up with a client is a rather tedious task, unpleasant for everyone. You have to know how to do it at the right time. This is the tool to do it.
What I wanted to share with you is that all these experiences stem from the same foundation: working on identifying value. I spend the clearest part of my time on this subject. It changes—value sometimes evolves too. There are new requests that come in during the mission. This notion of mapping, flows, activities—they are made to change as well. I never stay with one flow; it’s never fixed. We allow ourselves a lot of things. Creating the flow today—the limits, I only add them when there’s really an observation of exceeding limits that is already, let’s say, felt. Because setting limits a priori is very complicated. Often, they are too strict or too weak; they are rarely just right.
That’s what this conference offers you. Obviously, the most fun part will be going after the pull flow behind it. That’s the most exciting part. To improve yourselves.
In summary, everything I’ve done so far is to invite teams to work on stabilizing their organization, their service. It’s a global system, not a local one.
I have many teams working on optimization without knowing what they need to do. So, working on a global optimum rather than a local optimum revisits strategies within teams—it’s quite amazing, very powerful. Learning to consume more gently because it can create real revolutions. There are people who step out of their comfort zone; they need to be supported.
And I hope that when you arrive in Lyon next time, you’ll slow down. You’ll see that you’ll get to your vacation much faster. Good luck with your wobbling flow.