Using Lean-Agile to Provide the Real Value of ALM

• a problem may occur well before where the problem is observed
• attend to time, not productivity (see my blog Learning to Manage What Matters – Not Always Intuitive )
• eliminating delays between steps improves productivity and quality
• conversely, delays between steps actually causes more work to be done
• higher quality can be achieved by doing the right thing at the right time with the right people without adding to the amount of work to be done
• close knit teams do not work in the same way as individuals from different teams trying to work together
• managing how much work you have at any one step can achieve great results in quality and cost
• the amount of work given to a development group can affect their efficiency more than anything else
• the system that teams work in (e.g., are they co-located, do they have easy access to others they need) has a significant impact on them – often stifling their abilities and skills

This article is about using Lean principles, attitudes and mindsets to discover where your challenges are, and what you need to attend to solve them. It is about integrating the different steps in your methods so that all of those involved can keep their eye on the goal – value achieved by the customer. The times of easy improvements achieved by teams that embraced Agile and focused on delivering value iteratively are over. As Agile has crossed the chasm, these easy situations have most likely been encountered and solved. As we’ve jumped across the chasm, we have found situations where the standard team-based agile methods do not work nearly as well or at all. The Agile community’s focus on team-based Agile methods has been met with frustration by many and is creating a backlash against Agile in general. It is important that we not ascribe flaws to these later adopters and casually explain away their challenges. We must realize that methods that have worked in certain situations just do not work in others. 

Using Lean to Guide Agile Adoption
What we need is a way to be agile that attends to the entire organization. How do we do this? I believe the Lean insights I provided earlier, which I often call “Lean-Science” provides significant guidance. Lean, fortunately, provides us with much more than this. Lean goes beyond merely suggesting we attend to certain ‘laws’ of development. It also suggests ways people best learn. When transitioning people to new methods, most of us have observed pushing people too far can have an adverse effect. It’s not just that people stop improving, they actually get worse in many ways. Lean suggests a model of continuous improvement – of taking small learning steps to both learn better and keep the emotional aspect of change as a positive force.

Lean thus broadens our horizons in another way – that of suggesting we control the transition to new methods. Lean suggests we start where we are and respect the way people are currently working. We want to establish a method of continuous improvement – not just dramatically change our process and hope the team moves forward. This is a great difference between Kanban and Scrum at the team level. Scrum suggests throwing people into a new structure and organization that we know works. We assign new roles (ScrumMaster and Product Owner), we provide new work methods and timeframes. This dramatic jump often works. But in larger organizations, it seems to throw many people into chaos and fear – conditions not conducive to learning.

Kanban suggests a better learning approach is one of continuous