Using Lean-Agile to Provide the Real Value of ALM


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 process improvement. To do this requires two things. First, the policies of the team must be explicitly stated. Explicit policies merely means how the team works is explicitly discussed by the team and expressed to management. It does not mean writing them down or making them hard to change. The point of explicit policies is so that we can see 1) that we are doing what we say we think is the best way, and 2) if what we are doing is working.

These beliefs manifest themselves in Kanban development by having a Kanban board that reflects the process the team has been explicitly discussing amongst themselves while also making management (leadership) aware of how the team is working. People don’t follow the board, rather the board reflects the team’s explicitly stated best way of doing their work—in a sense, the board follows the team. This enables the team to try different things and see if these new ideas work.

A team starts Kanban by observing how they are currently working and then decides how they believe their work might be improved. While many people think Kanban is mostly about limiting work in progress (WIP) or doing Lean-Flow it is really about providing this transition management system. That is, it provides companies a method of managing the change in their organization to give an alternative to just abandoning their current methods and hoping for the best. It also enables us to start where we are. We don’t need to work on just one team and possibly adversely affect others. I believe this is a useful transition method in most places. However, it is absolutely essential where the creation of teams due to highly specialized people prevents effective team building across the development organization.

Lean therefore provides a more holistic approach in two dimensions. First, Lean suggests optimizing the whole—that is, looking at the entire process from idea initialization through consumption by the customer. The second one provides us with a method of managing how we introduce improvements and attending to the rate of change that is optimal for the organization making the transition. 

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.