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…

  • page
  • 1