Successfully reported this slideshow.
Your SlideShare is downloading. ×

Henrik Kniberg - Essence of Agile

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Loading in …3
×

Check these out next

1 of 50 Ad

More Related Content

Slideshows for you (20)

Viewers also liked (20)

Advertisement

Similar to Henrik Kniberg - Essence of Agile (20)

More from AgileSparks (20)

Advertisement

Recently uploaded (20)

Henrik Kniberg - Essence of Agile

  1. 1. The Essence of Agile Agile Israel April 11, 2011 Henrik Kniberg Agile/Lean coach www.crisp.se Board of directors henrik.kniberg@crisp.se 070 4925284
  2. 2. What is all this stuff?! TDD Agile Scrum XP Continuous Integration Refa c torin Pair g ming Lean program Henrik Kniberg 2
  3. 3. Agile in a nutshell 3 3
  4. 4. Agile Manifesto www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Feb 11-13, 2001 Snowbird ski resort, Utah Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Bennekum Brian Marick Alistair Cockburn Robert C. Martin Ward Cunningham Steve Mellor Martin Fowler Ken Schwaber James Grenning Jeff Sutherland Jim Highsmith Dave Thomas Andrew Hunt Henrik Kniberg 4
  5. 5. Agile Manifesto www.agilemanifesto.org We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools ‫אנשים ויחסי גומלין על פני תהליכים וכלים‬ Working software over comprehensive documentation ‫תוכנה עובדת על פני תיעוד מפורט‬ Customer collaboration over contract negotiation ‫שיתוף פעולה עם הלקוחות על פני משא ומתן חוזי‬ Responding to change over following a plan ‫תגובה לשינויים על פני מעקב אחרי התוכנית‬ That is, while there is value in the items on the right, we value the items on the left more. Henrik Kniberg ‫כלומר, בעוד שיש ערך לפריטים בצד שמאל‬ 5 ‫.אנחנו מעריכים יותר את הפריטים בצד ימין‬
  6. 6. Principles behind the Agile Manifesto !   Our highest priority is to satisfy the !   Working software is the primary customer through early and continuous measure of progress. delivery of valuable software. !   Agile processes promote sustainable !   Welcome changing requirements, even late development. The sponsors, developers, in development. Agile processes harness and users should be able to maintain a change for the customer's competitive constant pace indefinitely. advantage. !   Continuous attention to technical !   Deliver working software frequently, from excellence and good design enhances a couple of weeks to a couple of months, agility. with a preference to the shorter timescale. !   Simplicity--the art of maximizing the !   Business people and developers must work amount of work not done--is essential. together daily throughout the project. !   The best architectures, requirements, !   Build projects around motivated and designs emerge from self-organizing individuals. Give them the environment and teams. support they need, and trust them to get !   At regular intervals, the team reflects on the job done. how to become more effective, then !   The most efficient and effective method of tunes and adjusts its behavior conveying information to and within a accordingly. development team is face-to-face conversation. 6
  7. 7. Agile ”umbrella” FDD DSDM Scrum XP Crystal Kanban Sources: 3rd Annual ”State of Agile Development” Survey June-July 2008 •  3061 respondents •  80 countries 7
  8. 8. Traditional, predictive approach Release Design spec Requirements spec Order C D Actual P need P R 11-04-11 Henrik Kniberg 8
  9. 9. We tend to build the wrong thing Features and functions used in a typical system Half of the stuff we build is Always never used! 7% Often 13% Never Cost 45% Some- times 16% Rarely 19% # of features Sources: Standish group study reported at XP2002 by Jim Johnson, Chairman This graph courtesy of Mary Poppendieck 9 Henrik Kniberg 9
  10. 10. Traditional projects are like a cannon ball Assumptions: !   The customer knows what he wants !   The developers know how to build it !   Nothing will change along the way Henrik Kniberg 10
  11. 11. Agile is like a homing missile Assumptions: !   The customer discovers what he wants !   The developers discover how to build it !   Things change along the way Henrik Kniberg 11
  12. 12. Timeboxing A B Plan C D (doomed to fail, but we don’t know it yet) Week 1 Week 2 Week 3 Week 4 Traditional scenario A B ”We will deliver ABCD in 4 weeks” Oops, we’re late. C D Scope Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 X X Quality X Cost Time Agile scenario ”We always deliver something every sprint (2 weeks)” A A B A B E ”We think we can finish ABCD in 4 weeks, but we aren’t sure” ”We always deliver the most important items first” Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Scope Oops, our velocity is lower than we thought. It looks like we’ll only finish AB by week 4. Quality What should we do now? Cost Time 12 Henrik Kniberg
  13. 13. Planning is easier with frequent releases Henrik Kniberg 13
  14. 14. Scrum in a nutshell 14 14
  15. 15. Split your organization Scrum in a nutshell Split your product Large group spending a long time building a huge thing Small team spending a little time building a small thing ... but integrating regularly to see the whole Optimize process Optimize business value $$$ Split time January April $ Henrik Kniberg 15
  16. 16. Scrum overview – structure Product Cross-functional, Backlog self-organizing Team -  How much to pull in Stakeholders -  How to build it -  Quality Sprint -  Sustainable pace Backlog Team Users PO Helpdesk SM Direct communication Operations Product owner -  Vision: Where are we going & why? Scrum Master Management -  ROI -  Process leader/coach -  Priorities & tradeoffs -  Impediment remover ... etc ... Henrik Kniberg 16
  17. 17. Backlog management Estimate stories As a buyer 2 I want to save my shopping cart As a booker I want to receive notifications when new slots appear in the calendar 5 Write user stories so that I can continue shopping later so that I don't have to keep checking manually As a buyer 2 2 asdf kjsk flkjs df sd fk asdf kjsk flkjs df sd fk asdf kjsk flkjs df sd fk As a buyer I want to save my shopping cart 5 2 soIthat a can continue shopping later As I buyer asdf kjsk flkjs df sd fk want to save my shopping cart 3 asdf kjsk soIthat I can continue shopping later want to save my shopping cart flkjs df sd fk asdf kjsk flkjs df sd fk asdf kjsk flkjs df sd fk ? so that I can continue shopping later Break down big stories Prioritize REgister new 3 REgister new 3 user user Edit existing 5 Edit existing 5 Velocity-based forecast user user High prio stories Administrate small enough to users 13 Find 3 View Invoice in HTML, fit in a sprint April user PDF, or Excel format View Invoice in HTML, PDF, or Excel format Delete 5 As a helpdesk operator I want to see who is May user logged in As a helpdesk operator I want to see who is logged in View Invoice in HTML, Find 3 June PDF, or Excel format user Operations Later manual As a helpdesk operator I want to see who is Operations logged in manual Realistic 100 simultaneous planning horizon Low prio stories users Operations 100 simultaneous not broken manual users down yet 17 100 simultaneous users Delete user 5
  18. 18. Typical sprint Product Backlog release PO 1.3.0 Daily Scrum Week 1 Week 2 Week 3 Sprint- Demo/Review Sprint plan (Task board / Scrum board) planning Retrospective Timeline Henrik Kniberg 18
  19. 19. Velocity V= 8 V= 7 V= 9 1 2 2 1 1 2 2 3 1 3 1 2 2 1 Sprint 1 Sprint 2 Sprint 3 Likely future velocity: 7-9 per sprint Henrik Kniberg 19
  20. 20. Scope Release planning – example Quality Cost Time •  Today is Aug 6 •  Sprint length = 2 weeks •  Velocity = 30 - 40 300 What will be done PO by X-mas? (10 sprints) 400 2007-09-28 20
  21. 21. XP in a nutshell 21 21
  22. 22. Scrum Scrum ”wraps” Team Daily Scrum XP XP Sprint backlog Whole team Coding Burndown Collective chart ownership TDD standard Product backlog Customer tests Pair Refactoring Planning Sprint Product programming game Planning owner meeting Continuous Simple Sustainable Integration design Pace Metaphor Small releases ScrumMaster Sprint Review 2007-09-28 Henrik Kniberg 22
  23. 23. Feedback loops Sprint review Daily Scrum Continuous integration Unit test Pair programming Henrik Kniberg 23
  24. 24. Kanban in a nutshell Henrik Kniberg 24
  25. 25. Kanban in SW development !   Visualize the workflow Pioneered by David Anderson in 2004 !   Limit WIP (work in progress) !   Measure & optimize flow !   Explicit policies (definition of Done, WIP limits, etc) Backlog Dev UAT Deploy Done 5 3 2 3 orem ips dolor dolor orem ips sit amet um dolor orem ipsum orem ipsum um dolor , co nse nse nse sit amet ctetur sit amet, co sit amet, co , co nse ctetur cte tur cte tur dolor orem ipsum dolor orem ipsum co nse amet, co nse sit sit amet, ctetur ctetur orem ipsum dolor orem ipsum dolor orem ipsum dolor sit amet, co nse sit amet, co nse sit amet, co nse ctetur ctetur orem ipsum dolor ctetur sit amet, co nse ctetur orem ipsum dolor orem ips sit amet, co nse um dolor sit amet ctetur , co nse ctetur orem ipsum dolor sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur FLOW Avg lead time:12 days Henrik Kniberg 25
  26. 26. ”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 26
  27. 27. Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 27
  28. 28. Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 28
  29. 29. Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 29
  30. 30. Scenario 1 – one piece flow Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 30
  31. 31. Scenario 1 – one piece flow. Dev Backlog Next 3 In production :o) 2 Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 31
  32. 32. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A B G C F D H I J L E M K Henrik Kniberg 32
  33. 33. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G B C F D H I J L E M K Henrik Kniberg 33
  34. 34. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 34
  35. 35. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D B F H I J L E M K Henrik Kniberg 35
  36. 36. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done C A G D !? B F H I J L E M K Henrik Kniberg 36
  37. 37. Scenario 2 – Deployment problem Dev Backlog Nexet 3 In production :o) 2 PO Ongoing Done G !? A D B F E C H I J L M K Henrik Kniberg 37
  38. 38. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 38
  39. 39. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done A G D B F E C H I J L M K Henrik Kniberg 39
  40. 40. Scenario 2 – Deployment problem Dev Backlog Next 3 In production :o) 2 PO Ongoing Done D A G B E F C H I J L M K Henrik Kniberg 40
  41. 41. Evolve your own unique system! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 41
  42. 42. Case study: Cross functional teams 42 42
  43. 43. Before Design-ready games Production-ready games Game backlog 15 12 8 Lisa Concept Graphics Sound Integr. & Sam assigns Dev pres. design design deploy resources 2d 1m 6m 1w 6m 6m 2h 4h 1d 1m 3w 3m 3w (1m+2m) 3 m value added time Process = 12% cycle 25 m cycle time efficiency 43
  44. 44. Before Design-ready games Production-ready games Game backlog 15 12 8 Lisa Concept Graphics Sound Integr. & Sam assigns Dev pres. design design deploy resources 2d 1m 6m 1w 6m 6m 2h 4h 1d 1m 3w 3m 3w Process (1m+2m) 3 m value added time = 12% cycle 25 m cycle time efficiency After Game team (graphics, sound, dev, integrate) Cross-functional game team 3-4 m cycle time = 6-8x faster 3-4 months 44
  45. 45. Specialist teams & handovers We’re slow! I’m fast! 6 months Joe Dave Lisa Release Cross-functional teams 3 months We’re alot faster! Joe I’m a bit Dave slower Lisa Release January February March April May June July Henrik Kniberg 45
  46. 46. Kanban – ”evolution over revolution” Integrate! Next! Graphics! Sound! Development! & deploy! Done!! 3 2 3 2 1! Doing! Done! Doing! Done! Doing! Done! Doing! 2009-08-20! 2009-09-03! 2009-08-27! orem olor sit amet, co ipsum dolor sit am 2009-09-01! 2009-08-30! 2009-08-26! et, 2009-08-27! orem ipsum dolor sit nse ctetur adi pis co nse ctetur adi ! cing elit nisl pis orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co adi pis cing orem ipsum dolor sit amet, adi pis cing ! orem adi pis cing elit nisl ! ! adi pis cing elit nisl elit nisl! amet, ctetur adi ! cing elit nisl pis elit nisl cing elit nisl ! 2009-08-20 ! 2009-08-29! dolor sit 2009-09-03! 2009-09-02! orem ipsum ipsum dolor sit amet, orem ipsum dolor sit orem ipsum dolor sit amet, nse ctetur adi amet, co nse adi pis cing ctetur elit nisl ! co nse ctetur adi pis cing elit nisl ! amet, nse ctetur adi ! pis elit nisl ! pis cing elit nisl 2009-08-22 ! orem ipsum amet, co! dolor sit Definition of Done:! Definition of Done:! Definition of Done:! Definition of Done:! • …! • …! • …! • …..! Henrik Kniberg 46
  47. 47. Final points 47 47
  48. 48. Working smart is more important than working hard Big team working hard Working ”smart” is enabled by: •  Clear goal •  Transparency •  Direct contact with customers •  Focus •  Fast feedback Small team working smart Henrik Kniberg 48
  49. 49. Distinguish between… Using the tool wrong Using the wrong tool Neither of these problems are caused by the tool 49 Henrik Kniberg 49
  50. 50. The important thing is not your process. Essential skills needed The important thing is regardless of process your process for improving your process Splitting the system into Craftsmanship Retrospectives useful pieces As a buyer I want to save my shopping cart so that I can continue shopping later Henrik Kniberg 50

×