Tag Archives: Lean

Do You Measure Kanban Throughput?

Posted on by

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:

 

Sample CFD Diagram

 

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.

 

Sample CFD - Plotted Hourly

 

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.

 

Sample CFD Diagram With Lead Time, Cycle Time, and 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 may also be interested in these articles...

...and below books on Agile and Lean:

Will OKRs Rule The World?

Posted on by

Will OKRs rule the world? This article captures my thoughts on OKRs and their impact on the corporate industry.

 

What are OKRs?

OKR stands for Objectives and Key Results. It is a simple management methodology and an agile goal-setting system that enables everyone to align with enterprise objectives and to visualize the progress made towards them.

 

Founded by Intel CEO, Andy Grove, in the 1970s, the OKRs methodology was first adopted by Google in 1999. Since then, OKRs have helped Google and several other enterprises to stay focused, create transparency, gain alignment, and achieve better results. Today, several organizations across all sectors such as Spotify, LinkedIn, Walmart, Bill and Melinda Gates Foundation, and others are using this framework to set and achieve audacious goals.

 

In 1999, John Doerr, a venture capitalist, introduced OKRs to Google. In his meeting with Larry Page and Sergey Brin, co-founders of Google, he introduced the OKR system and explained how it can help Google to achieve its aggressive growth targets. In his book, Measure What Matters, John revealed how the system of OKRs has helped organizations achieve agility and explosive growth.

 

John Doerr’s formula for OKRs is:

I will (Objective) as measured by (set of Key Results).

 

Objectives define 'what' is to be achieved. They are qualitative, significant, concrete, short, inspirational, memorable, and ambitious. Each objective could have 2-5 key results.

 

Key Results define 'how' we achieve the objectives. They are a set of measurable milestones for each objective to track progress towards achieving the objective. They are quantitative, specific, measurable, time-bound, verifiable, and aggressive, but realistic. When key results are complete, the objective is necessarily achieved.

 

Will OKRs Rule the World?

Let’s look at some of the common problems faced these days and if OKRs can prove to be beneficial in those scenarios.

 

One of the common problems today is conflicting priorities. Often, different stakeholders have conflicting views on the features or capabilities that a product roadmap should include. Such conflicts lead to unpleasant conversations, strained relationships, and a demotivated team.

 

The OKRs framework brings focus to the purpose or objectives that a product has. The stakeholders start to think in terms of the product vision and its goals that they are trying to achieve. With OKRs, there’s also a better clarity on the success metrics or the key milestones for each product objective.

 

“OKRs are clear vessels for leaders’ priorities and insights.” -  John Doerr

 

The other common problem these days is lack of measurement or tracking of the specific outcomes or product goals. Teams continue to build new features and capabilities for the product but seldom measure the outcome or the result.

 

With the OKR model, Key Results (KRs) are measured and tracked periodically.

 

“If the focus is delivering something the customer wants, you must move from primarily measuring outputs to primarily measuring outcomes.” - Mario E. Moreira

 

But does one size fits all? No, OKRs are not meant for all enterprises. OKRs will not work for you when:

 

  • OKRs are not agile: When OKRs are rigid, the model does not provide any room for people to make mistakes, abandon OKRs, or be agile. The OKR model is meant to inspire people and drive better alignment, focus, engagement, and performance.

 

  • OKRs don’t flow quickly down the corporate hierarchy: Some enterprises find it difficult to align corporate OKRs with portfolio and team OKRs. Thus, it takes a considerable amount of time for them to cascade strategic OKRs to the teams.

 

  • When conflicting priorities are tough to resolve: With conflicting priorities, planning becomes a nightmare and it might consume a considerable amount of time and effort to lock down OKRs for each quarter.

 

If you would like to read more on OKRs and Enterprise Agility, you might like my latest book, Enterprise Agility with OKRs.

 

Download the FREE Agile templates for strategic planning:

  • The Product Persona Template
  • The Product Vision Template
  • The Product Roadmap Template

You may also be interested in these articles...

...and below books on Agile and Lean:

Scrum and Kanban

Posted on by

Scrum and Kanban

What is the Agile Scrum Framework? How is it different from the Kanban approach. If you are applying the Scrum framework and leveraging the Kanban board, you might be thinking that Scrum and Kanban are the same. In addition, you might be wondering which methodology is a better fit for your work.

In this article, I have listed the core differences between Scrum and Kanban. Moreover, I also covered which framework is best suited with different type of work or teams.

 

Scrum in a nutshell

Scrum is an iterative and incremental Agile process framework to build complex products of the highest possible value. In Scrum, the team always works on the highest priority items first. The work is performed in short, time-boxed iterations or sprints. Each sprint begins when the team commits to complete prioritized user-stories based on their available capacity in the sprint. An iteration ends when the team has delivered a potentially shippable product increment of the product. Therefore, the scrum development team delivers business value to users at the end of each sprint.

The three Scrum roles - Product Owner, Scrum Master, and the Development Team - are defined below: 

  • A Product Owner decides what needs to be built and in what order.
  • A Scrum Master acts as a servant leader and coaches the team to follow Agile Scrum principles.
  • A Development Team is a group of self-organizing individuals who develop a high-quality product.

Scrum requires the below ceremonies to be conducted on a regular cadence:

  • Product Backlog Refinement
  • Sprint Planning
  • Daily Stand-Up
  • Sprint Review
  • Sprint Retrospective

Above all, Scrum is most suited for complex projects where things are more unpredictable than they are predictable. In complex domains, there is a need to collaborate with others, have an innovative mindset to investigate, experiment with different ideas, and adapt based on the learnings.

To learn more about Scrum, you may read my book, The Basics Of Scrum – A Simple Handbook to the Most Popular Agile Scrum Framework. 

 

Kanban in a nutshell

Kanban is the most popular Lean framework. This approach works best for teams that have a continuous flow of incoming requests with different priorities. In the Kanban approach, each request or a work item is represented by a Kanban card that flows from one stage of the workflow to another until it is complete.

Kanban is very flexible in nature. New work items can be added to the backlog at any time. Even the workflow can change anytime. If team capacity changes, WIP limits get recalibrated. In addition, Kanban does not prescribe any roles or ceremonies. It optimizes an existing process by eliminating waste and improving time to market.

To learn more about Kanban, you may read my other book, The Basics Of Kanban - A Popular Lean Framework

 

Compare Scrum and Kanban

Below section lists the core differences between Scrum and Kanban:

  • Scrum was formulated for complex product development to mitigate the limitations with the traditional Waterfall approach. Kanban, on the contrary, originated to manage work and control inventory at Toyota with Just-In-Time and Lean principles.

 

  • Scrum prescribes product teams to manage work within time-boxed, short, and consistent length iterations or sprints. However, Kanban specifies a continuous flow of work across different states.

 

  • With Scrum, development teams create a potentially shippable product increment at the end of every sprint. Therefore, teams can release code at the end of every sprint if approved by the product owner. With Kanban, teams can release code anytime or on-demand. 

 

  • Scrum requires three roles - Product Owner, Scrum Master, the Development Team. Kanban, on the other hand, does not prescribe any specific role.

 

  • In Scrum, the smallest piece of business value that a team delivers is a user story. Each user story may then be broken down into smaller tasks or sub-tasks. However, in Kanban, each work item is represented as a Kanban card.

 

  • Scrum is best suited for complex product development efforts that are unpredicatable in nature. Such complex efforts require research, experimentation, and an emergent design. Kanban, on the contrary, is best suited for simple and complicated efforts where things are more predictable than they are unpredictable.

 

  • With Scrum, sprint review and retrospective ceremonies are conducted at the end of every sprint to inspect and adapt. Though Kanban does not prescribe any ceremonies, teams may conduct a review meeting on a monthly or a quarterly cadence to review cycle time, flow efficiency, etc.

 

  • Scrum prescribes user stories to be estimated in terms of story points. However, Kanban does not require work items or Kanban cards to be estimated. In Kanban, estimation is optional. Some teams choose to estimate their work to have more predictability while others prefer to split their cards such that each of the cards is of the same size.

 

  • With Scrum, the most popular metrics are sprint burndown and velocity. Other useful metrics are release burndown, release burnup, and sprint burnup. The most popular Kanban metrics is cycle time. Metrics such as lead time, throughput, cummulative flow diagram (CFD), and control charts are also leveraged.

 

  • Kanban has more flexibility than Scrum as new work items can be added to the workflow at any time. 

 

  • Scrum prescribes ceremonies to be conducted on a regular cadence. For instance, the sprint planning ceremony must be conducted at the start of each sprint. Sprint review and retrospective ceremonies must be conducted at the end of each sprint. In addition, the daily stand-up must be conducted each day of the sprint. However, Kanban does not prescribe any cadence or ceremonies to be conducted. In Kanban, meetings are held as needed.

 

  • With Scrum, additional or new user stories should not be added to the active or an ongoing sprint. However, in Kanban, new work items or cards can be added anytime, provided the WIP (Work-In-Progress) limit hasn't reached yet.

 

  • In Scrum, the sprint backlog is reset after every sprint. However, the Kanban board is continuous.

 

  • To adopt Scrum, enterprises need to develop an agile mindset. Scrum requires a considerable change to the existing organizational structure and processes. As a result, leaders invest into Scrum training and create new roles or positions to build the best Scrum teams. On the contrary, Kanban does not require any significant changes to onboard onto this framework.

 

Now that you understand the differences between the two frameworks, you can decide which approach works best for your team. For more on Agile, Lean, Scrum, or Kanban, you may read below books:

Agile and Lean

Posted on by

Agile and Lean - Same or Different?

Agile and Lean

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
  • Customer collaboration over contract negotiation

One of the 12 Agile principles, ‘Business people and developers must work together daily throughout the project.’ highlights the significance of teamwork and collaboration. 

Customer-centric approach

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 development thinkers 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.

 

More articles:

 

Learn more on Agile, Lean, Scrum, Kanban, and Enterprise Agility with below books:

 

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.