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.
Transitioning to Agile With Lean to Guide Us
Thus, Lean arms us with:
- A foundation of respecting people
- A scope of looking at the entire system
- An awareness that we must attend to the emotional and learning aspects of a transition to Agile methods
- A focus on time
We can combine these principles and insights of Lean to give us a roadmap for our Lean-Agile transition. Like any roadmap, we need to know:
- where we are
- where we want to go
- what our means are to get there
- what our suggested path is
Let’s see how Lean provides us with insights on each of these.
Where we are
In Net Objectives’ experience in transforming medium (300-500) and large (1000+) development groups to Lean-Agile, we have seen the following major challenges facing an organization:
- Business stakeholders not having clarity on what will add the greatest value to the customers of the development organization understanding
- Teams not knowing how to coordinate with each other
- Too many projects being dumped on the teams
- Teams not knowing how to deliver value incrementally
- Not being able to create well-formed teams across the organization
The prevalent assumption that the teams’ development methods are mostly always the primary problem is not founded in our experience. Lean’s analysis of the value stream helps you learn where to start, because it’ll tell you where you are.
Where we want to go
There are several challenges in transitioning an organization. First, everyone needs