10 Tips to make Agile Adoptionmore successful allan kelly Twitter: @allankellynethttp://www.softwarestrategy.co.uk/allankelly
Allan Kelly Director, Software Strategy Ltd – Consulting & Training for Agile – Custom Software DevelopmentAuthor – 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
The amount of significant, oftenThe 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?
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
Some advice… "I cant understand why people are frightened of new ideas. Im frightened of the old ones."John Cage
#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 youre crude, go technical; if they think youre technical, go crude. Im a very technical boy. So I decided to get as crude as possible.” William Gibson, Johnny Mnemonic (in Burning Chrome, 1995)
LightsabreEvery team must design their own board
Use the board, Luke• Accelerates learning• Always visible – Shared view• Easy to change
#2 Collect & Use statistics Basic Product Burn-Down Chart25020015010050 0 1 2 3 4 5 6 7 8 9 10 11 12 Iteration Work to do
Simple Cumulative Flow Diagram 140 120 100Points 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
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?
Metrics warning!1. Avoid hours: Human’s can’t estimate2. “Points” break-down with experience & stress3. Goodhart’s Law Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
#3 Engage a Coach/Consultant• You can do this yourself, but… – Increase risk – Adoption slower Warning: Consultant talking
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
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
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
Whats 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
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?
#4 Action over talkingOr• You could just start doing what you can and see what happens• Just Do It
#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
#6 Enthuse, Pull, don’t Push• Agile is a change initiative• Why would agile be any different?
Don’t push change - Let them pull!• Lay out your stall • Support interest – And wait • Fan the flames
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
Just Do It! ™ “Nobody givesStop being led by your you power,leaders… You just take it” And start leading them Rossanne Barr quoted by Tom Peters in Re-Imagine!
#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”
#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…”
The Technical side• Increase quality• Eliminate….
Invest in Technical Software Craftsmanship – Take quality seriously Images from WikiCommons under Creative Commons license Alegro - Charles01, Rolls Royce & VW - Thomas doerfer
TDD works! IBM Microsoft Microsoft Microsoft drivers Windows MSN Visual StudioDefect 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 CarolinaState University). Empirical Software Engineering journal 2008 http://research.microsoft.com/en-us/projects/esm/nagappan_tdd.pdf
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?
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
#9 Clear Requirements Flow Every 2 weeks…. Development Team Working software• Keep arteries clear – keep feeding team – Keep work flowing – little and often
Please OK, here’sA 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 strategyDev Team and things are that makes sense much better
Supply and DemandQuantity ofSoftware / 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
The Real Problem Demand is rampantQuantity of and inelasticSoftware / IT Mind the gap Supply (Development) 0 Price of Software / IT Supply is severely development constrained and inelastic
Worse? Demand - MoreQuantity of technology weSoftware / IT have, the more we want Mind the gap Supply constrained by Brooks Law 0 Price of Software / IT development
#10 Structural change• Process will take you so far…• Technical (alone) will buy you lots…• But…
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
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
① 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 firstname.lastname@example.org Twitter: @allankellynet