Adopting Agile (Lean Software Development - 4)

Brad Appleton, whom I mentioned in my last short post, also had this post linking to Agile Adoption as reported in the Agile Journal. This issue is talking about top-down agile adoption.

My own view is generally that the workers deliver to the customers, and the managers support the workers. So, in line with that, I think the best agile adoption comes with both bottom-up and top-down support. And both sides have to rigorously and compassionately face the truth and root out impediments.

Now, let me take something from the Poppendiecks, that to me puts agile adoption in perspective. This is step 1 in their 21 step program. (See the end of their new book.)

But having teased you, let me digress for a moment. I have had several conversations over the last few months where people would say something like "...but after all, this is not about agile, this is about getting the work done." And, depending upon the mood and meaning behind what they are saying, I am either nodding in agreement or shaking my head in amazement. If they understand agile and the value is brings, and their point is that agile is mainly about results and not about the perfection of the practices for their own sake, ok. But if they don't appreciate agile, and consider it little more than the flavor of the month, and just really want to go back to the old tired ways of working and delivering, I am discouraged. Agile is valuable because it helps delivers better business results.

After that seeming digression, what was step 1? Step 1 was "implement lean across an entire value stream and a complete product." Thus, before one considers software, one examines what the customers really want, in terms of some complete product or product set (product includes services), and what the full value stream is to deliver that. One uses lean techniques to identify how to improve that value delivery (more exactly what the customer wants, faster, cheaper, better quality).

Presumably improvements in the software will be identified as enablers to a "leaner" value stream. ("Leaner" meaning "better" in the most important ways rather than just the opposite of fat.) Even if the software is the product, bear in mind that creating that software is not the whole value stream. The problem to solve is to deliver to satisfy the need as soon as the need can reasonably be identified. Solving that problem is a lot more involved that just creating software.

If your firm is using Six Sigma or some other Business Process Reengineering approach to delivery, then connect Agile to that. (Exactly how is of course a potentially long discussion.)

Conclusions:
1. Start with a lean attitude toward value delivery to the end customer.
2. Place Agile in the context of helping to deliver business results for the end customer.

(Does my digression now make sense?)