Kanban Board

Recently there has been a lot of talk about Kanban and Kanban boards. Several vendors offer software solutions based on Kanban principle. Not only software engineering teams use Kanban, other disciplines have started using Kanban boards too. Kanban which means billboard in Japanese was developed by engineers at Toyota motors in 1950’s as a scheduling system for just in time manufacturing. Tahiichi Ohno an industrial engineer working for Toyota at the time developed this method to streamline manufacturing process and improve efficiency by developing a process for just in time manufacturing. Amazingly the origins of Kanban could be traced back to supermarket operations. Mr. Ohno noticed that in the supermarkets, store clerks reorder an item only when it is low in stock. He developed a visual system based on boards and cards, such that manufacturing teams can better communicate and move work forward. Manufacturing workers at Toyota used the cards to signal the status of each step in manufacturing process. This form of visual communication was great help in removing bottlenecks from manufacturing and identifying issues as soon as they occurred.

In 2005 a group of software scientists formed a group to apply Kanban process to the field of software engineering. The group was lead by Jim Benson, David J. Anderson, Corey Ladas and many more. Their work resulted in a new software approach aptly called agile process to speed up software development. In recent years diverse group of disciplines like marketing operations, construction, PR agencies and hardware developers have adapted Agile method.

This eBook is written to help a new user in Agile and Kanban to gain basic understanding of the core concepts quickly. It covers all aspects of Kanban process in some depth. For the reader who is interested in gaining more insight about Kanban process, many great books are available. I highly recommend several great books by David J. Anderson on Agile, Lean and Kanban process.

Kanban is a visual tool for development process. The reason for this is simple. Our brains are visual data processors; the visual information is processed and understood by us much faster than textual information. The focus of this eBook is Kanban process as used by software engineering teams and similar disciplines. There are many books on how Kanban could be used for manufacturing process which the reader can easily find in bookstores or online.

Kanban is adaptable with any project management methodology you are using or plan to use. It is not just for agile project management method. In fact if you use waterfall or any traditional project management methods you can easily adapt and use Kanban for your projects. Another advantage of Kanban is that it eases the path from traditional methods to agile. A new project management methodology called Hybrid project management method uses Kanban and work breakdown structure to utilize benefits of both approaches for optimum project delivery results. In short Kanban is not a project management methodology like agile or waterfall but a tool to visual the process of development more clearly.

Kanban core principles as applied to software engineering and similar disciplines are listed below:

In the following pages we go over each principles and discuss how to use Kanban for software development, hardware development, digital marketing, and human resources as needed.

Step one in understanding and utilizing Kanban is to visualize your current workflow. Start with how your current development and product delivery works. Document every step needed to go from concept to delivery. This understanding is crucial in successful adaption of Kanban by your team. Remember Kanban is an evolutionary process and unlike Scrum does not require a total change from what you have been doing in the past. In fact Kanban could be used by established methodologies like Agile and WBS. Kanban is all about continuously improving the life cycle of your development process. This continuous improvement is called Kaizen in Japanese. Many principles found in the lean development and manufacturing are used in Kanban.

As the first step, try to map the entire product delivery process you use today. A simple way of doing so is by using value stream maps or VSM. With advent of agile and Knowledge Work a new visualization method called Knowledge Creation Network (KCN) is invented. This method is better fitted for nonlinear creative work like software development, electronic design and digital marketing. Try to visualize every step that needed to bring a product from concept to release. Don’t leave any step out but at the same time keep the number of stages in check so not to overwhelm the map and discourage the team to try. For this tutorial we use simple VSM. A typical simplified VSM map for software development is shown here:

Now that you have mapped your product delivery process, let’s put all the details on a board. The board could be a physical whiteboard or an electronic board like we have in Binfire. I have shown a board based on Binfire design below. Every board starts with backlog list, which holds all features that are needed to finish the project or a sprint if you use scrum. As work starts, tasks from backlog list are moved to other lists in the board until they reach done or released or done list.

Visualizing your workflow has many benefits and I have listed the three most important ones here.

The Kanban board is designed to move work from left to right. This is a simple system for tracking work that moves in one direction and does not overwhelm the user with loops and bidirectional movement.

It is a bad idea to work on to many things or to focus on too many problems all at once. This is human nature, when you work on too many things at once, your productivity drops. The more you try to handle at a given time, the more things you do wrong or forget to do. You need to set limits as how many tasks you and your team can work at any given time. This forces you to focus on the most important tasks at hand. This is called limit the “work in progress” or WIP. This concept is fundamental in lean development and essential in Kanban.

Limit Work in progress defines how many tasks a team or an individual can handle effectively at a given time. To understand WIO, we need toi understand cycle time. Cycle time describes the total time it takes a task to enter and exit a closed system. The formula for cycle time is as follows:

Cycle Time = WIP / Throughput (per unit of time like day, week, month or year)

There are different definitions for cycle time, but for us it means the time it takes when work on a task starts until the time the task is released. Throughput means the number of tasks that could be finished in a unit of time. If your team can complete 3 tasks in any given week, then the throughput of your team is 3 in a week. This should be obvious to everyone that if you try to handle too many things at the same time, you will fail in most of them. Every system has a limit as how many actions or tasks it can handle and finish them properly at any given time. This limit is critical to understand the workload for both humans and systems. The best way to reduce cycle time is by reducing WIP. To understand this, assume your team’s throughput is 5 tasks per week and your total WIP is 50, this means your cycle time is 10 weeks. To reduce this by half you either need to increase your team’s throughput or by reducing the WIP. How do you increase throughput? One way is by making your team more productive which is very hard to do. The second is by increasing the number of your people working in your team. The later is not really effective because of increased overhead reduced team productivity. In Knowledge Work unlike manufacturing or construction, your output is not doubled when you increase the team size by 100 percent. On the other hand reducing WIP is relatively simple. Just by reducing the number of tasks per cycle time from 50 to 25, your cycle time is improved from 10 weeks to 5 weeks. It is important set the WIP for each stage and each individual in your team. Some people can handle more work than others.

How one finds the limit for WIP? It is not an easy answer, every individual and system is different. But by trial and error it is possible to figure out the right number of tasks that should be active at any given time. A rule of thumb based on our experience and other practitioners of Lean process is that WIP should be set to no more than five for individuals and five to ten for each stage like development or testing. Anything more reduces the focus from important tasks at hand and reduces productivity.

Establishing polices is hard work and enforcing them even harder. But without it your project does not have a chance to succeed. Fixing bugs is very expensive and fixing products after they are shipped is much more. So it is important to bake quality in the product from the get go. If you have ever used Lean process then you are familiar with Quality Built In. If your system produces bug free products you will spend much less time finding bugs and fixing them. This reduces the overall development cost substantially. By establishing quality policies and metrics, you can continuously improve quality in your system and become a much more productive development team.

Why quality is important, because finding and fixing bugs is very expensive. It is even more expensive when the customer finds a bug. Not only finding a bug reduces the customer’s trust in the product, finding and fixing the bug is a major expense and headache. Fixing a bug after the product is released causes massive disruption in the day to day workflow of a team. Instead of working on new features and improvements, the team members are doing fire fighting to fix a bug and patch the system. For apps which reside in the cloud called SaaS the distribution is less expensive than other applications or systems. Just try to imagine fixing a product already in the market.

It is good practice to add policies you establish for quality assurance to the Kanban board. In software development it means have code reviews, unit testing, local testing and testing on pre production servers in the Kanban board under the testing. For other disciplines you can come up with similar activities for quality assurance.

What is cadence you might ask? In Kanban Cadence is the rhythm or drumbeat of your delivery. This drumbeat is for delivering the minimum marketable feature or MMF for your product. An organization that can deliver in predictable intervals is always more productive than the ones that don’t.

Establishing the right product delivery cadence is extremely important in Lean Product Development (LPD). It helps to optimize the feedback loops, optimize product delivery and reduce risk. One of great benefits of Agile and Lean methods is the fact that feedback about the product is received often and in short intervals. This reduces the risk of developing the wrong features or wrong products which the market does not care for.

You should have a cadence for features you are developing for product delivery release and one cadence for features that need research or may take much longer before they are ready for release in the product. We call the first one external delivery cadence and the second one internal delivery cadence. Managing these two cadences is critical in efficient product delivery. It is true that the more features you include in a release the lower cost per feature, but you need to adjust this with the cost of waiting for longer release cycle so all features are become ready. This cost is called holding cost and refers to the fact that even though you might have a few good features ready to go out and make you money, you are waiting for unfinished feature to become ready before you release. Another cost you need to consider is the transaction cost for getting ready for each new release. You incur cost for each release. There is an optimal point when the transaction cost and the holding cost meet. At this point your total cost is lowest. You should find this point for your product delivery procedures. The cost vs. batch size tradeoff is shown in figure #4.

In software engineering the continous deployement has reduces the cost of transactional cost considerably. This is done by employing automated deployments procedures and complete suites of testing and quality assuarnce procedures which could be deployed automatically.In some extereme cases the sofware is released many times each day. I am not sure this applies to projects which produce physical goods and tools.

During development not tasks are equal in importance. For this reason Kanban treats tasks with different priority and importance not the same. The reason is simple we focus on important high priority tasks anytime time constrain is found in the system. For the above reasons we create different classes of service in Kanban. In my experience the following four classes cover the majority of cases encountered by development teams.

Class of service can be visualized by using different colors for each class. The tasks in expedite class will always have the color red associated with them. This gives you a tool to handle any event rationally and efficiently.

To measure workflow in a system is hard but one of the most critical aspects of efficient development. To measure progress you need the right metrics. In most projects often the wrong metrics are used. The fundamental measurement you need to know is what the capacity of your development team is. Without this basic metric any other metric does not have any meaning. For your deliverables to be on time, scalable and predictable you need to know how much you can do in any given time. Relying on heroic overtime is a fool’s game. So what you need to measure? The following four measurements will cover most of your needs.

Cumulative flow diagram or CFD is a better tool than Burndown chart and is gaining popularity. CFDs are easy to create and easier to update. They also are much better at showing how the system is behaving. CFD displays the current amount of work for each stage of development over time. A simple CFD shows the number of tasks per each stage like backlog, working on, under test, finished and so on. A better model shows the remaining work (hours, days or weeks) for each stage over time. We like the second approach much better, because not all tasks are made equal and some take much more effort than others to complete.

Quality is one of most important factors for success of a product or service. Fixing bugs to achieve quality is very expensive. That is why you need to watch the number of bugs as you test carefully. As the development progresses the number of found bugs increase at first and then start to fall off. If the numbers start moving up again you have an issue with quality.

During development there are issues that take longer than should. Hopefully the project you are working on doesn’t have blocked items, but in case it does it is important to keep track of all blocked items and make then visible to the team until they pass through the system.

To manage and monitor the flow in your system you need a set of tools to check what is happing at any moment. For this Kanban provides decision filters to make it easy to manage the flow. Agile decision filters which I find useful are listed here.

These filters are used to make it easier to make the right decisions when faced with difficult problems during development. To manage flow you need to do the following:

Managing flow means understanding your system and making changes to make the flow faster and more efficient.

This one is not just necessary for Kanban but every system you work with should encourage real time feedback. You need to make sure your system is capable of giving you real time feedback. When something goes wrong, the sooner you find out, the cheaper it is to fix it. You should also expect the same real time feedback from your team members. Although in reality this is harder, but it is important to create an atmosphere where issues and problems are not hidden but brought up to everybody’s attention.

Usually developers, engineers and designers tend to hide their problems with the belief that others will consider them as less qualified or not a star player if they know they are struggling with a task or a problem. You need to create a work environment in which everybody feels confident to share issues and ask for help. This collaborative culture is a huge factor in making teams more productive.

I am sure that nobody disagrees with the notion that for a system to be efficient it needs priorities. But the critical thing most new comers to Agile and Lean practices miss is that without having the right structure and flow as discussed above, setting priorities is meaningless. How do we set priorities among tasks? By using a principle called cost of delay or COD. The COD means how much money the organization will not make or will not save if a task is delayed by a number of days or weeks, which is business terms, means lost opportunity. Items with the highest COD are implemented first followed by the others in the list. When calculating COD, other factors like cost of implementation or COI and time it takes to implement the feature are taken into account.

To visualize priority in Kanban board, we use the pull from top method for the backlog and open tasks lists. This way the highest priority tasks are at top of the backlog and open task lists and the less important tasks at the bottom. Open task list holds tasks that are ready to be implemented, while backlog holds tasks that we may get into in the future. When the system frees up to handle a new task, the task from top of open task list is moved to working in list. It is a good idea to keep the number of tasks or WIP for these lists to a small number. When the list get thin, you bring new tasks to keep the limit, until all tasks are done.

What is service level agreement or SLA you might ask? SLA is a contract between a service provider (development team) and internal / external customers. In it you define what features you will deliver by when. In Agile each sprint is a SLA. In Kanban you can have different class of SLAs. Not all features or issues are created equal. It is prudent to create a different set of SLAs based on situation and priorities. Having these SLAs will help you manage the development much better. The SLAs are improved based on experience. So at the beginning you establish a set of SLAs for different classes of work. Over time you improve the data in each SLA. We recommend establishing four classes of SLA as shown below:

The X, Y and Z numbers are the values you and your team choose for each class. Notice these numbers are different for each class of SLA and not the same. The initial value is not important, but it is important to have them. As you gain experience you will improve these numbers for much better predictably as when you will ship products.

It is important to continuously improve your process. This is hard work, but there is no other way to improve your results. The great thing about Kanban is that is help to gather tremendous amount of data about your process. Use this data to improve your process. By analyzing the date and learning from it, you can improve the process over time. By its visual nature, Kanban gives tremendous insight to people who use it as how they process works. In addition, Kanban lets you to validate your experiment by using scientific methods.

The vast amount of data generated by Kanban process and established policies like SLAs for different classes of services has proved to facilitate continuous improvements which are not seen by other traditional methods. By its visual nature Kanban forces you to face the shortcomings in your process and deal with them as soon as possible. This continuous improvement culture not only helps Agile and Lean concepts but also traditional methods like Waterfall.

Kanban is the best tool to view their entire workflow process in one simple picture. It is amazing to watch experienced engineers and designers using Kanban for the first time and see their total joy as to be able to visualize their workflow process for the first time.

Remember Kanban is all about continuous improvements and not radical change. The fact that you can adopt Kanban slowly is a huge benefit over other methods. In our experience the first time teams adapt Kanban for their development; their productivity shoots up by 20%. Over time as the team gains experience, the productivity improvements seem to be endless.

One of best advantages of using Kanban for Agile, Waterfall or Hybrid project management methodologies is that by its very nature Kanban encourages and facilitates collaboration. It enhances collaboration within the teams and helps to keep external stakeholders like customers and sponsors informed of the real status of the project at any given time. It is well documented that proper collaboration is a potent ingredient for enhanced productivity. By using Kanban, you and your team have real time data as what is happening with the project and if there are issues or bottlenecks that need your team’s attention. It shows which tasks are on time and which ones are falling behind. Who in your team never misses a deadline and who always falls behind? This improves transparency and accountability in your projects. It is much easier to track the progress of projects using Kanban boards collaboratively. The fact that everyone in the project has the same view helps greatly to keep everyone in sync. Make sure your team values collaboration and uses Kanban to make the process transparent and increase productivity.

Binfire has offers personal Kanban board for the user’s own tasks and project Kanban board which displays all tasks for all members. The board has filters for selecting members which you want to display their data. A great feature is the use of color to show each stage of task as it goes through product development life cycle. All late tasks regardless as where they are on the board are shown in red. This makes it easier to identify tasks are falling behind and take corrective action.

Kanban is a great tool for improving productivity and shipping great products to the market fast. It fits agile, waterfall and other project management methodologies like Hybrid project management method. It is easy to use and easier to understand. There is little need for training and people learn to use it in no times. Both physical and electronic boards are available and both work well. For larger project the electronic Kanban boards have many advantages. They add features like attaching files to cards and keeping the history which are impossible with physical boards.

The visual importance of Kanban method can’t be emphasized enough. Using Kanban helps not only plan projects but track them in real time. It lets you get insight to your current workflow and gather data to improve your workflow and process performance. When issues arise, Kanban shows red flags just earlier than any other method for managing projects. Binfire project management software supports Kanban for Agile, Waterfall and Hybrid management methods. Start using the Kanban board for your first project and realize the productivity gains that are achieved by most teams using Kanban for Agile and Hybrid methods in relatively short time.