Can 5S apply to coding?

Dear Gemba Coach,

We’re exploring lean in software development. Can 5S apply to coding?

Interesting question. I remember consultants that went into a software house and asked devs to clean up their desks and tidy up their drawers. One dev left.

As we’ve often discussed, 5S is NOT a cleanup-your-desk technique. It’s a method to take ownership of your production resources to make a better, faster, easier job of it. It applies to software as anything else – but in the actual code.

Code is a sequence of instructions for virtual machines to do stuff. Take that input, put it there, process it, make this happen. It’s written in a weird language, but language nonetheless. To get into the topic, let’s take the easier example of e-mails. E-mails are like software for humans. Here is the info, process it, and make something happen with it. Here’s a message I received from someone I don’t know on LinkedIn:

“Hi Michael, Thanks for connecting. I am reaching out to leaders in quality and operations like yourself. If you believe in Layered Process Audits (LPA), we have the right tool to help your clients’ plant realize its full potential. Our development team members have been manufacturing experts like yourself with firsthand experience of implementing LPA in leading automotive and aerospace companies. Why are LPAs so difficult? Many audit programs do not close the loop on audit-finding by tracking corrective action. Most LPA software systems are burdensome to use. If the staff doesn’t feel the benefits, audit completion rates will taper off. Unique features of our product – iAudited: • Video and picture cues for auditors • Fully automated audit scheduling and mobile audits • Collaborative approach for corrective & preventative mitigations • Artificial intelligence driven risk prediction engine • Performance guarantee: Reduction in cost of quality, safety incidents or improved OEE Here’s an interesting article and video that explains the strength of our LPA platform: https://www.linkedin.com/pulse/do-layered-process-audits-seem-like-waste-time-pratik-shah/ If you are a bold and visionary leader who has already started an LPA program at a client’s plant, we can offer a hassle-free experience of porting to our new and improved LPA system – iAudited. Don’t hesitate in reaching out for a demo even if you are not actively looking for a new LPA system – what’s the harm in getting acquainted with the best?”

I still haven’t got a clue what this is about other than someone is selling something and that I shouldn’t have pressed the accept button on the LinkedIn invitation page. Could we 5S this?

1. Seiri – sort and eliminate: What information in that e-mail is useful?
2. Seiton – set in order: In what order should the information appear?
3. Seiso – shine or sweep: Is each sentence clear and grammatically correct?
4. Seiketsu – standardize: Do we have a standard to maintain the 3 previous Ss?
5. Shitsuke – sustain: Do we regularly go back and check the e-mails we’ve been sending to see if 1/ we keep to the standard and 2/ we should change the standard?

What I sorta-kinda understand from reading this a few times is that these guys have developed an app that allows you to audit a process and then collate the results in graphics. That’s not necessarily silly, and I might need something like that. They’re basically trying to get me to contact them to give me a demo of their software. If we start with sieri, the information is “we’ve developed a cool app to carry out process audits with a tablet and show meaningful results with it.” The action this is supposed to trigger is “contact us for a demo.”

Standard Work for E-mail

Humans are not machines, so we are not obliged to pay attention to information or to follow it through. They also need to 1/ grab my attention and 2/ make it worth my while. Seiton will point us towards:

1. Do you ever use Layered Process Audits?
2. We’ve developed an app to do so on a tablet and it calculates results as you go, and presents it in an easy format to transfer to PowerPoint.
3. Give us a shout, we’ll show you how it works for free.
4. Many people use it, it cuts their workload in half, and so-and-so recommends it.

Now, seiso, we could spend some time polishing each sentence to make them as effective as possible, throw in some positive priming words, such as “success” “efficient” “fun” “pleasurable.”

“Hi Michael, thank you for accepting my invitation. Do you ever use Layered Process Audits? Do you find the paperwork difficult to process? We’ve got a cool app to do so on a tablet and it calculates results as you go, and presents it in an easy format to transfer to PowerPoint for killer presentations. Give us a shout, we’ll show you how it works for free. John Smith, whom you might know, has been very successful with it and so have many other businesses. They’ve found it cuts their workload in half, and they highly recommend it.”

Now, for the interesting part – what could seiketsu, standardize, mean for an e-mail. Well, at the risk of sounding obsessive, I do have a standard for writing e-mails, taught to me long ago when e-mail replaced memos (I was told by the chap sitting next to me on a flight back from China that emails are old hat and multi-million dollar deals are now done on WeChat). My standard, for what it’s worth is MADE: Message, Action required/proposed, Detailed explanations, Evidence attached. Similar to a news story: 1) What is the frontline news; 2) Who is doing what about it; 3) What is the backstory; 4) Where to find references. I do also pay attention to the tone of the message according to the recipient.

Shitsuke: I haven’t found reason to change the standard so far, but we write so many emails I do occasionally check myself against the standard and face the fact that I write plenty of thoughtless emails – some times with unfortunate consequences. The standard is not a guarantee of writing the perfect email, it is a safeguard to think about what you’re writing beforehand: what information am I passing on? What action am I after? How is that persuasive?

Fine, e-mail is a far cry from code – although I believe all text is code. I was recently discussing with my friend Regis Medina, a lean digital guru about 5S in actual code. We were looking at a travel application. The trip’s price calculation shows up in different places in the code because it’s used in different contexts, such as when the user goes through the web page, or in the APIs. So whenever you change something in the price calculation, you’ve got to track several places to update in the code – and then change the tests in each of these areas.

A little seiton makes you realize it would make sense to have the price calculation in a single place: extract the price calculation and place it in a separate function. This refactoring, as agile call it, calls for careful seiso to make sure the new code works without surprises and you see at seiketsu phase that when you want to use it at every spot where the algorithm uses price, there are some local differences (function is 90% the same but…) – now you need to make sure the central function is flexible enough to accommodate various cases, which means shitsuke – checking back that the discipline of 4S is maintained.

See with Your Feet

This is about coding discipline itself. The second huge impact of 5S is creating standard naming practices and locations for coders on the same team to know what to look for in blocks of software. All the way back to when excels were cool, we’d learn to create a first block of cells with the input variables, then the output variables, and then the spreadsheet itself – a practice that has fallen into disuse, so that so many spreadsheets are incomprehensible now.

5S is not about clean your room. It’s an essential practice to manage all resources on hand. Whether physical, such as tools and parts, or informational. 5S is the practice of looking at how you prepare your own work mindfully as opposed to jump in and dig in.

Whatever your job, 5S is the “clean-the-window” practice that enables you to understand what the work really is. Handling every component of one job – tools and inputs – is the surest way to see with your feet and think with your hands and look into the what, how and why of the job. Doing so with your team is the starting point for clarifying the basic shared rules of work, and progressively standardize how we work together to lead a clear and vital workplace.