Standard Work?

By: Chris Sims

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.

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".

At first blush, I agreed. However, after doing more research on the topic of 'standard work', I came to understand that today's practices are the 'standard'. This is 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. 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.

Read the article I wrote about this for InfoQ.

Cheers,

Chris

Comments

[Hillary]

I was just catching up on reading blogs and came across this remark by Jim Shore in a post on The Agile Startup: "...process improvement does not mean lots of bureaucracy, overhead, or expensive Certified anythings. It means doing your job better." Amen!

[Tobias Fors]

Hey Chris! Yes! Standard work should be about "our best best way right now, so far". For example: our team's standard for how builds are made, consisting of some manual work and lots of automation. No reason not to standardize it.

The challenge is that we tend to equate "standards" with "externally imposed requirements on how we should do our work". The opposite though, is very powerful: our own articulation of how we do some of the things we do.