Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
What is kanban
Transcript of What is kanban
American statistician, professor, author,
lecturer, and consultant.
Deming made Plan-Do-Check-Act known
LEAN & TPS
focus from individual machines -> flow of the product through the total process
right-sizing machines for the actual volume needed
self-monitoring machines to ensure quality
lining the machines up in process sequence
quick setups so each machine could make small volumes of many part numbers
having each process step notify the previous step of its current needs for materials
Result: low cost, high variety, high quality, very rapid throughput times
5 lean principles
14 Toyota Management Principles
5 principles of lean
brings value to
Failure to learn
Building the wrong thing
Do not overburden people
Do not cause uneven production levels
Few Things in Process
Just in Time
An inventory strategy: relies on signals or Kanban between
different points in the process, which tell production
when to make the next part
Continuous Improvement (kaizen)
Lean before commitment
Build Quality in
If an abnormal situation arises the machine stops
and the worker will stop the production line.
A quality control process that applies the following four principles:
1.Detect the abnormality.
3.Fix or correct the immediate condition.
4.Investigate the root cause and install a countermeasure.
Kanban cards were developed by Taiichi Ono in the late 1940's
'Kanban card' is a message to someone upstream to move, purchase, or build more of a component for production
Each card tells what is needed and how much
Kanban uses the rate of demand (pull) to control the rate of production
What is kanban?
1. Eliminate Waste
Objective: to reduce cycle time (from concept to cash)
Waste is everything that does not add value to Customer
Overproduction: Extra features, extra process steps
Delays, waiting (queues and bottlenecks)
Partially done work
Task switching, motion
Defects, scrap, rework
Unused Employee Creativity
Motion, bad design of workplace
2. Build Quality in
Testing should not routinely find defects
Find and fix defects as early as possible.
Tests (unit tests, end-to-end tests, and integration tests) must be available to establish confidence in the correctness of the system at any time during development, at every level of the system.
Break Dependencies. System architecture should support the addition of any feature at any time.
3. Focus on Learning
4. Relentlessly Improve
5. Respect People
6. Optimize the System
Start with a deep understanding of all stakeholders and what they will value.
Rapid Delivery, High Quality, and Low Cost are Fully Compatible
Companies that compete on the basis of speed have a big cost advantage, deliver superior quality, and are more attuned to their customers' needs.
Queuing Theory Applies to Development, not Just Servers
Focusing on utilization creates a traffic jams that actually reduces utilization. Drive down cycle time with small batches and fewer things-in-process. Aggressively limit the size of lists and queues
Managing Workflow is a lot easier than Managing Schedules
The best way to establish reliable, predictable deliveries is to establish reliable, repeatable workflows with iterations or a kanban system.
Results are not the point – the point is to develop the people and the systems capable of delivering results.
Failure is a Learning Opportunity
The most reliable performance comes when even small failures are deeply investigated and corrected; when noise is not tolerated.
Standards Exist to be Challenged and Improved
Embody the current best known practice in standards that everyone follows, while actively encouraging everyone to challenge and change the standards.
Use the Scientific Method
Teach teams to: establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative.
People who are paid fairly and adequately are motivated by autonomy, mastery, and purpose.
The most effective work groups are semi-autonomous teams with an internal leader with ene-to-end responsibility for complete, meaningful tasks.
Respect for people means providing the challenge, feedback, and environment that enables everyone to become excellent.
Tie work to value. Only by believing in the purpose of their work will people become engaged in achieving that purpose.
Optimizing a part of a system will always sub-optimize the overall system.
Focus on the Entire Value Stream
From concept to cash.
From customer request to deployed software.
Deliver a Complete Product
Develop a complete product, not just software. Complete products are built by complete teams.
Measure process capability with cycle time. Measure team performance with delivered business value. Measure customer satisfaction with a net promoter score.
By Mary and Tom Poppendieck
Lean SW Development key elements in Practice
Lean SW Development Principles
2004 David J. Anderson implements first
kanban SW development in Microsoft
1. Loose coupling
components of the system depend on each other to the least extent practicable
Dependency injection techniques, see http://jamesshore.com/Blog/Dependency-Injection-Demystified.html
2. Incremental Design (XP):
start by creating the simplest design that could possibly work
incrementally add to it as the needs of the software evolve
continuously improve the design by reflecting on its strengths and weaknesses
applied to Architecture, Classes, Methods
Refactoring = Changing the design of the code without changing its behaviour
Refactoring requires good tests. Without it, it's dangerous because you can't easily tell whether your changes have modified behavior.
Refactoring requires continuous integration
There is no real alternative to refactoring. No matter how carefully you design, all code accumulates technical debt. Without refactoring, that technical debt will eventually overwhelm you, leaving you to choose between rewriting the software (at great expense and risk) or abandoning it entirely.
How often should we refactor?
Constantly. Perform little refactorings as you use TDD and bigger refactorings every week.
Isn't refactoring rework? Shouldn't we design our code right from the beginning?
If it were possible to design your code perfectly from the beginning, then refactoring would be rework. With large systems knows, mistakes always creep in. It isn't possible to design software perfectly. That's why refactoring is important.
Keep code integrated and build release infrastructure with the rest of the application. The ultimate goal is to be able to deploy all but the last few hours of work at any time.
To do so, integrate every few hours and keep your build, test, and other release infrastructure up to date. Each integration should get as close to a real release as possible.
Prefer synchronous integration, in which you wait for the integration to succeed, to asynchronous integration, in which a tool tests the integration for you. Synchronous integration requires fast builds, but ensures that they never break.
Question: Our organization (or customer) requires comprehensive design documentation. How can we satisfy this requirement with incremental design?
Ask them to schedule it with a story, then estimate and deliver it as you would any other story. Remind them that the design will change over time. The most effective option is to schedule documentation stories for the last iteration.
If your organization requires up-front design documentation, the only way to provide it is to engage in up-front design. Try to keep your design efforts small and simple. If you can, use incremental design once you actually start coding.
TDD is needed to catch and fix mistakes quickly
difficult to use on legacy codebases
takes a few months to overcome the learning curve
tests are written from the perspective of a class's public interface
focus on the class' behavior, not its implementation
Programmers write each test before the corresponding production code
need a testing framework for TDD ( e.g. JUnit for Java, NUnit for .NET)
need test architecture
need test maintenance
write the simplest thing that could possibly work that anticipates as little as possible, as cleanly as possible
this results in designs that are ready for any change, anticipated or not
Coding Dojos http://codingdojo.org/
Coding Katas http://codingkata.org/
1988 Toyota Production System (TPS)
based on experiences of Japanese automobile and textile industry starting from 1930s
Developed actively since 1950
Kanban cards were needed to prevent overproduction
by keeping people from asking (buying) too much too soon from previous process
by not allowing production without a kanban card
The term kanban
(= "signboard", "card you can see") is derived from a 17th century Japanese business practice
Japanese merchants used embossed or engraved signs to display one’s trade or expertise
2003 The term lean software development originated in a book by the same name, by Mary and Tom Poppendieck. The book presents the traditional lean principles in a modified form, as well as a set of 22 tools and compares the tools to agile practices
2010 First Kanban book
Kanban has 3 main rules
Limit the things you work on
Improve and optimize the whole system
by physical board
by electronic board (Jira, TFS, AgileZen... more tools listed in http://limitedwipsociety.ning.com/page/tools
When to use kanban?