Can Lean Explain Agile?
My discussion with agile software development project managers led to some great insights into overcoming barriers to agile transformation. I started by surmising that a company who had done lean manufacturing would be more likely to pursue agile software development. When asked why, I gave the example of “quality at the source” and compared it to the agile approach of test driven development (TDD).
Both approaches assess results closer to the creation (manufacture) of code (product). In manufacturing, the lean approach gives the operator power to assess quality and stop the entire process until the quality glitch is fixed. I grabbed my throwaway plastic cup with a vertical seam as an example. If the quality check is at the end of the cup making process, many thousands of bad cups may have been made before a bad seam process is detected. If the operator notices the seam opening and then stops the process, only a few bad cups will have been produced. Pretty basic stuff, but people, particularly cost accountants, will fight you on this approach.
The project managers emphasized that waiting to test code until the end of the development process yields similar results as quality checks at the end of the manufacturing process- a lot of code has been written and documented that may not work. Testing, or quality checking, at the source of the code, by the creator, catches problems earlier and reduces waste in the form of massive reworking or even throwing away code.
Lean manufacturing executives understand this and many other lean concepts that can be easily compared to the “manufacturing” of software code. Neither lean nor agile are intuitive. Having overcome the intuition barrier with lean, a lean executive is much more likely to embrace agile.
Tell me your successes/failures at using the lean/agile comparison. Do you think that an executive experienced in agile software development could be more easily convinced to embrace lean manufacturing?
Don’t miss a post! Subscribe by RSS or EMAIL.
Test Driven Development is more of paradigm shift for the developer than for the management, as the concept of “Fail, Inspect, Adjust, Acquire Goal” is easy enough concept in English to understand.
The hurdle for developers is to give up the idea that their spark of inspiration is what should be pursued; rather, you are forced to write your program code as a solution that answers a series of tests. These tests validate that “no book order to a customer of 3 years shall ship without a discount of 15%” rule is indeed implemented in by the program code. The idea is write no more code than is required to pass the test.
Here is a link to an Part 1 of a series that I am developing on Test Driven Development:
http://activeengine.wordpress.com/2007/11/16/drive-by-specficiations-part-1/
Thank you for being a frequent commentor- I learn a lot from these communications. Given my experience is with lean, I’m curious as to methods to convince management that agile is the way to go. In particular, what experiences can you share on convincing non-IT management to engage in the collaboration required? or is the impact to non-IT not as big as I think?
Collaboration is so key. I have always positioned it as “Your opportunity to validate early on that the project is on track”. As you might expect, different departments will react differently to iterative cycles. One boost is that the accounting and finance types will like the tight cycles, or challenge and response as I call it, of spec creating and spec validation. 1 – 2 hours spent with spreadsheets laying out expected results and a follow up meeting with actual results really instill confidence that the product is on target.
So, it sounds like the IT management paradigm shift is the key. Does this mean that other department executives don’t need to know about the transformation? Do they normally learn about it from the bottom up? Lean is very much a top down and bottom up process because it does transform how a company manages, solicits information, and does work; and the changes, without an understanding of lean, are easily viewed by execs as upsetting the norm and distractions to the “real work”. Agile, once accepted by IT, appears to simply give users what they want.