This document provides context and information for a workshop on evaluating process frameworks like Scrum, Scrumban, and Kanban using a questionnaire in Excel. The workshop aims to help a struggling team determine what process could work best for them by discussing a series of questions. The document includes an example questionnaire comparing Scrum, Scrumban and Kanban on factors like planning, decomposition, estimation, responsiveness, and culture fit. It also summarizes key differences between the frameworks in areas like planning, timeboxing, and metrics.
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
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.
Why can Kanban be a better Agile Approach than Scrum for your project?SnehaRoy74
Agile is an umbrella that comes with diverse frameworks that allow groups to acquire the blessings of patron satisfaction, turning in costs incrementally and frequently, decreasing comments loop, and so on. Check out why Kanban can be a better agile approach than scrum for your project?
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.
If you are interested in Agile software development, Scrum might be the first Agile methodology you have learnt. The problem is it might not fit your work environment. Let’s explore another methodology that stands the test of time. There are many people out there discovered that Lean/Kanban is more suitable for their environment than other methodologies. See, you might be one of those.
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.
Modern Professional Scrum using Flow and Kanban - Agile and Beyond Detroit 2019Yuval Yeret
Should you use Scrum or Kanban? You don’t have to choose: Scrum teams improve when they look at flows inside and outside their sprints from a Lean/Kanban perspective. In this session we will talk about Kanban-related myths prevalent in the Scrum world and identify common ground between them. We will look at ways to bring Kanban flow into your Scrum: the Kanban-based Sprint/product backlog, flow-based daily Scrum, visualizing aging work, and flow-based Sprint planning .We will describe ways to wrap Scrum with a Kanban flow system, and how DevOps fits into this picture.
You’ll leave with a better understanding of how Scrum, Kanban, and DevOps relate to each other and with ideas for experiments to try when back at work.
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.
Why can Kanban be a better Agile Approach than Scrum for your project?SnehaRoy74
Agile is an umbrella that comes with diverse frameworks that allow groups to acquire the blessings of patron satisfaction, turning in costs incrementally and frequently, decreasing comments loop, and so on. Check out why Kanban can be a better agile approach than scrum for your project?
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.
If you are interested in Agile software development, Scrum might be the first Agile methodology you have learnt. The problem is it might not fit your work environment. Let’s explore another methodology that stands the test of time. There are many people out there discovered that Lean/Kanban is more suitable for their environment than other methodologies. See, you might be one of those.
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.
Modern Professional Scrum using Flow and Kanban - Agile and Beyond Detroit 2019Yuval Yeret
Should you use Scrum or Kanban? You don’t have to choose: Scrum teams improve when they look at flows inside and outside their sprints from a Lean/Kanban perspective. In this session we will talk about Kanban-related myths prevalent in the Scrum world and identify common ground between them. We will look at ways to bring Kanban flow into your Scrum: the Kanban-based Sprint/product backlog, flow-based daily Scrum, visualizing aging work, and flow-based Sprint planning .We will describe ways to wrap Scrum with a Kanban flow system, and how DevOps fits into this picture.
You’ll leave with a better understanding of how Scrum, Kanban, and DevOps relate to each other and with ideas for experiments to try when back at work.
UiPath Test Automation using UiPath Test Suite series, part 4DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 4. In this session, we will cover Test Manager overview along with SAP heatmap.
The UiPath Test Manager overview with SAP heatmap webinar offers a concise yet comprehensive exploration of the role of a Test Manager within SAP environments, coupled with the utilization of heatmaps for effective testing strategies.
Participants will gain insights into the responsibilities, challenges, and best practices associated with test management in SAP projects. Additionally, the webinar delves into the significance of heatmaps as a visual aid for identifying testing priorities, areas of risk, and resource allocation within SAP landscapes. Through this session, attendees can expect to enhance their understanding of test management principles while learning practical approaches to optimize testing processes in SAP environments using heatmap visualization techniques
What will you get from this session?
1. Insights into SAP testing best practices
2. Heatmap utilization for testing
3. Optimization of testing processes
4. Demo
Topics covered:
Execution from the test manager
Orchestrator execution result
Defect reporting
SAP heatmap example with demo
Speaker:
Deepak Rai, Automation Practice Lead, Boundaryless Group and UiPath MVP
Securing your Kubernetes cluster_ a step-by-step guide to success !KatiaHIMEUR1
Today, after several years of existence, an extremely active community and an ultra-dynamic ecosystem, Kubernetes has established itself as the de facto standard in container orchestration. Thanks to a wide range of managed services, it has never been so easy to set up a ready-to-use Kubernetes cluster.
However, this ease of use means that the subject of security in Kubernetes is often left for later, or even neglected. This exposes companies to significant risks.
In this talk, I'll show you step-by-step how to secure your Kubernetes cluster for greater peace of mind and reliability.
Connector Corner: Automate dynamic content and events by pushing a buttonDianaGray10
Here is something new! In our next Connector Corner webinar, we will demonstrate how you can use a single workflow to:
Create a campaign using Mailchimp with merge tags/fields
Send an interactive Slack channel message (using buttons)
Have the message received by managers and peers along with a test email for review
But there’s more:
In a second workflow supporting the same use case, you’ll see:
Your campaign sent to target colleagues for approval
If the “Approve” button is clicked, a Jira/Zendesk ticket is created for the marketing design team
But—if the “Reject” button is pushed, colleagues will be alerted via Slack message
Join us to learn more about this new, human-in-the-loop capability, brought to you by Integration Service connectors.
And...
Speakers:
Akshay Agnihotri, Product Manager
Charlie Greenberg, Host
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
JMeter webinar - integration with InfluxDB and GrafanaRTTS
Watch this recorded webinar about real-time monitoring of application performance. See how to integrate Apache JMeter, the open-source leader in performance testing, with InfluxDB, the open-source time-series database, and Grafana, the open-source analytics and visualization application.
In this webinar, we will review the benefits of leveraging InfluxDB and Grafana when executing load tests and demonstrate how these tools are used to visualize performance metrics.
Length: 30 minutes
Session Overview
-------------------------------------------
During this webinar, we will cover the following topics while demonstrating the integrations of JMeter, InfluxDB and Grafana:
- What out-of-the-box solutions are available for real-time monitoring JMeter tests?
- What are the benefits of integrating InfluxDB and Grafana into the load testing stack?
- Which features are provided by Grafana?
- Demonstration of InfluxDB and Grafana using a practice web application
To view the webinar recording, go to:
https://www.rttsweb.com/jmeter-integration-webinar
Key Trends Shaping the Future of Infrastructure.pdfCheryl Hung
Keynote at DIGIT West Expo, Glasgow on 29 May 2024.
Cheryl Hung, ochery.com
Sr Director, Infrastructure Ecosystem, Arm.
The key trends across hardware, cloud and open-source; exploring how these areas are likely to mature and develop over the short and long-term, and then considering how organisations can position themselves to adapt and thrive.
Dev Dives: Train smarter, not harder – active learning and UiPath LLMs for do...UiPathCommunity
💥 Speed, accuracy, and scaling – discover the superpowers of GenAI in action with UiPath Document Understanding and Communications Mining™:
See how to accelerate model training and optimize model performance with active learning
Learn about the latest enhancements to out-of-the-box document processing – with little to no training required
Get an exclusive demo of the new family of UiPath LLMs – GenAI models specialized for processing different types of documents and messages
This is a hands-on session specifically designed for automation developers and AI enthusiasts seeking to enhance their knowledge in leveraging the latest intelligent document processing capabilities offered by UiPath.
Speakers:
👨🏫 Andras Palfi, Senior Product Manager, UiPath
👩🏫 Lenka Dulovicova, Product Program Manager, UiPath
Epistemic Interaction - tuning interfaces to provide information for AI supportAlan Dix
Paper presented at SYNERGY workshop at AVI 2024, Genoa, Italy. 3rd June 2024
https://alandix.com/academic/papers/synergy2024-epistemic/
As machine learning integrates deeper into human-computer interactions, the concept of epistemic interaction emerges, aiming to refine these interactions to enhance system adaptability. This approach encourages minor, intentional adjustments in user behaviour to enrich the data available for system learning. This paper introduces epistemic interaction within the context of human-system communication, illustrating how deliberate interaction design can improve system understanding and adaptation. Through concrete examples, we demonstrate the potential of epistemic interaction to significantly advance human-computer interaction by leveraging intuitive human communication strategies to inform system design and functionality, offering a novel pathway for enriching user-system engagements.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Monitoring Java Application Security with JDK Tools and JFR Events
Kanban India 2022 | Ravi Tadwalkar | From Scrum to ScrumBan/Kanban: Process Evaluator Workshop using Excel
1. From Scrum to Scrumban/Kanban:
Process Evaluator Workshop using Excel
Ravi Tadwalkar
Lean/Agile/DevOps Coach
Co-founder, “Cisco Internal Coaches Network” (2011-13)
Event Co-organizer, KIN20xx conferences (2017-current)
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
2. Context for the workshop:
Process Evaluator Workshop using Excel
• Assume that we are a team struggling to do iterative development with Scrum, but the
needle is not really moving, customers are not happy, and everything is just like before
Scrum, or even worse at times.
• How do we come out of this status quo situation and move the needle?
• Let's talk about what can work for our team.
• We will go thru' series of questions in a spreadsheet format to understand how to
evaluate what process framework can work for our team.
• Create 2-3 teams among the audience to compare and contrast process outcome,
perhaps group by company/industry, and I will fire up Excel spreadsheet to go thru’ each “team”.
– We will use common sense (not culture models) when forming and storming during this workshop
3. 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.
4. Compare & Contrast Scrum, Scrumban & Kanban:
Do Planning to fill available (not all) slots
Card Template
• Scrumban/Kanban process is about moving 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.
– 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 task level if all other cards on the board are of similar sizes, more like 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-point 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 team 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. Please refer to slides in appendix for 3 excerpts from his blog post.
5. From Scrum to Scrumban/Kanban: 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 to finish work in 1-2 weeks.
Sautéing with Jira
Kanban board -
perhaps using a
physical card wall
with it! That’s one
way to acclimatize
with transition to
Scrumban/Kanban!
Scrumban Level 1
- Scrum but no commitment to the content
- Team gets 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
9. 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.
Source: : David J Anderson (2010)
10. 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!
11. 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-Kanban
Getting 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.
12. 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."
13. 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."
14. 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."
15. 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.
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?
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
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.
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.
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.
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/
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.