5S Kaizen in Software Engineering: Part IV Seiketsu

The fourth of the 5 Ss is Seiketsu, or to Standardise. This is essentially the way in which Seiri, Seiton and Seiso are rolled out across a workplace. With Seiketsu and tomorrow's topic, Shitsuke (or Sustain), the major differences between traditional engineering practices and software engineering begin to fade, as the nature of the processes are not the focus of attention here, rather how those processes are maintained and improved.

Standardisation in software engineering is a common concept, but it must embody all aspects of the practice (physical and software resources, personal and shared) as I have been suggesting over the last three days:

1. Standardise the physical workplace where possible: maybe promote a standard cube layout; provide the same set of texts at multiple sites; develop an equipment standard for PCs; create minimum test equipment requirements for new hardware integration projects.
2. Standardise software development where possible: most importantly, coding standards and best practices; create commenting/documentation standards and automated tools; create source code organisation and dependency management policies; provide a patterns policy guidance (perhaps big posters, coaching); suggest a standardised set of developer resources such as code editors.
3. Standardise our project management methods where possible: suggest a range standardised methods for costing and tracking projects; educate engineers in the proposed techniques; create template project documents (perhaps a “skeleton project”).

Tomorrow's topic, as mentioned above is Shitsuke, or Sustain. Once we've looked at that, I'll try and sum up and pick out some areas that are the most ripe for learning from Kaizen 5S.