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