Autopsy of a failed agile project or Death of a thousand cuts

by Evan Leybourn on      3 minutes read


It is commonly accepted that at least 60% of all ICT project fail by one or more criteria including; schedule, budget, maintenance & return on investment. While agile projects fare better, with a 40% failure rate, this still implies a large number of failed projects. This presentation will forensically examine a failed agile project with the goal of helping agile project managers avoid similar issues in future. Issues (and possible resolutions) that will be discussed include; customer engagement, staff skills & capacity, stable environments, low team morale, and scope creep. The specific attributes of failure I will be looking at are;

  • Lack of customer engagement: Without a fully engaged customer, with well-defined user stories, it is impossible to deliver to the customers needs.
  • Unfocused development: Developing a combination of customer driven and non-customer driven work in order to develop a stable framework causes significant delays in measuring business value.
  • Poor project scope at inception: Lack of clarity on the end goal (and which stories were most important) reduces developer productivity and can prioritise the wrong stories.
  • No defined success measures: Without a clearly defined success measures it is impossible to measure benefits realisation on project completion.
  • Understaffed: Reduced team size (or incorrect team structure) can cause significant delays in development, especially if this is in key roles.
  • Competing Priorities: For example, team members may only be able to realistically allocate 50% of their time due to BAU commitments. This can be hard to manage to the scrum master.
  • Underlying architecture design: If the underlying framework is poorly documented and underdeveloped, this can cause delays and issues early in the project.
  • Unstable development environments: There can be significant productivity loss if the development, test and UAT environments are not available on demand.
  • Poor quality (or inconsistent) test data: Poor test data can cause inaccurate tests results (both false positives and negatives) resulting in additional rework after a feature is released.
  • Low team morale: If team morale is not address (for example, due to lack of delivery and a low understanding of project value) team productivity is reduced and in turn can lead to even worse morale.
  • Insufficient allocated time for delivery: In a fixed time agile model, if initial estimation is inaccurate (or external pressure is applied to deliver early) project quality will be impacted.
  • Lack of business SME’s for rule definition: The customer needs to provide access to a subject matter expert to avoid unneccersary rework and project defects.
  • No Shared Components: A good environment should share already successful elements to other projects.
  • Lack of systems and infrastructure support was slow: This can cause significant project delays. For example, our DBA could only get (on average) 10 database queries per day tuned, which is unsustainable when you have 200+ queries.

So, how can you identify these issue early and mitigate them before they become serious? This presentation will propose several possible mitigations, methods for bring a project back from the brink of disaster, and finally exploring why some projects are not suitable for agile methods.

Slides

Autopsy of a failed agile project evan leybourn v2 from Evan Leybourn

URL

http://prezi.com/dsqtjvrgnjzr/autopsy-of-a-failed-agile-project/