I recently came across this McKinsey paper - Applying lean to application development and maintenance (subscription required). The abstract has a few key bullets:
- Lean techniques, originally developed to reduce waste in manufacturing, are boosting performance in more and more service environments.
- Application development and maintenance—the part of IT that works closely with the business to develop software services—is a good candidate for lean. Many processes around software development are poorly organized, resulting in rework, unbalanced workloads, and other forms of waste that harm both productivity and morale.
- The transformation to lean requires companies to identify and measure the main sources of waste and define opportunities to reduce it.
It was an interesting paper and, if you are responsible for an application development and/or maintenance process, there is some good advice about applying lean techniques. Labor is 80% of these areas, they say, and some organizations are way more efficient than others. Applying lean processes to hunt for and eliminate waste and inefficiency is recommended. It does seem to me that most application and development organizations would do well to consider themselves more of a manufacturing business (for all that there are some issues with that as an analogy - check out this proposal that a garden analogy "sucks less" and this one on why construction does not work). Regardless, lean can clearly make a difference. I think the authors miss a critical issue, however, in that they never really challenge the basic assumption that changes to systems require programmers. Do they? I think not. Not that everyone wants to be a programmer, but there are other ways to solve this problem.
- The authors talk about quality ownership needing to extend to the business and of the inefficiency of developers going back to the business for clarification of maintenance requests and requirements. Why not learn to love change and find the secret of business user engagement in maintaining their own applications?
- They identify "rework" as waste when that rework is caused by changing requirements. But the problem is not changing requirements but changing business rules and writing better requirements is a false hope because rules are not requirements (something all CIOs need to know). You must learn to love change.
- Their list of software development productivity methods only included process improvement, metrics and CASE. What about agile methods with their focus on immediate need and regular releases, especially when you use agile methods and business rules together.
- Maintenance backlogs are a problem, both inherently and because they distort the application development process. Why not use business rules to write maintainable code and avoid write-only code and give a mainframe application a new brain while eliminating thousands of hours of maintenance work in the process?
The core to all this is to find the decisions made in your applications and automate them explicitly as decision services (there's more here on decision services) while brining business users into the process so they can collaborate on developing new and changed solutions. Lean processes will help, but you need to revisit the basic assumption that writing code is going to work for you here. There's more on lean at www.lean.org or here (no editorial comment from me, these are just links I found).