What is Kanban?
As you begin your pursuit of Agile Project Management mastery you will encounter the topic of Kanban. What is Kanban? The question has two distinct answers.
- It is a physical board for tracking work in process within a workflow system.
- It is an agile project management methodology that adheres to the Agile Manifesto.
This guide explains the first answer but is intended to explore and teach the second as fully as possible.
A Physical Board
To begin, Kanban originates from manufacturing workflow systems. A central, physical signboard held cards to represent work in process. Anyone could glance at the board and immediately see where work stood in the workflow.
This system allowed a clear understanding of the state of the overall system. Bottlenecks showed up quickly. Status updates go out to everyone simultaneously. Communication works.
Physical boards originated the concept and evolved into the project management practice that exists today.
An Agile Project Management Methodology
Agile practices began not as a formalized methodology but as best practices. These best practices streamlined project delivery and standardized the customs of agile teams. As teams gained experience methodologies emerged.
So, Kanban was developed as a continuous flow system. It focused on delivering value in an agile fashion as work finished. It models the assembly line method of production where physical Kanban boards first originated.
At present, this methodology distills project management down to essential artifacts and ceremonies. When executed consistently and with discipline teams using it realize a significant improvement in project success.
What Makes Up Kanban?
The practice consists of three components: team, artifacts, and ceremonies. They provide the three agile pillars that support a positive outcome and value delivery.
The Team
The Kanban team has somewhat less regimented roles than other agile methodologies like Scrum. The functions of team members follow the same categorizations as Scrum: Product Owner, Stakeholder, Scrum Master, Developer but these roles typically do not come as formal assignments.
Also, team members flow from one functional responsibility to the next as conditions require. A Scrum Master today could write code tomorrow and define user stories the next day. Roles and responsibilities flow like water. The three primary functions of the roles on a Kanban team fall into Developer, Scrum Master, and Product Owner.
Developer
Every member of the Kanban team acts as a developer at some point. The developer role simply means doing a task that is moving a user story towards completion. This involves coding, quality assurance, and administrative tasks in equal measure.
Scrum Master
Scrum Master roles involve keeping the team on track to deliver completed user stories. They facilitate the ceremonies and referee team members to keep them playing by the rules. When the resolution of an issue requires resources outside the team, the Scrum Master assumes this responsibility.
Product Owner
Product owners speak for the business. They determine priority. They determine acceptance criteria. This means the Kanban team relies on the Product Owner to be their rudder, guiding them to their destination.
The Artifacts
Two primary artifacts exist within the Kanban methodology; the product backlog and the product increment. This differs from Scrum where the product backlog, sprint backlog, and product increment compose the three artifacts. So, Kanban has no need for the sprint backlog since work continuously flows through the system.
Product Backlog
The product backlog consists of user stories (see Sprint Backlog Example) that have been well-groomed (see Backlog Refinement Meeting) and prioritized according to value to the business.
A well-groomed and prioritized product backlog guides the work of the development team. The highest priority item, typically the most valuable item to the business, moves from the backlog to the work in process.
When it reaches a “done” state the business realizes the value of the work and it becomes part of the Product Increment artifact.
Product Increment
All user stories that reach completion make up the Product Increment artifact. This historical log illustrates the functional capabilities of the product over time. It tells the story of the product’s evolution as well as its current capability profile.
Kanban Ceremonies
Planning, stand-up (daily scrum), demo, and retrospective make up the ceremonies of the Kanban methodology.
Planning
During planning the Kanban stakeholders replenish the sprint buffer for the development team. Planning occurs when the buffer drops below an established threshold. The threshold depends on the average throughput of the development team.
Planning occurs as often as throughput dictates. However, if the team finds itself in need of more than one planning ceremony per week the buffer should be increased. Also, if the team is not planning at least every other week the buffer should be decreased.
Stand Up (daily scrum)
This ceremony comes to mind when most people think of agile project management. In it, the Kanban team gathers to answer three simple questions.
- What progress have you made since yesterday?
- What will you be working on today?
- What issues are standing in your way?
Do not problem solve in the Stand-Up. Collect the issues that need to be resolved and tackle them in order of importance immediately following the meeting.
The daily Stand Up keeps the team communicating, insures problems are resolved right away, and sets the team up for success.
Demo
During the demo ceremony, the team demonstrates the product to show that it meets the acceptance criteria of the user story. The product owner either accepts or rejects the user story based on what they see in the demo.
Demo ceremonies should occur every one or two weeks depending on the throughput of the team.
Retrospective
Also called Post Mortem, the Retrospective ceremony allows the team to evaluate their performance, celebrate accomplishments, and make changes when needed.
Do not use this ceremony as a finger-pointing exercise. Discuss accomplishments as well as areas that need improvement.
Make a list of positives and instead of negatives, deltas or changes to make.
Capture any changes as user stories and add them to the backlog. Next, prioritize them and plan them for future development efforts.
Do not skip the retrospective. Schedule it at regular intervals. Make it a critical performance metric for your team.
Kanban Tools
I have created a few tools to help you set up and manage your Kanban teams. I’ve used Excel as most organizations have access to it and most team members know how to use it.
This tool lets you create your own Kanban board within Excel for your team. Add team members and tasks. Update status and see the results immediately on your Excel Kanban board.
A standard format for managing your team’s backlog via Excel.
Kanban Card Template For Excel
If your team uses a physical Kanban board this free template lets you standardize the information you show on that board.
Kanban Books
Learning more and more about Kanban sharpens your skills and helps you deliver higher throughput. I studied these books throughout my Kanban journey. They equip you with a better understanding of Kanban making you more skilled in its practice.
[FULL DISCLOSURE] These links are affiliate links. If you follow them and make a purchase I am paid an affiliate commission. However, I only recommend resources that I’ve used myself and feel will help you.
Kanban by David J. Anderson is the first book on Kanban that I read when gaining an interest in the topic. It explains the author’s own experiences in creating Kanban teams across multiple organizations. It will provide you with a solid foundation to build on.
The Goal by Elihyahu M. Goldratt should be required reading for everyone in business. Told as a parable it teaches powerful project and process management techniques and strategies. This book will change your perspective and motivate you to change the world around you.
Kanban questions? Contact us for answers.
