Definition, History, Process & Best Practices of Kanban

best practices of kanban

What Is Kanban Methodology?

Kanban is defined as a software development process within the agile framework that focuses on limiting the amount of work-in-progress (WIP) at any given time. 

The goal of this development process is ensure a smooth iterative (agile) workflow pipeline and to limit the amount of backlogs that may arise due to excessive pressure on the pipeline or other issues that need to be quickly identified and resolved.

The basic disciplinary concepts that make Kanban a successful work management formula, can be applied in software as well as other fields.

Where Did Kanban Come From?

The first Kanban system was developed by industrial engineer and business man Taiichi Ohno for Toyota automotive in Japan during the 1940s.

It was created as a simple planning system to control and manage work and inventory at every stage of production optimally.

One of the main reasons the Kanban was developed was due to the inadequate productivity and efficiency of Toyota compared to it’s American counter parts at the time.

Now, the term Kanban itself, pronounced “kahn-bahn,” is a Japanese word which means visual signal or card. The Kanban system works on the concept of “Visual Management” and limits work-in-processes to avoid bottlenecks.

The goal of applying this methodology is to reduce cost, increase productivity and quality, while simultaneously improving delivery time.

Unlike other workflow management methods, Kanban is about evolution, not revolution, meaning that it rests on the fundamental truth that you must know where you are before you can get to your desired destination.

The beauty of this method is that you can apply a Kanban to virtually any type of work that follows a repeatable process.

During its founding all those years ago, Toyota line-workers used a Kanban (at the time, an actual card) to signal steps in their manufacturing process.

In its original iteration, before the accessibility of technology, Kanban’s were physical boards with cards that were manually updated. Now, tools like Chisel, let you do the same activity asynchronously with your team online.

Originally, the Kanban system controlled the entire value chain from the supplier to the end consumer. It helped avoid supply disruption and overstocking of goods at various stages of the manufacturing process.

In 2004, David J. Anderson, applied the concept to IT, software development, and knowledge work in general.

A Brief History of Kanban for Software Development

The following excerpts are taken from David J. Anderson’s blog post titled “A History of Kanban for Creative Knowledge Work.”

October 2004

David J. Anderson is asked by Dragos Dumitriu, manager of XIT sustaining engineering at Microsoft, asks for help. David, created a pull system for Dragos’ group and coached him on how to introduce it. Dragos then sold the idea to his bosses and his 4 product managers.

This system was implemented on Microsoft product studio where there was no physical board and the engineering team was in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.


Winter of ’05: Donald Reinersten watched a presentation of David’s flow and FDD material at a conference in Chicago and follows him home to Seattle. Donald visited him in the café of Building 25 on the Microsoft campus and persuades David to try Kanban systems.

David decides to revisit the XIT implementation as a Kanban system and discovers that little would change other than perhaps the WIP limits would be slightly different.

David finds Kanban systems easier to explain to people and starts referring XIT implementation as a virtual Kanban system and presents it the following year in Chicago.

In October of 2005, XIT sustaining engineering study is presented at TOCICO in Barcelona and published as a white paper by Microsoft.


Winter of ’06: David presents the completed XIT story as a virtual kanban system implementation at the same Chicago conference Donald followed him home from the previous year.

This is the first public presentation of Kanban systems used in a knowledge work setting where previously, only Dragos and David had been involved.

Summer of ’06: Some people read and implement copies of the Microsoft XIT solution. Notably, Eric Landes from Robert Bosch copied it almost exactly for use with an intranet website maintenance team.

September of ’06: David changes jobs to become Senior Director of Software Engineering for Corbis.

He realizes the software maintenance process is badly broken and works with Rick Garber, the manager of the process improvement team, to design a Kanban system to replace the existing project-centric approach to minor application upgrades.

When working with stakeholders, Drew McLean, a VP at Corbis, suggests the expedite capability which added the first alternative class of service to a Kanban system for knowledge work.

Darren Davis, development manager for maintenance, and Diana Kolomiyets, the project manager, take control of the Kanban implementation in November 2006. Darren takes charge of standup meetings and Diana runs the replenishment meetings every week and plans and coordinates releases every two weeks.

December of ’06: There is an operations review of IT at Corbis. Results from the first Kanban system implementation are presented by Darren Davis during review.


January of ’07: Darren Davis suggests, that due to stagnation of improvements after a series of successful releases from the maintenance process, that there appears to be so much variation in flow that no one knows what to do next.

He suggests visualizing the workflow using a card wall implemented on a white board across the hallway from his cubicle. This idea was from one of his team members. A board goes up on the wall.

Winter of ’07: The wall is helping with further improvements and capacity is set aside for internal demand. A WIP limit of 2 is established for green tickets.

David noticed a trend for urgent work with externally fixed dates. He suggests offering a “fixed date” concept as a class of service.

What is now known as the Kanban method with it’s six practices and risks visualized and addressed using capacity allocation and classes of service emerges at the end of this season.

Corey Ladas is hired away from Microsoft to be a process coach for Kanban at Corbis.

April of ’07: The incoming CEO of Corbis asks why if the new maintenance process is working so well, then why isn’t it being used across all of IT. David agrees and rolls out Kanban across the project portfolio.

The digital asset management (DAM) project that has already adopts Scrum, adopts Kanban under Corey’s guidance. This is the first instance of a two tiered Kanban board with swim lanes.

May of ’07: Dan arrives as the development manager for the ERP project. Dan’s never worked with Kanban, but him and Corey design the process for the project. They roll the staff from the DAM project onto the ERP project bringing along the two-tiered, swim lane Kanban board.

June of ’07: Donald holds a conference for Lean New Product Development in Chicago and Rick Garber and David present. There are only 55 people in the audience.

This is the first presentation of what is now known as the Kanban method complete with classes of service, lead time histogram metrics, operations review, etc.

August of ’07: David presents same presentation from June at the conference within a conference at the Agile Conference in Washington D.C.

Members from Yahoo! are in attendance (Karl Scotland, Joe Arnold, and Aaron Sanders) and approach David the next day. They tell David that his evolutionary approach to change and alternative path to agility using virtual Kanban systems is appealing to them. They explain that they have tried to implement Scrum at Yahoo! and that there is a lot of resistance. They want to try Kanban with the resisting groups and they set up a Yahoo! discussion group to share their experiences. The kanbandev group was born this day and is still used at Yahoo!


August of ’08: Corey Ladas presents more detailed implementation scenarios at the Agile 2008 conference. Half of the presentation focuses on Kanban applied to teams and projects using Scrum. This is the foundation of what would be known as scrumban.


January of ’09: Corey Ladas’ book called Scrumban is published based around a series of blog posts he had written about evolving Scrum using Kanban.

May of ’09: The first Lean Kanban conference is held in Miami, an idea proposed by the kanbandev group at Yahoo!

David meets with Jim Benson to reflect on the conference at Miami. They discuss how Kanban for personal use is difference from corporate workflow usage (now known as the Service Delivery Kanban). There’d been instance of personal usage emerge in various places around the world including the Modus Cooperandi office.

July of ’09: Jim Benson launches Personal Kanban as a series of 12 blog posts.

October of ’09: Jim Benson launches


Kanban– Successful evolutionary Change for your Technology Business is published and becomes the best and most complete reference to implementing Kanban systems in creative and knowledge worker businesses. It has sold well over 40,000 copies.

Key principles for Kanban Development:

The 5 key principles that make Kanban an effective development process are:

Agreement on incremental agile framework

Kanban can only take effect within a work framework that is agile, meaning that the product will be developed in iterative cycles, each building on the previous version. This is fundamental to the Kanban methodology.

This of course is based on the fact that user preferences and market landscapes change too fast to not be taken into account while developing a new product or feature. Each iteration therefore is developed in only weeks, not months or years by when the product may be already outdated or lacking key customer preferences.

Starting with what is certain while leaving room for uncertainty

Teams that choose Kanban start with acknowledging that they may simply not know or understand every user need right at the start and that the product will need to be delivered in versions – starting with what they know and building towards betterment based on new insights.

Furthermore, by starting with the basic product model that passes the economic cost-benefit analysis and feasibility tests, it prevents delays from excessive planning and decision-paralysis.

Limit work-in-progress (WIP)

Kanban aims to limit the total work-in-progress at any given time. This is done through pressure-tests on the bandwidth through managerial guidance and carefully noting the capacity of each team and member.

Once a reasonable estimate of work that can smoothly pass through the development and test cycles into production, the workflow must be managed accordingly in each sprint/ build cycle. 

This is not to say that the workload should never be increased – in fact as the team matures and gets more accustomed to the product’s development and processes, the pressure-tests should take place from time to time.

Based on the work that needs to be done to meet business goals, and the team’s capacity to deliver, additional resourcing needs to be planned in advance.

Iterations based on user-feedback

Since Kanban aims to deliver the product in versions, one of the key insight sources that determines the work is user feedback.

User-need surveys and experience studies are a cornerstone in the Kanban methodology of development, since the point of delivering a product under continuous development is to stay informed on user preferences and deliver it before competitors.

User feedback and feature requests need to then be scanned through a cost-benefit lens and prioritization of the feature development is done accordingly.

Delivery ownership and team alignment over documentation

One of the key principles that allow for fast development is to create an environment of trust and ownership final work delivery, even if no one is checking in.

While task management from managers are still important with pipeline management, documentation of code through comments and spreadsheets is reduced in lieu of better team alignment and self-accountability.

Kanban Development Model: Life-Cycle Stages

Based on the principles of Kanban, below are the iterative stages within the method:

Stage 1. Product feasibility test and early need-analysis

Product-need analysis is the process of undertaking prospective-user surveying and understanding the demand for such a product, gaps in current products (if any) and the key features essential to break into the market.

Based on this initial must-have list of features, a cost-benefit analysis must be done to understand short-term and long-term potential return-on-investment.

Only once this stage is clear that any product development should be even conceived.

Stage 2. Team alignment

Team alignment is key for any agile framework, including Kanban. This means that before starting any actual development work, it is key to pull your team together for one or several alignment sessions to chalk out clarity on every feature, method and process. Given the importance of work ownership and cross-team collaboration, especially in the light of remote working post-covid lockdowns, team alignment is key to a smooth functioning work pipeline and timely delivery with least bottle-necks.

Stage 3. Product definition

“Creating product vision, feature roadmap and prioritization” – Product managers create a product and feature roadmap that is both compelling and achievable. They use their in-depth understanding of the target customer’s needs as well as the capabilities of the engineering team and the technologies available. Using this understanding, they create a product backlog to ship the right features at the right time.

Stage 4. Product development based on existing clarity

Once your team is aligned, it is time to move forward with your first iteration’s development work. This stage ends with the development of the planned iteration until it gets sent for QA and testing.

Stage 5. User-experience and QA tests

Internal quality assurance (QA) tests are the first layer of error-free product production. QA engineers only test the product or feature based on how it was originally intended to function as per the build-plan. 

If the product clears QA, the final test on en-user experience is conducted by a panel of users to identify gaps in navigation, layout, user-interface friendliness, intuitiveness etc.

Stage 6. Modifications and Production

If the user-feedback test returns with sanctioned pre-production updates, then these last-minute changes are to be implemented and QA must verify it. No further user-tests are typically done. Once the product passes QA, it goes into production.

Stage 7. Repeat

Once the product hits the market, the product manager needs to go back to step 1 to plan the next iteration.

The 6 Rules Of Kanban

Never Push Through A Defective Product

There is a level of quality expected when creating a product. You ought to remove any defective features and deal with them. This ensures only the highest quality product gets to your customer.

This is why in software development, every application has to go through rigorous quality assurance testing before anything is released. Only once the product has passed testing, then, and only then, can they be released to the market.

Focus only on what’s needed

Avoid getting bogged down in customer requests or orders on your product. You don’t want to incorporate every feature request because then you’ll be at risk of becoming a feature factory.

Your backlog has prioritization, follow it.

Produce what is required

This goes hand in hand with focusing only on what’s needed.

When creating a new product, having a Minimum viable product mindset is imperative. You need your product to functionally work in the way the customer is working for, nothing more, nothing less.

The absolute minimum requirements are what you ought to focus on creating and then build your product out as the market demands moving forward.

Don’t overwork your developers

One of the more ingenious aspects of the Kanban is setting your work-in-progress limit based on your limiting contributor.

The WIP exists so that when you spot a bottle neck, you can alleviate the burden by redirecting your resources and setting a WIP to prevent any long term issues from occurring.

Fine-tune and optimize the processes

Kanban metrics like lead time, cycle time, and throughput will help teams get quantitative and objective assessments of their work.

Teams must be looking for activities that produce excess bloat and eliminate them.

Regular team meetings where everyone discusses experiences, pain points, and improvement suggestions are key in fine-tuning production. As inefficiencies decrease, WIP items also decrease because the process is leaner.

Finalize the process

When you ensure quality, fair production, and optimize your process, your process becomes stable and finalized.

You should document your process so there is a common understanding of how everything should operate.

Any deviation from the process should be managed by other policies.

Keep in mind though, everything can evolve through time as you fine-tune your process.

Crafting great product requires great tools. Try Chisel today, it's free forever.