5S – taking it too literally?

As an old saying in Object Oriented Analysis (OOA) goes “Naming is essential.” And while I was writing this series on the 5S approach over the last couple of weeks I felt increasingly uncomfortable with the Sort – Straighten – Shine – Standardize – Sustain canon of the English translations.

The 5S-approach works well for knowledge work ...

I actually took the words from the Wikipedia article to create the titles for my articles, but as you can see in the current list of links below I amended the titles with the translation from Hirano‘s book on implementing 5S in e.g. office environments.

• Sort (or organization)
• Straighten (or orderliness)
• Shine (or cleanliness)
• Standardize (or standardized cleanup)
• Sustain (or discipline)

To me these translations made a lot more sense in the context of knowledge work. And – to be honest – in the context of the original descriptions as well.

... but not so much with the ideas associated with the English S-Words

It is my feeling that while it is a nice touch to have the 5 Ss from 5S matched up with English words starting with ‘s’ (which definitely helps with memorizing them), there is a very high risk of semantic-diffusion through this.

There is a qualitative difference between organizing things and sorting them. Just like straightening things out is not the same as being orderly. And so forth.

In business process design, design thinking and software development we have a couple of approaches that are completely in line with the 5S approach – but it is hard to recognize that when the (English) S-words are used.

To take one thing from software development, “refactor mercilessly” is a way to keep the codebase organized and clean – keeping the codebase sorted and shiny doesn‘t make too much sense in that context.

There are more things – like naming things correctly, which not only fits in with cleanliness but also with orderliness and discipline. But the point I am trying to make is that the 5S approach provides much more applicable guidance when not taken literally by the s-words from the Wikipedia article, but instead by the older translations from Hirano et.al.

So how about giving the translations from Hirano‘s book a try for your next process improvement session? You do have process improvement sessions, don‘t you?

Till next time
  Michael Mahlberg

Sustain! The fifth S of the 5S

(Shitsuke, 躾, according to Wikipedia)

Whether you look at Hirano or the Wikipedia article on the 5S Approach, the last pillar or practice is the hardest Shitsuke, 躾 which the Wikipedia article translates as Sustain, while Hirano translates it as Discipline.

Let‘s once again have a look at the implementations that are listed in the Wikipedia article:

• To keep in working order
• Also translates to "meaning to do without being told"
• Perform regular audits

These factory related implementations seem to translate quite easily into practices that are also known from agile software development processes or the teachings of clean code development or pragmatic programming, but are they really?

To keep in working order for example can be nicely mapped to practices like continuous integration (the practice, not the tooling) or the "no broken window rule.
Performing regular audits is at the heart of almost every agile method – be it as a retrospective or as a operations review- (as long as you don‘t call it a post-mortem).

But in my opinion and experience this is only part of it. The hardest thing about this pillar is that it is about discipline. About cleaning up even if I already worked late. About sorting things even when there is time pressure. About removing the mess I created while working while the sun is shining and the waves are luring. Agreeing on standards even though everybody seems to do it "almost the same way".
About just really following through on the other four Ss.

And for me this is the most important yet hardest to master of the five "S".

Till next time
  Michael Mahlberg

Standardize! The fourth S of the 5S

Seiketsu, 清潔, according to Wikipedia

Other parts of this series

• Introduction to the “5S” philosophy
• The first ‘S’ – sort or organize
• The second ‘S’ – straighten or orderliness
• The third ‘S’ – shine or cleanliness
• this article

Standardize what?

Even though the Wikipedia-Entry refers to this practice as “Standardize!” I prefer – once again – Hirano‘s definition of this technique as “Standardized Cleanup” which makes it somewhat clearer, what the subject of the standardization is.

Wikipedia suggests things like the following for the workplace on the shop floor:

• Maintain high standards of housekeeping and workplace organization at all times
• Maintain cleanliness and orderliness
• Maintain everything in order and according to its standard.

Now, from my point of view, standardized cleanup blends in perfectly with the XP-practice of ubiquitous automation and the current state of software development tools, where it is quite easily possible to actually define standards in such a way, that the compliance with those standards can be enforced or even maintained automatically.

On a coding level there are numerous things to be standardized

• coding conventions
• checkin comments
• build procedures
• key-bindings (especially if you're doing pair-programming with changing pairs)
• Concepts to adhere to (e.g. SOLID and things like that)
• Line-Endings ... (even though that may seem trivial)

And a lot of those standards could be validated by means of the development tools and the source-code management tool (e.g. git-hooks or the hook-mechanisms available in other source code management systems.

But there is also a lot of things you could standardize on other levels...

• User Story formats
• Requirements descriptions
• The quality of acceptance criteria

What else would you standardize?

Till next time
  Michael Mahlberg