Agile Project Failures: Root Causes and Corrective Actions

2,669 views

Published on

Agile initiatives always begin with the best of intentions—accelerate delivery, better meet customer needs, or improve software quality. Unfortunately, some agile projects do not deliver on these expectations. If you want help to ensure the success of your agile project or get an agile project back on track, this session is for you. Jeff Payne discusses the most common causes of agile project failure and how you can avoid these issues—or mitigate their damaging effects. Poor project management, ineffective requirements development, failed communications, software development problems, and (non)agile testing can all contribute to project failure. Learn practical tips and techniques for identifying early warning signs that your agile project might be in trouble and how you can best get your project back on track. Gain the knowledge you need to guide your organization toward agile project implementations that serve the business and the stakeholders.

Published in: Technology, Business

Agile Project Failures: Root Causes and Corrective Actions

  1. 1. Agile Project Failure: Root Causes and Corrective Actions Jeffery Payne Chief Executive Officer Coveros, Inc. jeff.payne@coveros.com www.coveros.com © Copyright 2012 Coveros, Inc.. All rights reserved. 1
  2. 2. Trainer Jeffery Payne Jeffery Payne is CEO and founder of Coveros, Inc., a software company that helps organizations accelerate the delivery of secure, reliable software. Coveros uses agile development methods and a proven software assurance framework to build security and quality into software from the ground up. Prior to founding Coveros, Jeffery was Chairman of the Board, CEO, and co-founder of Cigital, Inc. Under his direction, Cigital became a leader in software security and software quality solutions, helping clients mitigate the risk of software failure. Jeffery is a recognized software expert and popular speaker at both business and technology conferences on a variety of software quality, security, and agile development topics. He has also testified before Congress on issues of national importance, including intellectual property rights, cyber-terrorism, Software research funding, and software quality. © Copyright 2012 Coveros, Inc.. All rights reserved. 2
  3. 3. About Coveros  Coveros helps organizations accelerate the delivery of secure, reliable software  Our consulting services: – Agile software development – Application security – Software quality assurance  Agile services – – – – – – Agility assessments Process improvement Hands-on agile software development Agile project management Agile testing and automation Agile training by role © Copyright 2012 Coveros, Inc.. All rights reserved. 3
  4. 4. Pop  Quiz:  Agile  Development  Means  …  No  documentation.    We  don’t  need  to  write  anything  down!  No process. We can do it any way we want!  No overtime. We can go home at 5!  No management. We decide when to deliver!  No testers. Who needs them anyway! © Copyright 2012 Coveros, Inc.. All rights reserved. 4
  5. 5. What Agile Actually Is  An approach to software development that recognizes that building software is much more of a design process than a construction process – Adaptive over Predictive – People over Process – Visibility into the Process  Agile Methodologies – – – – – Extreme Programming SCRUM Lean Development Crystal Agile RUP © Copyright 2012 Coveros, Inc.. All rights reserved. 5
  6. 6. Agile Development Process  Just in time requirements definition  Integrated design, development, test  Automated build, test, deployment process  Disciplined iteration scope control  Intimate customer involvement throughout entire process  Continuous improvement © Copyright 2012 Coveros, Inc.. All rights reserved. 6
  7. 7. How often do project succeed anyway? © Copyright 2012 Coveros, Inc.. All rights reserved. 7
  8. 8. Root Causes of Agile Project Failure © Copyright 2012 Coveros, Inc.. All rights reserved. 8
  9. 9. Root Causes of Failure can be at Many Levels Organizational Level - Senior management - Organizational - Cultural Product/ Project Management Level - Traditional project management and PMOs - Product management function - Sales and customer support Agile Team Level - Development process - Team members / roles © Copyright 2012 Coveros, Inc.. All rights reserved. 9
  10. 10. Root Cause #1 – Who moved my cheese?  Resistance to change kills a lot of agile initiatives.  Most  people  don’t  like  change  …  particularly  those  who   didn’t  think  of  it    Challenges – – – – Politics – Agile changes corporate dynamics Turf – Agile  changes  the  definition  of  “success” Apathy – Many  people  don’t  want  to  learn  on  the  job Subversion – Some will actively work to sabotage Agile © Copyright 2012 Coveros, Inc.. All rights reserved. 10
  11. 11. Who moved my cheese? – early warning signs  “Agile  doesn’t  work  for  X”  “Agile  shouldn’t  impact  my  group”  “Agile  is  a  fad”  Line managers who insist on being part of projects  Managers who will not use the dashboards and measurements the team is using © Copyright 2012 Coveros, Inc.. All rights reserved. 11
  12. 12. Who moved my cheese? – what you should do  Educate – knowledge allays fears  Show success on something small  Include,  don’t  exclude  naysayers © Copyright 2012 Coveros, Inc.. All rights reserved. 12
  13. 13. Root Cause #2 – Culture of distrust  Agile depends upon trust between the business and IT.  Many organizations have a culture of distrust built up from many, many years of failed initiatives and broken promises  Challenges – Makes planning difficult to accomplish in an Agile manner – Makes completing of tasks in Sprints difficult – Undercuts accountability © Copyright 2012 Coveros, Inc.. All rights reserved. 13
  14. 14. Culture of distrust – early warning signs  Management will not agree that changes can be made to a release plan  Management  will  disagree  with  estimates  and  want  “more   done  with  less”  Management will nitpick individual story estimates  Management admits that they push for unrealistic deadlines on purpose © Copyright 2012 Coveros, Inc.. All rights reserved. 14
  15. 15. Culture of distrust – what you should do  Hold firm on first Sprint estimate AND THEN DELIVER  Hold firm on not modifying requirements mid Sprint  Trust is rebuilt over time, not in a day or because Agile is now involved © Copyright 2012 Coveros, Inc.. All rights reserved. 15
  16. 16. Root Cause #3 – Requirements churn  Just because Agile encourages change does not mean it can work in the face of constant change  If requirements are never finalized (iteratively), nothing of value will be built for the customer  Challenges with requirements churn – Estimates are not accurate due to vague requirements – Significant amounts of rework are done © Copyright 2012 Coveros, Inc.. All rights reserved. 16
  17. 17. Requirements churn – early warning signs  Product management wants to swap out Stories in the middle of a Sprint  You learn during the first Sprint that the Stories are not valid / accurate or too vague to estimate  Priorities swing wildly from Sprint to Sprint © Copyright 2012 Coveros, Inc.. All rights reserved. 17
  18. 18. Requirements churn – what you should do  Incorporate more customers into more UATs  Hold the line of swapping Stories out during Sprints  Increase estimates for Stories you believe are too vague as they will likely take more time to finalize and implement  Foreshadow the outcome with your customer © Copyright 2012 Coveros, Inc.. All rights reserved. 18
  19. 19. Root Cause #4 – Doing Agile vs. Being Agile  Agile is not a methodology but a set of principles  It is not the kind of process that you manage with a clipboard.    Or  with  “Nike  Management”  …  Just  Do  It!  Challenges – Following the process becomes the goal instead of building great software that satisfies customer needs – The  process  is  never  improved  because  it  is  being  “followed”   successfully © Copyright 2012 Coveros, Inc.. All rights reserved. 19
  20. 20. Doing Agile vs. Being Agile – early warning signs  ScrumMaster or associated project management is more concerned about following the process than the content discussions – During daily huddles – During kickoff meetings – During retrospectives  Management asks if there is a CMM for Agile   The right things to do are often overruled as  being  “outside   the  process” © Copyright 2012 Coveros, Inc.. All rights reserved. 20
  21. 21. Doing Agile vs. Being Agile – what you should do  Designate a key technical member of the team to act as the “internal  ScrumMaster”  and  begin  Being  Agile  Focus on customer feedback as it’s  the trump card over the process  Use your retrospectives to push adoption of additional Agile principles and measure the results © Copyright 2012 Coveros, Inc.. All rights reserved. 21
  22. 22. Root Cause #5 – Sporadic software builds  Continuous builds are a keystone of any Agile process  Because Agile is so iterative, on-going and constant feedback on quality is necessary to complete Sprints on time  Challenges with sporadic builds – Significant increases in debugging time/costs as the time between a defect and its discovery increase – Implementation of features / functionality on top of a broken system significantly increases integration time later – No ability to incorporate regression tests into frequent feedback loop if  continuous  build  isn’t  maintained © Copyright 2012 Coveros, Inc.. All rights reserved. 22
  23. 23. Sporadic software builds – early warning signs  Evidence of successful builds on at least a daily basis does not exist  No urgency around fixing a build when it breaks (i.e. teams are not forced to fix the build before the end of the day)  No continuous integration software has been setup for use by the team © Copyright 2012 Coveros, Inc.. All rights reserved. 23
  24. 24. Sporadic software builds – what you should do  Enforce a build policy that does not allow the team to finish their work for the day before a successful build is done.  Setup an open source continuous integration server if you have no budget for anything else – Hudson, Jenkins, CruiseControl  Step  toward  a  more  rigorous  definition  of  “build  complete”   that includes successful testing over time © Copyright 2012 Coveros, Inc.. All rights reserved. 24
  25. 25. Root Cause #6 – Lack of test automation  Most if not all testing that is performed during Sprints is done manually by developers and/or testers.  Often occurs when development is not fully vested in performing adequate unit testing and/or test team does not have the skills necessary to automate story, integration, and system level tests  Challenges – Iterative development of features will increase the amount of testing needed Sprint of Sprint – Implementation defects will be identified too late in the process © Copyright 2012 Coveros, Inc.. All rights reserved. 25
  26. 26. Lack of test automation – early warning signs  No interest / evidence of test driven development  Manual testers are identifying implementation level defects while performing integration / system testing  Test team is not completing their test cycles within Sprints and suggest that testing be carried over into the next Sprint (parallel programming / testing Sprints) © Copyright 2012 Coveros, Inc.. All rights reserved. 26
  27. 27. Lack of test automation – what you should do  Pair developers and testers to help developers learn how to write good unit tests for their code  Reassign  a  developer  to  be  an  “engineer  in  test”  and   automate Story level tests on at least a part time basis  Integrate these tests into continuous build process so all code is regression tested frequently © Copyright 2012 Coveros, Inc.. All rights reserved. 27
  28. 28. Root Cause Exercise #1  Identify some other symptoms of the first six Agile Root Causes  Determine some other ways you can help solve these problems  Present findings to class © Copyright 2012 Coveros, Inc.. All rights reserved. 28
  29. 29. Root Cause #7 – Inadequate Retrospectives  Effective retrospectives at the end of each Sprint are the key to iteratively moving toward an Agile approach that works best for you.  Kent  Beck’s  “Agile  Maturity  Model” – All – Some – None  Challenges with Inadequate Retrospectives – Cookie cutter approach for Agile will often not work – Sometimes throws the baby out with the bath water © Copyright 2012 Coveros, Inc.. All rights reserved. 29
  30. 30. Inadequate retrospectives – early warning signs  Recommended process changes appear in the notes taken at multiple retrospectives in a row  All suggested modifications appear to be gravitating the process back to a legacy process that did not work before  No one leads the retrospective and makes sure that recommendations are implemented © Copyright 2012 Coveros, Inc.. All rights reserved. 30
  31. 31. Inadequate retrospectives – what you should do  ScrumMaster is  responsible  as  the  “servant  leader”  to  make   sure  the  agreed  upon  Agile  process  is  followed  …  this  is   true of all modifications to the process as well  Explicitly assign someone to implement each process change and add it to the backlog if greater than a few hours of work  For each changed that is proposed, determine Agile principles that are impacted and make sure new process still adheres to these principles © Copyright 2012 Coveros, Inc.. All rights reserved. 31
  32. 32. Root Cause #8 – Scrummerfall  Scrummerfall: Waterfall development inside Scrum Sprint #1 Design Code Sprint #2 Test Design Code Test  Challenges with Scrummerfall – Increases need for unnecessary coordination and documentation – Decreases team velocity – Difficult to fit into short sprints © Copyright 2012 Coveros, Inc.. All rights reserved. 32
  33. 33. Scrummerfall – early warning signs  Entire development team is not working together day-to-day on the same Stories  Testing is often not completed by the end of a Sprint  Testing of previous Sprint Stories is done in parallel with design / development of new Sprint Stories  Moving toward one 9-12  month  “Sprint” © Copyright 2012 Coveros, Inc.. All rights reserved. 33
  34. 34. Scrummerfall – What you should do  Pair a developer and a tester to work together on specific Stories – Tester helps developer think through unit and integration tests for Story – Developer builds functionality and automates unit and integration tests – Tester reviews / validates unit and integration tests – Tester adds to system level test plan and creates additional tests – Developer reviews additions to test plan  Stories are not marked as complete until all testing has been performed and defects are fixed © Copyright 2012 Coveros, Inc.. All rights reserved. 34
  35. 35. Root Cause #9 – Waterscrum done wrong  Co-dependent Waterfall and Scrum projects Governance or non-agile project deliverables Sprint #1 Sprint #2 Sprint #3 Sprint #4  Challenges with Waterscrum – Temptation is to lapse into a Waterfall process to align with the rest of the organization – Team  shirks  it’s  responsibility  to  the  rest  of  the  organization  and   agile is disbanded – Waterfall schedule slips and agile team does not adjust © Copyright 2012 Coveros, Inc.. All rights reserved. 35
  36. 36. Waterscrum – early warning signs  Development team pushes back on providing necessary documentation  Agile team misses deliverable date(s) associated with Waterfall schedule  No visibility into progress on Waterfall process  Team does not factor external delivery dates into Story priorities and schedule © Copyright 2012 Coveros, Inc.. All rights reserved. 36
  37. 37. Waterscrum – What you should do  Designate a team representative to communicate / coordinate with the rest of the organization on at least a weekly basis – Should be the responsibility of the project manager or product manager  Assign  a  “customer”  to  the  project  from  the  Waterfall   initiative to assure agile deliverables meet organizational needs  Define documentation or functionality constrained by Waterfall process in terms of Stories and place them in the appropriate Sprints to meet Waterfall schedule © Copyright 2012 Coveros, Inc.. All rights reserved. 37
  38. 38. Root Cause #10 – Ad-hoc development  Team characterizes its development process as Agile to justify poor programming practices  Poor development practices – – – – Little or no structured unit testing Little or no test automation or continuous integration Little or no necessary product documentation Handoffs between development and testing  Challenges with Ad-hoc development – Ad-hoc development has never worked within any software development process except perhaps when prototyping something – Significant quality and maintainability issues will exist © Copyright 2012 Coveros, Inc.. All rights reserved. – Not a rigorous process 38
  39. 39. Ad-hoc development troubles – early warning signs  Lack of evidence that adequate unit testing has been done – No automation infrastructure to support unit testing – Limited code coverage  Lack of evidence that architecture / design has been thought through at a high level  Individual developers working on multiple Stories at the same time  Lack of testers on the team  Builds break and are not fixed within a day © Copyright 2012 Coveros, Inc.. All rights reserved. 39
  40. 40. Ad-hoc development – What you should do  Incorporate unit testing infrastructure (ex. jUnit, nUnit) and code coverage (ex. Cobertura, Quilt) into continuous integration  Incorporate design activity into Sprint kickoff meeting  Incorporate test planning activity into Sprint planning and Sprint kickoff meeting  Pair developers and testers during Sprints © Copyright 2012 Coveros, Inc.. All rights reserved. 40
  41. 41. Root Cause #11 – Non-existent customers  Customer’s  are  not  involved  throughout  entire  development   process – Requirement definition / priority – Functional clarifications – User acceptance testing  Challenges with Non-existent customers – Significantly reduces the business value of Agile as requirements are not validated – Increases in rework due to changing requirements – Reductions in Sprint velocity and productivity © Copyright 2012 Coveros, Inc.. All rights reserved. 41
  42. 42. Non-existent customers – early warning signs  Customer is not intimately involved in initial planning phase before Sprints  Customer is not available to answer questions regarding Stories / requirements during Sprints  Customer is not part of User Acceptance Testing or UAT is pre-scripted by development team © Copyright 2012 Coveros, Inc.. All rights reserved. 42
  43. 43. Non-existent customers – What you should do  Proactively seek out at least one customer to be involved in project – Talk  to  customer  support  to  identify  the  most  “vocal”  client  you  have – Don’t  assume  you  already  know  what  customers  want  If customer simply cannot be involved day-to-day or even week-to-week, work with customer to identify appropriate “proxy”  to  act  on  their  behalf  Do  initial  User  Acceptance  Testing  at  the  client’s  site  to   ease them into the process © Copyright 2012 Coveros, Inc.. All rights reserved. 43
  44. 44. Root Cause #12 – Frozen requirements  Complete requirements list created up front that feeds into Agile Sprints  Often occurs when development group has moved toward Agile but business side has not  Challenges with Frozen requirements: – 80% of requirements will typically not be useful to customers when implemented – Does not allow Agile team to adapt to changes in business circumstances – Prioritization of requirements across Sprints will not be accurate © Copyright 2012 Coveros, Inc.. All rights reserved. 44
  45. 45. Frozen requirements – early warning signs  SRS requirements document has been produced for the project  Contract exists that specifies fixed requirements to be delivered within a particular timeframe  Customer is not available / willing to discuss Story priorities during iterative planning process  Business resists changes to upcoming Sprints based upon customer feedback © Copyright 2012 Coveros, Inc.. All rights reserved. 45
  46. 46. Frozen requirements – What you should do  Prioritize existing requirements so highest priority requirements are satisfied first  Discuss priorities with customer during UAT and highlight differences between upfront plan and their needs – May result in modifications to priorities that can help drive a more effective process – May result in agreement to change requirements once they better understand the impact  If business resists requirements change, pull customer into discussion with business and get agreement © Copyright 2012 Coveros, Inc.. All rights reserved. 46
  47. 47. Root Cause Exercise #2  Identify some other symptoms of the last six Agile Root Causes  Determine some other ways you can help solve these problems  Present findings to class © Copyright 2012 Coveros, Inc.. All rights reserved. 47
  48. 48. Questions? Thank You © Copyright 2012 Coveros, Inc.. All rights reserved. 48

×