ADAPTing to Agile for Continued Success

Agile software development has had more of an influence and has become more widespread than any early practitioner could have imagined. Yet some still call agile a failure. They point to the fact that few teams have achieved the 10x productivity or quality gains that the best agile teams have shown us are possible. They rightly state that partial, half-hearted agile implementations are common. These are real obstacles, yes. But evidence of failure? No. Success with agile development is not binary. No teams are perfect--few have achieved the full benefits of being agile--but most who have begun the journey to embrace agile are better than they were.

We succeed by iterating toward becoming more and more agile. Join me as we explore the five stages of the ADAPT model, a sustainable approach for both getting started with and getting better at agile. By creating Awareness, increasing Desire, developing Ability, Promoting successes, and Transferring the implications of being agile to the rest of the organization (ADAPT), we not only become progressively more agile, we also create a solid foundation on which to continue the industry-wide march toward continued organizational success.

Transcript

1. © 2009 Mountain Goat Software © Copyright Mountain Goat Software® ADAPTing to Agile for Continued Success Agile 2010 - Orlando August 13, 2010 Mike Cohn mike@mountaingoatsoftware.com 1
2. © Copyright Mountain Goat Software® ® Expectations 2
3. © Copyright Mountain Goat Software® ® The OO-Agile connection Agile is the second wave of objects This is why so many Manifesto authors were early OOD / OOP advocates: Kent Beck Alistair Cockburn Ward Cunningham Bob Martin Dave Thomas etc. 3
4. © Copyright Mountain Goat Software® ® Looking back at OO Some said the OO revolution failed because: Objects didn’t achieve their full purpose Being enamored with objects prevented us from looking for even better ways to build software Businesses were led to expect miracles Yet: Could today’s applications be written without objects? 4
5. © Copyright Mountain Goat Software® ® 2005 2009 2010 2.4M 6M 10M Lines of Code in Ford Vehicles 100M Average luxury car 20M Navigation system in 2009 S-Class Mercedes 5
6. © Copyright Mountain Goat Software® ® Agile teams are 5–10x better. 1 What expectations do we have of agile today that could lead us to look back on it and call it a failure? There is a certain set of things you need to do or you aren’t agile. 2 Becoming agile is easy. 3 6
7. © Copyright Mountain Goat Software® ® Very few teams have achieved the gains that some teams have shown are possible Expectation #1: Agile is 5–10x better HWe can point to 5x and 10x success stories HThese are the companies that did everything right HBut these aren’t the norm 7
8. © Copyright Mountain Goat Software® ® Salesforce.com B?6;4
   N?@A
   F2.?
   <3
   B@6;4
   '0?B: +61% +94% +38% +568% Improvement in mean time to release for major releases Increase in features delivered in major releases Increase in features delivered per developer Increase in major release cumulative value Source: Scrum Gathering, April 16, 2008. 8
9. © Copyright Mountain Goat Software® ® Defects per KNCSS ePlan Services 10 Three years prior to introducing agile 2.9 First nine months after starting agile Productivity (NCSS / month) 270 US average 389 Three years prior to introducing agile 1206 First nine months after starting agile 9
10. © Copyright Mountain Goat Software® ® Cosmodemonic Biotech Waterfall Agile Use Case pages User Stories Calendar months Person months Lines of Java code Lines of Java code per person-month 3,000 1,400 9 12 540 54 58,000 51,000 120 840 10
11. © Copyright Mountain Goat Software® ® Pre-XP XP Improvement Cost Schedule Defects 'A.3N;4 $2.8 million $1.1 million 61% 18 months 13.5 months 24% 2,270 381 83% 18 11 39% Source: “10 Tips for Successful Agile Transitions,” Joshua Kerievsky, QCon 2007. At http://www.infoq.com/presentations/10-tips-for-agile-transitions Improvements using Extreme Programming 11
12. © Copyright Mountain Goat Software® ® Many teams miss the mark Either don’t do “all” of agile or don’t do it well “We do Scrum, but…” “we do 3-month sprints.” “we don’t have anything shippable at the end of each sprint.” “we do testing in a separate sprint.” Expectation #2: Agile is “this” set of things 12
13. © Copyright Mountain Goat Software® ® It’s not about strict adherence Meet daily Test first Integrate continuously Inspect and Adapt 13
14. © Copyright Mountain Goat Software® ® Expectation #3: Doing agile is easy Most claims are realistic “Although agile processes promise greater productivity once in place, productivity may decrease during the transition while the team learns new techniques.” 1 “Mastery” in two days “Maybe we need to say, ‘Agile is hard, and you can’t master it by sitting through a two-day course.’” 2 But there are some promises of miracles: “Current research shows that any team can achieve hyper- productivity in a few sprints, even in a dysfunctional company.”3 1Cohn and Ford, “Introducing an Agile Process to an Organization,” IEEE Computer, June 2003. 2James Shore, http://jamesshore.com/Blog/The-Decline-and-Fall-of-Agile.html 3Jeff Sutherland, http://scrumjeffsutherland.blogspot.com/2009/12/jeff-sutherland-google-dec-14-2009.html. 14
15. © Copyright Mountain Goat Software® ® Project Size Productivity Smaller Larger Lower Higher +/- 1 Standard deviation Industry average Agile projects So let’s see what the truth is Mah, Michael. 2008. “How agile projects measure up, and what this means to you.” Cutter Consortium 15
16. © Copyright Mountain Goat Software® ® Mah, Michael. 2008. “How agile projects measure up, and what this means to you.” Cutter Consortium Agile projects Project Size Time-to-Market Smaller Larger Lower Higher Industry average +/- 1 Standard Deviation 16
17. © 2009 Mountain Goat Software © Copyright Mountain Goat Software® ® Will agile continue to “fail” against these expectations? Of course, if that means Not all companies become 5–10x better Being done half-heartedly in some places It will continue to be hard to do 17
18. © Copyright Mountain Goat Software® ® But these are inappropriate measures of success Agile is not something you become, it’s something you become more of. 18
19. © Copyright Mountain Goat Software® ® Becoming more than you are I’m more
    O2E6/92
    A5.;
    
    used to be You’re more
    O2E6/92
    A5.;
    
    am She is
    O2E6/92 19
20. © Copyright Mountain Goat Software® ® Succeeding with agile Success in agile is about becoming better than we were Stop obsessing over being perfect 20
21. © Copyright Mountain Goat Software® ® How do we get there? We raise the bar on one another 21
22. © Copyright Mountain Goat Software® ® Raising the bar–slowly but steadily 22
23. © Copyright Mountain Goat Software® ® 23
24. © Copyright Mountain Goat Software® ® Continuing to raise the bar on one another 24
25. © Copyright Mountain Goat Software® ® This idea used to bother me 25
26. © Copyright Mountain Goat Software® ® It’s still about continuous improvement 26
27. © Copyright Mountain Goat Software® ® Awareness that there is room for improvement A Desire to change D Ability to work in an agile manner A Promote early successes to build momentum and get others to follow P Transfer the impact of agile throughout the organization so that it sticks T 27
28. © Copyright Mountain Goat Software® ® “I’m the ScrumMaster and ... ...the developers are not meeting expectations for code quality. One of our challenges is that we’re still hacking our way through lots of legacy code that isn’t unit- testable or automated yet. This code is mission- critical and the person who has been working mostly on that area of code consistently leaves holes in the design and implementation of new pieces of that code. How can I get her to write high-quality code with automated tests?” 28
29. © Copyright Mountain Goat Software® ® Individual and group change All individuals will need to move through the Awareness, Desire, and Ability stage But will do so at different rates Early adapters and leaders: Use the Promote stage to build Awareness and Desire in later adopters Need to Transfer the impact of agile to groups like Human Resources or the transition will fail 29
30. © Copyright Mountain Goat Software® ® Tools for building... Awareness HCommunicate that there’s a problem HUse metrics HProvide exposure to new people and experiences HFocus attention on the most important reason or two for changing 30
31. © Copyright Mountain Goat Software® ® Tools for building... Desire HCommunicate that there’s a better way HCreate a sense of urgency HBuild momentum HGet the team to take agile for a test drive HAlign incentives (or, at least, remove disincentives) HFocus on addressing any fears HHelp people let go HDon’t discredit the past HEngage everyone in the transition 31
32. © Copyright Mountain Goat Software® ® Waterfallacies H Mistaken beliefs or ideas about agile created from working too long on waterfall projects. Examples H Agile ignores architecture, which would be disastrous for the type of system we build. H Agile is OK for simple websites, but our system is too complicated. H Our team is spread around the world, and agile requires face- to-face communication. 32
33. © Copyright Mountain Goat Software® ® Ability HProvide coaching and training HHold individuals accountable HShare information HSet reasonable targets HJust do it Promote HPublicize success stories HHost an agile safari HAttract attention 33
34. © Copyright Mountain Goat Software® ® Transfer HTransfer the effects of agile beyond the current group HA team transfers to its department HA department transfers to its division Hetc. HIf you don’t transfer, the transition will eventually and inevitably fail HToo much organizational gravity pulling us back toward the status quo HExample: HIf you don’t align promotions, raises, annual reviews, those will work against you 34
35. © Copyright Mountain Goat Software® ® Iterating toward agility 35
36. © Copyright Mountain Goat Software® ® Enterprise Transition Community (ETC) Improvement backlog Improvement Communities Improvement backlog Improvement backlog Improvement backlog Impediments Energy, suppport, resources, guidance, & direction (occasionally) Iterating toward agility 36
37. © Copyright Mountain Goat Software® ® Enterprise Transition Community (ETC) Creates a culture in which passion and desire to improve can thrive Does not direct the transition effort Provides energy, resources, support and guidance Removes organizational impediments to agility Encourages Improvement Communities to form 37
38. © Copyright Mountain Goat Software® ® ETC members Sponsor From highest level at which change is supported Not a checkbook-only commitment Others From any level but driven by desire to improve Disbands when the “transition” part of adopting agile is over 38
39. © Copyright Mountain Goat Software® ® ETC responsibilities Articulate the reasons for adopting agile Stimulate conversation Provide resources Engage everyone Set appropriate aspirations Anticipate and address people issues and other impediments Encourage simultaneous focus on practices and principles 39
40. © Copyright Mountain Goat Software® ® An ETC’s improvement backlog Item Who Note ?2.A2
    .;
    M4692
    &3Q02N
    D52?2
    teams can get help. Jim (CTO) to talk this up at monthly development meeting. Let’s see if there’s any interest. Establish an internal program for developing ScrumMasters. How do we identify good internal candidates? How do we develop them? Collect and disseminate Scrum success stories in our company. SC Savannah has expressed interest in this. Resolve dispute with facilities <C2?
    ?2.??.;46;4
    @20<;1
    R<<?
    cubicles. JS Jim to talk to Ursula in facilities Get more teams to do continuous integration. AR Arie will summarize metrics from his project and see how many teams he can motivate. 40
41. © Copyright Mountain Goat Software® ® Improvement communities (ICs) Form around the passion of a small number of people Expand from there Do the real work of improving how the organization implements agile Focus on goals with practical relevance Examples: ScrumMaster, Testing, Product Owner, Continuous Integration 41
42. © Copyright Mountain Goat Software® ® Working with an IC An IC works with a project team Work is not done in an ivory tower Most ICs work in 2–4-week iterations Disband or refocus when goal has been achieved 42
43. © Copyright Mountain Goat Software® ® ETC Improvement Backlog … Establish an internal program for developing ScrumMasters. … Not everything on an IC’s improvement backlog needs to tie back to the ETC’s backlog An IC Improvement Backlog Figure out how to identify good candidates to become ScrumMasters (in addition to those who ask to participate in this program). Establish an internal mentoring program. Develop some internal classroom training. Which courses? Who can teach them? Can we license courses? Get budget for next year for external coaching. How many days? At what expected daily rate? 43
44. © Copyright Mountain Goat Software® ® <
    /.08
    A<
    A52
    <3N02
    .;1
    0?2.A2
    .;
    improvement backlog ?2.A2
    0<::B;6A62@
    <?
    ;<A
    /BA
    N;1
    passionate people to attack improvement backlog items Return here next year more agile than you are today Let’s see how soon we can make it “software development” instead of “Agile Software Development” 1 2 3 4 44
45. © Copyright Mountain Goat Software® ® Mike Cohn mike@mountaingoatsoftware.com www.mountaingoatsoftware.com twitter: mikewcohn (888) 61−AGILE 45