Failing With Agile
- 1. Failing with Agile:A How-to GuideDon’t end up with an apple instead of an Apple®!Presented byBob HartmanPresident, Agile For All303-766-0917bob.hartman@agileforall.comwww.agileforall.comPresentation Copyright © 2008, Agile For All, LLC. All rights reserved.
- 2. Before We StartCell phones, pagers, PDA’s, etc. to silentIf you have a question, please ask it. Don’t wait! It is better to answer the question while we are still in the same area than to go back.We will take a break after about 90 minutesFailing with Agile2
- 4. Bob Hartman (Agile Bob)30+ years of software industry experienceCertified Scrum PractitionerBachelor and Masters degrees in Computer ScienceRoles included Tester, Developer, Dev Manager, QA Manager, Product Manager, Project Manager, VP…Started with agile in 1999bob.hartman@agileforall.com303-766-0917Failing with Agile4
- 5. Who are you?Please introduce yourself including:NameCompany and roleAgile experienceAboutMeFailing with Agile5
- 7. Software project success ratesSource: The Standish GroupSuccess increasing by 1.7% per year. Will not reach 50% until 2014!Failing with Agile7
- 8. Industry realitiesMost “successful” projects were deliberately over-estimated at the start (Standish – 2001)The average project exceeds its schedule by 63% (Standish – 2001)50% of project failures are due to missing or misunderstood requirements (Ravenflow – 2006)Executive support and customer involvement are the two biggest critical success factors in project success by far (many studies in the past 10 years)Failing with Agile8
- 9. More industry realities56% of defects are attributable to missing or misunderstood requirements82% of defect fixing time and dollars go to fixing requirements related defectsNIST has estimated that 0.6% of the GDP is lost due to software defectsNIST also estimates that 1/3 of that money could be saved by using a process allowing earlier detection and correction of defectsFailing with Agile9
- 10. Things I sometimes ponder…Why do we make all important decisions on projects when we have the least information?Why do managers always think things will take less time than everyone else? Why do we let them estimate at all?Why has the software industry never improved the ability to estimate accurately?If we know that an average of 30% of requirements will change during a project, why do we use a process that is intolerant to change?Why do companies say that quality is important while internally they give QA less time than originally allocated to do their job?Why do developers always do the easiest things first?If the customer is always right, why do we only ask them their opinion AFTER we have completed the entire project?Failing with Agile10
- 11. Doing the right thingbut doing it wrongBut this is supposed to work!!!
- 12. Getting things to “done” – sort of!Iteration 1 – coded and tested! Iteration 2 – coded and tested! Iteration 3 – coded and tested! Iteration 4 – coded and tested! Where’s the problem?No regression testing – “done” for an iteration means all previous testing passes as well! The above scenario leads to:Final validation testing – FAILS! Failing with Agile12
- 13. Identifying tasks – but not all of themFailing with Agile13
- 14. The daily stand-up of deathYesterday I did that, today I’ll do this, nothing blocking me. Next…Failing with Agile14
- 15. Inadvertent sabotageHurting by helping!
- 16. Working aheadI know we are only initeration 1, but I did story3 and knew that story 322depended on it, so I did thatone too! Cool huh!Failing with Agile16
- 17. The return of command and controlI thought agile was supposed to empower us?!?Failing with Agile17
- 18. Hmm, how should I do this?I don’t really know how to solve this, but that’s ok, I’ll just think like a customerGood developers will try to think like a customer – THEN they will make the wrong decision!Failing with Agile18
- 19. Invite complexityMr. Product Champion, which way should I go?It doesn’t affect the user, so pick either!Complex – Yeah!Failing with Agile19
- 20. Small Group ExerciseDescribe inadvertent sabotage you have experienced. What were the results and how it was first detected?Failing with Agile20
- 21. Failures caused by management
- 22. Lack of sufficient agile trainingDilbert knows agile! Or, maybe not Failing with Agile22
- 23. Asking “How are we doing?”Hey George, how are we doing?Apparently executives and managers have no eyes!Failing with Agile23
- 24. Early hiccup = total failureSee! Iteration 1 wasn’t perfect. I told you agile wouldn’t work!!!Failing with Agile24
- 25. Seeding doubtPsst. Be careful. I’m pretty sure this agile stuff will fail.Failing with Agile25
- 26. Always follow the chain of command!I don’t care if it worked. This is the org chart and you should have asked me (even if it would have taken 5 extra days).Let’s make some spaghetti to show this in action!Failing with Agile26
- 27. Small Group ExerciseList a few different forms of management failure you have experienced and what happened.Failing with Agile27
- 28. Failures caused by Waste
- 29. What is waste?Anything that does not add value!Meetings, research that is never utilized, unfinished code, untested code, undocumented/unusable features…What else?Failing with Agile29
- 30. Building what you don’t needQuestion: What percentage of software features are NEVER used?Failing with Agile30
- 31. Poor requirements gathering techniqueFailing with Agile31
- 32. Building infrastructure firstSlices = lesswork to doLayers = Allwork doneWhich is easier to change?Failing with Agile32
- 33. Being dogmatic about processAgile says we have to have daily stand-ups. It doesn’t matter that part of the team is in Sri Lank 12.5 time zones away!Failing with Agile33
- 34. Small Group ExerciseWhat are some types of waste in your organization that you can start to eliminate immediately?Failing with Agile34
- 36. Play the blame gameIt’s your fault!Failing with Agile36
- 37. It’s ok to move things to the next iterationThis didn’t finish, so move it from iteration 1 to iteration 2, no 3, I mean 4.Failing with Agile37
- 38. Teams that are too largeWill this stand-up ever end?Failing with Agile38
- 39. Make silos even deeperTesters vs. DevelopersIs anyone a team member any more???Failing with Agile39
- 40. Poor communicationFailing with Agile40
- 41. Not my jobSee, right there it says it isn’t my job to do that!It’s not my fault the team failed the iteration because I didn’t press “Run”Failing with Agile41
- 42. Small Group ExerciseEven successful teams are held back in many ways by the way they do things. What “failures” are your current teams dealing with today?Failing with Agile42
- 43. Product Champion based failures
- 44. Keep the plan in your head…Don’t ever tell anyone else what the plan is. That way they need to rely on you, right???Failing with Agile44
- 45. Be efficient – have more than one roleIt’s great being a team member, Scrum Master and Product Champion! All have to bow to me!!! Oh, and all my stuff gets done first – sweeeeeeet!Failing with Agile45
- 46. Testing failures
- 47. Confusing unit tests and acceptance testsAutomated(QA)Business FacingManual(Anyone)UsabilityTesting ExploratoryTestingAcceptance TestsBusiness Intent(Design of the Product)When possibleSupport ProgrammingCritique ProductDuring IterationPropertyTestingResponse, SecurityScaling,…Unit TestsDeveloper Intent (Design of the Code)Automated(Developer)Tool-Based(Expensive)Technology Facingfrom Brian MarickFailing with Agile47
- 48. Testing at the end of an iterationCode FreezeDay 10Day 1Day 2Day 3Day 4Day 5Day 6Day 7Day 8Day 9CodingTestingQ: What are developers doing during the testing period?Failing with Agile48
- 49. Coding in one iteration, testing in the nextEach tester40% of time writing tests for current iteration20% of time running tests for current iteration40% of time regression testingIteration 1 this tester has 40% slack timeIteration 2 this tester has 20% slack time40% writing new tests, 20% running new tests, 20% running tests from iteration 1Iteration 3 this tester has 0 slack time40% writing new tests, 20% running new tests, 20% running tests from iteration 1, 20% running tests from iteration 2Iteration 4 we can no longer complete all testing!This is most often caused by dependence on manual testingFailing with Agile49
- 50. Lack of automated testingFailing with Agile50Regression Deficit Disorder
- 51. Group discussionWhat testing challenges currently exist in your organization?Failing with Agile51
- 52. Failures due tolack of trust
- 53. Measure inappropriatelyYou will get what you measure!!!DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.Failing with Agile53
- 54. The “no power” Product ChampionI know you told the team to do that, but I’m your manager and I think it’s wrong, so change it!Failing with Agile54
- 55. Agile in name onlyHere is the scope and the date, now be agile and deliver it all on time!Failing with Agile55
- 56. MicromanagementThis project is important and as CTO, I want to make sure we’re measuring up every day!Failing with Agile56
- 57. Process failures
- 58. Changing process before it is understoodThis is a simple process, why do we need to meet each day to discuss things?Failing with Agile58
- 59. Lack of commitment to improvementWoohoo! A new record! That retrospective only took 2 minutes!!!Failing with Agile59
- 60. Watching metrics, not the peopleGreat job! Another successful iteration.Failing with Agile60
- 61. Fixing failure
- 62. Small Group ExerciseTalk about some fixed failures and how they were fixed. Talk about some failings that are not yet fixed and what might be done to fix them.Failing with Agile62
- 64. What others are seeingFailing with Agile64
- 65. VersionOne Survey Results (2008)Survey asked people: Please try to estimate SPECIFIC IMPROVEMENTS you have actually realized from implementing Agile practices.Source: VersionOne 2008 State of Agile Development SurveyNOTE: All 2008 data is within 2% of 2007 data implying these numbers are not one-time anomaliesBiggest causes of company-wide agile failure: Company philosophy or culture could not be overcome – 23% Lack of experience with agile – 21%Failing with Agile65
- 66. Agile is a Proven ApproachSome Agile Companies (there are MANY more)Failing with Agile66
- 67. Resources
- 68. Places to go for helpMy website! www.agileforall.comOrganizationsAgile Alliance (www.agilealliance.org)Agile Project Leadership Network (APLN – www.apln.org Yahoo GroupsPMI Agile (pmiagile) – giving direction to people that will be responsible for the Agile PMI Virtual Community to be formed in 2009Agile Denver (agiledenver)APLN Denver (apln-denver)Failing with Agile68
- 69. Retrospective
- 70. Help me out!I’m doing this again at the PMI Mile Hi Symposium in March 2009 and I want to make sure it is as good as possible!What went well?What went less well?How can I improve things next time?Failing with Agile70
- 71. Final questions?
- 72. Thank you!Please fill out evaluation formsGet on my mailing list if you want to receivea PDF of this presentation via email
Editor's Notes
- #8: Is 50% even any good? Don’t we want to be a lot better than that?
- #30: What are some examples
- #37: The process allowed it – rules of engagement
- #39: Communication overhead is ridiculous
- #45: Knowledge is power – command and control’ish
- #51: You will fall further and further behind – remember doing the right thing wrong