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