Bootstrapping Scrum Lessons learned helping companies get started

Transcription

1 Bootstrapping Scrum Henrik Kniberg - Crisp AB Agile coach & Java guy Cofounder / CTO of Goyada (mobile services) 30 developers Lead architect at Ace Interactive (gaming) 20 developers Chief of development at Tain (gaming) 40 developers Agile coach at various companies henrik.kniberg@crisp.se Lessons learned helping companies get started Scrum Gathering Stockholm

2 Case 1 Bootstrapping agile teams Henrik Kniberg 2

3 Case 1: Bootstrapping agile teams Step 1: Ask Why change? Typical answers: Faster delivery Higher quality Increased motivation and work pride Clearer roles Henrik Kniberg 3

4 Case 1: Bootstrapping agile teams Step 2: Create rough transitioning plan Timeline Henrik Kniberg 4

5 Case 1: Bootstrapping agile teams Step 3: Interviews Henrik Kniberg 5

6 Case 1: Bootstrapping agile teams Root cause analysis - example Teams not businessoriented Teams grouped by component Teams not focused Team not getting feedback from customer Lack of team spirit Teams don t have own PO Ineffective requirements communication Too much focus on written specs POdoesn t have own team Unclear roles & responsibilities Lack of discipline in teams = fix first = root cause = visible damage = talked about = not talked about = vicious cycle Feature split across multiple teams Hard to plan Delayed releases Lack of transparancy No burndowns Fear of committing Bad throughput in development Problems estimating Not measuring velocity Cutting quality instead of scope Difficult to release Teams disrupted during sprint Many defects Lack of test automation Hard to change the code Many operational problems Customers dissatisfied Henrik Kniberg 6

7 Case 1: Bootstrapping agile teams Problem: Teams grouped by component PO Product A Feature A1 Product B PO Product C?!!? PO Product D PO Henrik Kniberg 7

8 Case 1: Bootstrapping agile teams Step 4: Half-day Scrum intro course Henrik Kniberg 8

9 Case 1: Bootstrapping agile teams Step 5: Half-day workshops Henrik Kniberg 9

10 Case 1: Bootstrapping agile teams Transitioning backlog Status What Definition of done Done Lean & Scrum training for everyone All potential SM &PO & team members understand their roles Done Go through product backlogs Product backlogs ready for estimation Ongoing Define teams ScruMLdrawn, buy-in from all PO and SM at the very least. Decide which team sits where Office map showing which team sits where Co-locate each team Alla team members sit together and have close access to sprint backlog and daily scrum.... etc... Henrik Kniberg 10

11 Case 1: Bootstrapping agile teams Transitioning team Status What Definition of done Done Lean & Scrum training for everyone All potential SM &PO & team members understand their roles Done Go through product Produkt backlogs ready for estimation backlogs Ongoing Define teams ScruML drawn, buy-in from all PO and SM at the very least. Decide which team sits Office map showing which team sits where where Co-locate each team Alla team members sit together and have close access to sprint backlog and daily scrum. Coach Project leader CTO Developer Tester Product manager Henrik Kniberg 11

12 Case 1: Bootstrapping agile teams Goal: Feature teams PO Product A Feature A1 PO Product B PO Product C PO Product D Henrik Kniberg 12

13 Case 1: Bootstrapping agile teams Who defines the teams? Option 1: Teams defined centrally (by transitioning team or management team) + Works + Fast -Lack of buy-in -Doesn t harness collective knowledge Option 2: Teams form themselves from scratch + Harnesses collective knowledge + Buy-in -Slow -Might not work Option 3: Combination of Preliminary teams defined centrally, teams then allowed to reform themselves + Works + Harnesses collective knowledge + Buy-in + Faster than option 2 -Slower than option 1 Henrik Kniberg 13

14 Case 1: Bootstrapping agile teams Self-organizing to form new teams Preliminary team allocation Combined After a week in the kitchen Combined New Henrik Kniberg 14

15 Case 1: Bootstrapping agile teams Case 1 Take-away points Look before you leap Interviews coach learns Course coach teaches Workshops coach facilitates Involve people Create a transitioning team Give the Scrum teams a chance to form themselves Incremental process improvement Use a transitioning backlog Think carefully about how big steps to take Set based design evaluate and compare multiple options Henrik Kniberg 15

16 Case 2 Speeding up product development Henrik Kniberg 16

17 Case 2: Speeding up product develompent Game backlog 8 Design-ready games 15 Production-ready games 12 2d Sam 2h 1m Concept pres. 4h 6m Lisa assigns resources 1d Graphics Sound design design Dev 1w 6m 6m 1m 3w 3m (1m+2m) Games out of date Missed market windows Demotivated teams Overhead costs 3 m value added time 25 m cycle time Integr. & deploy 3w = 12% Process cycle efficiency Estimate w1 w2 w3 w4 w5 w6 w7 w8 2 m cycle time = 12x faster Preliminary result 4 m cycle time = 6x faster w1 w2 w3 w4 w5 w6 w7 w8 Henrik Kniberg 17

18 Case 2: Speeding up product develompent Case 2 Take-away points w1 w2 w3 w4 w5 w6 w7 w8 Speeding up product development is often a matter of improving the process rather than adding people. Value stream mapping is a great tool for spotting bottlenecks Scrum is a great tool for removing bottlenecks But beware the Scrum trap suboptimization! The pictures make it look easy... But executing the change is hard Hey, let s do Scrum here! Maybe we can cut dev time in half! From 3 months to 1.5 months... 2d Sam 2h 1m Concept pres. 4h Lisa Graphics Sound assigns Dev design design resources 6m 1w 6m 6m 1d 1m 3w 3m (1m+2m) Integr. & deploy 3w Henrik Kniberg 18

19 Case 3 Revealing a failing project Henrik Kniberg 19

20 Case 3: Revealing a failing project Symptom: Waterfall process (under Scrum banner) 2006 Requirements Coding 2007 Release Testing? Q1 Q2 Q3 Q4 Q1 Q2 We are here Henrik Kniberg 20

21 Case 3: Revealing a failing project Symptom: Long, detailed requirements specifications Henrik Kniberg 21

22 Case 3: Revealing a failing project Symptom: Lack of trust & commitment Henrik Kniberg 22

23 Case 3: Revealing a failing project Strategy: Implement Scrum Show us where we stand Help us move faster 2007 Create product backlog Estimate product backlog Jan Execute 2 sprints, measure velocity Feb We are here Henrik Kniberg 23

24 Case 3: Revealing a failing project Step 1: Change Definition of Done Old definition of done: Code checked in New definition of done: Releasable Tester added to team Henrik Kniberg 24

25 Case 3: Revealing a failing project Step 2: Create a product backlog Features left to implement Features implemented but not tested & integrated PO Henrik Kniberg 25

26 Case 3: Revealing a failing project Step 3: Estimate product backlog Features left to implement Features implemented but not tested & integrated Total: 180 points Total: 70 points ? 3 Henrik Kniberg 26

27 Case 3: Revealing a failing project Sprint 1 Sprint 2 Step 4: Execute 2 sprints Estimated Velocity Actual Velocity Henrik Kniberg 27

28 Case 3: Revealing a failing project Step 5: Face reality & Revise the plan Backlog = 250 points Velocity = 10 points/sprint 25 sprints > 1 year until release! 2007 Promised release 2008 Earliest likely release Q1 Q2 Q3 Q4 Q1 Q2 We are here Henrik Kniberg 28

29 Case 3: Revealing a failing project Step 6: Act Reduce Backlog = 250 points Velocity = 10 points/sprint Reduce total scope Incremental releases Overall priorities 1. Operations 2. Project X 3. Anything else Increase Fix impediments Pressure on team Ineffective build & test environment Lack of teamwork, discipline & motivation Disruptions & context switching Unrealistic expectations ROOT CAUSE: Company needs to focus Henrik Kniberg 29

30 Case 3: Revealing a failing project Result 2007 Originally promised release (big-bang) 2008 Earliest likely release if process hadn t changed (big-bang) Q1 Q2 Q3 Q4 Q1 Q2 30 Velocity estimated Actual release (incremental) Actual release (incremental) actual 9-10 Q1 Q2 Q Henrik Kniberg 30

31 Case 3: Revealing a failing project Case 3: Take-away points Waterfall is still waterfall even if you call it Scrum Know your tools, get training & coaching early. Don t believe your plan There is no the plan must be right because we promised. Make sure you have reliable feedback loops & a changeable plan. There is no too low velocity Just actual velocity, and a realistic or unreleastic plan. Build quality in Don t postpone test & integration, that gives a false velocity. Having good people isn t enough An inappropriate process can cause even a great team to fail. Dramatic improvements can be made quickly With strong management & development teams, access to empirical data, and willingness to focus. Henrik Kniberg 31

32 Case 1: Bootstrapping agile teams Discussion Case 3: Revealing a failing project 250 points 10 points/sprint 2007 Originally promised release (big-bang) 2008 Earliest likely release if process hadn t changed (big-bang) Q1 Q2 Q3 Q4 Q1 Q2 Actual release (incremental) Actual release (incremental) Case 2: Speeding up product development