Fine Tuning the Use of Lean to Sell Agile

Here is a slightly edited conversation with ActiveEngine following his response to my post on using lean experience to justify agile software development. It may be that non-IT executives don’t need to know about agile processes- just that the IT department is doing a lot more collaborating, testing and verifying throughout the software development process than they used to. I’ve found that lean is clearly different in this regard- i.e., proof of lean process success plus understanding the process is necessary for most executives in a company pursuing lean. Here’s the discussion:

ActiveEngine: 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/

PM411: 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?

ActiveEngine: 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.

PM411: 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.

Add to the conversation. What has been your experience with groundbreaking paradigm shifts? How important is the support for the shifts from executives from different functional areas?

Don’t miss a post. Subscribe by RSS or EMAIL.