Lean Software Science

Yesterday we told you about a new blog, Lean Software Engineering.  Those of us that have lead groups that included software engineers know that software project management can be a challenge, to say the least. 

Many coders believe they’re artists, and therefore exempt from schedules and deadlines… and especially the systems and methods that create effective project management.  To some extent they really are artists, as an ingeniously well-written piece of logic really has beauty.  But on the other hand toolmakers, molding techs, design engineers, and even some sales guys also use that perspective to think of themselves as artists.  Supposedly their worlds are too fluid, too incongruous, too undefined to be governed by scientific method.  Hogwash.

The rise of high-quality overseas tool shops have made even class A tools a commodity, DOE and six sigma has taken the art out of molding, design methodologies are driven by defined customer and technology constraints, and sales is becoming a psychological science with qantitative metrics and goals.  Creativity and ingenuity are still critical components of success, but so are defined processes and methods.

So is the world of software development.  Jon Miller over at Gemba Panta Rei touched on this just yesterday, describing how the Toyota Production System can be applied to that specialty. 

Another gem was how they overcame the resistance to applying TPS to software development. People asked, "Why the Toyota?" and the kaizen instructors would ask "If there is another way, please tell us. It is easy to deny another person’s idea. If you are going to deny it, you must present a different idea." At least with regards to improving the software development process, nobody had any better ideas for how to improve, so they agreed to try TPS.

Last February we also discussed how lean manufacturing methods can be applied to software development. 

A hat tip to Curious Cat for finding a one hour video presentation titled Competing on the Basis of Speed that was given to a group of software developers at Google.  Mary Poppendieck, who learned about lean while an IT manager at an unknown lean plant, describes how lean manufacturing methods can be applied to software development.  In an interesting twist, some of the software examples she gives can also help us apply lean to manufacturing.

Mary and Tom Poppendieck have authored a couple of great books on the subject, most recently Implementing Lean Software Development: From Concept to Cash.  In the online video presentation referenced above they discuss some of the ways lean can be applied to software.

Simplicity: write less code, use less complex interfaces.  The Google home page is simple.  Common architecture, common naming conventions, common development tools.

Inconsistency: defect detection, mistake proofing, and how quality processes create quality products.  If you are testing at the end, then you are testing too late.  One piece flow is the rapid deployment of small feature sets into code development and production.

Overload: cycle time is time from problem detection to problem solution.  Value stream mapping of software development and problem solving.  It makes no sense to have a long queue in the development and deployment process.  Shut off development to balance the process.  Limit work to available capacity.

Do you still let your coders live in a sea of unaccountable cubicles?  Or are you truly leading them by demonstrating the advantages… to them and their customers… of lean methods?