10 Tips for Agile Adoption
6 likes1,809 views
The document provides 10 tips for making Agile adoption more successful. The tips are: 1) use a physical board, 2) collect and use statistics, 3) engage a coach or consultant, 4) prioritize action over talking, 5) the only way to know is to do it, 6) enthuse and pull people rather than push change, 7) be clear on the reasons for adopting Agile, 8) don't forget the technical aspects, 9) ensure a clear flow of requirements, and 10) consider structural changes like using vertical teams rather than projects. The document is authored by Allan Kelly from Software Strategy Ltd.
10 Tips for Agile Adoption
- 1. 10 Tips to make Agile Adoption more successful allan kelly Twitter: @allankellynet http://www.softwarestrategy.co.uk/allankelly
- 2. Allan Kelly Director, Software Strategy Ltd – Consulting & Training for Agile – Custom Software Development Author – Changing Software Development: Learning to be Agile (2008, Wiley) – Business Patterns for Software Developers (2012, Wiley - ISBN: 978-1119999249) 97 Things Every Programmer Should Know Henney, 2010 Context Encapsulation in Pattern Languages of Program Design Volume 5, 2006 (c) Allan Kelly http://www.softwarestrategy.co.uk 2
- 3. The amount of significant, often The Problem traumatic, change in organizations has grown tremendously over the past two • Change fails decades. – 70% change initiatives fail – (Commonly cited % but from where?) • Agile introduction fails Prof John P. Kotter, 1996 “Leading change” • Agile delivery fails – (We even have names for it) Scrummer Fall Has this changed?
- 4. 10 Tips for Agile Adoption ① Use a physical board ⑦ Clear on Why? ② Collect & Use Statistics ⑧ Don’t forget the ③ Engage Technical Coach/Consultant ⑨ Clear requirements flow ④ Action over talking ⑩ Structural change ⑤ Only way to know is to Do ⑥ Enthuse, Pull, don’t Push
- 5. Some advice… "I can't understand why people are frightened of new ideas. I'm frightened of the old ones." John Cage
- 6. #1 Use a Physical Board “I put the shotgun in an Adidas bag and padded it out with four pairs of tennis socks, not my style at all, but that was what I was aiming for: If they think you're crude, go technical; if they think you're technical, go crude. I'm a very technical boy. So I decided to get as crude as possible.” William Gibson, Johnny Mnemonic (in Burning Chrome, 1995)
- 8. Lightsabre Every team must design their own board
- 9. Use the board, Luke • Accelerates learning • Always visible – Shared view • Easy to change
- 10. #2 Collect & Use statistics Basic Product Burn-Down Chart 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 Iteration Work to do
- 11. Burn-Up, Burn-Down Burn-Up, Burn-Down 250 200 150 100 50 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Iteration Series5 (c) Software Strategy Ltd. 11
- 12. Burn-down with velocity Burn-Down with Velocity 250 40 35 200 30 25 150 20 100 15 10 50 5 0 0 1 2 3 4 5 6 7 8 9 10 11 12 Iteration Work to do Velocity (c) Software Strategy Ltd. 12
- 13. Layered burn-down 250 • By 200 release, milestone 150 , phase, etc. 100 • By epic or 50 collection of 0 stories 1 2 3 4 5 6 7 8 9 10 11 12 13
- 14. Simple Cumulative Flow Diagram 140 120 100 Points 80 60 40 20 0 0 1 2 3 4 5 6 7 8 9 10 11 12 13 Iteration Work to do Total done
- 15. Do you know? • Velocity: How fast are you going? • Backlog: – How much work do you currently know about? • How long does it take for work to clear board? – Rate of increase? (Scope Creep) • How many “bugs” do – Rate of decrease? (Scope you have? Retreat) • What else is useful for • Where you time is you to track? going?
- 16. Metrics warning! 1. Avoid hours: Human’s can’t estimate 2. “Points” break-down with experience & stress 3. Goodhart’s Law Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
- 17. #3 Engage a Coach/Consultant • You can do this yourself, but… – Increase risk – Adoption slower Warning: Consultant talking
- 18. Agile Coach • Notice • Feedback The art of Agile coaching is understanding the • Educate situation, the values underlying Agile • Facilitate software development, and how • Support the two can combine. Agile Coaching Davies & Sedley, 2009 (c) Software Strategy Ltd. 18
- 19. Agile Coach • Advisor – consultant? • Process expert • Someone with War Stories & Scars • Commonly – Occasional visitor who advises on Agile adoption, problems – Suggests, mentors, trains (c) Software Strategy Ltd. 19
- 20. 4D Coaching What is the company making? How is the company organized? Company: Strategy Advice for senior managers What processes are followed? Are you delivering? Product: Process Advice for teams What is the architecture? Is the code tested? Code: Technical Are you finding bugs? Advice for programmers Time…. Don’t expect everything at once Use different coaches in different dimensions
- 21. What's the best way Both ends at once to take a bridge? Brigadier General Gavin Major Julian Cook Quote: A Bridge Too Far • Cornelius Ryan (Book) Image: Nijmegen bridge from FaceMePLS, Creative Commons License on • Richard Attenborough (Film) Flickr
- 22. Our bridges have 3 ends! Technical Management Process & Products Tridge, Midland, Michigan - Image from © Gary Teall, Fenton Low Altitude FLAP @ http://www.panoramio.com/photo/15573763
- 23. Should we use #4 Action over talking Scrum or XP? • You could… – Ask lots of legitimate Should we be questions Agile or Lean? – Make lots of plans How do we get We need to plan the business to our adoption buy in? carefully Our Project Where is the Office won’t evidence it like it works?
- 24. #4 Action over talking Or • You could just start doing what you can and see what happens • Just Do It
- 25. #5 Only way To Know is To Do • Just do it! • Until you try doing Agile you can’t answer the questions • Agile is Empirical – Try it and see what happens • Agile is Learning – Learning -> Change -> Learning
- 26. #6 Enthuse, Pull, don’t Push • Agile is a change initiative • Why would agile be any different?
- 27. Don’t push change - Let them pull! • Lay out your stall • Support interest – And wait • Fan the flames
- 28. The Change from Above Myth • Might work for a dictator, but.. – Communication, Motivation, Ap plicability, Local differences, Self- Interest Push from top – (Dictators typically carry a big stick, IT Mangers don’t) (c) Allan Kelly - April 2006
- 29. Just Do It! ™ “Nobody gives Stop being led by your you power, leaders… You just take it” And start leading them Rossanne Barr quoted by Tom Peters in Re-Imagine!
- 30. #7 Be clear: Why? • What are you trying to achieve? • How do you know what tools to choose? • What are you trying to optimize? – Elapsed time: idea to product – Efficiency of delivery – Maximize revenue – Minimize costs – Speed to completing some “Backlog”
- 31. #8 Don’t forget TECHNICAL It’s the • Poor technology… code, stup – Lots of bugs – is the story done? id – Can you close a iteration? - can you deliver at the end of iteration? • Developers morale – “Technical debt… – Technical debt…. – Technical debt…”
- 32. The Technical side • Increase quality • Eliminate….
- 33. Invest in Technical Software Craftsmanship – Take quality seriously Images from WikiCommons under Creative Commons license Alegro - Charles01, Rolls Royce & VW - Thomas doerfer
- 34. TDD works! IBM Microsoft Microsoft Microsoft drivers Windows MSN Visual Studio Defect density W X Y Z (non-TDD) Defect density 61% of W 38% of X 24% of Y 9% of Z (with TDD) Increased time 15-20% 25-25% 15% 25-20% (with TDD) Nagappan, Maximilien, Bhat and Williams (Microsoft Research, IBM Research, North Carolina State University). Empirical Software Engineering journal 2008 http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf
- 35. Bugs • How much time do you spend finding bugs? • How many testers do you need? • How many bugs do you have logged? • How many bugs do you fix before shipping? • How much time do you spend in meetings discussing bugs? How would your life change if there were no bugs?
- 36. Without technical side… • Bugs overwhelm – Can’t deliver working software • Code becomes difficult to change – Velocity slows • So we test… – Test is slow & expensive • And we avoid change… – Avoiding change is avoiding Agile
- 37. Agile without quality? • How do you know you are done? • How do you time box? – How do you eliminate Test-Fix cycle? Agile without Quality is like Starbucks without Coffee Starbucks image © Louis Abate, Creative Commons License, c/o Flickr
- 38. #9 Clear Requirements Flow Every 2 weeks…. Development Team Working software • Keep arteries clear – keep feeding team – Keep work flowing – little and often
- 39. Please OK, here’s A story… help… we what you want to be do…. Agile! Umm… but I don’t think they really know what they are building Or why…. Gee… we took In fact, they don’t even have a the medicine business strategy Dev Team and things are that makes sense much better
- 40. Supply and Demand Quantity of Software / IT Demand also needs fixing (but fix it second) Supply (Development) Demand (Business Case/Requirem ents) 0 Price of Software / IT Initial focus on development improving supply
- 41. The Real Problem Demand is rampant Quantity of and inelastic Software / IT Mind the gap Supply (Development) 0 Price of Software / IT Supply is severely development constrained and inelastic
- 42. Worse? Demand - More Quantity of technology we Software / IT have, the more we want Mind the gap Supply constrained by Brooks Law 0 Price of Software / IT development
- 43. #10 Structural change • Process will take you so far… • Technical (alone) will buy you lots… • But…
- 44. Vertical teams • Staffed to delivery languages), Requirements, Manage business value ment, Testing, etc. etc. • Responsible for delivering business value • All skills needed Code (all • Keep together – Grow, shrink – Add new people, let folk leave
- 45. Forget projects • Form around Products • Project thinking is an obstacle • Good systems never die The initial difficulty with – They just evolve schedule measurement is a basic one: Identifying • Bad systems die the start point of any • “Done” given project! – Empty backlog is a sign of failure • Leave “Project” for accountants Capers Jones, 2008
- 46. ① Use a physical board ② Collect & Use Statistics ③ Engage Coach/Consultant ④ Action over talking ⑤ Only way to know is to Do ⑥ Enthuse, Pull, don’t Push ⑦ Clear on Why? ⑧ Don’t forget the Technical allan kelly ⑨ Clear requirements flow Software Strategy Ltd. ⑩ Structural change www.softwarestrategy.co.uk/ allankelly allan@allankelly.net Twitter: @allankellynet