Your SlideShare is downloading. ×

Failing With Agile

4,637

Published on

Presentation for Mile High PMI Workshop on November 15, 2008 …

Presentation for Mile High PMI Workshop on November 15, 2008

Abstract:

There are always people who want agile projects to fail. This will probably be the case until agile is the preferred process methodology used for projects. Are you one of them? In this workshop Bob Hartman will give participants a how-to guide for causing agile process failure. Attendees will learn various failure modes and how to cause them. There will be group discussions and exercises exploring how the failure modes can manifest themselves in real projects. At the end of this workshop each attendee should have the ability to cause agile project failure in a variety of ways and under a variety of conditions.

Obviously the first paragraph is a bit tongue-in-cheek. Hopefully project managers do not want agile projects to fail, but they need to know how they could fail. This knowledge will translate into an ability to recognize the failure modes and take corrective action. Interestingly, many of the agile project failure modes are also failure modes in other project process methodologies. All project managers on agile projects or in organizations that are considering using an agile process should attend this workshop. Project managers in organizations which typically struggle with projects may also gain insight into their project failure modes.

Published in: Technology, Business
1 Comment
4 Likes
Statistics
Notes
  • <br /><iframe width="350" height="288" src="http://www.youtube.com/embed/nvks70PD0Rs" frameborder="0" allowfullscreen></iframe>
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
4,637
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
235
Comments
1
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Is 50% even any good? Don’t we want to be a lot better than that?
  • What are some examples
  • The process allowed it – rules of engagement
  • Communication overhead is ridiculous
  • Knowledge is power – command and control’ish
  • You will fall further and further behind – remember doing the right thing wrong
  • Transcript

    • 1. Failing with Agile:A How-to Guide
      Don’t end up with an apple instead of an Apple®!
      Presented byBob HartmanPresident, Agile For All303-766-0917bob.hartman@agileforall.com
      www.agileforall.com
      Presentation Copyright © 2008, Agile For All, LLC. All rights reserved.
    • 2. Before We Start
      Cell phones, pagers, PDA’s, etc. to silent
      If 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 minutes
      Failing with Agile
      2
    • 3. Introductions
    • 4. Bob Hartman (Agile Bob)
      30+ years of software industry experience
      Certified Scrum Practitioner
      Bachelor and Masters degrees in Computer Science
      Roles included Tester, Developer, Dev Manager, QA Manager, Product Manager, Project Manager, VP…
      Started with agile in 1999
      bob.hartman@agileforall.com
      303-766-0917
      Failing with Agile
      4
    • 5. Who are you?
      Please introduce yourself including:
      Name
      Company and role
      Agile experience
      AboutMe
      Failing with Agile
      5
    • 6. Framing the problem
    • 7. Software project success rates
      Source: The Standish Group
      Success increasing by 1.7% per year. Will not reach 50% until 2014!
      Failing with Agile
      7
    • 8. Industry realities
      Most “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 Agile
      8
    • 9. More industry realities
      56% of defects are attributable to missing or misunderstood requirements
      82% of defect fixing time and dollars go to fixing requirements related defects
      NIST has estimated that 0.6% of the GDP is lost due to software defects
      NIST also estimates that 1/3 of that money could be saved by using a process allowing earlier detection and correction of defects
      Failing with Agile
      9
    • 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 Agile
      10
    • 11. Doing the right thingbut doing it wrong
      But 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 Agile
      12
    • 13. Identifying tasks – but not all of them
      Failing with Agile
      13
    • 14. The daily stand-up of death
      Yesterday I did that, today I’ll do this, nothing blocking me. Next…
      Failing with Agile
      14
    • 15. Inadvertent sabotage
      Hurting by helping!
    • 16. Working ahead
      I 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 Agile
      16
    • 17. The return of command and control
      I thought agile was supposed to empower us?!?
      Failing with Agile
      17
    • 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 customer
      Good developers will try to think like a customer – THEN they will make the wrong decision!
      Failing with Agile
      18
    • 19. Invite complexity
      Mr. Product Champion, which way should I go?
      It doesn’t affect the user, so pick either!
      Complex – Yeah!
      Failing with Agile
      19
    • 20. Small Group Exercise
      Describe inadvertent sabotage you have experienced. What were the results and how it was first detected?
      Failing with Agile
      20
    • 21. Failures caused by management
    • 22. Lack of sufficient agile training
      Dilbert knows agile! 
      Or, maybe not 
      Failing with Agile
      22
    • 23. Asking “How are we doing?”
      Hey George, how are we doing?
      Apparently executives and managers have no eyes!
      Failing with Agile
      23
    • 24. Early hiccup = total failure
      See! Iteration 1 wasn’t perfect. I told you agile wouldn’t work!!!
      Failing with Agile
      24
    • 25. Seeding doubt
      Psst. Be careful. I’m pretty sure this agile stuff will fail.
      Failing with Agile
      25
    • 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 Agile
      26
    • 27. Small Group Exercise
      List a few different forms of management failure you have experienced and what happened.
      Failing with Agile
      27
    • 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 Agile
      29
    • 30. Building what you don’t need
      Question: What percentage of software features are NEVER used?
      Failing with Agile
      30
    • 31. Poor requirements gathering technique
      Failing with Agile
      31
    • 32. Building infrastructure first
      Slices = less
      work to do
      Layers = All
      work done
      Which is easier to change?
      Failing with Agile
      32
    • 33. Being dogmatic about process
      Agile 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 Agile
      33
    • 34. Small Group Exercise
      What are some types of waste in your organization that you can start to eliminate immediately?
      Failing with Agile
      34
    • 35. Team failure modes
    • 36. Play the blame game
      It’s your fault!
      Failing with Agile
      36
    • 37. It’s ok to move things to the next iteration
      This didn’t finish, so move it from iteration 1 to iteration 2, no 3, I mean 4.
      Failing with Agile
      37
    • 38. Teams that are too large
      Will this stand-up ever end?
      Failing with Agile
      38
    • 39. Make silos even deeper
      Testers vs. DevelopersIs anyone a team member any more???
      Failing with Agile
      39
    • 40. Poor communication
      Failing with Agile
      40
    • 41. Not my job
      See, 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 Agile
      41
    • 42. Small Group Exercise
      Even 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 Agile
      42
    • 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 Agile
      44
    • 45. Be efficient – have more than one role
      It’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 Agile
      45
    • 46. Testing failures
    • 47. Confusing unit tests and acceptance tests
      Automated(QA)
      Business Facing
      Manual(Anyone)
      UsabilityTesting
      ExploratoryTesting
      Acceptance Tests
      Business Intent(Design of the Product)
      When possible
      Support Programming
      Critique Product
      During Iteration
      PropertyTesting
      Response, SecurityScaling,…
      Unit Tests
      Developer Intent (Design of the Code)
      Automated(Developer)
      Tool-Based(Expensive)
      Technology Facing
      from Brian Marick
      Failing with Agile
      47
    • 48. Testing at the end of an iteration
      Code Freeze
      Day 10
      Day 1
      Day 2
      Day 3
      Day 4
      Day 5
      Day 6
      Day 7
      Day 8
      Day 9
      Coding
      Testing
      Q: What are developers doing during the testing period?
      Failing with Agile
      48
    • 49. Coding in one iteration, testing in the next
      Each tester
      40% of time writing tests for current iteration
      20% of time running tests for current iteration
      40% of time regression testing
      Iteration 1 this tester has 40% slack time
      Iteration 2 this tester has 20% slack time
      40% writing new tests, 20% running new tests, 20% running tests from iteration 1
      Iteration 3 this tester has 0 slack time
      40% writing new tests, 20% running new tests, 20% running tests from iteration 1, 20% running tests from iteration 2
      Iteration 4 we can no longer complete all testing!
      This is most often caused by dependence on manual testing
      Failing with Agile
      49
    • 50. Lack of automated testing
      Failing with Agile
      50
      Regression Deficit Disorder
    • 51. Group discussion
      What testing challenges currently exist in your organization?
      Failing with Agile
      51
    • 52. Failures due tolack of trust
    • 53. Measure inappropriately
      You will get what you measure!!!
      DILBERT: © Scott Adams/Dist. by United Feature Syndicate, Inc.
      Failing with Agile
      53
    • 54. The “no power” Product Champion
      I know you told the team to do that, but I’m your manager and I think it’s wrong, so change it!
      Failing with Agile
      54
    • 55. Agile in name only
      Here is the scope and the date, now be agile and deliver it all on time!
      Failing with Agile
      55
    • 56. Micromanagement
      This project is important and as CTO, I want to make sure we’re measuring up every day!
      Failing with Agile
      56
    • 57. Process failures
    • 58. Changing process before it is understood
      This is a simple process, why do we need to meet each day to discuss things?
      Failing with Agile
      58
    • 59. Lack of commitment to improvement
      Woohoo! A new record! That retrospective only took 2 minutes!!!
      Failing with Agile
      59
    • 60. Watching metrics, not the people
      Great job! Another successful iteration.
      Failing with Agile
      60
    • 61. Fixing failure
    • 62. Small Group Exercise
      Talk 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 Agile
      62
    • 63. Agile Expectations
    • 64. What others are seeing
      Failing with Agile
      64
    • 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 Survey
      NOTE: All 2008 data is within 2% of 2007 data implying these numbers are not one-time anomalies
      Biggest causes of company-wide agile failure:
      Company philosophy or culture could not be overcome – 23%
      Lack of experience with agile – 21%
      Failing with Agile
      65
    • 66. Agile is a Proven ApproachSome Agile Companies (there are MANY more)
      Failing with Agile
      66
    • 67. Resources
    • 68. Places to go for help
      My website! www.agileforall.com
      Organizations
      Agile Alliance (www.agilealliance.org)
      Agile Project Leadership Network (APLN – www.apln.org
      Yahoo Groups
      PMI Agile (pmiagile) – giving direction to people that will be responsible for the Agile PMI Virtual Community to be formed in 2009
      Agile Denver (agiledenver)
      APLN Denver (apln-denver)
      Failing with Agile
      68
    • 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 Agile
      70
    • 71. Final questions?
    • 72. Thank you!
      Please fill out evaluation forms
      Get on my mailing list if you want to receivea PDF of this presentation via email

    ×