"The essence of agile"

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

What is all this stuff? TDD Scrum XP Continuous Integration Refa c torin Pair g ming Lean program RUP Agile Henrik Kniberg 2

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 how to build it !   Nothing will change along the way Henrik Kniberg 4

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

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

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

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

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

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

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

Agile in a nutshell Henrik Kniberg 12

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

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

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

Agile ”umbrella” FDD DSDM Scrum XP Crystal Kanban Sources: 3rd Annual ”State of Agile Development” Survey June-July 2008 •  3061 respondents •  80 countries 16

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

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

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 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

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

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

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

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

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

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

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

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

XP in a nutshell Henrik Kniberg 30

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

Feedback loops Sprint review Daily Scrum Continuous integration Unit test Pair programming Henrik Kniberg 32

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

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

Kanban in a nutshell Henrik Kniberg 35

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

Kanban @ Imperial Palace Gardens Henrik Kniberg 37

Kanban ”Visual Card” !   Signaling system !   Visual !   Limited in supply Henrik Kniberg 38

Kanban in your wallet Darn. Forgot to limit the supply. Henrik Kniberg 39

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

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

Kanban example Board shared by several teams Covers whole value stream from concept to release Henrik Kniberg 42

One day in Kanban land Henrik Kniberg 43

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kanban board evolution Henrik Kniberg 59

Kanban evolution example April 7 April 23 Henrik Kniberg 60

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!

Evolve your own unique system! Some of these photos courtesy of David Anderson, Mattias Skarin, and various other people Henrik Kniberg 62

Compare for understanding, not judgement Henrik Kniberg 63

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

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

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 Henrik Kniberg 67

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

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

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

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

Game teams Game team 1 Game team 2 Game team 2 Current game: Pac Man Current game: Pong Current game: Donkey Kong 72

Final points Henrik Kniberg 73

Distinguish between… Using the tool wrong Using the wrong tool Neither of these problems are caused by the tool 74 Henrik Kniberg 74

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

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

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

http://agileee.org	1847
http://bobsleanlearning.wordpress.com	209
http://agileee.com	65
http://test.agileee.org	34
http://agile.sk	32
http://vmylko.blogspot.com	23
http://www.agileee.com	11
http://2011.agileee.org	8
http://translate.googleusercontent.com	3
http://static.slidesharecdn.com	3
http://twitter.com	1

"The essence of agile"

by Agileee on Oct 10, 2010

Accessibility

Tags

Upload Details

Usage Rights

11 Embeds 2,236

Statistics

"The essence of agile" — Presentation Transcript