"The essence of agile"

download "The essence of agile"

of 77

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of "The essence of agile"

  1. 1. Copyright notice These slides are licensed under Creative The essence of AgileCommons. Feel free to use these slides &pictures as you wish, as long as you leavemy name and the Crisp logo somewhere. For licensing details see:Keynote http://creativecommons.org/licenses/by/3.0/Agile Eastern Europe, Kiev All slides available at:Oct 8, 2010 http://www.crisp.se/henrik.kniberg/Henrik KnibergAgile/Lean coach www.crisp.seBoard of directors henrik.kniberg@crisp.se070 4925284
  2. 2. What is all this stuff? TDD ScrumXPContinuousIntegrationRefac torinPair gming LeanprogramRUPAgile Henrik Kniberg 2
  3. 3. What have we learned?Henrik Kniberg 3
  4. 4. Traditional SW 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 Kniberg4
  5. 5. Most IT projects dont succeed The Standish Group has studied over 40,000 projects in 10 years. IT project success rate 1994: 15% Average cost & time overrun: 170% Plan: 1,000,000Actual: 2,700,000IT project success rate 2004: 34% Average cost & time overrun: 70% Plan: 1,000,000 Actual: 1,700,000Sources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Henrik Kniberg 5
  6. 6. How estimates are affected by specification length Spec Same spec more pages117 hrs 173 hrs SMSM Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 20062007-09-28 6
  7. 7. How estimates are affected by irrelevant information Spec 1 Same specA + irrelevant detailsBACBC20 hrs 39 hrsSM SMSource: How to avoid impact from irrelevant and misleading infoon your cost estimates, Simula research labs estimation seminar,Oslo, Norway, 20062007-09-287
  8. 8. How estimates are affected by extra requirements Spec 1Spec 2Spec 3A AAB BBC CCD DDEE 4 hrs4 hrs8 hrs SMSM SM Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 20062007-09-28 8
  9. 9. How estimates are affected by anchoring Spec Same specSame spec500 hrs50 hrs456 hrsPONever mind me Never mind me PO 555 hrs99 hrs SMSMSM Source: How to avoid impact from irrelevant and misleading info 2007-09-28 on your cost estimates, Simula research labs estimation seminar,Oslo, Norway, 2006 9
  10. 10. We tend to build the wrong thingFeatures and functions used in a typical systemHalf of the stuff webuild isAlwaysnever used! 7% Often 13% NeverCost 45%Some-times 16%Rarely19%# of features Sources: Standish group study reported at XP2002 by Jim Johnson, ChairmanThis graph courtesy of Mary Poppendieck 10Henrik Kniberg 10
  11. 11. What have we learned? Top 5 reasons for success1. User involvement2. Executive management support IT project success rate 1994: 15%3. Clear business objectives4. Optimizing scopeAverage cost & time overrun: 170%5. Agile processScope IT project success rate 2004: 34%Average cost & time overrun: 70%Quality CostTimeThe primary reason [for the improvement]is that projects have gotten a lot smaller. Doing projects with iterative processes as opposed tothe waterfall method, which called for all projectrequirements to be defined up front, is a major step Jim Johnsonforward. Chairman of Standish GroupThere is no silver bullet butagile methods come very closeSources:http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standishhttp://www.infoq.com/articles/Interview-Johnson-Standish-CHAOSHenrik KnibergMy Life is Failure, Jim Johnsons book 11
  12. 12. Agile in a nutshellHenrik Kniberg 12
  13. 13. Agile Manifestowww.agilemanifesto.orgWe are uncovering better ways of developingsoftware by doing it and helping others do it. Feb 11-13, 2001 Snowbird ski resort, Utah Kent BeckRon JeffriesMike BeedleJon KernArie van BennekumBrian MarickAlistair CockburnRobert C. MartinWard CunninghamSteve MellorMartin FowlerKen SchwaberJames Grenning Jeff SutherlandJim HighsmithDave ThomasAndrew Hunt Henrik Kniberg13
  14. 14. Agile Manifestowww.agilemanifesto.orgWe are uncovering better ways of developingsoftware by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.Henrik Kniberg14
  15. 15. 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 latedevelopment. 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 workamount 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 andteams. 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 oftunes and adjusts its behavior conveying information to and within a accordingly. development team is face-to-face conversation.15
  16. 16. Agile umbrella FDDDSDM ScrumXPCrystalKanban Sources: 3rd Annual State of Agile Development Survey June-July 2008 3061 respondents 80 countries16
  17. 17. Agile projects are like a guided missile Assumptions: ! The customer discovers what he wants ! The developers discover how to build it ! Things change along the wayHenrik Kniberg 17
  18. 18. TimeboxingA B PlanC D(doomed to fail, but we dont know it yet) Week 1 Week 2 Week 3 Week 4Traditional scenarioA B We will deliver ABCD in 4 weeks Oops, were late. C D ScopeWeek 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8X X QualityXCost Time Agile scenarioA B We always deliver something every sprint (4 weeks) A BE D We think we can finish ABCD in 1 sprint, but we arent sure We always deliver the most important items first Week 1 Week 2 Week 3 Week 4 Week 5 Week 6 Week 7 Week 8 Scope Oops, we only finished AB. Quality Our velocity is lower than we thought. What should we do now?Cost Time 18 Henrik Kniberg
  19. 19. Planning is easier with frequent releases Henrik Kniberg19
  20. 20. Scrum in a nutshellHenrik Kniberg 20
  21. 21. Split your organizationScrum in a nutshell Split your productLarge group spending a long time building a huge thingSmall team spending a little time building a small thing ... but integrating regularly to see the wholeOptimize process Optimize business value$$$Split timeJanuary April $ Henrik Kniberg21
  22. 22. Scrum overview structure Product Backlog Cross functional, self organizing Team Stakeholders- How much to pull in - How to build it Sprint Backlog TeamUsers POHelpdeskSM Direct communicationOperationsProduct ownerManagement - Where are we going & why?Scrum Master - Priorities - Process leader/coach - Impediment remover... etc ... Henrik Kniberg 22
  23. 23. Product backlog As a I want Definition of Done Product vision so that Releasable User Acceptance testedProduct Merged to TrunkBacklog As a buyer release notes writtenI want to save my shopping cart No increased technical debtso that I can continue shopping laterAs a booker = I havent messed upthe codebaseI want to receive notifications whennew available slots appear in thecalendarso that I don't have to keep checking GUImanuallyClient(... etc ...)Server DBHenrik Kniberg23
  24. 24. Agile estimating strategy ! Dont estimate time.! Estimate relative size of stories.! Measure velocity per sprint.! Derive release plan. ! Estimates done by the people who are going to do the work.! Not by the people who want the work done. ! Estimate continuously during project, not all up front. ! Prefer verbal communication over detailed, written specifications. ! Avoid false precision! Better to be roughly rightthan precisely wrongHenrik Kniberg24 http://planningpoker.crisp.se
  25. 25. Planning poker As a buyer I want to save my shopping cart2 so that I can continue shopping later As a booker I want to receive notifications when new available slots appear in the 5 2 2 calendar so that I don't have to keep checking 2 5 manually? 3 Henrik Kniberg25
  26. 26. Typical sprint Product Backlog release PO1.3.0DailyScrum Week 1 Week 2 Week 3 Sprint- Demo/ReviewSprint plan(Task board / Scrum board) planning Retrospective TimelineHenrik Kniberg 26
  27. 27. VelocityV= 8V= 7V= 9 1 2 2 1 1 22 3 1 312 21 Sprint 1Sprint 2Sprint 3Likely future velocity:7-9 per sprintHenrik Kniberg 27
  28. 28. Scope Release planning fixed dateQualityCost Time Today is Aug 6 Sprint length = 2 weeks Velocity = 30 - 40300 What will be donePO by X-mas? (10 sprints) 4002007-09-2828
  29. 29. ScopeRelease planning fixed scopeQualityCost TimeRelease burndown chartWhen will all ofthis be done?400Well be done around sprint Work remaining14-16 (story points) PO3002001001 2 3 45 6 7 89 10 11 12 13 14 15 16Sprint Henrik Kniberg29
  30. 30. XP in a nutshellHenrik Kniberg 30
  31. 31.