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?

Comments

[Pete Abilla]

Hey Guys,

Great post. Here is something you might be interested in: I interviewed Mary Poppendieck last year and allowed my site visitors to present questions to her -- great questions and equally great answers from Mary on Lean for Software:

http://www.shmula.com/183/12-questions-with-mary-poppendieck

[JM SANCHEZ]

That coders that you believe they believe they are artist normally align very well having a good technical explanation of why doing things in some way will be convenient for the team or organization, and most of the times that creative people is the first that understands it. In my experience the problem is when the "manager" have not a technical background (and i mean technical, not necessarily "programming background") that enables him to lead the group. In my opinion, if the reason to try TSP is "tell me if there is another way", then it will never make sense, and maybe the managers first must understand why they are not able to give a better explanation.
See you