Kanban the Framework
Project management is key to launching successful software on time and within budget. Agile methods of managing projects are the most popular with small to midsize teams. There are various frameworks that build onto the agile manifesto to allow for streamline approaches to managing resources. This article discusses the Kanban framework and its implementation.
- Subjects: Project Management and Software Development
- Objective: Example: The purpose of this post is to discuss the origin, principals, and implementation of the agile framework Kanban.
The inspiration for Kanban, the framework, comes from the Toyota Production System, which is a lean manufacturing methodology. In the 1940s, Toyota was looking to reduce manufacturing costs by eliminating waste in inventory management. Their problem was that having excess materials on hand did not translate into more products being shipped. Storing this inventory required storage space, inventory systems, staff to manage it, and a larger upfront cost to purchase these materials. To solve this problem, Toyota implemented a just-in-time inventory solution where materials were delivered to the location they were consumed just before they were needed. To communicate information about inventory through the supply chain employees would record what was needed on cards known as “Kanban”
In 2010 David Anderson published the book Kanban. Anderson developed what he called the “Drum Buffer Rope” method after years of trying to implement agile methods in an enterprise where employee stress and work/life balance were becoming problems. This would eventually evolve into Kanban. In his book, Anderson lays out the principles and policies required for a functional Kanban system.
Kanban has just three defining principles. The first is “Start with what you know”. It does not take any preparation to begin following the Kanban framework. You can begin just by doing what you are doing right now. Kanban has built in flexibility by not laying out requirements for processes or workflows. This makes it adaptable to almost any development environment.
Second, “pursue incremental, evolutionary change”, this is for any of the processes or workflows that are part of your pipeline. Requirements, staff, and technologies change overtime and the process that connects these pieces will become inefficient if it does not evolve with them.
Third, and this goes along with “starting with what you know”, respect the current “process, roles, responsibilities and titles”. These things were put there for a reason. Kanban is meant to sit on top of the current process and evolve it as needed.
Kanban can be defined by five properties. The last one here, identifying improvement opportunities, is important in keeping with the defining principles. All the preceding properties are there to help to make those opportunities more obvious.
In his book, Anderson talks about his “Recipe” for success in which he lays out a series of steps that generally build on one another.
Quality here is defined as being free of errors or “bugs”. This step is first because it is one of the simplest to fix and is a technical problem. Some of the easiest ways to improve quality is by implementing processes such as testing, code reviews, design patterns and reducing the amount of design work happening at any one time. The time and trust that is lost by delivering buggy code can be summed up by this quote from Anderson
This is probably the most fundamental process in Kanban. Anderson states, there is a causal relationship between the amount of work in progress and the average lead time, which is the amount of time it takes for a work item to go from in progress to completed. This relationship is known as Little’s Law and comes from queue theory. Basically, it shows that putting more items into the “in progress” queue does not make the work delivery rate any faster but, in practice, causes the work being done to lose efficiency and causes more errors. This is likely due the developer having to divide their attention among work items and losing productivity by going back and forth between tasks.
Furthermore, limiting the number of items in a workflow has the positive effect of freeing up developers who are always “busy” due to work being pushed at them. This allows you to see where true bottlenecks occur. If there is reduced work but a certain process is holding up work further down the line or is always overburdened, then you have just identified an opportunity for incremental improvement.
Also, by reducing the amount of work allowed to be “In progress” you are creating an environment where developers are not picking up tasks and getting them near completion before moving on to the next task. This encourages a culture of “done” where tasks are moved from beginning to end without the starting and stopping. Which leads to our next step.
Short lead times create more frequent deliveries, which in turn means more communication with the customer. These build trust between the customer and the development team.
Discussions about taking new work can only happen if previous work has been completed. This creates a pull methodology, where the developer will reach out to accept new tasks as they complete previous work. Unlike pushing tasks through the process where they can pile up on a developer’s queue before they are ready. Balancing demand also removes work tasks that are just sitting idle exposing where true bottlenecks occur.
Balancing the demand creates space giving developers time to focus on things like cleaning up their environment, improving their tools and their skills thereby improving the team.
The goal here is to increase business value through prioritization. The customers are the ones who determine priority. By building trust between the stakeholders and developers, management can begin to work with the stakeholders to maximize the value delivered. Priority is pointless unless you can offer a stable and predictable delivery schedule. It is best to focus on this after gaining consistency in the previous steps.
Variability reduces predictability, which then compromises priorities. By the time you have reached this point in the recipe, sources of variability are likely to require organizational changes to fix. Thus, this should only be attempted once the organization is more mature.
Kanban boards are one of the primary tools used in the framework to visualize the workflow. The idea is to openly communicate information about the workflow, process, and individual tasks. The board must be accessible to all members of the team and all members should be capable of pulling cards and moving them through the workflow. Physical boards are normally stored in a team’s common area, but as more and more development teams are working from remote locations, boards have shifted to the virtual realm. Virtual boards do offer more features such as task history and the ability to quickly adjust the columns of the board.
Kanban boards can be as simple as the one seen here or contain many specialized areas where specific processes take place. Kanban boards only need three phases. A place to hold a “To Do” list, a place to hold work in progress, and a place to put completed tasks.
Here is a more complex Kanban board. Here we can see sections for tasks on hold as well a place for tasks that require answers. The tasks in this board even have images of graphs and charts attached to help pass along information.
This is a Kanban board, but does it implement the framework Kanban? No, this Kanban board does not represent Kanban the framework. Could you see what was missing? There are NO limits for work in progress.
Here is a Kanban board that displays the properties of the Kanban framework. Keeping the properties of the framework in mind, we would expect to see five components in a Kanban board.
These are cards, sticky notes, or anything else you can use to stick to a board. These are used to communicate the requirements of the task. This could be a user story, or a checklist, or possibly just a simple outcome.
Each column represents a process in the workflow. Columns can be simple or complex. Here we can see that they have a column for “backlog”, a prioritized “to-do” list, and so on.
These are the maximum number of visual signals allowed for each column. When a column is maxed out it signals to the team to focus on that process to move things along. If that column is consistently having issues with being overburdened it has also exposed an area for improvement. Here we can see that the code review column has been highlighted because it is over its limit. This is an automated feature of this Kanban board. For physical boards, a process will need to be put in place for when this happens.
This is when an item is moved from the “backlog” or “to-do” column to the “in-progress” columns. This is the point in which the team is committed to doing the work.
This is the point at which the item is moved from the in-progress columns to the completed columns. The time between the commitment point and the delivery point is the lead time.
That is all for now. If you found this article useful, let us know in the comments. Want to learn more? Check out some of our other articles, such as our discussion on how to use Kanban Boards. We currently have two games on Google Play and at the Amazon Appstore for Android, check them out below.