Agile,lean, and kanban – friends or foes
5 likes6,488 views
The document discusses the relationship between Agile, Lean, and Kanban methodologies in software development, emphasizing their principles and practices. It highlights Agile's focus on customer satisfaction, continuous delivery, and team collaboration, while also addressing Lean principles such as waste elimination and fast delivery. Kanban is presented as a visual tool to manage workflow and improve efficiency, connecting these methodologies to enhance project outcomes.
Agile,lean, and kanban – friends or foes
- 1. Agile, Lean, And Kanban – Friends Or Foes? Michael Mahlberg – Agile BI Conference 2013 2013 Michael Mahlberg Slide # 1
- 2. IS THIS REALLY TRUE? 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) 2013 Michael Mahlberg Slide # 2
- 3. CONFERENCE ON SOFTWARE ENGINEERING 1968 Picture Credit: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/N1968/GROUP4.html 2013 Michael Mahlberg Slide # 3
- 4. REALITY CHECK ~1994 Picture Credit: http://www.flickr.com/photos/raneko/2469861680/sizes/o/ 2013 Michael Mahlberg Slide # 4
- 5. Challenged Successful Impaired THE CHAOS REPORT published since 1994 by “The Standish Group” 2013 Michael Mahlberg Slide # 5
- 6. ITERATIVELY INCREMENTALLY New Iteration = New Goal Final Product Initial Goal 2013 Michael Mahlberg Slide # 6
- 7. COMPLEMENTARY TECHNIQUES Ambiguous Specification Constant Customer Collaboration Little Requirement Specification DRY Continuous integration System metaphor TDD Refactoring Many others Little Documentation 2013 Michael Mahlberg Pair Programming Unmaintainable Product Slide # 7
- 9. 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. 2013 Michael Mahlberg - 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. Slide # 9
- 10. PRINCIPLES BEHIND THE AGILE MANIFESTO - Working Software/ Happy Customer Welcome changing requirements, even late in Change is Good development. Agile processes harness change - Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. - 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. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. for the customer's competitive advantage. - Deliver Often Involvement 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. Capable Team The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Face-to-Face 2013 Michael Mahlberg Working software is the primary measure of progress. Working Software (again) Sustainable Pace Technical Excellence Simplicity Work not Done Self-Organization Improve regularly Slide # 10
- 11. REALITY CHECK Michael Sahota 2010 2013 Michael Mahlberg Slide # 11
- 12. 2013 Michael Mahlberg Slide # 12
- 13. WHY? • Agile • in works best: small teams with • constant • face customer collaboration and to face communication (at least ‘The Manifesto’ says so) 2013 Michael Mahlberg Slide # 13
- 14. WHY? There is more to successful Projects that writing Software 2013 Michael Mahlberg Slide # 14
- 16. A LEAN LOOK ON FEATURE FLOW 2013 Michael Mahlberg Slide # 16
- 17. WHAT IS LEAN? The way Mary and Tom Poppendiek put the book together 2013 Michael Mahlberg Slide # 17
- 18. 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 2013 Michael Mahlberg Slide # 18
- 19. AGILE SOFTWARE DEVELOPMENT PRINCIPLES Working Software / Happy Customer (as driver) Change is Good Deliver Often Involvement Sustainable Pace Technical Excellence Simplicity Work not Done Self-Organization Improve regularly Capable Teams Face to Face Working Software (as a measure of progress) 2013 Michael Mahlberg Slide # 19
- 20. AGILE SOFTWARE DEVELOPMENT PRINCIPLES Working Software / Happy Customer (as driver) Change is Good Deliver Often Involvement Sustainable Pace Technical Excellence Simplicity Work not Done Self-Organization Improve regularly Capable Teams Face to Face Working Software (as a measure of progress) 2013 Michael Mahlberg Slide # 20
- 21. WASTE? Muda 無駄 useless, not adding value Muri 無理 overburdening Mura 斑 unevenness, inequality 2013 Michael Mahlberg Slide # 21
- 22. LEAN AND AGILE 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 2013 Michael Mahlberg Slide # 22
- 23. AGILE SOFTWARE DEVELOPMENT PRINCIPLES Working Software / Happy Customer (as driver) Change is Good Deliver Often Involvement Sustainable Pace Technical Excellence Simplicity Work not Done Self-Organization Improve regularly Capable Teams Face to Face Working Software (as a measure of progress) 2013 Michael Mahlberg Slide # 23
- 24. LEAN AND AGILE 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 Build integrity in Capable Teams, Involvement, Self-organization Technical Excellence See the whole Face-to-Face 2013 Michael Mahlberg Slide # 24
- 25. AGILE EMPHASIS Component Requirement Requirement Requirement 2013 Michael Mahlberg Component Slide # 25
- 26. LEAN EMPHASIS 2013 Michael Mahlberg Slide # 26
- 27. KEY AREAS Lean Agile 2013 Michael Mahlberg Slide # 27
- 28. ASSUMPTIONS Iterative approach ~20 features / iteration 2013 Michael Mahlberg Slide # 28
- 29. working elaboration (1h) acceptance (10min) Implementation (2 Weeks’) QA (2 hours) Deployment (2 hours) adding value idea (20 min) VALUE STREAM wait for discussion (2 weeks) wait for approval (1 week) wait for iteration wait for iteration (1 week) (1 week) Wait for QA (1 week) Wait for Deployment (1 week) idling 2013 Michael Mahlberg Slide # 29
- 30. QUICK CALCULATION Iteration length = 2 Weeks (10 days) Features in iteration = 20 = Average feature size = 4 ho urs s vs. design vs. implementation Split Analysi ~1/1/1 analyze a feature = 80 min design a feature = 80 min implement a feature = 80 min 2013 Michael Mahlberg Slide # 30
- 31. working elaboration (1h) acceptance (10min) Analysis (80’) Impl (80’) Design (80’) QA (2 hours) Deployment (2 hours) adding value idea (20 min) VALUE STREAM wait for discussion (2 weeks) wait for approval (1 week) wait for iteration wait for iteration (1 week) (1 week) Wait in imp. (~1 week) Wait in imp. (~1 week) Wait for QA (1 week) Wait for Deployment (1 week) idling 2013 Michael Mahlberg Slide # 31
- 32. VALUE STREAM acceptance (10min) Analysis (80’) Impl (80’) Design (80’) QA (2 hours) Deployment (2 hours) adding value idea (20 min) elaboration (1h) wait for discussion (2 weeks) work (min) idle (min) work (h) idle (h) wait for approval (1 week) wait for iteration (1 week) Wait in imp. (~1 week) Wait in imp. (~1 week) Wait for QA (1 week) Wait for Deployment (1 week) 20 + 60 + 10 + 80 + 80 + 80 + 120 + 120 ≈ 570 min 4800+2400+2400+2280+2280+2400+2400 ≈ 18960 min 570 min = 9:30 h 18960 min = 316 h 2013 Michael Mahlberg work (d) idle (d) 9:30h ≈ 1.2 days 316h ≈ 39.5 days Slide # 32
- 33. WHY IS IDLE-TIME SO BAD? 2013 Michael Mahlberg Slide # 33
- 34. LITTLE’S LAW Work in progress L λ Throughput © 2013 Tom Breur / Michael Mahlberg = w Average wait time in the system (per item) Slide # 34
- 35. LITTLE’S LAW Work in progress 40 = 1/15min Throughput © 2013 Tom Breur / Michael Mahlberg 10 hours Average wait time in the system (per item) Slide # 35
- 36. WHAT IS KANBAN? 2013 Michael Mahlberg Slide # 36
- 37. KANBAN = A VISUAL TOKEN AS A (PULL) REQUEST FOR ACTION Literally: 看板 (kanban) = Visual Sign Picture source: 2013 Michael Mahlberg Slide # 37
- 38. SOFTWARE-KANBAN OR THE KANBAN 2013 Michael Mahlberg METHOD Slide # 38
- 39. Three Principles As described by David Anderson 2013 Michael Mahlberg Slide # 39
- 40. SOFTWARE-KANBAN PRINCIPLES Start with what you do now Agree to pursue incremental, evolutionary change Respect the current process, roles, responsibilities titles 2013 Michael Mahlberg Slide # 40
- 41. Five Core Properties Or sometimes six or seven 2013 Michael Mahlberg Slide # 41
- 42. 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) 2013 Michael Mahlberg Slide # 42
- 43. Virtual Kanban Systems Where the card is not the signal 2013 Michael Mahlberg Slide # 43
- 44. Virtual Kanban System Visualizing the flow 2013 Michael Mahlberg Slide # 44
- 47. Take Order 2013 Michael Mahlberg Cashier Syrup Dairy Espresso Pick-up Slide # 47
- 48. Take Order . .g e 2013 Michael Mahlberg Cashier r o f Syrup Dairy a t S Espresso u b r Pick-up s k c Slide # 48
- 49. kanban Picture Source: http://www.flickr.com/photos/christophercarfi/3600910060/ http://www.flickr.com/photos/shanti/8432370756/sizes/l/in/photostream/ 2013 Michael Mahlberg Slide # 49
- 50. Virtual Kanban System Limiting the work in progress 2013 Michael Mahlberg Slide # 50
- 53. LEAN AGILE INTERJECTION 20 items in a 10 workday iteration = 4 h value creation = 36 ho urs idle time 2013 Michael Mahlberg } per item Slide # 53
- 54. ProductBacklog (∞) SprintBacklog Development Acceptance (25) (3) (3) Production (∞) d, i re p i ns r u m ess , s c ro c sed t p ba w- p m e n flo e l o w n dev r o re yo u t w a .g . e s of 2013 Michael Mahlberg Slide # 54
- 55. Why “Virtual” Kanban System? 2013 Michael Mahlberg Slide # 55
- 56. Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) item item item item item item item item item item item 2013 Michael Mahlberg Slide # 56
- 57. Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) item item item 2013 Michael Mahlberg ✓ ✓ item ✓ item item ✓ item item item item ✓ item ✓ Slide # 57
- 58. PULL REQUESTS? 2013 Michael Mahlberg Slide # 58
- 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 ... 2013 Michael Mahlberg Slide # 59
- 60. Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) item Pull item Pull item Pull item Pull Pull item Pull item Pull item Pull Pull item Pull item Pull item Pull item 2013 Michael Mahlberg Slide # 60
- 61. Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) item Pull item ✓ Pull item ✓ Pull ✓ Pull Pull item ✓ Pull item ✓ Pull item Pull item Pull item Pull item Pull item ✓ Pull item 2013 Michael Mahlberg Slide # 61
- 62. Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) Pull item Pull item Pull item Pull item Pull item ✓ item ✓ Pull Pull item Pull item ✓ ✓ item Pull ✓ item Pull ✓ Pull item Pull 2013 Michael Mahlberg Slide # 62
- 63. SIDENOTE: MORE EXPLIT Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) item item item item item item item item item item item 2013 Michael Mahlberg Slide # 63
- 64. SIDENOTE: MORE EXPLICIT PROCESS Requirement Analysis Development Test / QA Production (∞) (4) (3) (3) (∞) doing done item item item item item doing item item item item item done doing done item 2013 Michael Mahlberg Slide # 64
- 65. SIDENOTE: MORE EXPLICIT PROCESS Requirement (∞) Analysis 3 (4) Development 2 (3) Test / QA 2 (3) (∞) doing done 2013 Michael Mahlberg doing done doing done item item item item item item item item Production item item item Slide # 65
- 66. SIDENOTE: MORE EXPLICIT PROCESS Requirement (∞) Analysis 3 (4) 2 (3) doing done item item Development item Test / QA 2 (3) Production (∞) doing done doing done item item item item item item item item 2013 Michael Mahlberg Slide # 66
- 67. SIDENOTE: MORE EXPLICIT PROCESS Requirement (∞) Analysis 3 (4) Development Test / QA Production (3) (3) (∞) doing done item item item item item item item item item 2013 Michael Mahlberg doing done doing done item item Slide # 67
- 68. VIRTUAL PULL REQUESTS VIRTUAL KANBAN SYSTEM 2013 Michael Mahlberg Slide # 68
- 69. SIDENOTE: LITTLE’S LAW Requirement (∞) Analysis 3 (4) Development Test / QA Production (3) (3) (∞) doing done item item item item item item item item item 2013 Michael Mahlberg doing done doing done item item Slide # 69
- 70. LITTLE’S LAW Work in progress L λ Throughput © 2013 Tom Breur / Michael Mahlberg = w Average wait time in the system (per item) Slide # 70
- 71. LITTLE’S LAW Work in progress ∞ λ Throughput © 2013 Tom Breur / Michael Mahlberg =∞ w * Average wait time in the system (per item) Slide # 71
- 72. SIDENOTE: LITTLE’S LAW Requirement (∞) Analysis 3 (4) Development Test / QA Production (3) (3) (∞) doing done item item item item item item item item item 2013 Michael Mahlberg doing done doing done item item Slide # 72
- 73. SIDENOTE: LITTLE’S LAW Requirement (∞) Analysis 3 (4) Development Test / QA Production (3) (3) (∞) doing done item item item item item item item item item 2013 Michael Mahlberg doing done doing done item item Slide # 73
- 74. VISUALIZATION CAN DIFFER Requirement (∞) Analysis 3 (4) Development Test / QA Production (3) (3) (∞) doing done item item item item item item item item item 2013 Michael Mahlberg doing done doing done item item Slide # 74
- 75. VISUALIZATION CAN DIFFER Picture: Thomas Schuermann, Limited WIP Society, http://limitedwipsociety.ning.com/photo/formula-kanban?context=featured#!/photo/formula-kanban?context=featured 2013 Michael Mahlberg Slide # 75
- 76. VISUALIZATION CAN DIFFER Picture: Karl Scotland, AvailAgility http://availagility.co.uk/2010/09/30/exploring-the-kanban-multiverse-at-agile2010/#jp-carousel-693 2013 Michael Mahlberg Slide # 76
- 77. VISUALIZATION CAN DIFFER Picture: Karl Scotland, AvailAgility http://availagility.co.uk/2010/09/30/exploring-the-kanban-multiverse-at-agile2010/#jp-carousel-693 2013 Michael Mahlberg Slide # 77
- 78. HOW TO SORT THIS OUT? 2013 Michael Mahlberg Slide # 78
- 79. KANBAN IN THE PYRAMID Process Improvement Process Techniques Software - Kanban 2013 Michael Mahlberg Slide # 79
- 80. SCRUM IN THE PYRAMID Process Improvement Process Techniques Scrum 2013 Michael Mahlberg Slide # 80
- 81. XP IN THE PYRAMID Process Improvement Process Techniques eXtreme Programming (XP) 2013 Michael Mahlberg Slide # 81
- 82. MIXED PYRAMID Process Improvement Process Improvement Process Process Techniques Software - Kanban Techniques Scrum Process Improvement Process Techniques eXtreme Programming (XP) Source http://shu-ha-ri.michaelmahlberg.de/2012/07/die-pyramide-der-agilitaet.html 2013 Michael Mahlberg Slide # 82
- 83. MIXED PYRAMID Process Improvement Process Improvement Process Process Techniques Techniques eXtreme Programming (XP) Your individual combination Software - Kanban Scrum Source http://shu-ha-ri.michaelmahlberg.de/2012/07/die-pyramide-der-agilitaet.html 2013 Michael Mahlberg Slide # 83
- 85. LOCAL OPTIMIZATION WON’T HELP 2 / year Classic 2013 Michael Mahlberg 2 / month 2 / year Agile Classic Slide # 85
- 86. CONCLUSION Lean Lean and Agile complement each other Agile The Kanban Method can be used in both worlds 2013 Michael Mahlberg Slide # 86
- 87. THANK YOU VERY MUCH! 2013 Michael Mahlberg Slide # 87
- 88. CONTACT INFORMATION • If you have questions, don’t hesitate to contact me via e-mail at: mm@michaelmahlberg.com • You •I can also find me on Twitter as MMahlberg sometimes blog on http://agile-aspects.michaelmahlberg.com • My homepage is http://www.michaelmahlberg.de 2013 Michael Mahlberg Slide # 88