Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start 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

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Kanban 101 @ prezi

Open Academy 2012, Budapest

Kalman Kemenczy

on 23 May 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Kanban 101 @ prezi

" http://agilefaqs.com/nareshjain.html Naresh Jain Creative Commons http://creativecommons.org/licenses/by-nc-sa/3.0/ and such heavy weight methodologies characteristically are most successful when... not taking anything
new or unknown, do in static by Dr. Jeffrey Liker software waterfall Toyota way lean thinking Ohno Taiichi The Toyota Production System lean software Genchi Genbutsu Go to the source to find the facts to make correct decisions. 14 5S Sorting
Sustain Safety
Satisfaction Wikipedia The vehicle will not start. (the problem)

Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and not replaced. (fourth why)
Why? - The vehicle was not maintained according to the recommended service schedule. (fifth why, a root cause)
Why? - Replacement parts are not available because of the extreme age of the vehicle. (sixth why, optional footnote) by Mary and Tom Poppendieck unnecessary code and functionality
delay in the software development process
unclear requirements
insufficient testing, leading to avoidable process repetition
slow internal communication Requirements Design Implementation Verification Maintenance Herbert D. Benington, 1956 is a methodology requirements stable well known technology and mature everything is happens as expected heavy well known way 11 versions - 420k code line
17 defect industry bugs/KLOC 5 0.004 nasa USD/line 5 850 industry nasa Ballistic 1969-1975 man 5407 $25 billion 133 days operation by the time the 6-year anti-missile system project was completed, the new missiles were faster than the anti-missile's missile what is the difference? why? project was terminated examples environment + productmonkey kálmán kéménczy development methodologies everyone is not for thank you! software engineering what is ? to the development, operation, and maintenance
of software, and the study of these approaches;
that is, the application of engineering to software. systematic, disciplined, Software engineering is the application of a quantifiable approach year of Missile Defense System - = Winston W. Royce, 1970 1983 advanced programing methods for digital computers SAGE computer scientist at Lockhead Software Technology Center presented this model as an example of a flawed, non-working model. Essentially, lean is centered on preserving value with less work. deadly muda 7 TIM WOOD Overprocessing Overproduction Transportation Inventory Motion Wait Defect Bad communication Knowledge type of wastes The Toyota Way is a set of principles and behaviors that underlie the Toyota Motor Corporation's managerial approach and production system. Toyota first summed up its philosophy, values and manufacturing ideals in 2001, calling it “The Toyota Way 2001.” It consists of principles in two key areas: continuous improvement, and respect for people. principles management few hundreds improvements 7 principles Build integrity Empower the team Eliminate waste Amplify learning Decide as late as possible Deliver as fast as possible See the whole size does matter termination independence acceptance test driven development build strategy with the team together developer ux designer fast release brainstorming quick design ux test a/b test development release brask paper
decision analyze analyze analyze test something every day 100% done
100% working code company surveys support logs industry we have an acceptance test 15% 15% 35% 30% 5% http://martinfowler.com/bliki/ShuHaRi.html Martin Fowler development extreme by Kent Beck programing methodologies
best practices to the extreme level Goal organize people
to produce higher quality
software more productively Activities Values Values Communication
Respect Practices Pair programming
Planning game
Test-driven development
Whole team Continuous integration
Small releases Coding standards
Collective code ownership
Simple design
System metaphor Sustainable pace programming Coding Testing Listening scrum 1935 2B users out there i am head of product we are the HoX product teams goal of this semester #active users KPI projects goal tasks amazing service every strategy has a we have to be efficient how? philosophy process people and problem long term thinking eliminate waste partners respect, challenge and growth solving continuous improvement zero violation Honor Respect Dedicate Create Foster Pursue Work (1) Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals. (8) Use only reliable, thoroughly tested technology that serves your people and processes. (2) Create continuous process flow to bring problems to the surface. 8 min 5 min 8 min 1 min 4 min 5 min 5 min 1 min 2 min 3 min quality? first product? heartbeat? Builds in Quality Flexibility Higher Productivity Frees up Floor Space Safety Improves Morale Reduce Cost of Inventory (3) Use the "pull" system to avoid overproduction. The more inventory a company has, .... the less likely they will have what they need (4) Level out the workload (heijunka).
(Work like the tortoise, not the hare.) unevenness muri muda mura overburden waste (5) Build a culture of stopping to fix problems, to get quality right from the first. quality is a mindset (6) Standardized tasks are the foundation for continuous improvement and employee empowerment. (7) Use visual control
so no problems are hidden. standardization 5 why leads to self management Standardize Sort Straighten Shine Sustain (9) Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others. (10) Develop exceptional people and teams who follow your company's philosophy. (11) Respect your extended network of partners and suppliers by challenging them and helping them improve. (13) Make decisions slowly by consensus, thoroughly considering all options (Nemawashi根回し); implement decisions rapidly; (12) Go and see for yourself to
thoroughly understand the situation (Genchi Genbutsu現) (14) Become a learning organization through relentless reflection
(Hansei反省) and continuous improvement (Kaizen改善). agile (1 )Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

(4) Business people and developers must work together daily throughout the project.

(5) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

(6) The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

(7) Working software is the primary measure of progress.

(8) Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

(9) Continuous attention to technical excellence and good design enhances agility.

(10) Simplicity--the art of maximizing the amount of work not done--is essential.

(11) The best architectures, requirements, and designs emerge from self-organizing teams.

(12) At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan Ziv's law - specification will never be fully understood.
Humphrey's law - the user will never know what they want until after the system is in production (maybe not even then)
Wegner's lemma - an interactive system can never be fully specified nor can it ever by fully tested. (1) Satisfy the Customer
(2) Welcome change
(3) Deliver Frequently
(4) Work as a Team
(5) Motivate People
(6) Communicate face-to-face Agile Manifesto 2001, Snowbird, Utah Principles Values (7) Measure Working Software
(8) Maintain Constant Pace
(9) Excel at Quality
(10) Keep it Simple
(11) Evolve Design
(12) Reflect Regularly Requirements Design Implementation Verification Deploy Requirements Design Implementation Verification Deploy Requirements Design Implementation Verification Deploy Requirements Design Implementation Verification Deploy Requirements Design Implementation Verification Deploy Decision point
20% done
100% working code Decision point
40% done
100% working code Decision point
60% done
100% working code Decision point
80% done
100% working code agile is the new waterfall? there is no culture change
process and tools over teams
business around agile full of Ceremony and Dogmatism agile is fail use the philosophy shu ha ri not just the rules naked agile kanban optimize existing process
deliver with high quality
improve lead time
simplify prioritization
visualize the status manage your garden ToDo Test Do Check Done 3 2 2 Task 2 Task 1 Task 3 Task 4 Task 5 Task 6 Task 7 Task 8 Task 9 Task 10 Task 11 Task 12 Goal no deadline
no iteration Why? sometimes time-boxing
does not work How? follow-up meeting every day retrospective meeting end of the project post morten after prio1 and regressions show-and-tell
weekly head of product
weekly product meeting
weekly velocity kanban in action you can lose the responsibility
may cause inventory muda understand your process map your process keep it simple + = + add special blocks = what about buffers? Create your board Create cards Card attributes Link to Track Assignment Size Priority Block Date Tag Find MMF set WIP limits WIP should be based on
number of team members Minimal Marketable Feature Size does matter Cards can be small or big (1 or 2 days) Create User Story why? why? why? Brave enough to terminate why? Crystal clear description Measure Tips and Tricks Table design + cycle time frozen cards HoX report
monthly which is the right one?
Full transcript