Aside from lean’s emphasis on reducing waste, it also addresses the idea of “What is the value in what I am doing?” which is something agile did not, some experts say. Software Development SD Times, January 2011, “The Year In Review – Agile Development” page 64, Katie Serignese.

This reminded me of the “great breakthrough” in the 90s. Total Quality Management was all the rage, at least in government, and was to solve all our efficiency and productivity challenges. The problem was that we never knew where to start or what to work on first. This was the source of many arguments and many stops and starts in improvement projects, usually as management rotated in and out of a struggling organization.

The “great breakthrough” was, for software, this notion of a “Capability Maturity Model” (CMM). This guy, Watts Humphrey, had the temerity to tell us what it is we should focus on first when trying to improve our software quality and productivity. He had the gall to summarize in a ladder-like structure what he currently saw as the best practices, assuming we were ready for them, in software management. The biggest shock was the notion that tools (Integrated Computer Aided Software Environments were big at that time) were not the solution to all our productivity and quality issues. We first had to do smart management before we thought about tools to support them. Brilliant.

I was the Air Force’s resident affiliate at the Software Engineering Institute (SEI) at that time and became the default “expert” to many Air Force units on how to improve their software management. I noticed that I was often saying the same thing to everyone: 1) use the SEI CMM for direction on what to work on first, and 2) use TQM as the method to manage and measure the improvement effort. This provided both the “what” to work on and the “how” to go about implementing the changes.

Katie’s comment about lean and agile struck a déjà vu chord in me on this “what” and “how.” We often have a fancy new approach (Agile, Lean, Scrum, TPS, Kanban, etc.) but not always a notion of what to apply it to. While most improvement techniques (e.g., Six Sigma, etc.) give us a method to find and prioritize (based upon business value) what we should work on first, this still often seems like we are recreating the wheel. Doesn’t anyone have a notion of what the best practices are so we can just work towards them?

For software, Watts supplied the answer in the form of his Capability Maturity Model. In his book, Watts said that while not everyone may agree with his maturity levels, anyone looking to implement improvements should look towards building a similarly laddered approach. Otherwise, they risk trying to make changes that would fail due to a lack of being ready for those new tools and techniques. Having watched the Air Force throw tool after tool at the “software problem” with no noticeable improvements in quality or on-time delivery, it suggested to me that Watts was on to something.

Three things to regularly ask ourselves:
1. Do we know what are the current best practices (but not fads) that we should be doing now?
2. Do we know how to go about making the changes so that we are measurably doing these practices?
3. Are we currently making progress on projects implementing these practices?

Doing the right things in the right order can make a huge difference when compared to just doing a lot of things real fast. 

See related, Project Management Choose Quality Or Speed?

Do you feel you are working on the right things in the right order with the right projects?