When a CEO comes by, is luck around?

About a week ago, a fellow CEO came to our place for a brainstorming session. When we had finished our intense discussion, I asked if he was interested in a guided tour of our office.

The time I spend walking around is usually a way to light up new tangents in « high level » conversations with others from my digital (or lean) community. It can also be a way to ask my employees for a demo or an explantation: they would take a few minutes to comply and usually feel proud afterwards. But more often than not, my visitor would have no time for such frivolous endeavor and would leave as soon as possible. One exception is Lean henchmen: they wouldn’t miss an opportunity for another Gemba walk.

Another exception was this particular CEO: he’d heard about the way we worked and had some free time before his next meeting. After 5 minutes, we stopped in front one of our Kaizen boards : the header showed 6 columns, Problem, Cause, Action, Results, Learnings and Status. Interested, he took a couple of pictures: I could sense something ticked inside his brain. Straight after, he had seen enough and was ready to leave. Once again I was left wandering what it meant to « get Lean » and how to convey its importance to my daily routines as an entrepreneur.

And today I was reminded how CEO effect on firm performance is mostly due to chance events. How could I convey the importance of Lean to any CEO if his work and success hold so much to plain and simple luck?

Maybe an event like a simple Gemba walk or the Lean Tour I’m co-hosting in Lille next month is just an opportunity for someone to get lucky. Who knows what happens when you get to see a couple of teams doing good work for their customers? If Toyota has been lucky for quite some time, maybe there’s still something to learn along the way. Even if it means learning to see new problems everyday: some of us seem to find it fun, challenging and rewarding.

Using two hands: a tale of physical inspiration for digital work

It was during the fabulous Mifune masterclass that the anecdote came back to me. In the Toyota literature, I had already heard about these zealous workers who try to show their dexterity to their manager: "of course I can go faster, I can even gain a few seconds with each cycle". Except that this would mean doing everything with the right hand (if the worker is right-handed) and would lead to musculoskeletal disorders in the long term. Of course the sensei would insist on using left and right hands at all time.

During the gemba walk, Umemura-san (an ex-Toyota employee and now Mifune’s founder) stopped at the workstation of an operator and invited us to look at what was happening (off course there was way too much noise for anything else). As the virtual tour continued, he stressed how important the use of both hands was important.

I've been struggling for a long time with how to translate this remark to our digital world. There is of course the posture on the chair or the position of the screen to consider. But that seemed too far removed from the actual moves made by operators. Until one day I saw an employee from my own team typing on her keyboard: off course, she was using both hands but only a couple of fingers.

A brief aside: at the end of my own adolescence, my mother forced (or was it convinced? My memory fails me on this point) me to learn typing. It was on an IBM PC under DOS 6.1 with one of those heavy and dense keyboards that make new generations envious. And just like a bicycle, you never forget it. Despite switching back and forth between QWERTY and AZERTY keyboards, between PC and Mac keyboards, I still type naturally with my two hands and ten fingers. Even though I’m not at the speed of secretaries of old, and probably never will…

So we started a little experiment at No Parking, Chloé and Ewen take 5 to 10 minutes on their work schedule every other day to learn how to type. There are many websites to help you progress: the progression curve is easy to gamify, you "just" have to master the position of each finger, then follow the movements for each letter and finally forget these combinations by repeating them. The fingers will get their own memory.

In a few months' time it will be time to check the effectiveness of the experiment on the first two guinea pigs and with a bit of luck (or relevance) the rest of the team should follow.

Beyond OKRs, a deep dive into visualization with AramisAuto and its sensei

Google is such a behemoth in the digital world everything coming out of its innards is dissected with envy and copied vigorously. It was obviously the case with its OKR system : these “Objectives and Key Results” are used within Google to set ambitious goals and track progress. AramisAuto - an e-commerce site for cars that went through a successful IPO in 2021 - followed suite and discovered managers tracked a large number of numbers, explained the ups and downs to staff, but had few initiatives other than “work harder” at what they already did.

Lean practitioners know numbers are often just a glance through a rear-view mirror : they won’t show you the way to do anything. And they can be part of the Plan (what’s the gap?), Check (is the gap filled?) and Act/Adjust (can the improvement be sustained and replicated?) in any PDCA cycle. But are of no use for the Do (what are we testing to fill the gap?).

“What is the problem you’re trying to solve?” was the sensei’s starting point. People rarely expected such a direct question, and, when they fumbled their response, the sensei would say to start by visualizing your process. For instance, right from the start as we wanted to improve the on-time delivery from our factory, the sensei suggested we draw squares on the ground to place in advance of each truckload of cars. Here, again, we misunderstood - the sensei was not solving the performance problem. He was trying to find the process problems by making the situation visible. He as constantly looking for things we couldn’t see physically: results. To him, processes came down to results and the activities to achieve these results. A problem was therefore anything that interfered with the activity and lowered the results.
Make processes visible (in "Raise the Bar")

The consequential shift suggested by the Lean framework (as recommended in the highly enjoyable Raise the Bar) is focusing on singular events (no average, no Pareto) in the actual process, at the Gemba.

Gap between process and real-life event (in "Raise the Bar")

But that’s already the next step. First is visualizing: what are your squares on the ground?

The difference between a Product Manager and a Chief Engineer

X — Why do you insist on a « technical » product manager? Why not someone like me, always in touch with the customers, from the marketing or the sales department? Like all product managers from all other companies…

Me — And what do these « product managers » do?

X — Simple, they talk from time to time with customers and users then come back with a list of features to be implemented.

Me — And how do you choose which set of features gets to be implemented first?

X — Again, that’s quite straightforward: I would ask the technical team to put every feature in a 2x2 matrix. One axis would be « Easy / Difficult » to implement and the other would be « Very Valuable / Nice to Have » for the customer. The magic combo is making sure we’d do the « Easy / Very Valuable » first. And the rest if we have time.

Me — And where would you put the « Very Valuable » stuff for the team? Don’t you think it has something to say about the product while building it?

X — I’m pretty sure they could set aside some time for that kind of stuff. I’ve heard teams setting about 20% of their time to internal work: I wouldn’t have any kind of authority on those tasks, making sure they have enough freedom.

Me — And would you trust them on doing the right stuff for the long term good of the customers? Or the company?

X — Well, I guess it would depend on how much they know the actual users. For example, if they choose to work on the issues arriving through the support desk, that would be OK. I also heard another story where the technical team wanted to update their stack but the product manager insisted to get a big feature out: a few months later, the feature was indeed released and the team just skipped a release or two in their framework. The customer was happy, there was no harm involved.

Me — How much luck was involved?

X — What do you mean? They didn’t report any problem, as far as I know anyway.

Me — Skipping a version or two in a framework usually means some vulnerabilities weren’t patched for a while. So my best guess is the customer was probably under some security risk, at least for a while.

X — That would have been really unfortunate… I guess the team knew what it was doing.

Me — Let’s jump to another topic. Have you ever heard about the 737-max crashes? Boeing needed to have a bigger engine on the plane to competed with Airbus: the decision created a trade-off between a redesign for the plane (effectively long and painful) and a software patch (usually short and easy). But with a CEO without an aviation engineering background, the management team probably chose the « Very Valuable / Easy » combo: the engineers were silenced, the redesign shelved and the software outsourced to $9-an-hour engineers. And 346 people died.

X — You’re taking an extreme case: we’re not dealing with life and death decisions here.

Me — Alright then, here’s a second anecdote: I was visiting a company and during the gemba walk, I had the privilege of hearing two kaizen presentations. The first one by a sales person: she spoke fluently, with a large smile, happy to show off how well her team was performing. The second one by a tech guy: english wasn’t his first language and it showed, his presentation was choppy, punctuated by digressions and the poorly readable graphics didn’t help much. It was obvious he was struggling to get his points across. But everybody there knew how important he was to the local endeavours. Change the CEO and nine time out of ten, she’s first on the line to get a seat to the board.

X — So is avoiding costly mistakes the reason you insist on a technical leader for our product management?

Me — Not really, you could follow Marc Andreessen’s advice: « find the smartest technologist in the company and make them CEO. »

X — I guess it would be the inverse. And Apple would have been very different since Steve Jobs was not that technical.

Me — Actually he probably was one of the greatest Chief Engineer of all time: making opinions based decisions and explaining why, willing to articulate trade-offs and to share the vision, delaying data driven decisions. But more importantly capable of embodying the product. For example, should the iPhone screen be in plastic or in glass? Made of plastic, it would get a lot of little scratches inside your pocket. Made of glass, it would break badly when falling on the floor.

X — It’s obvious: glass should be chosen. And indeed it was.

Me — But in the late 2000s the Blackberry was loved by its users for its robustness and its rock solid keyboard. It was already made of street-proof plastic.

X — OK, maybe it wasn’t so obvious back then.

Me — The Chief Engineer holds the answer and the « why » would usually be found inside his concept paper or in his head. Every design decision can be traced there. He’s the guarantee the product holds true to its vision, from the design phase and all the way to the customer care phase. Including the production and marketing phases.

X — So « why » did Apple chose glass over plastic?

Me — They argued that putting a phone inside a pocket was a « normal » thing to do, so it would be their fault if a scratch would appear. But if you let your phone fall in the kitchen, it was obviously your fault: Apple had nothing to do with it.

X — But again, you’re arguing with an extreme case: we can’t all be Steve Jobs.

Me — Precisely. Chief Engineer is probably the most difficult position to fill inside a company. Usually the founder doubles up as the first Chief Engineer: it was certainly the case for me. There's no product and no company to start with so it boils down to my vision of the current landscape, the potential customers, the close competitors, etc. But fast forward ten years and I had to kill our second product when I realized I couldn't carry it forward to the marketing and sales phases, two years after we’d started working on it. I couldn't clone myself to create a second Chief Engineer.

X — But that was more than 4 years ago!

Me — Exactly: that’s when I started exploring what a Chief Engineer actually does when not the CEO. And then examining who could be our next Chief Engineer. It took three years of mentoring and teaching to get there. Finally Opentime (our time management SaaS product) got its new Chief Engineer and my best guess is I need about three more years to learn how to become a non-Chief Engineer CEO.

X — So what it's your plan then?

Hayao Miyazaki's The WindRises

Me — I've read quite a few books on the subject over the years: Takao Sakai's The Secret behind the Success of Toyota and Cécile Roche and Luc Delamotte's Lean en Ingénierie have been quite influential for example. But since summer is here and summer means kids, next on my list is Hayao Miyazaki's The Wind Rises. It's the story of Jiro Horikoshi, one of the original Shusa - the name in Japanese for Chief Engineer - during the 1930s. Should be interesting to look at it with this perspective in mind!

Taming the baratsuki

When I am asked to describe what changed when we added kanbans to our work practices, I usually start explaining the difference between driving the pace in the office with a due date (« this piece of work should be done by Friday afternoon ») or a start date (« you should start working on this piece of work on Tuesday »).

In the first context, the not-so-subtle advice is you can work overtime and/or over the week-end to finish it off. The manager will only see it on his desk on the following Monday early morning anyway. Unleashing the compliance spirit if necessary, trying to find to whom the blame can be attributed.

In the second context, an andon will be triggered as soon as Tuesday if work isn’t started. The chain of help will be activated and the manager should be at hand, trying to understand the problem, its sources and its consequences. And then trying to get everything back in shape before the customer is impacted : he has until the Friday afternoon to mitigate the problem.

The role of the manager changes completely. The « power over » is gone. In the words of Masaaki Imai in his Strategic Kaizen, he becomes an entropy fighter:

Shop floors are fraught with abnormalities that disrupt smooth flow. Every time it happens, it is management’s task to bring it back to normalcy. Even when no problem seems to exist and everything seems to be under control, one should be reminded that anything and everything that goes on the shop floor is destined to deteriorate on its own if left alone.

And since no Lean concept would be entirely adequate without its Japanese word, Masaaki Imai introduces baratsuki (ばらつき), ie. scattering or dispersion. In the Nassim Nicholas Taleb’s tradition of Via Negativa, it becomes taming the baratsuki.

Baratsuki Control

The Lean tools become a mean to ensure the entire team can produce good quality work. And kanbans are no exceptions.

Missed a kanban ? Asking why five times...

Me — Did you manage to make any progress last night on your first deployment for the iOS app?

X — Unfortunately not. And I’m pretty sure I'm not going to be able to have another go today.

Me — But I thought your code was fine and your team leader was happy with the results…

X — Unfortunately Apple won’t let us deploy the end result to the App Store. Apparently because the version numbers for xcode and the sdk are too low. Anyway that’s the current blocking message. And it's always possible that a new error message will appear later in the process.

Me — Can you remind me why we’re discovering this problem when there are already 5 kanbans to deploy?

X — Because I've never put any iOS related stuff into production before, so this is the first time I've seen these errors. This exact setup (hardware and software) worked last year with the last intern but apparently Apple decided it wasn’t good enough now.

Me — But why are we discovering this today? When there are already 5 kanbans that are "finished". Why wasn't it discovered just after the first ticket was ready for deployment?

X — Because when a kanban is finished, I just push it to the main repository and stop there. It’s very different from the continuous deployment we use for the web related stuff. Since those 5 improvements were quite small, I thought I would finish them first and then send everything live with a spoonful. And that’s when the errors appeared.

Me — I'm not sure why you didn't pushed your iOS work in production after each kanban.

X — Well I'm sure it's not a good idea to have the App Store update the application 5 times in 2 days. That's why I was aiming for 1 or 2 updates per week : it makes more sense.

Me — Let’s deep dive a little bit here : how many updates could have been possible this week?

X — Well I did the 5 kanbans in 3 days so the first update would have been on Tuesday with two small features, the second on Wednesday with another pair of features and the third on Thursday with the last one.

Me — So imagine if we had tried to deploy the first ticket on Tuesday. What do you think would have happened next? You can do the exercise with two scenarios in mind: 1/ everything goes smoothly and 2/ reality bites and it stalls because of a configuration mismatch as we’ve just seen.

X — I see where you’re trying to go… In the first scenario, we know on Tuesday evening that everything is going according to plan and we can decide with the marketing team or even with our users if we deploy a second time on Wednesday, on Thursday or even on the following Monday. In the second scenario, we stumble on the actual errors early in the week but we can still deploy the first batch of features by Friday, possibly as soon as Wednesday.

Me — How does that sound?

X — I’m still not quite sure if it's a good idea to have two updates per week, but I'm pretty sure it's a better idea to have one update instead of none. It’s somewhat frustrating to realize that even though we've been working on this stuff all week, the end users can’t see anything at all.

The App Store deals successfully with our Opentime app
The App Store deals successfully with our Opentime app

Who's on your teaching list?

X — Your office is incredibly quiet and peaceful. Don’t you have any angry customers or suppliers calling from time to time?

Me — I tend to visit Lean offices and workshops these days, so I can’t compare to your place, but apart from the machines’ noise most are indeed pretty focused on the job at hand.

X — You’ve got to tell me the secret: I’m desperate for a smooth and tranquil day at work.

Me — Sorry, but the secret is « there’s no secret ». Take a problem, try to get to the bottom of it with whoever can do something about it, rinse and repeat.

X — But I’m bombarded by calls and texts and emails from just about everybody in my company: it feels I have to be on top of everything all the time.

Me — So who is on your teaching list?

X — What do you mean? I’m no teacher. I’ve barely enough time to give directions or instructions when called upon.

Me — So why are they calling you, maybe you’re the one having a problem? If your goal is « having a smooth and tranquil day at work », surely receiving impromptu text messages all day long is a pretty big gap from this ideal scenario.

X — And you think teaching a few people there or here would help?

Me — You’re right maybe I was a little too presumptuous. Maybe you could start understanding a little more about who’s calling you most often. Is it the sales guy or the shop floor manager? The graphic designer or the accountant?

X — Well it’s definitely not the accountant: she’s on maternity leave and I have to fill up her job as well…

Me, joking — And I hope it’s not your banker! But more seriously who’s calling you the most?

X, frustrated — Hmm, I would have to check on my phone and it would take a little bit of precious time. Do you really think that’s the most pressing issue I should be addressing right now?

Me, shrugging — I don’t know. I’ve made my own choice for the kind of work environment I wanted years ago. But the Lean literature says you can or should start with angry customers and their complaints. And I have a feeling you most direct customers - your own team - are quite vocal…

X, irritated — But they’re not my customers, they’re my team! They should be working for me.

Me, whispering — I think I’ll keep the kanban cards at bay for the time being…

X — Sorry, I didn’t quite hear your last phrase.

Me, aloud — Remind me of visiting your customers' service if I ever get a chance to visit your office…

Before using a kanban, rule 1

The first prerequisite of a kanban tool is expressed very explicitly in the book Kanban / Just-In-Time At Toyota.

Do not send defective products to the subsequent process
Making defective products means investing materials, equipment and labor in something that cannot be sold. This is the greatest waste of all.
Rule 1 before using a kanban

To illustrate this unappreciated aspect of kanban management, nothing beats a little anecdote. About ten years ago I taught a programming class to non-scientific students : they all wanted to be librarians of some sorts and with the digitalization already well underway, the university had marked out a coding course. On the third session, after an explanation of what an algorithm is, I set out to write down a simple one on the blackboard. Their following task what to translate it into actual code. After 10 minutes a girl shouts happily : « eureka, it works » and everyone else felt envious at her speed to finish this piece of work. When I got to her desk, I realized how much my teaching was off the mark : the result she was so proud of was a perfectly white screen. She had tediously and painstakingly manage to delete all the notices and warnings the compiler had thrown at her after copying word for word my pseudo-code on the blackboard. And while her program did literally nothing at all, she felt it was OK.

To be able to make the distinction, the operator (or the developer or the student in this case) needs to be able to get some help, on the spot. In a classroom, it should be easy : the teacher is at hand.

In Lean, the way to get some help is the Andon : a simple mechanism to bring the manager to the worker’s Gemba (usually a sound or a light turned on), forcing him to have a conversation and engaging him in the task of undertaking measures against recurrence.

That’s when the learning curve can kick in : when you don’t know if your work is OK or KO, it’s impossible to improve. But when you’ve learn to distinguish the two, you can start experimenting at your own pace and gradually get better at it. Until this chain of help is materialized, the worker is condemned to subpar work or to luck.

On the spot training with the folding chair

X — Funny how you have more chairs than people in your office ! I’d thought they should be placed in the meeting room.

Me — Have you noticed as well how simple these are ? Foldable and light, they actually have a very different purpose from the classical « office chair » with a set of wheels for mobility and adjustable height.

One of the folding chairs in the office

X — Don’t tell my there’s some Lean thinking behind them! I was actually joking when I hinted they could be a form of waste.

Me — Well, we do try to avoid meetings but we do need to coordinate actions. For example, when a junior developer wants to get his latest piece of code reviewed, he could add a patch to some digital queue and wait for someone else to pull it for review.

X — Yeah, I guess that would be lean in some way : there’s a pull system there.

Me — But what we actually want is to flow. Wouldn’t it be much better if the junior developer in question could commit his patch directly to the main trunk?

X — But that would require a very strict set of rules to follow, and procedures, and guidelines, and …

Me — Training.

X — You’ve lost me there.

Me — Every time he needs to have some code reviewed, one of the senior developer would grab the folding chair, sit next to him, and start a live review. It’s actually an opportunity to get some training as soon as possible, to create a feedback loop as close as possible to the work being done, when everything is still fresh in the head. And to put him on track to be able to commit his changes on his own.

X — So you don’t have any rules to follow and procedures and guidelines?

Me — Off course we do ! For example, we are in the underscore family (camelCaseStyle is banned) and force brackets in IF statement (even if PHP doesn’t care). We even have tests catching up common errors like forgetting translations or minification of CSS files.

X — Automated guidelines beyond the compiler!? Now that’s food for thought…

Just give me $20

Dating back to the 1950’s Lean has generated a long lore of stories in its wake. Most of them involve a Japanese sensei seeing things other have failed to see. They embody an aspect of Lean that is usually totally obscure for any traditional manager and particularly obvious for whoever has made the leap of faith into Lean.

Opening the chapter on « What Lean Leaders Do » in Art Byrne’s The Lean Turnaround, I found another gem.

Just give me $20, part of the Lean lore
Just give me $20, part of the Lean lore
Shuichi Kurosaka […] condutcted a « walk of shame » after one of the 4 p.m. leaders’ meetings. This was a big plant, so we had six teams with about 70 people on this walk. We had barely gotten started when Kurosaka-san pulled up the whole group in front of a big pile of WIP inventory. He then asked the plant manager, Bob Pugh, to give him $20. « What? » said Bob. « Just give me $20, » said Kurosaka. So Bob gave him $20, and Kurosaka stuck it on the big pile of inventory. He then turned to Bob and said, « Look, you are wasting the company’s money with all of this inventory, so you might as well waste some of your own as well. » He then turned to the rest of the group and said, « Let’s go. » Poor Bob was left standing there with his mouth open, knowing that he couldn’t go back and retrieve his $20. He just moved on with the rest of the group, but he got the message loud and clear and is still fond of telling this story.

We’re know about 30 years after the story. But I can still feel both the pain for Poor Bob and the sheer confidence glowing from Kurosaka-san. Both have acquired a quasi-mythical patina.

Off course, when I first read the book I was very much un-impressed : in the digital world, there’s no such thing as an inventory. Or so I thought. And then my very own sensei asked us to slash our backlog by at least a factor of 10. Which we did in about 18 months. It actually means we can choose the path we want to take on the spot. And stop drifting along the path that was envisaged months ago. Before the new Chief Engineer take-over. Before our biggest ever deal. Before a war broke in Ukraine.

Lean, a fifty years strong strategy

X — You seem keen on reading books about Lean. Don’t you feel it’s time to reach out to the next thing coming up?

Me — And find out it was a fad all along? No thank you.

X — But you were doing PHP back in the PHP3 era : surely you felt it was the next right thing back then… What’s different this time?

Me — I was young then : PHP (over ASP and Flash) was one of those things that gets decided by your date of birth. Most of the people I know who bought into Ruby were born in the 1980’s. I was born three years too early for that. And the Javascript cohort is late 1990’s and early 00’s.

X — So how is Lean different?

Me — Simple : you can read old books and they are still relevant. There’s so much wisdom in them I have to re-read them after each improvement I make along my own Lean journey and understanding.

A Lean bookshelf
A Lean bookshelf

X — But the world of 1950’s Japanese engineers is a very different one from the current business markets dominated by financial imperatives.

Me — I couldn’t agree more: this stranglehold is one of the reason I left London in 1999. Consulting and financial services were the main career path for young mathematicians like me. And now more than ever I have a feeling it’s the path we have to leave in earnest.

X — And you feel a fifty year old strategy will help you on whatever new path you envision?

Me — Call me an optimist but I’m sure we need thinking people to overcome the next crisis, and the following one and all the ones after those. Lean is learning framework, it’s been tested quite a few times and still inspires neophytes and old-timers to explore new ways of doing things: I am convinced it still has a lot to teach us. Maybe you’d like to come to the Lean Summit in Paris in June 2022 : the event is nearly sold-out. A testimony to its enduring pull.

Reading books to anchor knowledge, after practice

I’ve been for 5 years on a Lean journey and I’ve read countless books about the topic : wandering through my personal library, I can actually count 26. Though not « countless », it’s still a sizable lot.

Unfortunately there’s no shortcut from reading a book to practicing lean on the Gemba. And I start to feel the arrow of usefulness flies in the other direction as well : first you practice techniques with your team and then it’s time to anchor the knowledge through book reading.

At the turn of 2022, I decided to have another go at mandating kaizen work for all my team. But I decided my focus would be less on the actual results (which had lead to dwindling energy output over long periods) and more on the interactions between team members.

And off course, when I re-opened earlier this week Lead With Lean by Michael Ballé, I was struck by an article about the Standard Work for CEOs?

Lean thinking brings in a major change for managers: training their direct reports becomes their number one responsibility.

Lead With Lean
Lead With Lean, an excerpt from page 205 : Standard Work for CEOs?

The ink hadn’t moved: I did read that page back in 2017 but it didn’t make an impact then. And now the words do… I guess I should re-read books more often !

A Lean journey is built upon relations

X — You seem to make a difference between Lean and Operational Excellence but I feel they’re the same thing : both tend to use Kanbans, Red bins, 5S and everything in between.

Me — I would argue the difference is not related to tools : as you’ve noticed, they tend to be the same. My feeling is the discrepancy emerges with the attitude of the « boss ». From my experience, bosses sending their teams to training will create - at best - an « Operational Excellence » culture. But when bosses start teaching their staff (because they’ve learned the path beforehand), you end up in a very different whereabouts : « Lean » is the concept I tend to use for such places.

X — But if you have the people doing the actual work using the same set of tools, surely it should be indistinguishable.

Me — It would be the case if bosses didn’t matter. Maybe being a boss means I’m biased, but I feel a management team can make or break such effort.

X — Obviously any bad boss can derail a company. But I wasn’t thinking about them… What difference do you see between a good boss teaching lean tools and a good boss sending his staff to lean workshops ? Surely there’re both doing OK.

Me — The team’s capacity to challenge assumptions. A key factor here is the boss going to the gemba to understand firsthand what’s going on. You can be fooled by numbers on a spreadsheet in the meeting room, it’s more difficult to not see clues when actively looking for them on the shop floor.

X — But I thought you were talking about the team’s capacity to challenge assumptions. A boss can always do that, from his office, from his team’s office or even from the warehouse if he went there.

Me — Off course, but for the team to challenge assumptions, you need two things : trust and proximity. And for both to emerge you need a boss going regularly to the Gemba. Everything is tied to the relations created there and then ! Otherwise they're just throwing bottles into the sea.

Building a problem-orientated culture

X — How do you know you’re working towards the right goal ? I’ve seen lots of companies building sand castles over the years.

Me — I guess you’re referring to the keep on aspect of Lean… Nobody wants to be caught driving towards a dead end.

X — Precisely : knowing when to start a project and when to stop it is always very difficult.

Me — In Lean, you’d start with « cleaning the glass » : small problems have been impeding your team for years, everyone is working around them, now is the time to tackle them. And the countermeasures that emerge shouldn’t be treated as « quick wins ». Quite the contrary, they’re just the fuel for the kaizen spirit.

X — But we have tons of problems and of all sizes, shouldn’t I be trying to solve the big ones instead ?

Me — You could also try climbing floors Parkour-style without taking the stairs and see if it works for you.

X — I see your point, but I fail to see why addressing random problems would be a strategic advantage.

Me — Because you’re not just fixing random stuff : you need to teach you teams to see problems, to understand them and to learn from them. And Lean is very specific on the type of problems that are worth investigating, always starting with quality. It’s also very explicit on the set of tools to visualize problems : Just-in-time (pull, takt, kanban, etc.) and Jidoka (andon, autonomation, poky-yoke, etc.).

X — But we don’t have a quality problem : our customers are usually happy. Otherwise we would have been out of business a long time ago !

Me — That was my line of thought as well. But a month ago, we realized we were missing 90% of our errors : a parameter changed and the notices, warnings and failures within a large part of our software was sent to a different log file, in a directory we were not supervising at all. It took us more than 5 years to notice it, happy as we were of not having too many problems. Overnight we were drowned in a 131-fold increase and it took us a couple of days to clean up this mess that went unnoticed for so long… Remember : having no problems is the biggest problem of all.

Keeping on the kaizen spirit

One of the key insights I’ve gathered with Lean over the years is learning to keep on improving. The improving part is usually the easiest : find a problem and solve it. I can ask any developer in my company and given the time slot, he’ll do something.

Dantotsu, a book by Sadao Nomura
The Toyota Way of Dantotsu Radical Quality Improvement, by Sadao Nomura

Reading The Toyota Way of Dantotsu Radical Quality Improvement by Sadao Nomura, I was particularly impressed by the keep on part since it’s the difficult chunk.

The first example is the sensei’s timetable. The schedule is done yearly : it’s not some improvised visit but a recurrent trip (3 times a year) over a long period (9 years in total). And there’s no shortage of repetition.

Dantotsu, the book
Annual quality improvement guidance schedule
For overseas employees, the Toyota Production System (TPS) seemed to have some unbelievable points, no matter how much they read the relevant books or learned from others. Therefore, I decided to hold a 2-week TPS training program in Japan three or four times a year in addition to the local on-site lessons, and gave the experience to 100 or more managers, team leaders, engineers, and other key persons coming from each company. Through this training program, they learned by actually seeing with their own eyes and experiencing what they had not believed through reading or listening.

Another example is the number of successive countermeasures taken against problems found on the Gemba.

Dantotsu, the book
Countermeasures for service parts pickup work

There’s no magic silver bullet : it’s always about digging deeper until a root cause is found. Rinse and repeat as some would suggest.

The kanban is kicking me back to reality

X — Isn’t the kanban a pain?

Me — It sure can be… Like right now : there’s a kanban card publish a new article on the very top of my own board. And I haven’t got any at hand : I was too busy skiing last week during a well deserved holiday.

Back from the Alps

X — But it’s not just you, I’ve always felt it was too difficult for anyone : it’s like being pinned to the wall and not being able to escape.

Me — My sensei would say it’s the entire point. And he would add « make sure you pull the andon cord: it’s there precisely for that moment ».

X — But I guess that being your own boss, you don’t have any andon cord to look out to. And you can’t rely on a team leader ready to help you out either.

Me — Obviously. I’m back to WWSD - aka What Would Sensei Do. First don’t let the customer down, ever : just do what you have to do, stop complaining and write the article. Then think hard and through about how you can avoid the pain next time.

X — And…

Me — Well, someone is reading the aforementioned article (ie. this one). And it was written on the spot in less than 60 minutes. Maybe I can let my stock go down to 0 from time to time and feel the adrenaline. Maybe I can prepare rough drafts to rely on and feel the serenity. It’s all about tradeoffs.

Building psychological safety to make great teams

When Google published the result of its Project Aristotle back in 2016 on what made great teams, a concept stood out : psychological safety. That’s when "team members feel safe to take risks and be vulnerable in front of each other". It was the number one factor in their original paper.

After the successful NUMI experiment, Toyota decided to build its own plant in the US in the early 1980’s, Georgetown - Kentucky was chosen and a group of mentors (ie. senseis) was sent from Japan to teach, train and guide the newly recruited management team.

Steven R. Leuschel went back to this group of American employees in order to gather their views 30 years later for his PhD. The book Sensei Secrets: Mentoring at Toyota Georgetown was the end result. And guess what: it’s the notion of protection that stands out.

Sensei Secrets: Mentoring at Toyota Georgetown
Sensei Secrets: Mentoring at Toyota Georgetown

Monday morning, we unload the dolly at 5 a.m., the trial started at 7, by this time I've been up like 48 hours and I was covered with black soot and grime. So [my sensei] comes in, and I walk up to his desk and he is sitting there, writing like he always does, and I said, "Kaz, I got the dolly in."

He said, "How did it go?"

I said, "It was a piece of shit."

And he just kind of started grinning.

I said, "You knew that when you signed it off."

He said, "Yeah."

At this point, Jeff thought he was going to get screamed at or even fired because his mistake cost a few thousand dollars. The conversation contined:

He said, "You knew that is was a piece of crap, yet you let me do it anyway?"

Kas said, "Will you ever do that again?"

"Hell no!"

Kas smiled. "Cheap lesson."

Sensei Secrets: Mentoring at Toyota Georgetown
Sensei Secrets: Mentoring at Toyota Georgetown
All these stories of protection showed an unanticipated them of the research: the extent to which the Japanese senseis protected the Americans from negative emotional experiences, from fear of failure, and from the negative consequences of failure.

If it’s not a path to psychological safety, I don’t know what is!

Kanbans, where is the pressure ?

X — I’ve had a glance at the way you work, with digital kanbans and the lot. But there’s one thing that bothered me for a while afterwards : finishing a kanban a day is real constraint for the developers. Surely they must feel a constant pressure from this machine?

Me — You mean the list of tasks they have to complete for the following day, and the one after, and on and on?

X — Precisely : where I work, we pushed back on setting deadlines long ago. It was too much stress upon the team. Ever heard of the Death March? It’s the one thing I want to avoid now.

Me — There are actually two countermeasures built into our kanbans implementation. The first one is the « time boxed » part : if it takes more than one day, it means there should be two kanbans (and not one). Usually developers are quite good at estimating on such small scale… That’s the leveling part.

X — And the second bit?

Me — The automatic andon. If a task does take more than a day, the andon cord is pulled automagically by the system and the responsibility is now on the manager to do something about it.

A supervisor responding to an andon call

X — But I’m the only manager in my team of 12 developers. It will likely be hell for me, having to switch from on guy to the other just because they can’t finish on time every other task.

Me — That’s the point. The pressure is on the manager to make everything work, not on the developers. They’re the ones producing value added work for the customers or the end users.

Teaching and learning in the new normal

Empty desks in No Parking office, 2022
Empty desks in No Parking office, 2022

X — With the pandemic still under way, it must be a challenge to practice the kind of Lean you’ve been trained to do.

Me — Sure ! When you’ve invested in post-its and boards and pencil markers for the last 10 years, it can be frustrating.

X — I guess you’re happy having avoided them most frivolous of 2020 investment, the top floor office with a view.

Me — Well, here’s the view from our nearly empty office we got into in 2018… Not sure we’d be doing the same kind of investment in 2022.

View from the No Parking office
View from the No Parking office, 2022

X — Are you forcing the staff to enjoy it?

Me — Not quite : everyone can work from home as long as he wants.

X — No strings attached ?

Me — The only one is coming at least half a day for training purposes : it’s the main part I’m not confident of doing online. I feel I haven’t cracked that yet. That and onboarding new staff.

X — Hold on a minute, are you teaching your employees every other week ? It seems an absurd amount of wasted energy. Surely they know what they’re doing!

Me — There’s a classic in Lean circles that goes like this: a CEO asks What happens if we train people and they leave? and the sensei answers What happens if we don’t and they stay? And Toyota actually means it : in their french plant, every manager has a local supervisor, like you would expect, and a second « coordinator » directly from Japan as well. His task is simply to instill the Kaizen spirit.

X — I’d call that an overloaded bureaucracy.

Me — That’s because you haven’t heard the Toyota CEO actually doing the first lecture from their TPS training program to its upper management. But back to what we’re doing to deal with the online training stuff : we’re calling it the « Gemba Code ». Each week with a different developer, I’ll do a deep dive into a problem found in the « red bin ». It’s usually a one-hourish Zoom session and brings invaluable knowledge about the things we need to get better at for the next time.

X, shrugging — And I thought pair programming was some fringe and extreme practice.

Me — Ah, XP : music to my hears. Funny how one of their core practices isn’t possible anymore : imagine being in one room with the entire team, sharing a desk and a computer with your closest neighbour and chatting with the customer as well. The health officer would go nuts. And I wonder how the XP community will cope in this new normal.

X — It seems you do like experimenting weird stuff at your place.

Me — The weird thing is people accepting the status quo in their company, waiting for a magic wand that will get them through without doing too much effort such as bringing on the consultants to do some change management.

X — And what are you suggesting instead?

Me — I’m actually so glad I’ve found a bunch of likely minded folks in Lean, trying to push the agenda towards a better futur for their customers, their companies, their people and the planet. And writing books, and doing conferences, and so on and so forth. And lately I’m particularly eager to follow their new « on-line gemba » course.

Lost in Lean's translation

X — With all these Japanese words dotted around lean literature, it must be difficult to spread the knowledge around.

Me — Sometimes having difficult words can be an asset : take lean for instance, it’s probably impossible to translate in any language. Certainly not in French for instance : maigre doesn’t quite sound right for any thoughtful way to do stuff.

X — I was speaking about the Japanese stuff…

Me — Well I did learn some Lean stuff while not speaking any Japanese at all. Andon, Gemba and Kanban are not that difficult to grasp. Kanban for instance is only a tangible sign made of paper or metal…

X, interupting — Hold on, we’re both in the tech world and we know Kanban is something else altogether : it’s just a board with 3 columns To Do, Doing and Done.

Me — Alas… Old Lean senseis would be devastated to hear such nonsense. This kind of board is not event showing the lead time for each task : there’s no space whatsoever for any self-reflection. It’s only good enough - at best - to cap the work-in-progress. It’s missing the entire chain of help that’s crucial for any lean initiative for instance. It feels like some consultant found a gem in the old manufacturing literature and set up a big tent on his way back from the mine with a big neon light flashing « you too can have a glimpse of the gem I found, and you know what, you don’t have to go down there : I did all the work for you ».

X — I can feel the irony and the sorrow in your last tirade.

Me — Indeed the door is wide open but remains very small. And the world is getting bigger and fatter, with more money, more processes and more bureaucracies. I’m just waiting for the interest rates to go up and resources to become scarce : Lean’s true potential will be felt more widely then. Not before unfortunately.

X — That sounds gloomy.

Me — That’s probably because you haven’t heard the news about climate change and all the rest of it : they’re a real cause for concern. Off course, you can look out for true Lean companies doing incredible stuff with Karakuri Kaizen or Lean & Green. But in the meantime, don’t forget that better quality brings profitability and faster lead-times brings cash.

X — Are you joking? The entire world heard about the « Just-in-time » rout.

Me — That’s what happens when Japanese engineers use a catchy name for a new concept : it was supposed to mean « at the right time, not before, not after ». In Toyota, everyone knows you can’t finish a car if you’re missing one piece. That’s the reason they started stockpiling chips when they understood - before everyone else - a shortage was coming. Only Tesla is trying some other way, selling car without the USB port.

How remote working forced us to review the use of our kanban cards

In charge of marketing and communication at No Parking (a web software company based in Lille, France) Chloé works closely with other teams (development, customer relations...) to ensure the production and development of Opentime, a time management and activity monitoring tool. Today, Chloé shares with us her experience of how the pandemic led the company to an in-depth review of its working practices.
Chloé in front of here kanbans board

Lockdown brought to light new problems within the team. Remote working, staggered working hours, and digitalization of visual management inevitably led to new difficulties that the team tried to resolve. Until then, the order of tickets was managed on a daily basis during the physical stand up in the office. But, with digital tickets, priorities have been blurred. No direct visualization of lead time on current tickets, no physical meetings and less regular coordination in the team.

Two problems resulting from this situation were then identified within our organization. On one hand, there was no logic in the order of everyone's cards on the digital Kanban board. There wasn’t any prioritization by value. The kanban cards were then displayed according to the estimated end date and those that didn't have one appeared last: an irrelevant order. On the other hand, it was possible to change the starting and ending dates of the kanbans, which we sometimes did according to our desires or the customers' remarks.

The consequence immediately appeared : many kanban cards were stagnating at the same point in the process for long periods of time. They were also postponed (change of the estimated end date) either because the subject seemed less important than others, or because the tasks were too long to carry out, too complicated or the person in charge did not have the skills to deal with them. The following questions then appeared: Are these really issues that need to be addressed ? Are we behind schedule? What should we do about it? What do we need to test to eliminate this unproductive process?

Driving kanbans by launch date

The solution chosen and applied at No Parking was to drastically change the management of kanbans. From a control by the presumed end date, we have switched to a control by the launch date (the date on which the task associated with the kanban card must start). The second important point is that this launch date can no longer be changed once the date has passed. However, one card, and only one, can be given priority (physically pinned to the top of the tasks pile).

We also eliminated kanban cards that had been around for too long, making sure that the needs were no longer expected by our customers. After this cleanup, we decided we could not repeat the same problem!

Concretely, this change has been materialized by a fundamental modification of the working habits of the team members, in particular for Ophélie in charge of creating the kanban cards for the IT development team. On our digital tool dedicated to kanbans, she now indicates the launch date when creating the card, taking into account the availability of each person and the client's initial request. For example, a customer asks us to add a new validation method for expense reports in the Human Resources tab of our Opentime software. Ophélie assigns this ticket to Laury in 2 days since she does not have any ticket to work on that day. In addition, there are no alerts for the tickets she is currently working on that need to be completed before this new requirement is taken care of.

In the marketing and communication sector, I also had to change my habits. I now have to enter the start date of my tasks knowing that it could not be changed after, which created a new view of my tasks ordered by predefined start date and time. This change led me to several discoveries: I could no longer create kanbans for "later / maybe / if I feel able to do it" and I had to consider much more how much time each topic would take me when creating the kanban.

The organization of kanbans of each member of the team thus evolved automatically, putting the actions that needed to be done first (customer request or critical anomaly which needs to be corrected immediately) on the top of the board. The advantage of working with digital software is that it allows us to have global visibility of the kanbans and to be able to establish rules that are impossible to cheat on !

Better control of lead time

With this start date, our lead time measurement has become much more real and accurate. Through the processing of the discrepancies that we can see on the kanbans’ board, we learn about the real time of each request and have access to a better projection of the duration of future topics.

In fact, piloting requests by launch date has influenced the overall productivity of the team. When it comes to selecting the next task, it is no longer an employee’s choice based on how long a kanban will take or what he/she likes, it is now a choice based on priorities. The Kanban card that comes first in the board is not the shortest but the most urgent/important (value); and this makes our productivity grow.

In general, our average lead time is now lower and more constant. Indeed, until March 2021, our average lead time per week (on all the teams' kanbans) was between 2 days (for the best weeks) and 10 days (for the worst weeks). Since then, with the implementation of this control by launch date, it has halved to between 1 and 5 days per week.

Even so, if the maximum lead time per week has dropped from 100 to 50 days, it still remains high. Having identified these maxima allowed us to define reaction rules through the use of the « andon » and to work on the root causes to avoid this to be recurrent.

What did we learn?

First of all, we learned from this experience that there is a possibility for each person to be more focused on their task if the organization is done at the time of the creation of the kanban cards. The operator will now spend more time creating value than thinking about which task to do first!

This situation leads to a less stressful job, as the IT development trainees pointed out to me. Vincent sharing: "The benefit of having a pre-set schedule, of not having to do it yourself is that you really see it as a schedule and not as a constraint." And Quentin adding : "Since there is not necessarily a closing date, there is less stress about the deadline, we just know that we have to move forward since other kanbans start the next day or the day after. We're less stressed because if we're stuck on a kanban that we've started, there's the andons and the red bin to help us."

In fact, the developer knows on his own that he needs to finish his active kanbans before the next ones start, but for the system to work, he must not get stuck. The use of andons and red bin then makes a lot of sense. Even if one team member is interrupted to help another, the work is completed more quickly than if no support had been provided. For Valentin, "with this organization and especially the fact that I can more easily call on the andon, when I start a ticket I don't think so much about whether I'll be able to do it."

This method has enabled us to better identify our skill needs. The impossibility of changing the end date makes us force ourselves to try to accomplish a task and the andon provides the necessary support to learn from people who actually have the skills, which helps to share those important skills!

In a more indirect way, with the hybrid work that led part of the team to work from home, this method of managing the kanban cards allowed us to highlight a weakness in the versatility of our team, due to a lack of skills. When the only person who can carry out an action is absent, on vacation or telecommuting and difficult to reach, his kanban card stagnates and the lead time increases. Thus, in July, we noticed a clear increase in our average and maximum lead time!

We must therefore ensure that :

  • information circulates easily with constant exchanges within the team
  • we are aware of the planning of different team members
  • we permit skills to spread between team members

Finally, this way of working has allowed us to identify a real link between the internal organization of our customers and our production. In September, for example, one of our customers (who validates the features we develop for them on the software) was on vacation. We did not anticipate this period and the lead time of the cards associated with this customer increased without us having the possibility to do anything.

Controlling tickets according to the launch date has allowed us to positively impact three key points in the functioning of our team: productivity, pressure felt by team members and the team's contribution to each member. We now need to use what we have learned from this experience to reduce the maximum lead time of our kanbans and impact more strongly on the service provided to the customer.

A french version of this article appeared on the Institut Lean France website.

Lean tools for the CEO in a hurry

X — I remember discovering lean tools at my first job but that was long ago. Hearing you talking about it has sparked my interest again: any tips on what tool I should try at my company?

Me — Forget about the tools, there are too many of them. Maybe you want to start with a couple of books with stories about lean turnarounds, I’ve got a dedicated bookshelf at my office.

— I don’t read much, sorry. I’ve also heard kanbans were interesting though really hard. Maybe something else, more palatable?

— Sorry, you need to embrace Lean to the full or you’ll just pick up the low hanging fruits.

— Sounds good enough to me, picking up the low hanging fruits is already a quick win. Where do I start?

Me, disheartened — Since you’re a e-commerce company, the shipping area should be interesting enough. Go there, look for missed deadlines, try to remove any blocker and set a target of halving the bad and doubling the good.

X, interrupting — But that’s the job of my logistics manager! Not mine.

— If you can’t pierce through silos within your own company, nobody can. That’s part of the CEO magic. The real lean transformation always start with a CEO. In France, the biggest IPO in 2021 was Aramis Auto: its CEO went as far as co-writing a book with his sensei (among others). OVHcloud did follow a few months later with a much-anticipated IPO as well. Guess what: in 2018, it was already hosting lean events.

— Funnily enough, it’s my CTO that really enjoys taking a break from his coding routine by doing some picking with the front-line staff for an hour or two.

— Let me guess : you know have a picking app that’s stellar.

— I don’t know. And how would I know anyway ? That’s his job by the way…

— All right then, what’s your job?

— What do you mean? I’m the CEO, and that’s what it is ! And by the way, thanks to our determination through the pandemic, we’ve just had a great year.

— How do you know it wasn’t just luck?

— …

— Maybe a visit to the warehouse could help : just standing there and listening deeply will probably bring clues. And if you ever need to justify yourself, for example if someone asks you what you’re doing there doing nothing, just say you’re practicing Genchi Genbutsu. It’s one of those Lean tool you were asking about after all.

Michael Ballé's definition of Lean

In his latest article Michale Ballé asks a simple but profound question Where do you start with developing people?. Along the way he advocates a definition of Lean.

Overall, this is what lean is about:
- Plan, check where you are against plan, and think through the gap
- Have a team leader, coordinator or coach help you to actually look at the gap rather than avoid it
- Combine both to come up with something new to try and learn to stay cool out of your comfort zone

Andon will give you the frame for on-the-spot routine. Kanbans for a daily routine. Hoshin Kanri for a yearly routine. They are numerous other examples. But the secret sauce of Lean is to repeat over and over such simple steps: sustainability to bridge the gaps breeds success...

With Lean, we're always making people

X — I noticed you finished up your last conversation mumbling about Jidoka: any insights since then?

Me — Glad you asked, I’ll be able to think again about TPS… I really need to do it from time to time. What did you find?

— A little wikipedia search brings up four principles: 1/ Detect the abnormality. 2/ Stop. 3/ Fix or correct the immediate condition. 4/ Investigate the root cause and install a countermeasure .

— You missed the separation for human work from machine work.

— But in the digital world, the human work is on a desktop by the developers while the machine work is on the servers. Easy, isn’t it?

— Ever saw the XKCD comic about "compiling"?

— Ah, touché.

— Fortunately we now have building environnements that will simply take the load on through Continuous integration. And if you’re lucky, Continuous Delivery as well.

— The "automate everything" of the software community...

— Remember if we can avoid automating the bad stuff, we’d be much better off. So we’re back at detecting bad stuff and we want to do that as soon as possible. We can start at the requirement: is it complete? Precise? Does it contain examples or context? Can the developer work on it straight away? Usually a check list will be the first step towards proper standards.

— I guess User Stories would fit the bill.

— You can call them whatever you want. What we’re looking for is a way of making sure the entire workplace learns to make good requirement day in day out. The key tool here is the andon.

— Again one of the those funny japanese words, isn’t?

— Not anymore, it’s actually a loanword now so you’ll get over the desire to translate it. It’s just a system to notify the local leader you spotted something wrong and need some help.

— But I’ve a team of about 15 devs, there’s no way I could fit all the meetings I need to attend to and their constant requests. I need them to be more autonomous.

— Well, in Lean, we tend to favor teams of 4 or 5 people. Including the team leader. And dealing with the andon is his first responsibility. The second is also straightforward: making sure a countermeasure is put in place to prevent the problem of occurring again.

— I thought we’d be talking about the pros and cons of unit testing versus integration testing.

— Of course they can help, you could even argue they can be a form of Poka Yoke, another lean tool for Jidoka. But please make sure you get you help chain right. Otherwise you’ll find out to late your devs were indeed autonomous, just going in the wrong directions.

— I can sense scarves behind such warning.

— One of my big lesson of Covid19… We’re always making people.

Red bins for the digital world

X — I know Lean started in manufacturing. Why on earth are you trying to use this system in the digital world?

Me — That’s simple enough, because Lean provides a full set of tools to frame the world differently. And Toyota (among others) has shown they can be useful.

— Example?

Red bins, the place where operators put defective parts.

— Why not use a regular scrap bin directly? We’re piling up bad stuff : surely a case of muda.

— Not so fast, we want built-in quality. So you need to make waste visible and to train operators detecting good and bad parts: when a part is put in the red bin, it’s actually an opportunity to check with the team or line manager if the part is indeed not OK.

— Alright. But why not simply have one red bin per plant. Surely it should be enough for highly automated and perfectly functional plants.

— That’s because those plants don’t exist! There’s always some deviation and you want to start your investigation as close as possible to the crime scene both in time and in space. Remember: whenever you have unexpected things happening, you have an opportunity to learn.

— But we’re back in hard stuff zone. I thought we’d be talking about code and developers and digital stuff.

— We’re getting there, we do use red bins in our digital world as well. But first we needed to ask, who’s the operator here.

— It can’t be the computer engineers: surely they should know better!

— Remember we’re trying to project a vision of the world in another universe, so we need to keep an open mind. But if you consider we’re operating a SaaS product, then it’s indeed the server that’s doing the valuable work to the end user, so you can just as well assume the operator is the actual server. And each server has a simple built-in mechanism to identify bad requests : the log file.

— Are you actually considering the log file as a red bin?

— A layer just above it: we filter out lines we’ve found irrelevant over the years. And aim for the lowest number of errors possible, i.e. zero, from there.

— With Pareto tables to manage the overwhelming onslaught of notices and warning.

— Maybe. At the beginning. To clean up the existing mess. What you really want is to be fast at patching: so you really need close interactive loops between developers and sysadmins. This gap is one of the space of the digital world. And one of the insights leading to DevOps by the way.

— You mean DevOps is related to Lean? I thought it was more Agile-like.

— Please don’t make me angry. I was on the XP bandwagon when it lost all its momentum to Scrum, that’s when I first jumped ship actually and scrapped both sprints and retrospectives.

— Sorry, didn’t want to make it personal. Going back to new entries in the log file, are you implying you’re fixing every error as they come in? It surely sounds a hell of a job to me.

— It could also be an entry point to the holy grail of one piece flow, aka sell one, make one.

— With the server creating a ticket in the bug tracker for each error? At our place, they would get a Won’t fix / Didn’t replicate answer 99 times out of 100.

— Here, we know that every time we postpone a fix, we’re faced with two problems : 1/ the original problem of course and 2/ the difficulty of recreating the initial conditions.

X, interrupting — Again we’re back to lead time stuff.

Me, mumbling — Funny how we switched from Jidoka to Just-in-Time. Not quite sure what to make of it though…

Kanbans, and the art of not choosing

X — Look, this kanban is really easy, I’m sure I can do it in less than fifteen minutes.

Me — I’m sure you can but the kanbans board tells you something else, doesn’t it?

— I know, it’s in second position. There’s another kanban at the top.

— And…

— I guess it’s the one I should be working on next. But the problem is I don’t know how long it’s going to take : it’s one to those « red bin » kanban, we never know if it’s a 5 seconds fix or a 2 hours deep dive into old and obscure code.

— And from which one are you going to learn more ?

— Easy… The 2 hours deep dive. The other type is usually a simple condition someone forgot about : just looking at the log trace is usually enough to have an idea of the method that needs updating.

— Is this « 5 seconds / 2 hours » categorization the same for you and the rest of the team ?

— Of course not. For example, if it’s related to Javascript, it’s usually « 5 seconds » stuff for M.

Me, laughing
— And a « 2 hours » nightmare for me.

— But what if I’m really stuck.

— We’ve talked about the other button, haven’t we ? The orange « andon », right next to « red bin ».

— But if I click on it, I’ll be interrupting somebody else…

— That’s exactly the point : making sure you can draw the attention of anybody in the company while you’re dealing with your share of potentially difficult problems or bugs, improving your skills and learning new ones along the way.

— You mean it’s a privilege to be assigned those « red bin » kanbans?

Me, smiling — I hadn’t thought of it that way, but I guess it is…

Lean starts with commitment

Even though Toyota created Lean (or TPS as it’s called inside of the car company) within its manufacturing plants, this « business strategy » has had tremendous success in all different types of companies : consumer electronics (Apple - with Steve Jobs as its Chief Engineer), fashion (Zara - with its focus on putting consumers in charge) or e-commerce (Amazon - using andon cords, Kaizen programs, and eliminating the root cause of errors).

Recently Toyota has seen a new surge in TPS training for its office staff. And its suppliers are taking notice : « Toyota, are you committed? » said one.

Product General Manager Wada - from DENSO - talking about TPS commitment to Toyota
We were told about it in September last year, and the first thing I said was, “Are you committed?” because I wanted to know from the start how deeply we were to get involved in it. I wanted to know this, because we had worked on the same initiative with Toyota in the past on several other occasions. (…) This isn’t easy to say, but in the past, I feel that Toyota has given up in the middle of some projects. Based on such past experience, I wanted to know from them how committed they are this time and how they plan to make changes.

What a lesson in Respect for People when you accept to transcribe such powerful statement on your own website. Because challenging misconceptions is always hard, implementing Lean is never easy and it starts with facing the reality as it is.

The Kanban must remain stone-faced

"But how will I adjust priorities?" This was the existential question that Ophélie asked when our tickets were finally transformed into digital kanbans.

It must be said that the last transformation had been the most radical: not only would the "start date" replace the "end date" as the sorting item for the tasks within the technical team, but the field itself would no longer be editable once the date had passed, even if the task had not been started, even if another client had brought in a more urgent or more important task. Of course, this date is crucial: for us, it corresponds to the date of the initial request for an external customer or, for an internal customer, to the date on which we anticipate availability within the technical team. Because of a simple remark by a Sensei, pointing, midway through a mundane conversation, that he didn't understand the order of each developer's tickets, she had lost the ability to continuously modify the schedule for the entire technical team. Gone were the days she could shift a ticket or postpone another according to the pressing demands of a loyal customer or the high expectations of a potential client.

The previous transformations had had less of an impact on her. First, there was another remark during a gemba walk with our Sensei: "no help chain, no kanban." We therefore added a "trigger andon" button on each ticket. By clicking on it, the developer indicates that he needs help: his manager is automatically assigned to the ticket and a message is sent on our internal chat tool. This button complements another one, « to the red bin": this one allows the developer to specify that the request being processed is - one way or the other - problematic. It allows him to materialize it will be necessary to come back with the team leader or the CTO and to explore the root causes of the problem.

The list of tickets that went through the "red bin" or the "andon" has become a gold mine for our "gemba code" routine: by taking the time to delve into the details for this or that ticket, by finely analyzing lines in a log file or by dissecting the source code, the members of the technical team have brought to light design errors, lack of training, security gaps, and knowledge deficits. These discoveries have become a wall of continuous improvement that every developer can come to - whenever he or she comes into the office.

A good context for these explorations is the arrival of PHP8. This new version of our programming language forces us to dust off a lot of old knowledge. For example, when we discovered that our continuous integration server was not displaying notices, it was because the procedure for updating a server was out of date, not just some PHP initialization file. Or when a specific plugin started to give us errors, it was the mechanism to ensure compatibility with all plugins that needed to be addressed, not just the impacted users.

But it was by blocking their start date, by materializing the launcher, that the kanbans spilled over from the technical team to the teams in direct contact with the customers and end users of our software. And we switched from managing day-to-day operations with accordion-like delivery dates to managing them with a start-up date set in stone. Of course, this works because at our level of maturity, we know that a task should not take more than 8 hours of effective work and that, consequently, a task started on any day should be « live » on the following day. This technique ensures a task more complicated than the others will no longer slip imperceptibly to the end of the project: we want the problems to surface quickly. And that another, more complex task will not be left to the one specialist within the team: we want the necessary training to be carried out as close to the need as possible. By losing the "choice" of taking an easier or more common ticket, developers gain opportunities to improve their skills.

Because kanbans are a system: they are a real transactional framework between customer and producer, guaranteed by the responsiveness and support from the rest of the organization. Because of their power to reveal discrepancies and problems of all kinds (the virtue of lead-time), they imply a web of trust between the stakeholders and offer countless learning opportunities.

Of course, this beautiful mechanism can be interrupted at any time. We had the opportunity to verify it when a developer went on sick leave while another one was forced to take days off to take care of his little boy. The kanbans started to freeze, triggering automatic andons: Ophelie found herself in the middle of the exchanges with all the stakeholders. Not because the task was already well behind schedule, but because the start date had passed, which - from the client's point of view - was at least 24 hours in advance. Enough time to agree with all parties and check each other's priorities. Copious time to demand better tools for her daily work. Sufficient time to build trust beyond the team, with customers and users. Reasonable time to find the full measure of her function, "Customer Success Manager".

  • page
  • 1