Agile Adoption - Opportunities and Challenges


Published on

Agile adoption tips for organizations and change leaders.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Stay flexible by reducing obstacles to changeChange is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead.EmergenceEmergence is one of the founding principles of agility, and is the closest one to pure magic. Emergent properties aren't designed or built in, they simply happen as a dynamic result of the rest of the system. "Emergence" comes from middle 17th century Latin in the sense of an "unforeseen occurrence." You can't plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it.A classic example of emergence lies in the flocking behavior of birds. A computer simulation can use as few as three simple rules (along the lines of "don't run into each other") and suddenly you get very complex behavior as the flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. None of this advanced behavior (such as reforming the same shape around an obstacle) is specified by the rules; it emerges from the dynamics of the system.Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior.Many common software development practices have the unfortunate side effect of eliminating any chance for emergent behavior. Most attempts at optimization — tying something down very explicitly — reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it's the interactions and relationships that create the interesting behavior.The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.Keep it small. Keep it simple. Let it happen.—Andrew Hunt, The Pragmatic Programmers
  • Your thoughts & experiencesIs it easy?We’ve heard it all: black, white, and shades of gray in between.many Agile principles aren’t intuitive or are counter to traditional management approaches. Some of these initially counter-intuitive principles:Starting more stuff faster means you will finish more stuff later. Striving for perfect definition up front is going to slow down delivery. Don’t build everything that might ever be needed right now – only build what you will need today. More testing speeds you up. Changing Mental Models creates new possibilities and allows us to make better decisions. We allow the results to influence our Mental Model and not just the next decision. When learning influences our Mental Model we call this Double Loop Learning.
  • To collaborate across silos
  • To collaborate across silos
  • Agile Adoption - Opportunities and Challenges

    1. 1. Service<br />Knowledge<br />Result<br />3 February 2011<br />Silvana Wasitova<br />Agile Adoption: Opportunities and Challenges<br />
    2. 2. To Do Doing Done<br />2<br />© Itecor all rights reserved <br />Opportu<br />nities<br />Examples<br />Challenges<br />Strategy<br />
    3. 3. I little bit about me<br />3<br />© Itecor all rights reserved <br />Waterfall<br />Scrum<br />
    4. 4. At<br />4<br />© Itecor all rights reserved <br />
    5. 5. To Do Doing Done<br />5<br />© Itecor all rights reserved <br />Opportu<br />nities<br />Examples<br />Challenges<br />Strategy<br />
    6. 6. 64% implemented features are rarely or never used<br />6<br />Focusing on customer needs ensures:<br />the right features are built<br />not wasting effort (and resources) on features that are not needed<br />Main principle:<br />Only build the features that the client/users need<br />Ref: Jim Johnson, Chairman of Standish Group, quoted in 2006 in: government and commercial organizations, no vendors, suppliers or consultants<br />© Itecor all rights reserved <br />
    7. 7. Scrum vs. Waterfall: Time To Market<br />SCRUM<br /><ul><li> Faster Time to Market
    8. 8. Higher Quality
    9. 9. Satisfied Customer
    10. 10. Better Usability</li></ul>3 MONTHS<br />Develop & QA + Changes<br />Spec<br />Collaborative<br />Results-Oriented<br />Waterfall<br />6-10 MONTHS<br />Develop & QA<br />Changes<br />Spec<br />ywks<br />x wks<br />Sequential <br />Process-Oriented<br />© Silvana Wasitova<br />
    11. 11. Lower cost of change<br />8<br />© Itecor all rights reserved <br />Cost of change<br />Traditional project<br />Agile<br />project<br />Time<br /><ul><li>More defects prevented & fixed
    12. 12. Continuous testing
    13. 13. Fast feedback & adaptive planning</li></li></ul><li>Agile deals with<br />9<br />© Itecor all rights reserved <br />
    14. 14. Why Scrum works<br />10<br />© Itecor all rights reserved <br />Close collaboration with client (or proxy) <br />better product<br />increased satisfaction<br />Transparency through daily check-ins: <br />early visibility of issues <br />early resolution <br />reduced risk<br />Increased ROI: delivering business value in small increments, more often<br />Eliminate waste, focus on highest priorities<br />Inspect, adapt, improve: in each iteration<br />
    15. 15. To Do Doing Done<br />11<br />© Itecor all rights reserved <br />Opportu<br />nities<br />Examples<br />Challenges<br />Strategy<br />
    16. 16. Scrum Adoption at Yahoo<br />12<br />© Itecor all rights reserved <br />2004: VP of Product Development authorized experiment with scrum<br />2005: Hired Senior Director of Agile Development<br />2008 status: <br />3 coaches, each coaching approx. 10 scrum teams/year<br />200 scrum teams world wide, total approx. 1500+ employees<br />Results in 2008:Average Team Velocity increase estimated at +35% / year,in some cases 300% - 400%<br />Development cost reduction of over USD 1 million / year<br />ROI on transition and trainings about 100% in first year<br />Note:In those first three years, 15-20% of people consistently DID NOT like Scrum<br /><br />
    17. 17. Scrum: New Effectiveness: 27.25/50 = 54.5%<br />Increase by 430%<br />British Telecom 2007,<br />Typically BT Value Stream<br />13<br />© Itecor all rights reserved <br />
    18. 18. HCL EAI Services Inc. <br />14<br />© Itecor all rights reserved <br />Enterprise application integration services: healthcare, retail, telecommunication, wireless.<br /><br />
    19. 19. - 2007 <br />15<br />Down to 1 release/yr<br />Scrum adoption: 3 months<br />Results:<br />60+ Critical features delivered in < 9 months<br />“Idea to Release” avg. rate: 2.2 quarters<br />70% of “Top 10 Ideas” are on track for delivery in 2007<br /><br />
    20. 20. - 2007 <br />16<br /><br />
    21. 21. To Do Doing Done<br />17<br />© Itecor all rights reserved <br />Opportu<br />nities<br />Examples<br />Challenges<br />Strategy<br />
    22. 22. Challenges: Mindset Change<br />Coaching Helps<br />I heard of this new thing<br />People are talking about it<br />I want to try!<br />Do I have to?<br />Will this work?<br />The Chasm<br />Innovator<br />Early adopters<br />Early Majority<br />Late Majority<br />Laggards<br />Crossing the Chasm, Geoffrey Moore, 2002<br />© Itecor all rights reserved <br />18<br />
    23. 23. MINDSET CHANGE<br />19<br />© Itecor all rights reserved <br />
    24. 24. Barriers to Adoption<br />20<br />© Itecor all rights reserved <br /><br />
    25. 25. Causes of Failed Adoption<br />21<br />© Itecor all rights reserved <br /><br />
    26. 26. To Do Doing Done<br />22<br />© Itecor all rights reserved <br />Opportu<br />nities<br />Examples<br />Challenges<br />Strategy<br />
    27. 27. Keys to SuccessfulAgile Adoption<br />23<br />© Itecor all rights reserved <br />
    28. 28. 24<br />© Itecor all rights reserved <br />Visionary &<br />Champion<br />Christopher Colombus<br />
    29. 29. 25<br />© Itecor all rights reserved <br />Sponsor<br />Queen Isabelle<br />
    30. 30. 26<br />© Itecor all rights reserved <br />Translation Key<br />Rosetta Stone<br />
    31. 31. 27<br />© Itecor all rights reserved <br />Trainer & Coach<br />Coach Extraordinaire <br />
    32. 32. Agile Champions<br />28<br />© Itecor all rights reserved <br /><br />
    33. 33. Strategy: A.D.A.P.T.<br />29<br />© Itecor all rights reserved <br />Strategy:<br />Mike Cohn, MountainGoat Software<br />
    34. 34. What Works<br />
    35. 35. 31<br />© Itecor all rights reserved <br />Start small, then grow<br />
    36. 36. 32<br />Train, Raise Awareness<br />
    37. 37. 33<br />© Itecor all rights reserved <br />Build Organizational Support<br />all directions<br />at the same time<br />
    38. 38. 34<br />© Itecor all rights reserved <br />Teamwork<br />
    39. 39. 35<br />© Itecor all rights reserved <br />Align Incentives<br />
    40. 40. 36<br />© Itecor all rights reserved <br />Inspect, Adapt<br />
    41. 41. 37<br />© Itecor all rights reserved <br />And one more thing…<br />
    42. 42. That 10x hyper-productivity...<br />
    43. 43. it only comes <br />if serious <br />about removing real impediments<br />even some sacred cows<br />
    44. 44. COURAGE<br />
    45. 45. 41<br />© Itecor all rights reserved <br />Silvana Wasitova, PMP, CSM, CSP <br />Vevey, Switzerland<br /><br />+41 79 558 05 09<br />
    46. 46. References<br />42<br />© Itecor all rights reserved <br /> Scrum Rollout Results, 2007<br />Yahoo Scrum Rollout Results, 2008<br />BT Scrum Rollout Results, 2007<br />VersionOne Surveys<br />HCL EAI Scrum Rollout Results<br />Crossing the Chasm, Geoffrey Moore, 2002<br />“ADAPT” – Mike Cohn, <br />The Heart of Change: Real-Life Stories of How People Change Their Organizations (2002) and Leading Change (1996), John Kotter<br />Organizational Patterns in Agile Software Development, James Coplien & Neil Harrison<br />