agile,lean, and kanban – friends or foes
DESCRIPTION
More and more new words come up in the context of Agile, now that Agile itself has "crossed the chasm" and is accepted as the de-facto standard of software development. But even though a lot of these new terms fit under the Agile umbrella as defined in the "Agile Manifesto" it is sometimes hard to get to the bottom of these concepts. This presentation does exactly that - it goes to the bottom of Agile, Lean and Kanban. Without much ado we'll revisit the fundamental ideas behind Agile and then investigate Lean and the Kanban Method in comparison. Not only will you get introduced more closely to Kanbans, WIP-Limits and the pull principle, but I'll also share my experience how the different approaches fit together and complement each other in various settings.TRANSCRIPT
2013 Michael Mahlberg Slide #
Agile, Lean, And Kanban – Friends Or Foes?
Michael Mahlberg – Agile BI Conference 2013
���1
Slide #2013 Michael Mahlberg
Agile make a team fast and good (fact or fiction?)
Lean makes an organization more cost effective
(fact or fiction?) !
(from a poll @ agile cologne, 2013-11-22)
���2
IS THIS REALLY TRUE?
Slide #2013 Michael Mahlberg
CONFERENCE ON SOFTWARE ENGINEERING
���3
1968
Picture Credit: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/GROUP4.html
Slide #2013 Michael Mahlberg
REALITY CHECK
���4
~1994
Picture Credit: http://www.flickr.com/photos/raneko/2469861680/sizes/o/
Slide #2013 Michael Mahlberg
THE CHAOS REPORT
���5
published since 1994 by “The Standish Group”
Challenged Successful Impaired
Slide #2013 Michael Mahlberg
ITERATIVELY & INCREMENTALLY
Initial Goal
Final Product
New Iteration => New Goal
���6
Slide #2013 Michael Mahlberg
DRYContinuous integration
COMPLEMENTARY TECHNIQUES
���7
Constant Customer Collaboration
Little Documentation
Pair Programming
Little Requirement Specification
Unmaintainable Product
Ambiguous Specification
System metaphorTDD
Refactoring
Many others
Slide #2013 Michael Mahlberg ���8
values
Slide #2013 Michael Mahlberg
PRINCIPLES BEHIND THE AGILE MANIFESTO
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
���9
Slide #2013 Michael Mahlberg
PRINCIPLES BEHIND THE AGILE MANIFESTO
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
���10
Working Software/ Happy CustomerChange is Good
Deliver Often
Involvement
Capable Team
Face-to-Face
Working Software (again)
Sustainable Pace
Technical ExcellenceSimplicity & Work not Done
Self-Organization
Improve regularly
Slide #2013 Michael Mahlberg
REALITY CHECKMichael Sahota 2010
���11
Slide #2013 Michael Mahlberg ���12
Slide #2013 Michael Mahlberg
WHY?
• Agile works best: • in small teams with • constant customer collaboration and • face to face communication (at least ‘The Manifesto’ says so)
���13
Slide #2013 Michael Mahlberg
WHY?
There is more to successful Projects that writing Software
���14
Slide #2013 Michael Mahlberg
ALTERNATIVES?
���15
Slide #2013 Michael Mahlberg
A LEAN LOOK ON FEATURE FLOW
���16
Slide #2013 Michael Mahlberg
WHAT IS LEAN?The way Mary and Tom Poppendiek put the book together
���17
Slide #2013 Michael Mahlberg
LEAN SOFTWARE DEVELOPMENT PRINCIPLES
Eliminate waste Amplify learning
Decide as late as possible Deliver as fast as possible
Empower the team Build integrity in See the whole
���18
Slide #2013 Michael Mahlberg
AGILE SOFTWARE DEVELOPMENT PRINCIPLES
Working Software / Happy Customer (as driver)
Change is Good
Deliver Often
Involvement
Capable Teams
Face to Face
Working Software (as a measure of progress)
Sustainable Pace
Technical Excellence
Simplicity & Work not Done
Self-Organization
Improve regularly
���19
Slide #2013 Michael Mahlberg
AGILE SOFTWARE DEVELOPMENT PRINCIPLES
Working Software / Happy Customer (as driver)
Change is Good
Deliver Often
Involvement
Capable Teams
Face to Face
Working Software (as a measure of progress)
Sustainable Pace
Technical Excellence
Simplicity & Work not Done
Self-Organization
Improve regularly
���20
Slide #2013 Michael Mahlberg
WASTE?
���21
Muda 無駄 useless, not adding value
Muri 無理 overburdening
Mura 斑 unevenness, inequality
Slide #2013 Michael Mahlberg
LEAN AND AGILE
���22
Lean principles Agile principles
Eliminate waste Working Software, Customer Satisfaction, Sustainable pace
Amplify learning
Decide as late as possible Change is Good
Deliver as fast as possible Deliver Often
Empower the team Capable Teams, Involvement
Build integrity in
See the whole
Face-to-Face
Slide #2013 Michael Mahlberg
AGILE SOFTWARE DEVELOPMENT PRINCIPLES
Working Software / Happy Customer (as driver)
Change is Good
Deliver Often
Involvement
Capable Teams
Face to Face
Working Software (as a measure of progress)
Sustainable Pace
Technical Excellence
Simplicity & Work not Done
Self-Organization
Improve regularly
���23
Slide #2013 Michael Mahlberg
LEAN AND AGILE
���24
Lean principles Agile principles
Eliminate waste Working Software, Customer Satisfaction, Sustainable pace, Simplicity & Work not Done,
Amplify learning Improve regularly
Decide as late as possible Change is Good
Deliver as fast as possible Deliver Often
Empower the team Capable Teams, Involvement, Self-organization
Build integrity in Technical Excellence
See the whole
Face-to-Face
Slide #2013 Michael Mahlberg
AGILE EMPHASIS
���25
RequirementRequirement
Component
RequirementComponent
Slide #2013 Michael Mahlberg
LEAN EMPHASIS
���26
Slide #2013 Michael Mahlberg
KEY AREAS
���27
Lean
Agile
Slide #2013 Michael Mahlberg
ASSUMPTIONS
���28
Iterative approach
~20 features / iteration
Slide #2013 Michael Mahlberg
VALUE STREAM
���29
working
idling
addi
ng
value
idea (20 min)
wait for discussion (2 weeks)
elaboration (1h)
wait for approval (1 week)
acceptance (10min)
wait for iteration (1 week)
wait for iteration (1 week)
Wait for QA (1 week)
Wait for Deployment
(1 week)
QA (2 hours)
Deployment (2 hours)Implementation
(2 Weeks’)
Slide #2013 Michael Mahlberg
QUICK CALCULATION
���30
Iteration length = 2 Weeks (10 days)
=> Average feature size = 4 hoursFeatures in iteration = 20
Split Analysis vs. design vs. implementation ~ 1 / 1 / 1
analyze a feature = 80 mindesign a feature = 80 min
implement a feature = 80 min
Slide #2013 Michael Mahlberg
VALUE STREAM
���31
working
idling
addi
ng
value
idea (20 min)
wait for discussion (2 weeks)
elaboration (1h)
wait for approval (1 week)
acceptance (10min)
wait for iteration (1 week)
wait for iteration (1 week)
Wait for QA (1 week)
Wait for Deployment
(1 week)
QA (2 hours)
Deployment (2 hours)
Analysis (80’)
Design (80’)
Impl (80’)
Wait in imp. (~1 week)
Wait in imp. (~1 week)
Slide #2013 Michael Mahlberg
VALUE STREAM
���32
addi
ng
value
idea (20 min)
wait for discussion (2 weeks)
elaboration (1h)
wait for approval (1 week)
acceptance (10min)
wait for iteration (1 week)
wait for iteration (1 week)
Wait for QA (1 week)
Wait for Deployment
(1 week)
QA (2 hours)
Deployment (2 hours)
Analysis (80’)
Design (80’)
Impl (80’)
Wait in imp. (~1 week)
Wait in imp. (~1 week)
work (min)idle (min)
20 + 60 + 10 + 80 + 80 + 80 + 120 + 120 ≈ 570 min4800+2400+2400+2280+2280+2400+2400 ≈ 18960 min
work (h)idle (h)
570 min = 9:30 h18960 min = 316 h
work (d)idle (d)
9:30h ≈ 1.2 days316h ≈ 39.5 days
Slide #2013 Michael Mahlberg
WHY IS IDLE-TIME SO BAD?
���33
© 2013 Tom Breur / Michael Mahlberg Slide #
LITTLE’S LAWWork in progress
ThroughputAverage wait time in the system (per item)
L =λ w
���34
© 2013 Tom Breur / Michael Mahlberg Slide #
LITTLE’S LAWWork in progress
ThroughputAverage wait time in the system (per item)
40 = 10 hours
���35
1/15min
Slide #2013 Michael Mahlberg
WHAT IS KANBAN?
���36
Slide #2013 Michael Mahlberg
KANBAN = A VISUAL TOKEN AS A (PULL) REQUEST FOR ACTION
Literally: 看板 (kanban) = Visual Sign
���37
Picture source:
Slide #2013 Michael Mahlberg
SOFTWARE-KANBAN OR
THE KANBAN METHOD
���38
2013 Michael Mahlberg Slide #
Three Principles
���39
As described by David Anderson
Slide #2013 Michael Mahlberg
Start with what you do now Agree to pursue incremental, evolutionary
change Respect the current process, roles,
responsibilities & titles
���40
SOFTWARE-KANBAN PRINCIPLES
2013 Michael Mahlberg Slide #
Five Core PropertiesOr sometimes six or seven
���41
Slide #2013 Michael Mahlberg
THE KANBAN METHOD
1) Visualize the workflow 2) Limit WIP
3) Manage Flow 4) Make Process Policies Explicit
5) Improve Collaboratively (using models & the scientific method)
���42
2013 Michael Mahlberg Slide #
Virtual Kanban SystemsWhere the card is not the signal
���43
2013 Michael Mahlberg Slide # ���44
Virtual Kanban SystemVisualizing the flow
Slide #2013 Michael Mahlberg ���45
Product- Backlog
Sprint- Backlog Development Acceptance Production
Slide #2013 Michael Mahlberg ���46
Product- Backlog
Sprint- Backlog Development Acceptance Production
e.g. for Scrum
Slide #2013 Michael Mahlberg ���47
Take Order Cashier Syrup & Dairy Espresso Pick-up
Slide #2013 Michael Mahlberg ���48
Take Order Cashier Syrup & Dairy Espresso Pick-up
e.g. for Starbucks
Slide #2013 Michael Mahlberg ���49
kanbanPicture Source:
http://www.flickr.com/photos/christophercarfi/3600910060/ http://www.flickr.com/photos/shanti/8432370756/sizes/l/in/photostream/
2013 Michael Mahlberg Slide # ���50
Virtual Kanban SystemLimiting the work in progress
Slide #2013 Michael Mahlberg ���51
Product- Backlog
Sprint- Backlog Development Acceptance Production
(∞) (25) (25) (25) (∞)
e.g. for Scrum
Slide #2013 Michael Mahlberg ���52
Product- Backlog
Sprint- Backlog Development Acceptance
Production
(∞) (∞)
e.g. for Scrum
Sprint(25)
Slide #2013 Michael Mahlberg
LEAN & AGILE INTERJECTION
���53
20 items in a 10 workday iteration
=> 4 h value creation => 36 hours idle time } per item
Slide #2013 Michael Mahlberg ���54
Product- Backlog
Sprint- Backlog Development Acceptance Production
(∞) (25) (3) (3) (∞)
e.g. your own flow-based, scrum inspired,
software development process
2013 Michael Mahlberg Slide # ���55
Why “Virtual” Kanban System?
Slide #2013 Michael Mahlberg ���56
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item item
item
item
item
item
item
item
item
Slide #2013 Michael Mahlberg ���57
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item
item item
item ✓
item ✓
item ✓item ✓
item ✓item ✓
Slide #2013 Michael Mahlberg ���58
PULL REQUESTS?
Slide #2013 Michael Mahlberg ���59
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
...
Slide #2013 Michael Mahlberg
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
���60
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item item
item
item
item
item
item
item
item
Slide #2013 Michael Mahlberg
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
���61
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item
item item
item ✓
item ✓
item ✓item ✓
item ✓item ✓
Slide #2013 Michael Mahlberg
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
Pull
���62
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item
item
item
item ✓item ✓
item ✓item ✓
item ✓item ✓
Slide #2013 Michael Mahlberg ���63
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item item
item
item
item
item
item
item
item
SIDENOTE: MORE EXPLIT
Slide #2013 Michael Mahlberg ���64
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item item
item
item
item
item
item
item
item
SIDENOTE: MORE EXPLICIT PROCESS
doing doing doingdone done done
Slide #2013 Michael Mahlberg ���65
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item item item itemitem
item item
item
item item
item
SIDENOTE: MORE EXPLICIT PROCESS
doing doing doingdone done done
223
Slide #2013 Michael Mahlberg ���66
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item itemitem
SIDENOTE: MORE EXPLICIT PROCESS
doing doing doingdone done done
3 22
Slide #2013 Michael Mahlberg ���67
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
SIDENOTE: MORE EXPLICIT PROCESS
doing doing doingdone done done
3
Slide #2013 Michael Mahlberg ���68
VIRTUAL PULL REQUESTS VIRTUAL KANBAN SYSTEM
Slide #2013 Michael Mahlberg ���69
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
SIDENOTE: LITTLE’S LAW
doing doing doingdone done done
3
© 2013 Tom Breur / Michael Mahlberg Slide #
LITTLE’S LAWWork in progress
ThroughputAverage wait time in the system (per item)
L =λ w
���70
© 2013 Tom Breur / Michael Mahlberg Slide #
LITTLE’S LAWWork in progress
ThroughputAverage wait time in the system (per item)
∞ =λ w
���71
∞ *
Slide #2013 Michael Mahlberg ���72
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
SIDENOTE: LITTLE’S LAW
doing doing doingdone done done
3
Slide #2013 Michael Mahlberg ���73
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
SIDENOTE: LITTLE’S LAW
doing doing doingdone done done
3
Slide #2013 Michael Mahlberg ���74
Requirement Analysis Development Test / QA Production(∞) (4) (3) (3) (∞)
item
item item item
itemitem
item
item
item
item
item
VISUALIZATION CAN DIFFER
doing doing doingdone done done
3
Slide #2013 Michael Mahlberg ���75
VISUALIZATION CAN DIFFER
Picture: Thomas Schuermann, Limited WIP Society, http://limitedwipsociety.ning.com/photo/formula-kanban?context=featured#!/photo/formula-kanban?context=featured
Slide #2013 Michael Mahlberg ���76
VISUALIZATION CAN DIFFER
Picture: Karl Scotland, AvailAgility http://availagility.co.uk/2010/09/30/exploring-the-kanban-multiverse-at-agile2010/#jp-carousel-693
Slide #2013 Michael Mahlberg ���77
VISUALIZATION CAN DIFFER
Picture: Karl Scotland, AvailAgility http://availagility.co.uk/2010/09/30/exploring-the-kanban-multiverse-at-agile2010/#jp-carousel-693
Slide #2013 Michael Mahlberg
HOW TO SORT THIS OUT?
���78
Slide #2013 Michael Mahlberg
KANBAN IN THE PYRAMID
���79
Software - Kanban
Techniques
Process
Process Improvement
Slide #2013 Michael Mahlberg
SCRUM IN THE PYRAMID
���80
Scrum
Techniques
Process
Process Improvement
Slide #2013 Michael Mahlberg
XP IN THE PYRAMID
���81
eXtreme Programming (XP)
Techniques
Process
Process Improvement
Slide #2013 Michael Mahlberg
MIXED PYRAMID
���82
Software - Kanban
Techniques
Process
Process Improvement
eXtreme Programming (XP)
Techniques
Process
Process Improvement
Scrum
Techniques
Process
Process Improvement
Source http://shu-ha-ri.michaelmahlberg.de/2012/07/die-pyramide-der-agilitaet.html
Slide #2013 Michael Mahlberg
MIXED PYRAMID
���83
Software - Kanban
Techniques
Process
Process Improvement
eXtreme Programming (XP)
Techniques
Process
Process Improvement
Scrum
Techniques
Process
Process Improvement
Your individual combination
Process Improvement
Techniques
Process
Source http://shu-ha-ri.michaelmahlberg.de/2012/07/die-pyramide-der-agilitaet.html
Slide #2013 Michael Mahlberg
CONCLUSION
���84
Slide #2013 Michael Mahlberg
LOCAL OPTIMIZATION WON’T HELP
���85
Agile ClassicClassic
2 / year 2 / month 2 / year
Slide #2013 Michael Mahlberg
CONCLUSION
���86
Lean
Agile
Lean and Agile complement each
other
The Kanban Method can be used in both
worlds
Slide #2013 Michael Mahlberg
THANK YOU VERY MUCH!
���87
Slide #2013 Michael Mahlberg
CONTACT INFORMATION
���88
• If you have questions, don’t hesitate to contact me via e-mail at: [email protected]
• You can also find me on Twitter as MMahlberg
• I sometimes blog on http://agile-aspects.michaelmahlberg.com
• My homepage is http://www.michaelmahlberg.de