There is an urban legend about a Lean deployment which, in the process of applying the 5S to a workshop, drew lines on the desk to indicate where each worker should keep their banana.

5S, for the uninitiated, is a set of principles by which Lean practitioners organize a workspace – which might apply to a virtual, shared workspace, or Sharepoint repository just as well as a back office space or factory floor.

• Sort – identify and get rid of unnecessary items
• Set in order – organize what’s left so that everything has a logical place – including deciding on the optimum spot for banana placement
• Shine – tidy up and clean your new workspace
• Standardize – document and put boundaries around your newly organized workspace so that it’s obvious where everything should go – including drawing a line around that banana
• Sustain – establish systems, tasks and behaviors to ensure your work place remains neat, organized and free from clutter

These are great principles to apply to any shared workspace – and standardization will speed your adoption of DevOps principles. Standardizing the way we organize information allows for fungibility, so a Quality Manager can switch teams at short notice and quickly pick up the way their new team works, and access the information they need. Standardizing storage in a way is the principle behind Docker, and other modular code concepts. Standardization can reduce errors: if user requirements are captured in a consistent way it is easier to see at a glance if any essentially information is missing before we start work. And standardization ensures consistency, for example, applying a pre-determined decision tree and criteria to enhancement requests will allow prioritization decisions to be made quickly and equitably.

But you can have too much of a good thing, Creative activities and problem solving tasks are often intuitive or require people to take a variety of approaches until they find one that fits. A checklist just may not help here. Furthermore, one of the aims of DevOps is to increase flexibility and speed to market. So if your standard start to get in the way of that, you’ve lost your way.

As a Lean Coach I have struggled with the amount of churn I see in requirements during the development lifecycle: at first glance it reads like rework. But it is, in fact, a healthy feature of an iterative, responsive process. Many IT departments have sought to manage churn by trying to standardize it out – setting deadlines for new intakes, and arduous change control procedures. As soon as you layer governance on top of a process, you create a need for a shortcut, and an expedited route.

I recently ran a Lean workshop for an IT team during which we identified that 30% of change requests were going through an ’emergency’ process.  Clearly the standard process wasn’t working.

DevOps requires standardization on an ‘as needed’ basis. This includes a standard way to handle rapid change, and variation. That standard approach must be light touch governance: make the right way the easiest way. And I’ll stick my neck out and say that standardizing where a worker keeps their snack is a step too far.