Why Lean-Kanban?

Software development across an enterprise involves more than efficiently managing a collection of teams. It requires managing a vision across the organization, prioritizing work to realize that vision, and creating contexts and methods that let teams thrive and deliver value. This article describes Net Objectives' own journey and why we feel Lean and Kanban, taken together, make for effective software development at the enterprise.

Net Objectives has been in the business of helping transform software development organizations for over 12 years. We started with technical practices: design patterns, refactoring, test-driven development, and so on. From there, we expanded to process and management practices: starting with Scrum, then Lean, and most recently adding Kanban. Along the way we broadened our offerings to include practices that span technical and process, such as acceptance test-driven development and emergent design. We expanded to support more of the value stream such as product portfolio management and business consulting. Why do we keep expanding our offerings? Because we have found it is not enough to fix individual pieces of the development process. Like "whack-a-mole," fixing one piece at a time merely raises up another problem somewhere else. And the common approach – starting out by introducing Agile practices to a team – yields even more uneven results. You may truly help the team to improve; but if the team is not what was impeding software development, you have not significantly helped. No, it requires a holistic approach in order to create effective IT and product development. Technical, process, management, value stream, portfolio, ...

This is not a simple task. It has been over a decade of learning for us.

As development organizations get larger – 50 or more people – there is a desire to find an overall method that will work for every team. Consistency, it is hoped, will help teams collaborate more effectively. It rarely works that way. The truth is that teams work in different contexts. They face different challenges technically and with customers. They are comprised of different people. They have had different experiences. Uniformity is just not possible: there will always be some differences. At the same time, "every team gets to choose for themselves" is also not desirable. Collaboration would certainly not happen as effectively as required.

Scrum offered a middle path between the two. And it has indeed proven to be extremely successful in many organizations for many teams. And yet, as good as it was at the team level, it has rarely scaled throughout the organization. Where it has scaled well, it required an external force such as a CEO mandate.

The heart of the problem lies in resolving the dilemma of integrating a customer focus at the team level with the business / management focus required for large scale adoption of agile methods. Focusing only on a team and giving them power to delight customers is good but may result in a loss of business focus. A management focus on only business value, however, may leave teams disempowered, weakening their ability to innovate. Somehow we need to create a context within which empowered teams can thrive in their own context while also working on those aspects of IT or product development that provide the most value to the business. As good as it is, Scrum and other team-based approaches are insufficient. Agility at the business level involves different approaches than agility at the team level.

Here is what we have learned. Lean thinking provides the necessary mindset to "see globally but act locally." It provides a global perspective that helps the organization take local actions that optimize the whole. By creating a global perspective, it helps provide clarity on which projects that add the biggest value to the business. Kanban then equips teams to self-organize in order to manifest that value. And this is why we added Kanban to the mix.

But Kanban is more than a tool at the team level. A cornerstone of Lean is "respecting people." This goes beyond the common view to "let people figure out how they must work." In Lean, respecting people means to respect how they react to change, how they work in groups, how groups of people interact, and how people learn best. Kanban was specifically designed to include all of these aspects of respecting people. Kanban is an integration of how people behave with how the work is done. Using Lean principles, it lets organizations start where they are, lets teams adapt and improve through fact-based incremental steps, gives tools to even out the flow of work, and gives the business the means to prioritize work based on value.

The combination of Lean, Kanban, and agile and technical practices, offers a cohesive set of perspectives that are consistent with each other and work at all levels of the organization. It gives the organization enough practices and principles to guide their work while avoiding a prescriptive approach that may or may not work (on the one hand) or having to figure it all out for themselves (on the other).

It has worked successfully at all sizes of organizations. And putting them together has been a journey of discovery.