One of the main features of Lean is the idea of "standard work". Lean
manufacturing is very prescriptive, and the TPS is build on "scripts" that
prescribe exactly how each job should be done. These scripts are arrived at by
performing "time and motion" studies and using the data to determine the "best"
way to perform each manufacturing step so as to eliminate "waste". This then
becomes the "standard work" which is written down and followed.

The TPS is big on standards. Where it differentiates itself from the traditional
western approach, is the belief that standards should always be in flux,
changing and improving.

Changes to standards are data driven. Building on the ideas of Deming and
statistical process control, "quality control limits" are strategically placed
at different stages of manufacture. Should the manufacturing system fall outside
the control limits then action is taken.

The detection of problems, I think is the Andon Corey mentioned. In a
manufacturing plant, this could be defective parts being produced. The detection
mechanism could be a machine that measures the parts as they are manufactured to
see whether they fall within given tolerances. If a part falls outside the
tolerance, then action is taken, which can mean stopping the line "Jidoka", so
that no more defective parts are made. The data collected is then analysed and
used to improve the "standard work" to ensure that the defect doesn't happen
again. This could mean running the machine more slowly, or changes in the
maintenance procedure. Either way the "standard work" is modified, and the
process monitored for improvement.

OK so what does this have to do with software? Well over the years a number of
analogies have been used to try and improve the software development process.
The Engineering analogy is what triggered off the idea of "Software
Engineering". A manufacturing analogy is often used too, and can readily be seen
in the work of the SEI and the CMMI and today with Lean Software Development. My
question is how useful are these analogies and how far should they be taken?

CMM Level 5, is a stage of software development process "maturity" where the the
"standard work" is sufficiently defined and sufficient "process metrics" exist
to allow the detection of "defects" in software manufacture. This "Optimized"
state is a pre-requisite to using quantitative data collected durng the
"manufacturing process" to continuously improve the "standard work".

What have we learned over the last 20 years? Is software pure Engineering? Is it
manufacture? Does the idea of "standard work" really apply?

For me, the break through that Agile made, was acknowledging that software
development was not a deterministic process and that there is no "standard
work". Instead the idea of software development as "creative collaborative
process" came to the fore. The acknowledgment of the role of creativity and
design skill can be readily be seen in the writings of Jim Highsmith and others.

Can creativity be "scripted"? Do fashion designers, playwrights etc follow a
script? Can process metrics be used to improve creativity and design skills?

For me these questions are central to how far Lean practices can be applied to
software. Perhaps we should be looking elsewhere? Fashion design follows a very
similar process to Agile software development. Someone comes up with an idea for
a new product. The idea is explored and elaborated using a story board, and the
new product is developed iteratively, gaining feedback from potential customers
along the way.

Can Andon be applied to Fashion Design? If not should it be applied to new
product development in general and Software in particular?

For manufacture, where each manufactured unit has a pre-determined "value", then
the main goal is to eliminate waste in an attempt to reduce costs and increase
margins. There is no exploration needed, no discovery and no creative design.
New Product Development however is very different.

Paul.