What is Kanban throughput? What's the best way to measure it? This article reflects on these questions and provides a perspective to track a Kanban team's performance in an effective way.
What Is Kanban Throughput?
Kanban Throughput is defined as the average number of items or cards passing through the flow within a specific time duration provided that the work load stays uniform during that period. It is generally used to track team's performance. Throughput variability reflects the difference in size, complexity, and team skills.
According to the Little's Law:
Throughput = Total WIP / Average Lead Time
Measuring What Matters: Kanban Throughput
The best way to measure throughput in Kanban is with the CFD (Commulative Flow Diagram). The Cumulative Flow Diagram is the visual representation of the cards as they move from one column or state to another on a Kanban board. The CFD plots the number of cards at each stage at a given time.
Below is a sample CFD for your reference:
The different colors on this diagram represent the various states in the flow. The height of each color band indicates the number of cards in that state at that point in time.
The CFD provides you with an insight on how many cards moved from one state to another in a specific time duration. Generally, the CFD is plotted for each day, however, if there are too many moving cards in a day, it can be plotted on an hourly basis as well. Below is a sample CFD when plotted for every hour in a working day.
Moreover, the CFD provides valuable data on lead time and cycle time trends. Both lead time and cycle time denote the time a work item spends in the workflow until they are complete. Lead time is the time that a card takes from start to finish. Cycle time is the time an engineer spends to actively work on it. In a CFD, both lead time and cycle time metrics are measured along the horizontal axis.
The Cumulative Flow Diagram (CFD) also displays total cards across different columns i.e. total WIP. This data is measured along the vertical axis of the CFD diagram.
Below is a sample CFD that depicts lead time, average cycle time, and the total WIP.
If you are interested about other Kanban charts such as Average Lead Time, Average Cycle Time, Flow Efficiency Chart, or the Blocker Clustering Chart, read my book, The Basics Of Kanban - A Popular Lean Framework.
You might ask whether Agile and Lean are the same or different. Which one is the best methodology for your business? Below are my views on the main similarities and differences between the two.
Similarities in Agile and Lean
The core similarities between Agile and Lean are listed as follows:
Development approach
Lean development encourages to limit the work-in-progress (WIP). Agile methodology also promotes incremental development within short, time-boxed iterations. Both methologies have a similar approach to reduce the batch size.
Continuous Improvement
Lean is very focused on Kaizen or continuous improvement. Agile, too, encourages inspect and adapt activities (such as product demo and retrospectives) that promote continuous improvement.
Collaboration
Teamwork is one of the core values defined in Toyota Way 2001. Lean methodology encourages collaboration between team members. Agile methodology also focuses on collaboration (refer to the two statements from the Agile Manifesto below):
Individuals and interactions over processes and tools
Lean is a customer-centric methodology. It delivers the best quality work in the shortest sustainable lead time. Similarly, Agile is customer-centric as well. For instance, the 1st Agile principle, ‘Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.’ is customer-focused.
Just-in-Time (JIT) approach
With Just-in-Time (JIT) approach, teams build only what is needed, when it is needed, and in the quantities needed. Both Agile and Lean methodologies support this approach. In Lean, work items are pulled only when needed. In other words, a lean engineer starts working on a new Kanban card only when the WIP limit allows the same.
Similarly, Agile development promotes the JIT approach. It encourages teams to refine, design, and document only the prioritized work items. Moreover, Agile concepts, such as incremental development and emergent design, reinforce this approach.
Waste Elimination
Lean is the major proponent to eliminate waste. Agile methodology, too, supports this concept by delaying decisions until the last responsible moment (LRM). With Agile, any possible rework is minimized.
Differences in Agile and Lean
Some of the core differences between Agile and Lean are as follows:
Origin
Lean management was originated in the manufacturing sector. The original intent was to reduce waste within the Toyota Production System (TPS). Agile methodology, on the contrary, was conceived by the software developmentthinkers to solve problems with the traditional, plan-based approach.
Nature of work
Lean is best suited for:
Managing work that flows through different workflow states
Optimizing an existing workflow process
Simple and repetitive tasks
Eliminating blockers or waste
Agile, on the other hand, is best suited for:
Developing complex products
Managing work that requires research and experimentation
Delivering maximum business value
Adapting to frequent changes
Encouraging team collaboration
End Goal
With Lean, the end goal is to deliver work that:
Has high-quality.
Is released within the shortest sustainable lead time.
Is carried out in the most economical way.
Has minimal redundancies or waste.
With Agile, the end goal is to deliver a product that:
Has the maximum business value.
Responds quickly to the changing business needs.
Is built incrementally and iteratively.
Team Size
The Lean methodology is applied to improve processes in large enterprises and teams. With Lean, the Value stream mapping helps to visualize end-to-end journeys for large organizations.
On the other hand, Agile is most effective when applied to smaller teams, with a team size of 5-8 people.
Now that you understand the similarities and differences of Agile and Lean, you can select the methodology that works best for your team. Feel free to add a comment to this post and share your experiences with me.
The Agile Manifesto is comprised of 12 Agile Principles that set the foundation for being agile. Often, people interpret these principles in different ways. In this article, I will break-down each principle into smaller phrases or words to clarify its meaning. Let's dive into each one, understand what they really mean, and be agile.
12 Agile Principles Explained
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Agile Principle 1 - Satisfy the Customer Photo by rawpixel on Unsplash
What does this Agile principle mean? The phrase “our highest priority” signifies that the entire product team should know their priorities and should work on the highest priority items first. The highest priority for the product team is to “satisfy the customer” such that the product meets the needs of the customer. The phrase “early and continuous delivery of valuable software” implies that the work completed during the iteration must be demonstrated to the customers as soon as it meets the ‘Definition of Done’ to get their early feedback. Moreover, the team must strive to deliver valuable software to the customers at the end of each time-bound iteration.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Agile Principle 2 - Welcome Changing Requirements 🙂 Just Kidding! Photo by rawpixel on Unsplash
This Agile principle focuses on embracing change. The phrase “welcome changing requirements” signifies the importance of accepting revised business priorities. The phrase "even late in development" signifies that changes should be welcomed irrespective of the time and effort the team has already invested to develop a feature. It's hard not to get defensive! But, think from your customer's perspective and understand the business value or the key drivers of the change.
“Intelligence is the ability to adapt to change.” – Stephen Hawking
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Let’s understand what this principle means. The phrase, “deliver working software” means that the Agile development team should target to deliver high-quality production-ready work at the end of each iteration. The team should target to deliver working software frequently, preferably, after every couple of weeks. The shorter the delivery timescale, the more incremental development happens with the lesser cost of change.
Principle 4: Business people and developers must work together daily throughout the project.
This principle focuses on collaboration between the business and the development team. The phrase “must work together daily” implies that Agile development teams must interact with product sponsors daily throughout the work execution.
“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work.” - Vince Lombardi
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Agile Principle 5 - Motivation, Support, and Trust Photo by Samuel Zeller on Unsplash
What does this principle mean? The phrase, “build around motivated individuals” emphasizes the importance of having motivated people on the team.
“Find people who share your values, and you’ll conquer the world together.” - John Ratzenberger
“Give them the environment and support they need” – this phrase means that agile leaders should provide the necessary infrastructure that development teams need to continuously integrate and deploy their changes and should trust the team to deliver valuable software to customers.
Principle 6: The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.
Out of the 12 Agile principles, this one is based on face-to-face conversation. Face-to-face conversations boost creativity, credibility, trust, and collaboration as people better understand feelings and reactions via body language and expressions. Moreover, face-to-face conversations promote friendliness and build relationships. Therefore, agile leaders, product sponsors, and business stakeholders must meet with the development team in-person regularly.
However, face-to-face conversations are often constrained by the geographical presence of the development team. Platforms for video conferencing provide the same benefits as that of face-to-face conversations and should be encouraged.
Principle 7: Working software is the primary measure of progress.
This Agile principle focuses on “working software”. The Agile development team must deliver high-quality work at the end of each iteration that can be released on-demand to end-users or customers of the product. Working software is the primary success measure. Other metrics such as productivity, committed vs actual work, and burndown charts are secondary.
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The phrase “sustainable development” means that work is developed at a constant pace that can be sustained indefinitely without overburdening a development team.
“It does not matter how slowly you go as long as you do not stop.” – Confucius
Principle 9: Continuous attention to technical excellence and good design enhances agility.
This Agile principle states that agile leaders, developers, and the product team must continuously seek technical excellence and emergent design to enhance agility.
“In an agile project, technical excellence is measured by both capacity to deliver customer value today and create an adaptable product for tomorrow.” - Jim Highsmith
Principle 10: Simplicity--the art of maximizing the amount of work not done--is essential.
The developers, product sponsors, and the agile leaders must identify things that do not add value or in other words, must simplify things by maximizing the amount of work not done.
“A designer knows he has achieved perfection not when there is nothing left to add, but when there is, nothing left to take away.” - Antoine de Saint-Exupery
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Agile Principle 11 - Self-Organizing Teams Photo by rawpixel on Unsplash
This principle is all about self-organizing teams. The product architecture, design, and features emerge from mature self-organizing teams who can freely take decisions and remove temporary blockers on their own. If developers are free to make decisions, they tend to be more accountable, innovative, and collaborative. Such an environment is best suited for emergent design and iterative development.
“A self-organizing team has authority over its work and the process it uses.” - Mike Cohn
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This principle focuses on inspect and adapt. The phrase “at regular intervals” signifies the importance of setting up a regular cadence to inspect and improve. Agile frameworks recommend regular practices such as product demo and retrospectives to continuously improve the process in an iterative way.
“Continuous improvement is better than delayed perfection.” - Mark Twain
Apply these 12 Agile Principles and be agile. Please post your valuable feedback in the comments section.
To learn more about the Agile Scrum Framework, read my book, The Basics Of SCRUM. If you like to understand the Lean Kanban method, check out my other book, The Basics Of Kanban.
A Kanban board is a visual tool for enabling Kanban to manage work for any business. The board helps the team to track each of their work items, minimize idle time, improve predictability, increase quality, and reduce time-to-market.
Sample Kanban Boards
Let's dive-in into a few practical examples when teams manage their work via the Kanban approach.
Consider a scenario that a DevOps team receives several requests each day to automate build process in Jenkins, resolve test environment issues, onboard new applications onto the hybrid cloud, and so on. Here’s a sample Kanban board for such a scenario.
Sample Kanban Board - DevOps
The second example is of an operations team that receives several calls during the day from its customers and works together to analyze reported issues, provide real-time guidance, and execute fixes to a customer-facing application. Here’s a sample Kanban board for such a scenario.
Next, let's consider a scenario that a software development team receives new requests on a regular basis to build new capabilities and enhance existing application features. This team targets to deliver a quality code and invests time in peer code reviews and application testing. Here’s a sample Kanban board for such a scenario.
Another example is of an organization’s legal team that receives requests on a regular basis from different portfolios in the organization to review content on their sites, campaigns, offers, etc. from a legal point of view. Here’s a sample Kanban board for such a scenario.
Let's take a practical example of a platform team that receives multiple requests from different application teams every day. Here’s a sample Kanban board to visually track their onboarding requests.
One of the examples of a personal Kanban board is to track the process when buying a new home. In order to track the various tasks and reduce distractions, you create a Kanban Board with a WIP limit of 2 home viewings. Here’s a sample board for such a scenario.
Next, let's consider another example of a personal Kanban board. In this scenario, you need to sort your house over the weekend. You decide to organize your work and reduce task-switching by creating a Kanban board. Here’s a sample board for such a scenario.
Now that you have seen a few sample Kanban boards, will you be able to create one for yourself? Share your board in the comments section below. Don't forget to apply a WIP (Work-In-Progress) limit to your board.
