Lean 'Standard Work' Applied to Software Development

One component of the Toyota Production System is the concept of standard (or standardized) work. A recent post on the Kanban Development list asked if this concept carries over when TPS and lean are applied to software projects. Despite the fact that software development is not manufacturing, respondents did find value in applying the 'standard work' concept to development.

Norman Bodek, in 'Standardized Work - Toyota's Powerful Improvement Process' described seeing standard work in action at Toyota this way:

I noticed a woman on the factory floor putting nozzles onto rubber hoses. In front of her was a [wooden sign] around one inch thick and two feet by two feet. [Affixed to] the wood were examples of the perfect finished piece of hose plus variations of hoses with errors. There were also the quality tolerances for her to check and [beside these] there was space for her to write both the problems she detected and also a place for her to write her suggestions on how to improve the process.

On the Kanban Development list, the original poster's position was that the notion of 'standard work' did not apply to software development.

For me, the breakthrough that Agile made, was acknowledging that software development was not a deterministic process and that there is no "standard work".

Alisson Vale's view was different. He sees standard work as "the way the team does the job today." Interpreting standard work in this way, some examples applicable to an agile software team might include:

• Holding a stand-up meeting every day at 9:00 AM
• Writing code using the red-green-refactor approach
• Using a checklist to verify that new stories are really done
• Pair Programming
• Ping Pong Pair Programming
• Using particular versions of tools and libraries

In 'The no-nonsense guide to standardized work', Robert Thompson explains:

Employees, not 'outsiders', study the jobs they know intimately in order to uncover best practices and create methodologies for continuous process improvement. Thus they become responsible for solving problems and own the standards that result.

Today's practices are the standard, the best way the team currently knows how to do the work. With the standard established, the team is encouraged to experiment and find ways to improve, resulting in an ever-evolving standard. The idea isn't to use the standard way as something to limit the team. Rather, the standard is to be used a baseline for continuous improvement.

Do you feel that this is an appropriate and useful interpretation of 'standard work'? Leave a comment and share your view.