Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Copyright notice

                                 These slides are licensed under Creative


The essence of Agile
       ...
What is all this stuff?
                          TDD
                                  Scrum
       XP
                  ...
What have
we learned?

Henrik Kniberg   3
Traditional SW projects are like a cannon ball
Assumptions:
!   The customer knows what he wants
!   The developers know h...
Most IT projects don’t succeed
  The Standish Group has studied over 40,000 projects in 10 years.




IT project success r...
How estimates are affected by
specification length
    Spec               Same spec – more pages




             117 hrs ...
How estimates are affected by
irrelevant information
Spec 1                 Same spec
     A                 + irrelevant ...
How estimates are affected by
extra requirements
Spec 1                Spec 2                          Spec 3
     A      ...
How estimates are affected by anchoring
Spec             Same spec                          Same spec




                ...
We tend to build the wrong thing
 Features and functions used in a typical system


         Half of the stuff we
        ...
What have we learned?                                       Top 5 reasons for success
                                    ...
Agile in a
nutshell

Henrik Kniberg   12
Agile Manifesto




                       www.agilemanifesto.org
             We are uncovering better ways of developing...
Agile Manifesto
                       www.agilemanifesto.org
             We are uncovering better ways of developing
   ...
Principles behind the Agile Manifesto
!   Our highest priority is to satisfy the        !   Working software is the primar...
Agile ”umbrella”




                                          FDD
                   DSDM

 Scrum        XP              ...
Agile projects are like a guided missile
Assumptions:
!   The customer discovers what he wants
!   The developers discover...
Timeboxing                                                          A B
  Plan                                            ...
Planning is easier with frequent releases




Henrik Kniberg                              19
Scrum in a
nutshell

Henrik Kniberg   20
Split your organization

        Scrum in a nutshell
  Split your product


                             Large group spend...
Scrum overview – structure
                  Product
                  Backlog                                       Cross...
Product backlog                   As a <stakeholder>
                                    I want <what>        Definition o...
Agile estimating strategy
  !   Don’t estimate time.
       !   Estimate relative size of stories.
       !   Measure velo...
Planning poker


As a buyer
I want to save my shopping cart    2
so that I can continue shopping later


As a booker
I wan...
Typical sprint
        Product
        Backlog




                                                                       ...
Velocity
                 V= 8                  V= 7                    V= 9

 1       2                   2              ...
Scope


Release planning – fixed date              Quality

                                    Cost             Time
•  T...
Scope


     Release planning – fixed scope                                                                Quality

      ...
XP in a
nutshell

Henrik Kniberg   30
Scrum                                      Scrum
”wraps”                 Team
                                            ...
Feedback
loops             Sprint review

                  Daily Scrum

                   Continuous
                   ...
Agile architecture
                      Timeline

Don’t do: Quick ’n dirty features => Slow ’n dirty => Entropy death? Bi...
import java.sql.Connection;
                                                          import java.util.concurrent.Executor...
Kanban in a
nutshell

Henrik Kniberg   35
Which team needs                                                                                                          ...
Kanban @ Imperial Palace Gardens




Henrik Kniberg                     37
Kanban
                        ”Visual Card”

!   Signaling system
!   Visual
!   Limited in supply




Henrik Kniberg    ...
Kanban in your wallet




                        Darn. Forgot to
                        limit the supply.




Henrik Kni...
Kanban @ Toyota


           Buyer                                           Supplier




Consume    Detach         Receiv...
Kanban in SW development
!       Visualize the workflow                                                                   ...
Kanban example
Board shared by several teams
Covers whole value stream
from concept to release




Henrik Kniberg         ...
One day in
Kanban land

Henrik Kniberg   43
”One day in Kanban land”
                 http://blog.crisp.se/henrikkniberg/tags/kanban/




Henrik Kniberg              ...
Scenario 1 – one piece flow


                                                  Dev
            Backlog                  N...
Scenario 1 – one piece flow


                                                  Dev
            Backlog                  N...
Scenario 1 – one piece flow


                                                  Dev
            Backlog                  N...
Scenario 1 – one piece flow


                                          Dev
            Backlog          Next             ...
Scenario 1 – one piece flow.


                                           Dev
            Backlog          Next           ...
Scenario 2 – Deployment problem


                                                   Dev
            Backlog              ...
Scenario 2 – Deployment problem


                                                   Dev
            Backlog              ...
Scenario 2 – Deployment problem


                                           Dev
            Backlog           Next       ...
Scenario 2 – Deployment problem


                                            Dev
            Backlog           Next      ...
Scenario 2 – Deployment problem


                                            Dev
            Backlog           Next      ...
Scenario 2 – Deployment problem


                                             Dev
            Backlog           Nexet    ...
Scenario 2 – Deployment problem


                                           Dev
            Backlog           Next       ...
Scenario 2 – Deployment problem


                                           Dev
            Backlog           Next       ...
Scenario 2 – Deployment problem


                                           Dev
            Backlog           Next       ...
Kanban
board
evolution
Henrik Kniberg   59
Kanban evolution example
April 7




April 23



 Henrik Kniberg             60
Henrik	
  Kniberg	
  
                                                           Kanban www.crisp.se/kanban/example	
   ex...
Evolve your own unique system!




                                 Some of these photos courtesy of
                     ...
Compare for
understanding,
not judgement

Henrik Kniberg   63
Lean & Agile process toolkits

                                Values & Principles
                    Lean, Agile, Theory...
Compare for understanding, not judgement
More prescriptive                                                                ...
Customizing
your agile
process
Henrik Kniberg   66
Shu-Ha-Ri stages of learning

!  Shu = follow the process
!  Ha = adapt the process
!  Ri = never mind the process




Hen...
Agile does not require timeboxed iterations

Sprints
                                    week 1   week 2     week 3   week...
Different ways of limiting WIP
Scrum                                              Velocity = 15 story points
•  Indirect l...
Estimation options
                                                                              ”Typical”
Features       ...
Portfolio-level board
Next!                          Develop!                        Release! Done!
   1               Con...
Game teams
Game team 1             Game team 2          Game team 2
Current game: Pac Man   Current game: Pong   Current g...
Final points


Henrik Kniberg   73
Distinguish between…

 Using the tool wrong                Using the wrong tool




                        Neither of the...
Don’t be dogmatic

Go away! Don’t talk to us!
    We’re in a Sprint.
                        Come back     Though Shalt
  ...
Essential skills needed
  regardless of process

 Splitting the system into              Craftsmanship   Retrospectives
 u...
Perfection is a direction, not a place

                           The important thing is not your process.
              ...
Upcoming SlideShare
Loading in …5
×

"The essence of agile"

9,634 views

Published on

Slides of a keynote by Henrik Kniberg done at Agile Eastern Europe 2010.

"The essence of agile"

  1. 1. Copyright notice These slides are licensed under Creative The essence of Agile Commons. Feel free to use these slides & pictures as you wish, as long as you leave my 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 Kniberg Agile/Lean coach www.crisp.se Board of directors henrik.kniberg@crisp.se 070 4925284
  2. 2. What is all this stuff? TDD Scrum XP Continuous Integration Refa c torin Pair g ming Lean program RUP Agile 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 Kniberg 4
  5. 5. Most IT projects don’t 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,000 Actual: €2,700,000 IT project success rate 2004: 34% Average cost & time overrun: ≈70% Plan: €1,000,000 Actual: €1,700,000 Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Henrik Kniberg 5
  6. 6. How estimates are affected by specification length Spec Same spec – more pages 117 hrs 173 hrs SM SM Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006 2007-09-28 6
  7. 7. How estimates are affected by irrelevant information Spec 1 Same spec A + irrelevant details B A C B C 20 hrs 39 hrs SM SM Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006 2007-09-28 7
  8. 8. How estimates are affected by extra requirements Spec 1 Spec 2 Spec 3 A A A B B B C C C D D D E E 4 hrs 4 hrs 8 hrs SM SM SM Source: How to avoid impact from irrelevant and misleading info on your cost estimates, Simula research labs estimation seminar, Oslo, Norway, 2006 2007-09-28 8
  9. 9. How estimates are affected by anchoring Spec Same spec Same spec 500 hrs 50 hrs 456 hrs PO Never mind me Never mind me PO 555 hrs 99 hrs SM SM SM 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 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 10 Henrik Kniberg 10
  11. 11. What have we learned? Top 5 reasons for success 1.  User involvement 2.  Executive management support IT project success rate 1994: 15% 3.  Clear business objectives 4.  Optimizing scope Average cost & time overrun: ≈170% 5.  Agile process Scope IT project success rate 2004: 34% Average cost & time overrun: ≈70% Quality Cost Time “The primary reason [for the improvement] is that projects have gotten a lot smaller.” “Doing projects with iterative processes as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step Jim Johnson forward.” Chairman of Standish Group “There is no silver bullet but agile methods come very close” Sources: http://www.softwaremag.com/L.cfm?Doc=newsletter/2004-01-15/Standish http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Henrik Kniberg ”My Life is Failure”, Jim Johnson’s book 11
  12. 12. Agile in a nutshell Henrik Kniberg 12
  13. 13. 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 13
  14. 14. 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 14
  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 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. 15
  16. 16. Agile ”umbrella” FDD DSDM Scrum XP Crystal Kanban Sources: 3rd Annual ”State of Agile Development” Survey June-July 2008 •  3061 respondents •  80 countries 16
  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 way Henrik Kniberg 17
  18. 18. 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 A B ”We always deliver something every sprint (4 weeks)” A B E D ”We think we can finish ABCD in 1 sprint, 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 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 Kniberg 19
  20. 20. Scrum in a nutshell Henrik Kniberg 20
  21. 21. 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 21
  22. 22. Scrum overview – structure Product Backlog Cross functional, self organizing Team Stakeholders -  How much to pull in -  How to build it Sprint Backlog Team Users PO Helpdesk SM Direct communication Operations Product owner Management -  Where are we going & why? Scrum Master -  Priorities -  Process leader/coach -  Impediment remover ... etc ... Henrik Kniberg 22
  23. 23. Product backlog As a <stakeholder> I want <what> Definition of Done Product vision so that <why> •  Releasable •  User Acceptance tested Product •  Merged to Trunk Backlog As a buyer •  release notes written I want to save my shopping cart •  No increased technical debt so that I can continue shopping later As a booker = I haven’t messed up the codebase I want to receive notifications when new available slots appear in the calendar so that I don't have to keep checking GUI manually Client (... etc ...) Server DB Henrik Kniberg 23
  24. 24. Agile estimating strategy !   Don’t 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 right than precisely wrong Henrik Kniberg 24 http://planningpoker.crisp.se
  25. 25. Planning poker As a buyer I want to save my shopping cart 2 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 Kniberg 25
  26. 26. 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 26
  27. 27. 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 27
  28. 28. Scope Release planning – fixed date 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 28
  29. 29. Scope Release planning – fixed scope Quality Cost Time Release burndown chart When will all of this be done? 400 We’ll be done around sprint Work remaining 14-16 (story points) PO 300 200 100 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Sprint Henrik Kniberg 29
  30. 30. XP in a nutshell Henrik Kniberg 30
  31. 31. 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 31
  32. 32. Feedback loops Sprint review Daily Scrum Continuous integration Unit test Pair programming Henrik Kniberg 32
  33. 33. Agile architecture Timeline Don’t do: Quick ’n dirty features => Slow ’n dirty => Entropy death? Big bang rewrite? F F F F F F Don’t do: Big Up Front Design F F F F Architecture Do: Find a balance F F F F F F F F F F A A A A A A A A A A Henrik Kniberg 33
  34. 34. import java.sql.Connection; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; public class Dog { Clean & simple code private Executor executor = Executors.newFixedThreadPool(18); private int CACHE_SIZE = 50; public Dog() { try { Class.forName("oracle.jdbc.ThinDriver"); Simple code: Code is an asset connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); } catch (ClassNotFoundException e) {} All code is cost! new Thread().start(); 1. Passes all tests Some code is value. } public void woof(Person woofCaller) { Connection connection = null; PreparedStatement statement = null; 2. No duplication try { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); statement.setString(2, person.getName()); 3. Readable statement.setString(3, person.getPhoneNumber().getNumber()); statement.executeUpdate(); public class Dog { } private final String name; } } 4. Minimal private int woofCount = 0; } Connection a = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); b = a.prepareStatement("select * from Dog where name = '" + name + "'"); public Dog(String name) { c = b.executeQuery(); this.name = name; if (c.next()) { } String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Person person = new Person(foundName, phoneNumber); public void woof() { return person; ++woofCount; } else { Simple is hard! } return new Person("", null); } } } catch (SQLException e) { return null; } catch (IllegalArgumentException x) { throw x; } } public List<Person> getAll() { connection = DriverManager.getConnection("jdbc:oracle:thin:@prod", "admin", "beefhead"); statement = connection.prepareStatement("insert into Dog values (?, ?, ?)"); statement.setLong(1, System.currentTimeMillis()); } if (statement != null) { if (c.next()) { String foundName = c.getString("name"); PhoneNumber phoneNumber = new PhoneNumber(c.getString(“woofCount")); Embrace Person person = new Person(foundName, phoneNumber); return person; } else { Change! Robert C Martin (Uncle Bob) Kent Beck Henrik Kniberg 34
  35. 35. Kanban in a nutshell Henrik Kniberg 35
  36. 36. Which team needs Managers who don’t know how to measure what they want settle for most improvement? wanting what they can measure Russel Ackoff Team 1 Team 2 Todo Doing Done Todo Doing Done this week this week dolor orem ips um dolor orem ipsum dolor orem ipsum orem ipsum dolor orem ips sit amet, co nse nse um dolor dolor sit amet , co nse sit amet, co dolor sit amet orem ipsum ctetur ctetur ctetur orem ipsum oremdolor dolor ipsum sit amet, co nse orem ipsum , co nse sit amet, co nse orem ipsum dolor orem ipsum dolor sit amet, co nse co nse ctetur orem ips um dolor oremnse sit amet, co ipsum orem ctetur ips um dolor sit amet, ctetur sit amet, co nse amet, co nse sit sit amet ctetur do sit amet ctetur ctetur orem ipsum ctetu dolor , co nse ctetur sit amet, dolor lor orem ipsum co ns , co nse orem ipsum dolor ctetur ctetur orem ipsum dolor r ctetur co nse e sit amet, sit amet, co nse sit amet, co nse sit amet, co nse ctetur orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor orem ipsum dolor orem ipsum dolor dolor ctetur sit amet, co nse sit amet, co nse orem ipsum dolor sit amet, co nse orem ipsum orem ips ctetur co nse um dolor ctetur sit amet, co nse ctetur sit amet, sit amet orem ipsum dolor , co nse ctetur ctetur dolor sit amet, co nse ctetur orem ips um dolor orem ipsum ctetur orem ipsum dolor sit amet orem ipsum dolor co nse , co nse sit amet, orem ipsum dolor sit amet, co nse ctetur sit amet, co nse ctetur sit amet, co nse orem ipsum dolor ctetur ctetur ctetur sit amet, co nse orem ipsum dolor ctetur sit amet, co nse ctetur orem ips orem ipsum dolor um dolor sit amet sit amet, co nse , co nse Avg lead time: 20 days ctetur Avg lead time: 3 days ctetur Henrik Kniberg 36
  37. 37. Kanban @ Imperial Palace Gardens Henrik Kniberg 37
  38. 38. Kanban ”Visual Card” !   Signaling system !   Visual !   Limited in supply Henrik Kniberg 38
  39. 39. Kanban in your wallet Darn. Forgot to limit the supply. Henrik Kniberg 39
  40. 40. Kanban @ Toyota Buyer Supplier Consume Detach Receive Ship Allocate Manufacture The tool used to operate the [Toyota Production] system is kanban. Taiichi Ohno Father of the Toyota Production System Henrik Kniberg 40
  41. 41. 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 41
  42. 42. Kanban example Board shared by several teams Covers whole value stream from concept to release Henrik Kniberg 42
  43. 43. One day in Kanban land Henrik Kniberg 43
  44. 44. ”One day in Kanban land” http://blog.crisp.se/henrikkniberg/tags/kanban/ Henrik Kniberg 44
  45. 45. 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 45
  46. 46. 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 46
  47. 47. 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 47
  48. 48. 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 48
  49. 49. 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 49
  50. 50. 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 50
  51. 51. 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 51
  52. 52. 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 52
  53. 53. 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 53
  54. 54. 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 54
  55. 55. 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 55
  56. 56. 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 56
  57. 57. 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 57
  58. 58. 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 58
  59. 59. Kanban board evolution Henrik Kniberg 59
  60. 60. Kanban evolution example April 7 April 23 Henrik Kniberg 60
  61. 61. Henrik  Kniberg   Kanban www.crisp.se/kanban/example   example kick-start version  1.2   2009-­‐11-­‐16   Next! Analysis! Development! Acceptance! Prod! 2 3 3 2 Ongoing! Done! Ongoing! Done! Ongoing! Done! 2009-08-20! 2009-09-03! 2009-09-01! 2009-08-27! orem olor sit amet, co ipsum dolor sit am 2009-08-30! 2009-09-08! orem ips 2009-08-27! nse ctetur adi pis et, co nse ctetur adi ! cing elit nisl pis orem ipsumipsum dolor orem dolor sit orem ipsum dolor sit orem ipsum dolor sit amet, ! ctetur um dolor co nse orem ipsum dolor amet, ctetur adi sit pis orem ipsum dolor sit cing elit nisl ! amet, cosit amet, co nse nse ctetur ! or cteturem adi pis cingt amipsum dolor si elit nisl ! amet, co adi pis cing elit nisl ! ! sit amet, co nse ctetur cing elit nisl ! amet, adi pis cing elit nisl! ctetur ! et, co n se orem ipsum dolor ! 2009-08- 25! 2009-08-20 2009-09-02! orem ipsum dolor xxxx orem ipsum dolor ctetur ! sit amet, co nse orem ipsum dolor sit ! ctetur ! kjd dj d amet, co nse nse orem ipsum dolor sit ctetur ! sit amet, co ctetur! sit amet, co nse xxx orem ipsum dolor ! sit amet, co nse orem ipsum dolor adi pis cing elit nisl amet, nse ctetur adi ! ctetur ! orem ipsum dolor sit amet, co nse 2009-08-22 pis elit nisl orem ipsum dolor ctetur! sit amet, co nse ctetur orem ipsum ! ! sit amet, co nse ctetur amet, co ! dolor sit 2009-08-29! 2009-08-26! 2009-09-02! orem ipsum dolor sit orem adi pis orem ipsum dolor sit amet, co nse ! amet, nse ctetur adi pis cing elit nisl ! orem ipsum dolor orem ipsum e dolor co ns cing elit nisl! 2009-08-25! orem ipsum dolor sit sit ! orem ipsum dolor amet, co nse sit amet, ctetur ! ctetur adi pis cing ! ! sit amet, co nse ctetur ctetur elit nisl Definition of Done:! Definition of Done:! Definition of Done:! • Goal is clear! • Code clean & checked in on trunk! • Customer accepted! • First tasks defined! • Integrated & regression tested! • Ready for production! • Story split (if necessary)! • Running on UAT environment! Feature / story! Hard deadline! Task / defect! What to pull first! ! =task! ! Date when added to (if applicable)! (description) (description) =defect! •  Panicfeatures! board! (should be swarmed and kept (description) ! = completed! moving. Interrupt other work and = priority! break WIP limits as necessary)! 2009-08-20! 2009-09-30! ! ! = blocked! ! (description) Why •  Priority features! = panic! •  Hard deadline features! (description) ! (only if deadline is at risk)! (description) = who is doing Who is analyzing / •  Oldest features! this right now! testing right now!
  62. 62. Evolve your own unique system! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 62
  63. 63. Compare for understanding, not judgement Henrik Kniberg 63
  64. 64. Lean & Agile process toolkits Values & Principles Lean, Agile, Theory of Constraints, Systems Thinking, etc Kanban Other lean tools XP (Value Stream Mapping, Root Cause Analysis, etc) Scrum Henrik Kniberg 64
  65. 65. Compare for understanding, not judgement More prescriptive More adaptive RUP   XP   Scrum   Kanban   Do  Whatever   (120+) (13) (9) (3) (0) •  Architecture Reviewer •  Business use case realization •  Business Designer •  Business use-case model •  Whole team •  Scrum Master •  Visualize the workflow •  Business-Model Reviewer •  Business vision •  Coding standard •  Product Owner •  Limit WIP •  Business-Process Analyst •  Change request •  TDD •  Team •  Measure and optimize lead time •  Capsule Designer •  Configuration audit findings •  Collective ownership •  Sprint planning meeting •  Change Control Manager •  Configuration management plan •  Customer tests •  Daily Scrum •  Code Reviewer •  Data model •  Pair programming •  Sprint review •  Configuration Manager •  Deployment model •  Refactoring •  Product backlogt •  Course Developer •  Deployment plan •  Planning game •  Sprint backlog •  Database Designer •  Design guidelines •  Continuous integration •  BUrndown chart •  Deployment Manager •  Design model •  Simple design •  Design Reviewer •  Development case •  Sustainable pace •  Designer •  Development-organization •  Metaphor •  Graphic Artist assessment •  Small releases •  Implementer •  End-user support mateirla •  Integrator •  Glossary •  Process Engineer •  Implementation model •  Project Manager •  Installation artifacts •  Project Reviewer •  Integration build plan •  Requirements Reviewer •  Issues list •  Requirements Specifier •  Iteration assessment •  Software Architect •  Iteration plan •  Stakeholder •  Manual styleguide •  System Administrator •  Programming guidelines •  System Analyst •  Quality assurance plan •  Technical Writer •  Reference architecture •  Test Analyst •  Release notes •  Test Designer •  Requirements attributes •  Test Manager •  Requirements •  Tester management plan •  Tool Specialist •  Review record •  User-Interface Designer •  Risk list •  Architectural analysis •  Risk management plan •  Assess Viability of architectural •  Software architecture proof-of-concept document •  Capsule design •  Software development •  Class design plan •  Construct architectural proof-of- •  Software requirements specification concept •  Stakeholder requests •  Database design •  Status assessment •  Describe distribution •  Supplementary business •  Describe the run-time architecture specification •  Design test packages and classes •  Supplementary specification •  Develop design guidelines •  Target organization assessment •  Develop programming guidelines •  Test automation architecture •  Identify design elements •  Test cases •  Identify design mechanisms •  Test environment configuration •  Incorporate design elements •  Test evaluation summary •  Prioritize use cases •  Test guidelines •  Review the architecture •  Test ideas list •  Review the design •  Test interface specification •  Structure the implementation •  Test plan model •  Test suite •  Subsystem design •  Tool guidelines •  Use-case analysis •  Training materials •  Use-case design •  Use case model •  Analysis model •  Use case package •  Architectural proof-of-concept •  Use-case modeling guidelines •  Bill of materials •  Use-case realization •  Business architecture document •  Use-case storyboard •  Business case •  User-interface guidelines •  Business glossary •  User-interface prototype Henrik Kniberg 65 •  Business modeling guidelines •  Vision •  Business object model •  Work order •  Business rules •  Workload analysis model •  Business use case
  66. 66. Customizing your agile process Henrik Kniberg 66
  67. 67. Shu-Ha-Ri stages of learning !  Shu = follow the process !  Ha = adapt the process !  Ri = never mind the process Henrik Kniberg 67
  68. 68. Agile does not require timeboxed iterations Sprints week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Sprint 1 Sprint 2 Plan & commit Review Retrospective (release?) Separate cadences week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning cadence (2w) Release cadence (1w) Event-driven week 1 week 2 week 3 week 4 week 5 week 6 week 7 week 8 Retrospectives (4w) Planning (on demand) Release (on demand) 68
  69. 69. Different ways of limiting WIP Scrum Velocity = 15 story points •  Indirect limit per unit of time •  Items must fit in a sprint Sprint 1 Sprint 2 Sprint 3 Sprint 4 Kanban •  Direct limit per workflow state •  Can combine big & small items Big item WIP limit = 3 items Big item 69
  70. 70. Estimation options ”Typical” Features Tasks Kanban 1. Don’t estimate features. Just count them. 1. Skip tasks 2. Estimate features in t-shirt size 2. Don’t estimate tasks. Just count them. S M L S M L Hours? Days? Weeks? 3. Estimate features in story points 3. Estimate tasks in days ”Typical” 2sp 0.5d 1d Scrum 1sp 5sp 2d 4. Estimate features in ideal man-days 4. Estimate tasks in hours 4h 12h 1d 3d 8h 6d Henrik Kniberg 70
  71. 71. Portfolio-level board Next! Develop! Release! Done! 1 Concept! Playable! 3Features! Polish! 2 Game Team Pac Bingo 1 man Solitaire Game Zork Mine Team Pong sweeper 2 Dugout Game Team Donkey Duck Kong hunt 3 FLOW Avg lead time: 12 weeks 71
  72. 72. Game teams Game team 1 Game team 2 Game team 2 Current game: Pac Man Current game: Pong Current game: Donkey Kong 72
  73. 73. Final points Henrik Kniberg 73
  74. 74. Distinguish between… Using the tool wrong Using the wrong tool Neither of these problems are caused by the tool 74 Henrik Kniberg 74
  75. 75. Don’t be dogmatic Go away! Don’t talk to us! We’re in a Sprint. Come back Though Shalt in 3 weeks. Pair Program Henrik Kniberg 75
  76. 76. Essential skills needed regardless of 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 76
  77. 77. Perfection is a direction, not a place The important thing is not your process. The important thing is your process for improving your process Henrik Kniberg 77

×