Seeking Good Agile and Avoiding Bad Agile. Agile Aus2n Monthly Mee2ng Jan. 06, 2015

Transcription

1 Seeking Good Agile and Avoiding Bad Agile Agile Aus2n Monthly Mee2ng Jan. 06, 2015

2 Who am I? Earl EvereE Director, Manager, Developer, Tester 1st professional sokware experience in st agile experience in 1973 Have rolled out Scrum and/or Kanban in 8 companies and rebooted in two (all achieved a hyper- produc2ve state)

3 Waterfall vs. Agile Project Results Successful Waterfall Challenged Failed Agile CHAOS project database results from for waterfall vs. agile projects Source: The CHAOS Manifesto, The Standish Group, 2012

4 The agile process is the universal remedy for sokware development project failure. SoKware applica2ons developed through the agile process have three 2mes the success rate of the tradi2onal waterfall method and a much lower percentage of 2me and cost overruns. Source: The CHAOS Report, (pg. 25) The Standish Group, 2011

5 The Stacey Diagram Requirements ( What ) Agreement Far from Close to Close to Certainty Far from Technology ( How )

6 Bad Agile Waterfall Successful Challenged Failed 49% of Agile is Bad Agile Agile Source: The CHAOS Manifesto, The Standish Group, 2012

7 What are the Primary Reasons for Bad Agile? Failure to implement the Agile Manifesto Individuals and Interac;ons over Processes and Tools Working over Comprehensive Documenta;on Customer Collabora;on over Contract Nego;a;on Responding to Change over Following a Plan Teams cannot respond to stakeholder feedback at the end of a Sprint because the so6ware doesn t work! Teams do not work together to produce working sokware at the end of a Sprint Fixing defects later can mean 24x more tes2ng!

8 Why is it so important to have Working SoKware at the end of each Sprint? Since 2006, all OpenView Venture Partners porgolio companies do Scrum, and all employees are on Scrum Teams. With data from thousands of Sprints, OpenView investors did a detailed analysis, and they discovered something interes2ng Source: Jeff Sutherland, Scrum Inc., 2014

9 Teams That Finish Early Accelerate Faster!

10 Why don t Teams have Working SoKware? Poor Defini2on of Done (DoD) Stories not Ready Dysfunc2onal leadership Technical debt Ineffec2ve coaching

11 Poor Defini2on of Done (DoD) Defini2on of Done is unclear It is impossible to be done if you don t know what Done is. Lack of consistent quality standards Defini2on of Done does not include working sokware. Dysfunc2onal Product Owner accepts Stories that are not done.

12 Stories Not Ready Poorly wrieen stories Stories are not clear, par2cularly the acceptance criteria. Uniden2fied dependencies. Story Sizing Bad es2mates - inconsistent use of story points Taking stories that are too large into Sprint Taking too many stories into Sprint

13 Dysfunc2onal Leadership (1/2) Too many projects in pipeline. (Context switching) Everything is #1 or #! Priority. Pressure to get things done delays projects and reduces quality. Lack of understanding of agile.

14 Dysfunc2onal Leadership (2/2) Inadequate or no business involvement / Product Ownership Fear of exposure or change in responsibili2es Inadequate or no tes2ng (e.g. healthcare.gov) No Con2nuous Integra2on (CI)

15 Technical Debt Not finishing Sprints creates bad code - > 24x delay 1 Legacy code is oken an accumula2on (mountain) of technical debt, which slows velocity Severely aggravated by not having Con2nuous Integra2on and automated tes2ng, and current tools for same. Technical debt is incurred by running development too close to maximum, leading to short cuts, lack of refactoring, loss of crea2vity, demo2va2on, poor morale, and sloppy craksmanship. 1 Source: Scrum and CMMI Going From Good To Great, Jeff Sutherland and Carsten Jakobson, IEEE digital Library.

16 Poor Coaching Silos and specializa2on cripple velocity Specialized test teams are the worst example Developers not func2oning as a Team Minimal collabora2on, no swarming No con2nuous improvement flatlines velocity Pretend Agile no teamwork, no working sokware, no customer/business collabora2on, and no effec2ve response to change.

17 Systema2c Approach to Getng to Done Implemen2ng the Defini2on of Done (DoD) Ensuring the backlog is Ready Training for management Technical debt remedia2on plan Upgrading coaching and ScrumMaster posi2ons

18 Implemen2ng Done Defini2on of Done (DoD) must include integra2on tes2ng, and test capacity must exceed coding capacity. Testers must be on the Scrum Team no separate test teams Do not take too much into the Sprint. Use paeerns: Yesterday s Weather Illegi2mus Non Interruptus Scrum Emergency Procedure

19 Implemen2ng Done (cont.) Use an automated build system Systema2cally build automated acceptance tests Fix defects in less than a day

20 Implemen2ng Ready The Scrum Guide (hep://scrumguides.org/) is being updated to include the concept of Ready Like the Defini2on of Done, the Team agrees on a common Defini2on of Ready. Only Ready Stories go into the Sprint Backlog. Backlog Refinement assures the Ready state. A good Ready state can triple velocity.

21 Ideas for your Defini2on of Ready Story defined and wrieen Story traceable to source document (where appropriate) Acceptance criteria defined Dependencies iden2fied Size es2mated by delivery team User experience included (where appropriate) Performance criteria iden2fied (where appropriate) Person who will accept the user story is iden2fied Team has a good idea about how to demo the user story

22 User Story Readiness Progression Stage 1. (IniAal User Story) 2. Criteria PromoAon to Next Stage All inputs accepted Product Owner determines Story matches Product goals Analysts decompose UX researches context Business alignment needs iden2fied Matches Release goals Ready Card details, acceptance criteria, UI pre- work, (wireframes, visual and content prototypes) Legal & compliance issues reviewed Ready for Sprint Candidates for Release & Sprint Planning Minimal refinement expected on core UX Alignment with key stakeholders on features, func2ons, and visuals (Source: Jeff Sutherland, Scrum, Inc.)

23 Using Ready can Triple Velocity

24 Leadership 101: Provide the 3 C s Clarity Condi2ons Constraints

25 Clarity is What to work on Provide challenging goals for the Team How it fits into the big picture

26 Condi2ons are Set up the Teams (in collabora2on with Teams). Organiza2onal structures and policies that support the work. All the resources the Teams need

27 Constraints are What can always should be done, and What should never be done (guardrails) (These are not constraints in the Lean sense.)

28 The 3 C s (Clarity, Condi2ons, and Constraints) are the elements that enable people to take individual leadership and not make huge mistakes.

29 Level Descrip2on Comment 4 Secure 3 Safe 2 Neutral 1 Dangerous Everything is discussable without filtering Almost everything is discussable without filtering Most things are discussable without filtering Many of my best ideas are not discussable ++++ *** *** *********** ********** ++ * +++ ***** 0 Treacherous Most of my best ideas are not discussable

30 Leadership Responsibili2es Iden2fy and remove impediments for the Teams Understand what slows Teams down Remove waste Hold P.O. accountable for value delivered per point Hold S.M. accountable for Team happiness and process improvement.

31 Remediate Fix Technical Debt 80% of bugs come from 20% (or less) of code Strategy for determining remedia2on priori2es Stop the Pain Systema2cally build acceptance tests into the build Reduce the Debt Team builds the business case for Product Owner Management commitment to systema2c improvement of product

32 Product Value Visibility Visible Invisible Posi2ve Value Feature Architecture Defect Technical Debt Nega2ve Value

33 Spo2fy Excellent Coaching Example Hires great workers Every Team has a coach Coaches are responsible for 1 process improvement every Sprint They use an Improvement Backlog, and measure improvement con2nuously Coaching has improved radically the output of high- performance Teams In the last year, 33% of all Spo2fy Teams have moved to con2nuous deployment mul2ple 2mes per Sprint.

34 Best Metrics for Coaches Time to fix a defect If average < 24 hrs., Team s velocity will 2x Measure swarming (How well do individuals and interac2ons generate performance) Measure flow (actual work to do a story / calendar 2me to Done) If this is over 50%, the Team velocity will 2x again

35 Conclusions Bad Agile is caused by five primary factors: 1. Poor Defini2on of Done (DoD) 2. Stories not Ready 3. Dysfunc2onal Leadership 4. Technical Debt 5. Ineffec2ve coaching

36 Conclusions (cont.) Focusing systema2cally on ameliora2ng these issues will consistently produce high- performing Teams with 200% to 400% improvement in produc2on. Failure to focus on these will add yet another Team to the 49% of Teams that are Bad Agile, leading to unhappy customers, employees, and lost revenue.

37 Coaching PaEerns Stable Teams (getng started) Yesterday s Weather (how to pull into Sprint) Daily Clean Code (get to defect- free product) Swarming (how to get work done quickly) Interrupt PaEern (how to deal w/interrup2ons) Stop the Line (how to deal with emergencies) Scrumming the Scrum (how to insure improvement) Happiness metric (how to insure Teams aren t overburdened) See for more informa2on

38 ?

39 Contact info LinkedIn Earl EvereE