Kanban is a workflow management system that visualizes work and limits work-in-progress. It focuses on optimizing flow and reducing lead times rather than velocity. There are three primary feedback loops in Kanban: daily standups, system capability reviews, and operations reviews. Kanban metrics like lead time, flow efficiency, and work-in-progress are analyzed to understand workflow and identify areas for improvement. Coaches advise teams to adjust work-in-progress based on trends in these metrics.
Cross-department Kanban Systems - 3 dimensions of scaling #llkd15Andy Carmichael
Describes Clearvision's journey of adopting Kanban, not just in the software development team but in Marketing and other departments. Uses 3 dimensions of scaling - Width (before and after); Height (different sizes, timescales, decision-making); Depth (interdependent services at the same level)
STATIK (Systems Thinking Approach to Introduce Kanban) es un enfoque exploratorio y colaborativo para implementar Kanban. Ayuda a entender la demanda y las dinámicas actuales, para diseñar y poner en marcha un modelo Kanban de trabajo que permita elevar la eficiencia y calidad en el servicio a través de la cultura y las técnicas de la mejora continua.
También es una buena herramienta para descubrir todos los servicios que proporciona un equipo, sus flujos de trabajo y su alineación con el propósito y las expectativas del cliente.
Value Stream Mapping: From Tool to Management PracticeTKMG, Inc.
Recorded webinar: http://slidesha.re/1sKe9P7
Subscribe: http://ksmartin.com/subscribe
Purchase the book: http://bit.ly/VSMbk
Too many organizations today suffer from silo-centric behavior and intra-organizational conflict. Yet most don’t understand what’s holding them back from achieving outstanding performance.
Value Stream Mapping (VSM), popularized in Mike Rother and John Shook’s landmark book Learning to See, is a highly effective method for improving performance across an organization. However, VSM is commonly misunderstood, misapplied and under-utilized. Properly executed, value stream mapping is much more than an operations design tool. It also results in a more engaged and knowledgeable leadership team; surfaces hidden cultural and organizational issues; and aligns values, resources, goals and priorities.
In this webinar, you’ll learn how to
* Use value stream mapping as an organizational transformation tool
* Properly scope and plan for a value stream mapping activity
* Obtain leadership consensus about the future state design
* Create and execute a highly effective Value Stream Transformation Plan
Kanban method in four easy steps. Enjoy kanban.
Kanban in 4 easy steps is one of the most popular Kanban presentations. Learn how to successfully implement Kanban in your business process or life. Get to know basic Kanban principles and to see how easily you can improve your productivity using Kanban boards.
Cross-department Kanban Systems - 3 dimensions of scaling #llkd15Andy Carmichael
Describes Clearvision's journey of adopting Kanban, not just in the software development team but in Marketing and other departments. Uses 3 dimensions of scaling - Width (before and after); Height (different sizes, timescales, decision-making); Depth (interdependent services at the same level)
STATIK (Systems Thinking Approach to Introduce Kanban) es un enfoque exploratorio y colaborativo para implementar Kanban. Ayuda a entender la demanda y las dinámicas actuales, para diseñar y poner en marcha un modelo Kanban de trabajo que permita elevar la eficiencia y calidad en el servicio a través de la cultura y las técnicas de la mejora continua.
También es una buena herramienta para descubrir todos los servicios que proporciona un equipo, sus flujos de trabajo y su alineación con el propósito y las expectativas del cliente.
Value Stream Mapping: From Tool to Management PracticeTKMG, Inc.
Recorded webinar: http://slidesha.re/1sKe9P7
Subscribe: http://ksmartin.com/subscribe
Purchase the book: http://bit.ly/VSMbk
Too many organizations today suffer from silo-centric behavior and intra-organizational conflict. Yet most don’t understand what’s holding them back from achieving outstanding performance.
Value Stream Mapping (VSM), popularized in Mike Rother and John Shook’s landmark book Learning to See, is a highly effective method for improving performance across an organization. However, VSM is commonly misunderstood, misapplied and under-utilized. Properly executed, value stream mapping is much more than an operations design tool. It also results in a more engaged and knowledgeable leadership team; surfaces hidden cultural and organizational issues; and aligns values, resources, goals and priorities.
In this webinar, you’ll learn how to
* Use value stream mapping as an organizational transformation tool
* Properly scope and plan for a value stream mapping activity
* Obtain leadership consensus about the future state design
* Create and execute a highly effective Value Stream Transformation Plan
Kanban method in four easy steps. Enjoy kanban.
Kanban in 4 easy steps is one of the most popular Kanban presentations. Learn how to successfully implement Kanban in your business process or life. Get to know basic Kanban principles and to see how easily you can improve your productivity using Kanban boards.
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...TKMG, Inc.
To subscribe: http://ksmartin.com/subscribe
To purchase the book: http://bit.ly/VSMbk
These are slides from a talk given on 1/8/14 in San Diego, California at SME Connect's Operations Roundtable.
Too many organizations today suffer from silo-centric behavior and intra-organizational conflict. And yet most don’t understand what’s holding them back from achieving outstanding performance. This is where Karen Martin’s new book Value Stream Mapping comes into play.
Value stream mapping can unleash the full potential of an organization and deliver greater customer value, increased profit margins, and create fulfilling work environments.
In this talk, Karen discussed how to:
• Prepare and engage your leadership team in the transformation process
• Gain a deep understanding about your current work systems and the related barriers to delivering value
• Design a future state that enables outstanding performance on all fronts
• Adopt a new design and lay the foundation for continued improvement
Janice Linden-Reed's presentation at Lean Kanban Central Europe describing the feedback mechanisms in the Kanban Method used with Enterprise Services Planning to evolve to a business to be "fit for purpose" constantly sensing & responding to political, economic & market changes
Kanban 101 workshop by John Goodsen and Michael Sahota.
This covers everything you will need to know to play Russell Healy's Kanban Game: visualizing the work, metrics, and creating explicit policies.
Slides are available on request. Please email me.
Kanban vs Scrum: What's the difference, and which should you use?Arun Kumar
Originally presented at the 207 Lean Transformation Conference, this presentation provides a practical introduction to Scrum, particularly for public sector employees, and guides you to deciding whether Kanban or Scrum will work best for your teams and projects.
Imported from Japan, Kanban is an agile methodology that is gaining a lot of traction. Kanban, or Japanese for signal card, is a process that focuses on transparency and limiting the work in progress. By utilizing Kanban, you can pinpoint the bottlenecks and address them easily. In this session you will learn what Kanban is, how it evolved from its roots in the Toyota Production System (TPS) and lean manufacturing to software development, Kanban’s benefits, and how best to implement a Kanban system. We’ll also discuss when not to use Kanban and how to modify other agile methodologies, such as Scrum, to be used in conjunction with Kanban.
Implementing Kanban to Improve your WorkflowJennifer Davis
Tutorial from LOPSA East
System, network, and security senior engineers manage intricate relationships ensuring that everything from simple tasks to complex projects gets completed in a timely manner. In this workshop, we will talk about using agile processes to identify, visualize, and improve work.
Outline:
Overview of the kanban process. What is kanban?
Identify common problems.
Define common terminology explicitly.
Work through common problems as a group using kanban.
Identify metrics for improvement.
Review, next steps, additional resources.
At the end of this tutorial, attendees will have a solid understanding of kanban and agile processes to take back to their environments.
Value Stream Mapping: What to Do Before You Dive InTKMG, Inc.
Recorded webinar: http://slidesha.re/1juuPs4
To subscribe: http://ksmartin.com/subscribe
To purchase the book: http://bit.ly/VSMbk
Value Stream Mapping is a powerful way to improve performance across a large portion of an enterprise. But, before you dive into mapping, there are significant steps you must take to assure a successful outcome. In this webinar, award-winning author, Karen Martin shares the proper preparation an organization must take to reap the full set of benefits Value Stream Mapping offers.
Topics include:
Leadership – what is their role?
Scoping – how "big” should you go?
Team formation – who are the right people to include?
Facilitator selection – what traits and skills are needed?
Charter development and socialization – it’s far more than a planning tool!
Logistics & communication – how do you make sure everyone is engaged and prepared?
Watch this webinar for a no-nonsense discussion about the key success factors and common failings in preparing to value stream map.
A Kanban board is a work and workflow visualization tool that enables you to optimize the flow of your work. It utilizes a visual cues that tell you what to produce, how much to produce and when to produce it. This presentation contains brief information related to Kanban board like what is Kanban board, how Kanban works and how to start with Kanban board.
Enterprise Services Planning: Defining Key Performance IndicatorsDavid Anderson
Defining KPIs for use in Enterprise Services Planning and with Kanban systems. Understanding the difference between KPIs, Improvement Guides, and General Health Indicators. Understanding how KPIs drive behavior such as establishing multiple classes of service. Relating KPIs to evolutionary change. KPIs are Fitness Criteria Metrics with defined threashold values
Kanban is the simplest approach which is currently used in software development. Since Kanban prescribes close to nothing there are often a lot of basic questions about the method.
The presentation depicts what Kanban is generally using Scrum as a reference point. Then it presents a series of situations to answer basic questions about working with Kanban
Value Stream Transformation: Achieving Excellence through Leadership Alignmen...TKMG, Inc.
To subscribe: http://ksmartin.com/subscribe
To purchase the book: http://bit.ly/VSMbk
These are slides from a talk given on 1/8/14 in San Diego, California at SME Connect's Operations Roundtable.
Too many organizations today suffer from silo-centric behavior and intra-organizational conflict. And yet most don’t understand what’s holding them back from achieving outstanding performance. This is where Karen Martin’s new book Value Stream Mapping comes into play.
Value stream mapping can unleash the full potential of an organization and deliver greater customer value, increased profit margins, and create fulfilling work environments.
In this talk, Karen discussed how to:
• Prepare and engage your leadership team in the transformation process
• Gain a deep understanding about your current work systems and the related barriers to delivering value
• Design a future state that enables outstanding performance on all fronts
• Adopt a new design and lay the foundation for continued improvement
Janice Linden-Reed's presentation at Lean Kanban Central Europe describing the feedback mechanisms in the Kanban Method used with Enterprise Services Planning to evolve to a business to be "fit for purpose" constantly sensing & responding to political, economic & market changes
Kanban 101 workshop by John Goodsen and Michael Sahota.
This covers everything you will need to know to play Russell Healy's Kanban Game: visualizing the work, metrics, and creating explicit policies.
Slides are available on request. Please email me.
Kanban vs Scrum: What's the difference, and which should you use?Arun Kumar
Originally presented at the 207 Lean Transformation Conference, this presentation provides a practical introduction to Scrum, particularly for public sector employees, and guides you to deciding whether Kanban or Scrum will work best for your teams and projects.
Imported from Japan, Kanban is an agile methodology that is gaining a lot of traction. Kanban, or Japanese for signal card, is a process that focuses on transparency and limiting the work in progress. By utilizing Kanban, you can pinpoint the bottlenecks and address them easily. In this session you will learn what Kanban is, how it evolved from its roots in the Toyota Production System (TPS) and lean manufacturing to software development, Kanban’s benefits, and how best to implement a Kanban system. We’ll also discuss when not to use Kanban and how to modify other agile methodologies, such as Scrum, to be used in conjunction with Kanban.
Implementing Kanban to Improve your WorkflowJennifer Davis
Tutorial from LOPSA East
System, network, and security senior engineers manage intricate relationships ensuring that everything from simple tasks to complex projects gets completed in a timely manner. In this workshop, we will talk about using agile processes to identify, visualize, and improve work.
Outline:
Overview of the kanban process. What is kanban?
Identify common problems.
Define common terminology explicitly.
Work through common problems as a group using kanban.
Identify metrics for improvement.
Review, next steps, additional resources.
At the end of this tutorial, attendees will have a solid understanding of kanban and agile processes to take back to their environments.
Value Stream Mapping: What to Do Before You Dive InTKMG, Inc.
Recorded webinar: http://slidesha.re/1juuPs4
To subscribe: http://ksmartin.com/subscribe
To purchase the book: http://bit.ly/VSMbk
Value Stream Mapping is a powerful way to improve performance across a large portion of an enterprise. But, before you dive into mapping, there are significant steps you must take to assure a successful outcome. In this webinar, award-winning author, Karen Martin shares the proper preparation an organization must take to reap the full set of benefits Value Stream Mapping offers.
Topics include:
Leadership – what is their role?
Scoping – how "big” should you go?
Team formation – who are the right people to include?
Facilitator selection – what traits and skills are needed?
Charter development and socialization – it’s far more than a planning tool!
Logistics & communication – how do you make sure everyone is engaged and prepared?
Watch this webinar for a no-nonsense discussion about the key success factors and common failings in preparing to value stream map.
A Kanban board is a work and workflow visualization tool that enables you to optimize the flow of your work. It utilizes a visual cues that tell you what to produce, how much to produce and when to produce it. This presentation contains brief information related to Kanban board like what is Kanban board, how Kanban works and how to start with Kanban board.
Enterprise Services Planning: Defining Key Performance IndicatorsDavid Anderson
Defining KPIs for use in Enterprise Services Planning and with Kanban systems. Understanding the difference between KPIs, Improvement Guides, and General Health Indicators. Understanding how KPIs drive behavior such as establishing multiple classes of service. Relating KPIs to evolutionary change. KPIs are Fitness Criteria Metrics with defined threashold values
Kanban is the simplest approach which is currently used in software development. Since Kanban prescribes close to nothing there are often a lot of basic questions about the method.
The presentation depicts what Kanban is generally using Scrum as a reference point. Then it presents a series of situations to answer basic questions about working with Kanban
Agile China - Deep Kanban - Worth The Investment?David Anderson
Implementing deeper Kanban and the extra value it brings for organizations who make the investment. The Depth of Kanban Assessment Framework and how to use it.
A workshop presenting tools to define what is success for you Kanban system and how to get there using Continuous Improvements.
This material was first presented at the Lean Kanban North America conference 2016 in San Diego
You’ve had some success with your Kanban System: you’ve managed flow and quickly increased your capability. But now the energy goes down, your Kanban system – (r)evolutionary at first - becomes the new normal. How do you keep momentum? How do you keep succeeding in the long term?
Building on the insights gathered by starting and following more than 70 Kanban implementations, this talk presents a set of tools designed to discover the real purpose of your Kanban system. You will understand your quest, your origin story, your strengths and weaknesses. Having found your “Why”, you will be able to create a plan to lift your Kanban system from good-enough to great. You will have unity and alignment around a strong sense of purpose: the bases to make you Kanban system resilient!
The interactive Kanban Pizza Game demonstrates how a Kanban System works. While common Kanban games usually focus only on the flow of an existing Kanban system, our new Kanban Pizza Game goes beyond that, demonstrating the path from an existing process to Kanban. Learning by doing and having fun at the same time - that‘s what our Kanban Pizza Game is all about.
_______
Here are the links for the printouts for the orders, the oven plate and the point-system, which I used in this set up:
https://www.dropbox.com/s/0wvbblo65lyndht/Kanban%20Pizza%20Game%20-%20Orders.pdf?dl=0 https://www.dropbox.com/s/wghw809788go0iq/Kanban%20Pizza%20Game%20-%20pizza%20plate.pdf?dl=0
https://www.dropbox.com/s/tyj08gm510pkjkk/Kanban%20Pizza%20Game%20-%20Point%20System.pdf?dl=0
Updated version at https://www.slideshare.net/GiulioRoggero/kanban-board-82363781
Do you have a team that works on both project and maintenance? Do you need to organize your team activities? Do you have a lot of activities in parallel and the time to market it's a problem? With a Kanban board and an Agile approach you can solve your problems!
Take a look of the animation of the slides to discover how it works.
Scrum vs Kanban - Which Agile Methodology Fits Best For Your Team?Invensis Learning
Scrum vs Kanban? Which fits best for your team? Learn the key differences between the two popular Agile frameworks, Scrum and Kanban. Also, learn when to use these two Agile Methodologies.
https://www.youtube.com/watch?v=pxxmSLJj8FQ&t=435s
WebCamp: Project Management Day: World of Agile: Kanban - Евгений АндрушкоGeeksLab Odessa
World of Agile: Kanban
Евгений Андрушко
Project Manager at Softserve
- Что общего между садом сакуры и тойота?
- Какую методологию выбрать на Вашем проекте?
- Реальная практика примения Kanban SDLC.
- Kanban kick-start.
- Kanban vs Iterative agile.
- Софт для Agile: Lean Kanban vs Jira vs Trello.
Kanplexity - a jumping-off point for Cynefin using KanbanOrderly Disruption
Kanplexity - a jumping-off point for Cynefin using Kanban, a complexity expansion pack for Kanban. Kanban is based on Kanban Guide and Cynefin, with strong influences from various communities. Kanplexity has a direction of travel, a team or crew, a guide, an orientation reference, a rhythm of interactions, and guidance for multi-team/crew patterns and agile products & projects.
Kanban is a scheduling system for lean manufacturing and just-in-time manufacturing. Kanban is an inventory-control system to control the supply chain. Taiichi Ohno, an industrial engineer at Toyota, developed kanban to improve manufacturing efficiency.
Scrum, Kanban, and DevOps Sitting in a Tree… - Big Apple Scrum Day 2018Yuval Yeret
Scrum, Kanban, and DevOps Sitting on a Tree... (Learn how to leverage Kanban & Scrum together and how to fit DevOps into the picture)Should we use Scrum? Should we use Kanban? Where does DevOps fit into the picture? The best agile teams already know they don’t need to choose. Scrum teams improve when they start to look at flow inside and outside their sprints. Kanban teams improve when they have a disciplined cadence, and effective Product Ownership and Scrum Mastership. DevOps really is mainly about doing Agile the right way. In this session, we will look at a core definition of Scrum, Kanban & DevOps, do some myth-busting as well as identify the quite significant common ground between Scrum, Kanban and DevOps. We will then look at practical ways like the Kanban-based Sprint Backlog, Flow-based Daily Scrum, Visualizing aging work, Flow-based Sprint Planning - which bring some Kanban flow into your Scrum. We will look at how to bring Scrum roles/events/artifacts into your Kanban. We will look at ways to wrap Scrum with a Kanban Flow system that looks upstream/downstream and at the higher level picture of a DevOps Culture/Process. You’ll leave with a better understanding of how Scrum, Kanban, and DevOps relate to each other and with some ideas for experiments to try when back at work.
Pecha kucha format- how can devops be implemented with lean and agileRavi Tadwalkar
Title:
-------
Case Study: Lean Manufacturing plant level continuous improvement
How can DevOps be implemented with Lean and Agile?
Description:
-----------------
How can we leverage our knowledge of Lean Manufacturing and TPS (Toyota Production System) to implement Agile & DevOps in organizations?
My topic is about "how DevOps can be implemented with Lean and Agile", by implementing Enterprise Kanban system that has this value stream:
“Portfolio Kanban (upstream “Epics”) -> Scrum / ScrumBan / Kanban “In the middle” -> Release Engineering Kanban(Downstream “Deployable Artifacts”),
Presentation History:
Agile2016, PechaKuchaLightening Talk on July 27, 2016
Reference:
---------------
Slides 21-27 in my preso:
http://www.slideshare.net/RaviTadwalkar/devops-approach-point-of-view-by-ravi-tadwalkar
Senior Project and Engineering Leader Jim Smith.pdfJim Smith
I am a Project and Engineering Leader with extensive experience as a Business Operations Leader, Technical Project Manager, Engineering Manager and Operations Experience for Domestic and International companies such as Electrolux, Carrier, and Deutz. I have developed new products using Stage Gate development/MS Project/JIRA, for the pro-duction of Medical Equipment, Large Commercial Refrigeration Systems, Appliances, HVAC, and Diesel engines.
My experience includes:
Managed customized engineered refrigeration system projects with high voltage power panels from quote to ship, coordinating actions between electrical engineering, mechanical design and application engineering, purchasing, production, test, quality assurance and field installation. Managed projects $25k to $1M per project; 4-8 per month. (Hussmann refrigeration)
Successfully developed the $15-20M yearly corporate capital strategy for manufacturing, with the Executive Team and key stakeholders. Created project scope and specifications, business case, ROI, managed project plans with key personnel for nine consumer product manufacturing and distribution sites; to support the company’s strategic sales plan.
Over 15 years of experience managing and developing cost improvement projects with key Stakeholders, site Manufacturing Engineers, Mechanical Engineers, Maintenance, and facility support personnel to optimize pro-duction operations, safety, EHS, and new product development. (BioLab, Deutz, Caire)
Experience working as a Technical Manager developing new products with chemical engineers and packaging engineers to enhance and reduce the cost of retail products. I have led the activities of multiple engineering groups with diverse backgrounds.
Great experience managing the product development of products which utilize complex electrical controls, high voltage power panels, product testing, and commissioning.
Created project scope, business case, ROI for multiple capital projects to support electrotechnical assembly and CPG goods. Identified project cost, risk, success criteria, and performed equipment qualifications. (Carrier, Electrolux, Biolab, Price, Hussmann)
Created detailed projects plans using MS Project, Gant charts in excel, and updated new product development in Jira for stakeholders and project team members including critical path.
Great knowledge of ISO9001, NFPA, OSHA regulations.
User level knowledge of MRP/SAP, MS Project, Powerpoint, Visio, Mastercontrol, JIRA, Power BI and Tableau.
I appreciate your consideration, and look forward to discussing this role with you, and how I can lead your company’s growth and profitability. I can be contacted via LinkedIn via phone or E Mail.
Jim Smith
678-993-7195
jimsmith30024@gmail.com
The Team Member and Guest Experience - Lead and Take Care of your restaurant team. They are the people closest to and delivering Hospitality to your paying Guests!
Make the call, and we can assist you.
408-784-7371
Foodservice Consulting + Design
The case study discusses the potential of drone delivery and the challenges that need to be addressed before it becomes widespread.
Key takeaways:
Drone delivery is in its early stages: Amazon's trial in the UK demonstrates the potential for faster deliveries, but it's still limited by regulations and technology.
Regulations are a major hurdle: Safety concerns around drone collisions with airplanes and people have led to restrictions on flight height and location.
Other challenges exist: Who will use drone delivery the most? Is it cost-effective compared to traditional delivery trucks?
Discussion questions:
Managerial challenges: Integrating drones requires planning for new infrastructure, training staff, and navigating regulations. There are also marketing and recruitment considerations specific to this technology.
External forces vary by country: Regulations, consumer acceptance, and infrastructure all differ between countries.
Demographics matter: Younger generations might be more receptive to drone delivery, while older populations might have concerns.
Stakeholders for Amazon: Customers, regulators, aviation authorities, and competitors are all stakeholders. Regulators likely hold the greatest influence as they determine the feasibility of drone delivery.
Oprah Winfrey: A Leader in Media, Philanthropy, and Empowerment | CIO Women M...CIOWomenMagazine
This person is none other than Oprah Winfrey, a highly influential figure whose impact extends beyond television. This article will delve into the remarkable life and lasting legacy of Oprah. Her story serves as a reminder of the importance of perseverance, compassion, and firm determination.
Artificial intelligence (AI) offers new opportunities to radically reinvent the way we do business. This study explores how CEOs and top decision makers around the world are responding to the transformative potential of AI.
Advanced kanban overview for waterfall & scrum practitioners (16x9 deck)
1. Advanced
Kanban Overview
for Waterfall/Scrum Practitioners
Ravi Tadwalkar
Lean/Agile/DevOps Coach
Co-founder, “Cisco Internal Coaches Network”;
Event Organizer, AgileCamp.org & SVALN
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
2. Advanced Kanban Overview
Top 5 Topics for Discussion:
1. Compare “Toyota kanban” (aka TPS) with “software kanban” (aka “K”anban)
2. Scrum
vs. Scrumban
vs. Kanban
Evaluator
3. Feedback Loops
in Kanban
4. Kanban Metrics
5. Kanban Depth Framework- A Model for Kanban Team Assessment
3. Compare
Kanban for lean manufacturing (aka TPS)
With
Kanban for knowledge work (aka “K”anban)
4. Kanban for lean manufacturing
TPS (Toyota Production System) invented “kanban”
• In Lean Manufacturing, a kanban is a signaling device that gives authorization and instructions for production or
withdrawal (conveyance) of items in a pull system.
Toyota's Six Rules from TPS
1. Later process picks up the number of items indicated by the kanban at the earlier process.
2. Earlier process produces items in the quantity and sequence indicated by the kanban.
3. No items are made or transported without a kanban.
4. Always attach a kanban to the goods.
5. Defective products are not sent on to the subsequent process.
The result is 100% defect-free goods.
6. Reducing the number of Kanban reduces WIP and increases the sensitivity of the system to pull signals (kanbans),
because there is less buffer between the processes.
Kanbans maintain inventory levels; a signal is sent to produce and deliver a new shipment as material is consumed.
These signals are tracked through the replenishment cycle and bring extraordinary visibility to suppliers and buyers.
Purpose: Logistic control system
Implemented at: Toyota
Date implemented: 1953
Source: Ohno, Taiichi (1988)
5. Kanban for knowledge work
• David J Anderson created “K”anban, now known as Kanban Method. Kanban
for knowledge work is a management method of just-in-time delivery based on
capacity to do work. As such, here the focus is not to overload the team
members.
• In kanban, the process workflow, from definition of work to its delivery to the
customer, is displayed for participants to see and team members pull work
from each queue.
• Kanban for software development means a visual process management system
that tells what to produce, when to produce it, and how much to produce-
inspired by the Toyota Production System and Lean Manufacturing.
• For more details on “Kanban (Method)”, please check out this wikipedia page.
Source: : David J Anderson (2010)
6. Done
F
E
I
Engineering
Ready
Deployment
Ready
G
D
GY
PB
MN
2 ∞
P1
AB
Ongoing
Development Testing
Done Verification Acceptance
3 3
DE
Proto-Kanban
You may have used or seen a kanban board for running events like conference or even hackathon.
Whenever a team starts visualizing work with a kanban board, that team is doing proto-kanban!
Explicit policies &
WIP Limits based on
queues (aka lanes or
columns)
Lead time ends at
1st infinite queue!
There could be
additional queues
with no WIP limit.
Lead time
“clock” starts
at the 1st
queue aka
input queue!
7. Done
F
E
I
Engineering
Ready
Deployment
Ready
G
D
GY
PB
MN
2 ∞
P1
AB
Ongoing
Development Testing
Done Verification Acceptance
3 3
Expedite
1
3
Fixed
Date
Standard
Intangible
2
2 DE
Lead time ends at
1st infinite queue!
Lead time “clock”
starts at input queue!
NPD
i.e.
New
Prod
Dev
(60%)
Defect&
Tech
Debt
(30%)
Innov
ation
(10%)
Getting Beyond Proto-KanbanGetting beyond visual board:
Hedge risk by allocating capacity, by defining WIP limits to shape demand (total WIP) for queues/swimlanes.
Explicit policies &
WIP Limits
based on classes of
service & work type!
5
2
1
In my kanban coaching experience, kanban "flow
& pull" aspect orientation forces you to "stop
starting, start finishing", better than scrum
"inspect & adapt" orientation. Kanban being
workflow management tool, requires solid
engineering practices for teams to succeed in
lean software development. However, it's non-
prescriptiveness can let newbies fall back on
practices & controls that worked in waterfall
world. For those, I have always found scrumban
to be a practical middle-ground since it brings
best from both scrum and kanban.
8. From proto-kanban to kanban: A Practitioner’s Way to improve Flow Efficiency
A team improves its average lead time and flow efficiency by applying explicit policies, WIP limits for queues/swim-lanes, at regular cadence!
Mature kanban teams calculate lead time when accepting cards flowing on the physical/virtual card wall, with scrumban-style regular cadence.
After participating in release planning, such kanban teams commit to iterative development/support on a cadence so as to finish in 1-2 weeks.
Rallying with
virtual kanban
board & syncing
physical card wall
with it! That’s
one way to do
scrumban!
Source: PayPal
9. Scrum
vs.
Scrumban
vs.
Kanban
Evaluator
Scrumban Level 1
- Scrum but no commitment to the content
- Teams get most value out of daily standups,
retrospectives, grooming and to a lesser degree
planning (at least some planned work is done)
- Aim to empty the queue in each timebox
- Don't split stories
Scrumban Level 2
- Essentially Kanban but timeboxed
- It forces stories to be broken down so work is
completed (versus open ended Epics)
- Aim to empty the queue in each timebox
- Don't split stories
10. Compare & Contrast Scrum, Scrumban & Kanban:
Do Planning to fill available (not all) slots
User Story Template
• scrumban/kanban process is about moving story/task/activity cards as fast as you can across the value stream to have
shortest lead time. This requires slightly different way to look at requirements than following scrum-style user story
templates.
– So while it does help when you use a user story template with tasks associated for teams that prefer that kind of card on their board,
it can very well be at a granular activity level if all other cards on the board are of similar size and they are also activities rather than
stories. Unlike scrum framework, in kanban (and scrumban) there is no need to take a particular stance on this.
– Stories hover around typical size for kanban/scrumban teams (e.g. 3,5,8 if average size is a 5 pointer story).
• Kanban manifesto could very well begin with this one liner: We prefer having typical sizes over following user story template!
• Kanban does not put emphasis on estimation of work, as long as all work items have similar levels of effort, complexity & risk.
– Decomposition- using patterns for splitting (i.e. slicing) work- remains same scrumban adds timeboxing on top of kanban board.
Planning mechanism
• This is another area where contrasting scrumban with scrum and kanban makes a lot of sense, based on Corey Ladas's
blog about scrumban. In scrumban (& kanban), planning is done to fill the available (not all) slots: just in time & slack.
Timeboxing
• Scrumban does not distinguish between sprints/releases. It’s better to call it "timebox".
– That way folks will know that in scrumban, burndown is less important than Lead Time and Cycle Time. Here are quotes from the
scrumban creator Corey Ladas whose blog exemplifies this. Read on these 3 excerpts:
11. Burndown is
less important than
Lead Time and Cycle Time
"With the pull system in place, our flow will become smoother as our process capability
improves. We can use our inter-process buffers and flow diagrams to show us our process
weaknesses and opportunities for kaizen. As we get closer to level production, we will start to
become less concerned with burndown and more concerned with cycle time, as one is the
effect and the other is the cause. Average lead time and cycle time will become the primary
focus of performance. If cycle time is under control and the team capacity is balanced against
demand, then lead time will also be under control. If cycle time is under control, then
burndowns are predictable and uninteresting. If burndowns are uninteresting, then goal-setting
and risky heroic efforts are unnecessary. If burndowns are uninteresting, then iteration backlogs
are just inventory for the purpose of planning regularity and feeding the pull system. As such,
they should be the smallest inventories possible that optimize planning cost."
12. Sprint backlog-
Smallest Inventory
to Optimize Planning Cost
"A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than go
through the trouble of estimating a scope of work for every iteration, just make the backlog a
fixed size that will occasionally run to zero before the planning interval ends. That’s a simple
calculation. It’s just the average number of things released per iteration, which in turn is just a
multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days
to complete something, on average, then you’ll finish 1 thing per day, on average. If your
iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10.
You can add one or two for padding if you worry about running out. This might be a point that’s
been lost on the Scrum community: it’s never necessary to estimate the particular sizes of
things in the backlog. It’s only necessary to estimate the average size of things in the backlog.
Most of the effort spent estimating in Scrum is waste."
13. Why estimate
the average size of
things in the backlog?
"In our final incarnation of Scrumban, iteration planning still happens at a regular
interval, synchronized with review and retrospective, but the goal of planning is to fill
the slots available, not fill all of the slots, and certainly not determine the number of
slots. This greatly reduces the overhead and ceremony of iteration planning. Time
spent batch processing for iteration planning estimation can be replaced with a
quality control inspection at the time that work is promoted to the ready queue. If a
work item is ill-formed, then it gets bounced and repeat offenders get a root cause
analysis."
14. Process Framework Evaluator –
An Example Questionnaire
Questions Explanation
Planning:
Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox?
Do you have more than 25% scope churn during the chosen timebox?
Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their
delivery.
Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily
to quickly changing priorities.
Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the
slots, and certainly not to determine the number of slots.
Decomposition:
Even after trying your best, is it impossible to break features into incremental pieces of value to
be delivered within the chosen timebox?
Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can
help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective).
Scrumban: Can you decompose work to lock scope for the timboxed duration?
Estimation:
Is it hard or impossible for the team to size the work in the chosen timebox?
Does estimation take more than 3 hours?
Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be
comprised of similarly sized activities for Kanban.
Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint.
Scrumban: Scrumban does not require estimation.
Responsiveness:
Is your top priority to optimize responsiveness to customer needs?
Must work begin in the current timebox (cannot wait until the next one)?
Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity.
Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the
potential cost of productivity.
Predictability & Productivity:
Is your top priority predictability and productivity for larger projects?
You can achieve predictability and a high level of productivity using any agile framework.
Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams.
Process Oriented Culture:
Does your team culture demand a higher degree of process ceremonies?
Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more
easily be integrated into a culture requiring them.
Shared Team Members:
Do you share engineers with other teams? Does your team lack all the required skills to complete
the work?
Scrum: Scrum teams work best when they do not have dependencies on people outside of the team
.
Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time.
Variety in work (complexity & size):
Are your work items of approximately similar size & complexity?
Both Scrum and Kanban work very well with similar sized work items.
However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
Source: Steve Sanoff
15. Primary Feedback Loops in Kanban
Kanban has three primary feedback loops:
1. Daily standups (team level)
2. System capability review (team/department level), and
3. Ops review (organizational).
Kanban includes many retrospective feedback loops, focused on
various aspects of improvement and closing daily, monthly and
every time in between.
16. Implement Feedback Loops in Kanban
• Daily Standups
– First level of feedback is daily standups, where team collaborates to review flow of work and demand versus
capability measures, metrics and indicators.
– Why are daily standups in kanban are done differently than “daily scrums”?
• Purpose of primary feedback loop - daily standup - in kanban
– The focus of a kanban daily standup is on “flow”, with sanity check on WIP limits set for queues and swim-lanes. Your read the
kanban board from right to left, as if the team were to read an Arabic poem! Watch what’s due in expedite, intangible & any
other work-type specific swim-lanes, where the bottlenecks are developing, what is blocking the flow.
– It’s no more about the scrum-style “3 questions” format then.
• With that, size of a kanban team is not the issue, so team size can exceed the scrum team size of 5-9.
• Daily standups result in the team/workgroup-level problem-solving activities that foster collaboration.
• System Capability Review
– Second level of feedback is known as system capability review – this is where the demand is shaped (replenished)
at cadence based on average lead time. (We will revisit “shaping demand” when discussing average lead time, later.)
– This feedback is at the level of the team, workgroup, department or business unit.
• Ops Review
– Third level of feedback - operations review – is where organizational process improvements occur beyond a
localized team level, to realize full benefits of Kanban.
17. 0
20
40
60
80
100
120
140
160
48 1 6 9 1217202326293235384144475053 3 6 9 12151821242730333639
2012 2013 2014
Throughput
(# of resolved tickets / week)
Average Lead Time / week
Average Flow Efficiency % / week
Kanban Metrics
* Lead Time Distribution indicates Predictability
* Average Lead Time impacts SLA Adherence
* High Productivity means better “Flow Efficiency”
* Monte-Carlo forecasting for planning fixed bid projects
How do you coach a kanban team
on adjusting their "Total WIP“? By
observing trends in throughput,
lead time & flow efficiencies!
Apply Little’s law:
Total WIP (for each workday) =
Avg. delivery rate (per workday)
* Avg. lead time (in workdays)
Source: PayPal
18. Lead Time Distribution indicates Predictability
• Lead Time Distribution Curve
– Average lead time helps “shape demand” by
coming up with a cadence for replenishing
input queue for “planning” work intake.
– Team can try to reduce the average lead time
by doing scrum-style decomposition.
– Example stats:
• Analyzing Lead Time Distribution Curve
– Have you ever wondered how we measure lead time
in Kanban and how we make use of them?
– Alexei Zheglov has posted a couple of insightful articles
on how to analyze, measure and understand lead time.
Click to read more -
• Analyzing the Lead Time Distribution Chart
• Inside a Lead Time Distribution
• Introducing Lead Time Forecasting Cards
• Scrum Commitments, Little’s Law, and Variability
• Lead Time and Iterative Software Development
– Alexei Zheglov shows how scrum teams can analyze
lead time distribution curve using mode, median, average
and 75 percentile values of lead times as shown here:
Lead Time Stats
33.80435(Average)
26.5 (Median)
0(Mode)
0
2
4
6
8
10
0 10 20 30 40 50 60
Frequencies
Lead Times
Lead Time Distribution (Frequency Curve)
Lead Time Frequencies
Smoother frequency curve is better!
19. Average Lead Time impacts SLA Adherence
• Due Date Performance
– For SLA adherence
for classes of service,
Due Date Performance
metric can be used.
– In this example,
the +ve numbers indicate
few missed SLAs, whereas
the –ve numbers indicate
that the SLAs were met
on time or even earlier.
– According to Russell Healy, creator of getkanban board game: +ve and -ve values should not be treated equally. The cost of
delay for a fixed delivery date item is a "Heaviside step function" (http://en.wikipedia.org/wiki/Heaviside_step_function)
modified for the opportunity cost incurred for -ve values of x. Go figure!
10/3/2013
11/22/2013
1/11/2014
3/2/2014
4/21/2014
6/10/2014
7/30/2014
-50 0 50 100 150 200 250 300 350
AcceptanceDates
SLA Adherence
Due Date Performance
Accepted Date
earlier (i.e. on time or before) is better!
20. High Productivity means better “Flow Efficiency”
Flow Efficiency metric
• What percentage of lead time does a work item actually take end-to-end, on an average?
By comparing lead time against the touch time (aka assigned time), we get “waste indicator”.
• waste can be due to high WIP
• waste can be due to wait/blocked times
• How to compute Flow Efficiency?
• It should be possible to create
histogram based this formula:
Flow Efficiency =
“touch time”
/ “lead time”
• Although very difficult to measure
flow efficiency for knowledge work,
histograms are useful
• David Anderson mentions that
15% flow efficiency is quite normal
for knowledge workers. In this example,
max flow efficiency is 5.3%, with
average of 0.6% which is too low.
• What can teams do to increase it?
In other words:
How do you use this metric to inspire teams to be even more productive?
In order to improve flow efficiency , teams should try to reduce the WIP, so that less cards will have delays due to wait times and/or blocked times.
0
5
10
15
20
25
30
35
40
FlowEfficiency%
Acceptance Dates
Flow Efficiency (Ratio)
Flow Efficiency
higher % is better! It
means there is not much
waste!
21. Monte-Carlo forecasting for planning fixed bid projects
Monte Carlo Simulation
• Lean Kanban community & tool vendors recommend using Monte Carlo based forecasting for planning fixed bid projects,
e.g. the forecast below:
Use the 85 percentile as the delivery time
• Based on projected delivery time histogram above, Dimitar Bakarzhiev recommends using 85th percentile for
commit point, which David Anderson talks about during his kanban training as well.
0.00%
20.00%
40.00%
60.00%
80.00%
100.00%
120.00%
Probability
Projected Delivery time (days)
Source: Dimitar Bakardzhiev
22. Control Chart vs. “Time In Process”
• Control Chart for Lead Time Variability
Control chart can be used to determine lead time variability. It is a useful way to observe anomalies about out-of-control frequencies of lead
times. In the example below, there are outlier lead times with values of greater than 80 days. Team should analyze special causes behind those
outliers before ruling those out, to get smoother control “band”:
• Time In Process
– This metric is specific to Rally Insights tool, and sounds very complementary to lead time, cycle time, and time to market.
– Time in Process is the number of business days a typical user story is in the "In-progress" or "Completed" column. (i.e. not accepted yet).
– Why is this Important? According to renouned metrics guru Larry Maccherone, Accurate planning & budgeting need accurate estimates.
– Time in Process charting in Rally shows how long the median of Stories are in process.
-50
0
50
100
150
200
10/3/2013 11/22/2013 1/11/2014 3/2/2014 4/21/2014 6/10/2014 7/30/2014
LeadTimes
Acceptance Dates
Control Chart for Lead Time Variability
Lead Time
Smoother control band is better!
24. Practitioners in smaller organizations have tended to adopt
a relative assessment model
Outer edge
defines
specific local
goals
Visualize
Limit WIP
Manage FlowExplicit Policies
Feedback Loops
Improvements
Activity Not present
at
Proto-Kanban levelWhere we would
like to be
25. Assessing the Depth of
a Kanban Implementation
Limit WIPFeedback
Loops
(13)
(4)
(11)(12)
(7)
(10) VisualizeImprove
Explicit Policies Manage Flow
7
1
2
5
2
Lean
Excellence
10
2
68
3
2
Effects
4
7
(12)
12
3
10
10
6
4
10
Improving Sustainably
Necessary for
sustainable
improvements
6
• See & Understand
(WIP, Blocks, Queues)
• Increase Liquidity
• Measure Flow / capability
(WIP, throughput, Queues,
lead time)
• Defer Commitment
• Improve Predictability
• Reduced Task Switching
• Reduced Lead times
• Reduced Overburdening
(quality, sustainability)
• Set Standards to improve upon
• Generate actionable
feedback (information)
from stakeholders to
improve
• Improve continuously in a
sustainable way
Source: Christophe Achouiantz – @ChrisAch
26. Team:
________
Date:
__/__/__
Visualize
1. Work (all, according to current policies)
2. Work Types
3. Workflow (“process”, way-of-working, value stream)
4. ‘Next’ & ‘Done’
5. Current Team Focus (avatars)
6. Blocks
7. Current Policies (DoD, DoR, capacity allocations, etc.)
8. Ready for Pull (“done” within the workflow/in columns)
9. Metrics (lead-times, local cycle times, SLA targets, etc.)
10. WIP limits
11. Inter-work dependencies (hierarchical, parent-child, etc.)
12. Inter-workflow dependencies
13. Risk dimensions (cost-of-delay, technical risk, market risk)
Limit Work in Progress
1. No WIP limit, but commitment to finishing work over
starting new (eventually reaching a WIP level that “feels
OK” for the team)
2. Some explicit WIP limits, at lower level than workflow
(a.k.a Proto-Kanban): personal Kanban, WIP limit per
person, WIP limits for some columns or swim-lanes,
workflow with infinite limits on “done” queues, etc.
3. Explicit WIP limit at workflow level - Single workflow full
pull
4. Multiple interdependent workflows with pull system
Manage Flow
1. Daily planning meetings (as “daily” as agreed by policies)
2. Blocks out of team control are escalated for resolution
3. Next is re-prioritized continuously (no commitment in Next)-
Deferred Pull decisions (dynamic prioritization)
4. CFDs (updated at least once a week)
5. Control Charts (updated at least once a week)
6. Size of ongoing work items is limited (large work is broken
down)
7. Flexible staff allocation (swarming)
8. Cadence is established (planning, delivering, retrospective)
9. Flow metrics (number of days blocked, lead-time efficiency)
10. SLA expectations and forecasts (lead-time targets)
11. Capacity Allocations
Make Policies Explicit - All Policies must be CURRENT (known & actually used)
1. Definition of Work Types and Work Item (template)
2. How to pull work (selection from ‘Next’/prioritization of WIP)
3. Who and when manages the ‘Next’ and ‘Done’ queues
4. Staff allocation / work assignment (individual focus)
5. Definition of Ready for ‘Next’
6. Who, when and how to estimate work size
7. Limit size of work items (work breakdown)
8. How to select & prepare work for the ‘Next’ queue
9. Definition of Done at all steps (seen as a Target Condition)
10. Knowledge spreading/sharing strategy
11. Class-of-Service
12. Capacity allocation
Implement Feedback Loops
1. Daily Team standups
2. Key stakeholders (mngt, customers, other groups) are
regularly updated on the current situation
3. Managers go and see (walk the ‘gemba’) regularly
4. Regular discussions with upstream and downstream
partners
5. Regular presentations and discussions about Financial
performance
6. Regular presentations and discussions about Quality KPI
(defect rate, customer satisfaction, etc.)
7. “Regularly” means once per month or more often
Improve
1. The group knows why it exists and its criteria for success
2. Regular Retrospectives / Kaizen events
3. The team knows its current condition (may require metrics)
4. True North exists, is communicated and shared by the team
5. The team knows the current target condition (the challenge)
6. There is a validation criteria (test) for the current target condition to
know when the target condition is reached
7. The team knows what obstacles are preventing them from reaching
the target condition
8. The team knows what obstacle is being currently addressed
9. The team knows what is the next step in resolving the current obstacle
(PDCA)
10. The team go and see what they have learned from taking that step
Effects (seeing Evidence of…)
1. Team members are seeing and understanding the Big Picture
(team-level vs. local situations)
2. Better “team spirit” (helping each-others to complete work,
respect)
3. Focus on removing blocks
4. Focusing on finishing work rather than starting new work
5. Team is working on the “right” thing (“right” prioritization)
6. Limiting work to team’s capacity (limited stress, optimal lead-
times)
7. Team has motivation to drive improvements
8. Local process evolution (visualization, workflow, policies, WIP
limits)
9. Increase depth of Kanban implementation
10. Process evolution was model-driven
11. Process or management policy evolution as a result of mentor-
mentee
12. Inter-workflow or management policy evolution due to
Limit WIPFeedback
Loops
(13)
(4)
(11)(12)
(7)
(10)
Visualize
Improve
Explicit Policies Manage Flow
7
1
2
5
2
Lean
Excellence
10
2
68
3
2
Effects
4
7
(12)
12
3
10
10
6
4
10
Baseline
Necessary
6
Source: Christophe Achouiantz – @ChrisAch
00Current
”Score”
Trend
27. References & External Links
There is more continuous improvement happening in Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”),
Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team assessment survey) or Hakan Forss (creator of flow efficiency
metric as the primary Kanban metric).
References
• Pre-requisite #1: “STOP Starting, START finishing” by Arne Roock
• Pre-requisite #2: Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press.
• Pre-requisite #3: Anderson, David (April 2012). Lessons in Agile Management- On the road to Kanban. Blue Hole Press.
• Pre-requisite #4: Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas
• External links
– David Anderson’s blog posts & Henrik Kniberg’s blog posts
– InfoQ eBooks by Henrik Kniberg & others [e.g. Jasper Boeg (2012-02). "Priming Kanban" (in English). InfoQ]
– The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
– Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas
– What is Kanban? by Joseph Hurtado
– Aspects of Kanban by Karl Scotland
– De-mystifying Kanban by Al Shalloway of Net Objectives
– Kanban Applied to Software Development: from Agile to Lean
– What is Best, Scrum or Kanban?
– Kanban for Teams by Al Shalloway
– Open Kanban Presentation
– Open Kanban Documentation
– LKNA conferences & related links
• https://plus.google.com/113439681622341364754/videos
• http://leankanban.com/case-studies
• http://blackswanfarming.com/cost-of-delay/
Editor's Notes
A Wine (or tea) tasting session based on Ravi Tadwalkar’s training during KCP (Kanban Coaching Professional) Masterclass for kanban practitioners taught by LKU (David Anderson), during 2014, Apr 28 – May 2; and LKNA 2014, during 2014, May 5-8- both events held at SFO.
New to kanban? The name ‘kanban' originates from Japanese[かんばん] (Chinese: 看板), and translates roughly as "signboard" or "billboard".
In both Japanese and Chinese, the syllable “kan” is used a verb and it means “to see”; and “ban” means “billboard”.
While we are starting this workshop, glance thru’ a tiny booklet titled “STOP Starting, START finishing” by Arne Roock. I usually distribute ~10 copies that I use for this kind of event. We can play getkanban game at a later time when possible.
In my kanban coaching experience, kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found scrumban to be a practical middle-ground since it brings best from both scrum and kanban. In this session, we will discuss 5 important topics related to kanban and scrumban, comparing & contrasting with scrum, as and when needed.
New to kanban? The term ‘kanban' originates from Japanese[かんばん] (Chinese: 看板), and translates roughly as "signboard" or "billboard".
In both Japanese and Chinese, the syllable “kan” is used a verb and it means “to see”; and “ban” means “billboard”.
While we are starting this workshop, glance thru’ a tiny booklet titled “STOP Starting, START finishing” by Arne Roock. I usually distribute ~10 copies that I use for this kind of event. We can play getkanban game at a later time when possible.
We will focus on these 5 topics for discussion:
Comparing “Toyota kanban” with “software kanban”
Scrum vs. Scrumban vs. Kanban
Feedback Loops in kanban
Kanban Metrics
Kanban Depth Framework
Source: Ohno, Taiichi (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. p. 176. ISBN 9780915299140.
I would relate to lean manufacturing literature (including TQM & six sigma related information) only for comparisons. What works for TPS does not work for knowledge work. As such, I would stop there to avoid any confusion around terminology and maintain my focus on “Kanban for knowledge work”. I refer you to read the blue book by David J. Anderson, creator of “Kanban for knowledge work”, instead of lookup on Wikipedia or any other literature that is not considered the gold standard for knowledge work related Kanban framework and David Anderson’s Kanban Method.
Sources:
Ohno, Taiichi (1988). Toyota Production System: Beyond Large-Scale Production. Productivity Press. p. 176. ISBN 9780915299140. Translation of 1977 Japanese Edition.
Waldner, Jean-Baptiste (September 1992). Principles of Computer-Integrated Manufacturing. London: John Wiley. pp. 128–132. ISBN 0-471-93450-X.
lean.org, the Lean Lexicon: http://www.lean.org/Common/LexiconTerm.aspx?termid=242
Lean glossary of terms : http://www.systems2win.com/c/time_definitions.htm#LeadTime
Wikipedia, the free encyclopedia: https://en.wikipedia.org/wiki/Kanban
From Wikipedia, the free encyclopedia: http://en.wikipedia.org/wiki/Kanban_%28development%29
Proto-Kanban is a term used for teams new to kanban, and is not meant to be derogatory term such as scrumbut.
Expedite swimlane: You can use this swimlane to visualize a single work item that is allowed to violate work in progress (WIP) limits.
Intangible swimlane: You can use this swimlane for intangible work such as architectural refactor. Cards in this swimlane are similar EPICs that bubble up (i.e. become tangible) from stack of product backlog items in scrum.
Already doing kanban? Read the blue book (David Anderson’s Kanban book), page 70, figure 6.5 for an example of kanban board with work type based swim lanes indicating capacity allocation.
In my kanban coaching experience, kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found scrumban to be a practical middle-ground since it brings best from both scrum and kanban.
Proto-Kanban is a term used for teams new to kanban, and is not meant to be derogatory term such as scrumbut. It’s their first step on a lean journey!
In my kanban coaching experience, kanban "flow & pull" aspect orientation forces you to "stop starting, start finishing", better than scrum "inspect & adapt" orientation. Kanban being workflow management tool, requires solid engineering practices for teams to succeed in lean software development. However, it's non-prescriptiveness can let newbies fall back on practices & controls that worked in waterfall world. For those, I have always found scrumban to be a practical middle-ground since it brings best from both scrum and kanban. In this session, we will discuss 5 important topics related to kanban and scrumban, comparing & contrasting with scrum, as and when needed.
The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard".
The term scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard".
The term scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
Scrumban Level 1
- Scrum but no commitment to the content
- Teams get most value out of daily standups, retrospectives, grooming and to a lesser degree planning (at least some planned work is done)
- Aim to empty the queue in each timebox
- Don't split stories
Scrumban Level 2
- Essentially Kanban but timeboxed
- It forces stories to be broken down so work is completed (versus open ended Epics)
- Aim to empty the queue in each timebox
- Don't split stories
The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard".
The term scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard".
The term scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
The name 'Kanban' originates from Japanese[看板], and translates roughly as "signboard" or "billboard".
The term scrumban was introduced by Corey Ladas in his original blog: http://leansoftwareengineering.com/ksse/scrum-ban/
References:
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf (Chapter 6) http://leansoftwareengineering.com/ksse/scrum-ban/ http://www.eylean.com/blog/2013/04/scrum-vs-kanban-vs-scrumban-iterations-work-routines-and-scope-limits/ http://www.netobjectives.com/blogs/why-contrasting-scrumban-and-kanban-belies-lack-understanding-both
http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html
Kanban Applied to Software Development: from Agile to Lean What is Best, Scrum or Kanban?
Proto-Kanban is a term used for teams new to kanban method, and is not meant to be derogatory term such as scrum-butt.
“Stop Starting, Start Finishing” booklet exemplifies how to conduct daily standups in kanban.
Feedback loops are not limited to those three. Some advanced practitioners found interesting, custom organizational feedback loops that help them evolve their departments in a way that helps the whole company seek, contextual fitness for purpose.
There are 3 primary metrics in kanban: average lead time, due date performance, and flow efficiency.
There is growing trend of using Monte-Carlo simulation based to forecast delivery dates for planning fixed bid projects.
I request you all to not consider cycle time as far as kanban/scrumban team metrics are of your concern. Here is why:
Even though there are well-established definitions of lead time & cycle time on the lean glossary of terms, those apply to lean manufacturing world, not always to knowledge work. In contrast, just like Stefan Roock’s blogpost, vendors like Rally (on this Rally help page) have defined cycle time as time from “WIP” to “accepted”, and I tend to agree with that definition for knowledge work.
However, in past few months after my advanced Kanban coaching related training, I have had several discussions with various scrum/kanban experts on this and they don’t find cycle time practical for Kanban workflows. David J Anderson’s Kanban book (called “the blue book”) is considered equivalent of scrum guide in the lean Kanban community, and the blue book does not even mention the term “cycle time”. At a recent lean Kanban retreat, the practitioners of the Kanban method (David J Anderson & his disciples) decided not to recommend use or application of cycle time, since cycle time is not as important to the “customer”, even though it may be dearer to the delivery/product team management. There is an excellent blog post that mentions this with examples: The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
There is more continuous improvement happening in the Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team kaizen survey) or Hakan Forss (known to popularize flow efficiency metric as the primary Kanban metric).
I request you all to not consider cycle time as far as kanban/scrumban team metrics are of your concern. Here is why:
Even though there are well-established definitions of lead time & cycle time on the lean glossary of terms, those apply to lean manufacturing world, not always to knowledge work. In contrast, just like Stefan Roock’s blogpost, vendors like Rally (on this Rally help page) have defined cycle time as time from “WIP” to “accepted”, and I tend to agree with that definition for knowledge work.
However, in past few months after my advanced Kanban coaching related training, I have had several discussions with various scrum/kanban experts on this and they don’t find cycle time practical for Kanban workflows. David J Anderson’s Kanban book (called “the blue book”) is considered equivalent of scrum guide in the lean Kanban community, and the blue book does not even mention the term “cycle time”. At a recent lean Kanban retreat, the practitioners of the Kanban method (David J Anderson & his disciples) decided not to recommend use or application of cycle time, since cycle time is not as important to the “customer”, even though it may be dearer to the delivery/product team management. There is an excellent blog post that mentions this with examples: The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
There is more continuous improvement happening in the Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team kaizen survey) or Hakan Forss (known to popularize flow efficiency metric as the primary Kanban metric).
The flow efficiency metric is getting very popular in the lean Kanban community. For flow efficiency, touch time & lead time, I refer you to Forss’s presentation link from Agile2014 conference event, the slide number is 58 and it is about flow efficiency related industry stats: http://schd.ws/hosted_files/agile2014/b2/1313_How_to_improve_Flow_Efficiency__remove_the_red_bricks_Agile_2014.pdf
Source: Dimitar Bakardzhiev, Expert in managing successful and cost-effective technology development
How to use Monte Carlo simulation for predicting the delivery time for your next project. Dimitar goes pretty quickly through the slides and focus on how to simulate project delivery time using Monte Carlo simulation in MS Excel. The method presented can be used by any team that uses user stories for planning and tracking project execution no matter the development process used (Scrum, XP, kanban systems). The PPT can be seen here : https://www.slideshare.net/dimiterbak/noestimates-project-planning-using-monte-carlo-simulation And here is an Excel file to show how Monte Carlo is done http://modernmanagement.bg/data/NoEstimate_Project_Planning_MonteCarlo.xlsx
play video #NoEstimates project planning using Monte Carlo simulation youtube.com
Dimitar Bakarzhiev: “Clients come to us with an idea for a product and they always ask the questions - how long will it take and how much will it cost us to deliver? They need a delivery date and a budget estimate. This talk is about planning a fixed bid project by applying Monte Carlo simulation using collected historical data about lead time per story.”
FYI: Metrics guru (Dr.) Larry Maccherone has 2 PDFs shared with me when I was talking to him about 3 key kanban metrics popularized by David Anderson. You will note that Larry cautions me against doing control charting for knowledge work. Here is his email to me about avoiding control charts:
From: Larry Maccherone [mailto:lmaccherone@rallydev.com] Sent: Monday, May 26, 2014 9:38 AMTo: TADWALKAR, Ravi
Hi Ravi,
I am not a believer in the value of "control" with respect to TiP. The visualization of TiP along with the distribution is valuable. The analysis of common cause variation and special cause variation is also great. The analysis of the TiP of specific work items is also very valuable as a conversation starter. I discuss some of this here in this paper. I discuss why controls charts are "sins" here in sins #1 and sin #6.
So, I don't think we're going to be adding a true control chart any time soon to Rally. That said, we will be providing a visualization toolkit with an example TiP chart so you would be able to easily add your own control limits to that chart and achieve your goal.
Thanks,
Larry
Kanban team assessments tend to be much broader due to serviceability agenda of kanban, when compared with product-focused scrum team assessments. Let’s see why!
Kanban assessment focusses around these “skills”: visualization, WIP limiting, Flow management, explicit policies (e.g. we will expedite work 3 days prior to due date), Feedback loops (daily, input queue replinisment & ops-reviews) and improvements (kaizen aspect).
The colors indicate the questions from the survey that reflect the kanban depth: teams need to move from red (inner-most) to green (outer-most) “color”.
The colors indicate the questions from the survey that reflect the kanban depth. Update: Ravi Tadwalkar created spreadsheet based model of Kanban Team Assessment tool, using Kanban Depth Framework of Christophe Achouiantz
He has been interacting with @ChrisAch on the spreadsheet based survey created out of these questions, to define & refine those via a crisp glossary of terms he used in this survey. PFA the attached spreadsheets titled “Example 1” and “Example 2”, that include notes from our correspondence..
In summaryKanban is a catalyst for change through small, incremental improvements to your existing process – be it scrum or otherwise.
Rooted in lean manufacturing, kanban is a signaling system that can be effectively applied to software development, DevOps, IT operations, and many other processes.