Enhancing Your Agile Practice with Kanban

I often hear agile practice coaches and other agilists say that a team cannot begin using Kanban for agile software development until its agile practice is mature enough. They say the team’s estimation is not consistent enough, work has to be perfectly prioritized in a perfectly groomed backlog so teams know exactly what to pull, or that Kanban is not structured enough for teams that need the rigor of Scrum ceremonies.

Personally, I fundamentally disagree with these arguments. If one takes a hard look at the basic principles of Kanban, it should be obvious that Kanban is a natural starting point for any product development organization, mature or not, that is interested in the kind of incremental evolutionary change that leads to predictable and happy agile development teams.

What is Kanban?

But what is Kanban? When I was being trained on Lean Six Sigma at GE many years ago, we were told that Kanban was a Japanese word meaning ‘signal’ and in particular a signal in a pull-based work system. In Japanese, Kan means ‘card’ and Ban means ‘board’ so Kanban translated means ‘card-board’. These ‘card boards’ were initially used by shopkeepers in 17th century Japan to advertise their wares to potential customers.

In the mid-1950s in Japan, Taiichi Ono of Toyota Motor Company needed the means to ensure his factories did not overproduce. He observed how Piggly Wiggly supermarkets in the U.S. were able to keep just the right amount of inventory in their stores and bring in new inventory just in time when it was needed.

When customers in a store depleted an item on a shelf, it was a signal to bring more into inventory. Ono brought this signaling system back to Toyota using cards and called it Kanban. By leveraging this approach, Ono was able to ensure that Toyota inventories stayed low and alleviated much of the risk of overproduction.

The system improved flow through Toyota’s production system and kept stocks at optimal levels. Ono’s implementation of his Kanban system reduced waste throughout Toyota’s production system and optimized delivery of value to Toyota’s customers.

Kanban Finds Its Way into Agile Software Development

The creation of the Agile Manifesto and its underlying principles ushered in the era of the mainstreaming of agile software development approaches that were in stark contrast to existing waterfall approaches. In the agile practice, the principle of responding to change over following a plan meant requirements could be taken at the last minute. The agile principle of delivering working software frequently meant creating smaller batches of just-in-time value to customers.

This was a significant change for teams practicing waterfall software development that meant giant specs and long development times. Just-in-time delivery of small batches of value was not only very effective for agile software development teams but was also very similar to the concepts implemented in Toyota’s Kanban system and Piggly Wiggly’s supermarket inventory system. This sparked the interest in the Toyota Production System (TPS) by software development teams.

Emerging agile development frameworks like XP and Scrum embraced the Agile Manifesto ethos and used TPS-inspired Kanban boards to move work through the agile development process in small batches over short periods of time called sprints. In an effort to get working software out to customers sooner, agile software development teams began to embrace the concepts found in the TPS, and product development methodologists like David J. Anderson developed their own approaches to implementing Kanban for agile software development teams.

Today, when used for agile software development organizations, Kanban has come to mean a pull-based work system that seeks to optimize the flow of customer value by managing the volume of work in progress, while enabling teams to continuously improve. Utilizing Kanban optimizes value delivery while not overburdening teams, keeping morale high.

About the Kanban Method

The Kanban method was developed by David J. Anderson while he was at Microsoft and Corbis, and is discussed in depth in his book, Kanban: Successful Evolutionary Change for Your Technology Business. The book lays out a well-thought-out approach to implementing Kanban and is useful for anyone considering using Kanban in their organizations.

Anderson’s Kanban method leverages four principles and six practices to demonstrate how Kanban can be introduced to any team, at any time, and dispels the myth that Kanban is only for mature or unique teams. The four principles are explained below, and the six practices will be included in a future blog.

The Four Principles of the Kanban Method

1. Start with What You Do Now

Teams that want to introduce Kanban to their existing process can. Kanban need not be a culture shock. It is an incremental process to achieve predictability, responsiveness, high levels of quality, and productivity while working to eliminate waste.

A quick and simple way for a team to begin is to create a basic Kanban board that models the team’s existing process. Tools like Broadcom’s Rally Software can not only help teams stand up basic Kanban boards, but also support teams as they work to improve the alignment of daily work to business strategy.

2. Agree to Pursue Incremental, Evolutionary Change

Most organizations understand that they could benefit from a positive change to improve how they deliver value. The Kanban method offers a non-prescriptive approach for gentle change as it advocates for small, incremental, and evolutionary changes.

Teams should find times to retrospect on their process and introduce potential changes as experiments. If changes help delivery and quality while maintaining high team morale, teams may decide to permanently adopt those changes. However, if they don’t believe a change is beneficial to the team, they can end the experiment, discard the change and continue with their existing process.

3. Respect the Current Process, Roles, Responsibilities, and Titles

Companies need not worry about massive organizational upheaval when implementing Kanban. The Kanban method is first and foremost meant to start with what you do now.

If a team is contemplating a change to the required roles, the ideas and decisions can come as an outgrowth of the organization’s approach to slow evolutionary improvement. If a team is already using an agile framework, like Scrum, that suggests specific roles and behaviors, that’s ok - start there. The benefit of Kanban is that if one of your Scrum practices doesn’t necessarily work for you, you can always do an experiment to see if there is a better solution.

4. Encourage Acts of Leadership at All Levels

Leadership, when understood and executed correctly, is truly a baton that can be passed to anyone at any level of an organization. The people who are closest to the problems are often those in the best position to lead their teams and organizations to solve those problems. Therefore, fostering a culture that empowers anyone to lead the change to fix a problem is essential. Leadership at all levels leads to higher morale, a greater sense of ownership and engagement for all, and faster and more effective improvement initiatives.

Starting a team on their Kanban journey should be as easy as saying, “We’re going to do Kanban”, and then simply committing to the four principles explained above. The team doesn’t have to change its process. The team doesn’t have to alter its roles and titles. The team doesn’t have to be exceptionally mature.

They just have to commit to incremental improvement and allow leadership and change to come from all levels of the organization. There are certainly agile practices that can help with all this. We’ll take a deeper look at those in the next blog in this series.  

Visit the Rally Software pages on Broadcom's Enterprise Software Academy to learn more about how it can help you get started with Kanban.