Lean 'Standard Work' Applied to Software Development

Posted by Chris Sims on Apr 20, 2009

Sections

Process & Practices

Topics

Agile Techniques ,

Agile

Tags

Lean ,

Toyota Production System

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.

1. Back to top

   Standardized work

   by McGee Steve

   In the example of the woman fitting nozzles on hoses, the standard she was directed toward could be changed by the worker herself, via the improvement suggestion section.
   
   In this way, the standard is set by the workers themselves, with 'market approval' providing feedback. In a factory production setting, the market is the next person to use the output, the supervisor responsible for quality, the manager evaluating productivity, etc. The demands of the people around an individual worker will shape the decision-making and innovation they apply towards developing the ultimate standard of work - that they have the resources and capabilities to produce.
   
   So, I think this scenario is really close to what we see in Agile. Developers have their 'customers' who create the environment for them to establish their standards for work. For example, aren't story points standardized? Not across teams, but that is not the issue. Variance in points is discouraged, and quickly discovered through the standardized metrics process. Teams have coding standards, the definition of done (as said before) is agreed on, the language used is chosen, etc.
   
   I think the thinking behind the idea that software development can't have standardized practices / components is coming from an acknowledgment that the process of development includes a lot of discovery. So is poetry, but even this involves standardized letters, words and (usually) spelling and grammar.
   
   More important, which Robert Thompson's quote seems to point out, is the difference between who sets the standard.
   
   One of the more powerful parts of agile methods like Scrum is that the responsibility to make decisions tends to be in the hands of those who are accountable for them - as well as who have the capabilities to make them - more often.

   Reply

• Older >