Our Blog

Agile - Why Fail Fast?

Posted by David Pledger

Tags: Agile, Scrum, Lean

The Hertz Corporation recently filed a lawsuit[1] in US District Court, Southern District of New York against Accenture.  Accenture was engaged “to redefine the customer experience on Hertz’s digital platforms, by developing a market-leading website at Hertz.com and a complementary suite of mobile applications, all based on a platform that Hertz could readily extend to its other rental brands, including Dollar and Thrifty.” 

Accenture failed to deliver a working product and missed multiple deadlines according to the lawsuit.  Hertz ultimately paid Accenture in excess of $32 million and now Hertz wants their money back, plus damages, and attorney fees.

Screen Shot 2019-08-19 at 3.52.17 PM


Search the internet for “Why Software Projects Fail” and you will discover many opinions, but most include the following themes:

  • Too many / too few / inexperienced developers to get the job done.
  • Not enough time resulting in cost overruns.
  • Poor planning.
  • Unclear requirements and/or communication.
  • Insufficient testing.
  • Bad management.

The Hertz versus Accenture lawsuit is a grand example of what happens when everything goes wrong.  This white paper highlights the difference in failure modes between software developed using a traditional Waterfall method and software developed using an Agile methodology using the Hertz v. Accenture lawsuit as an example.

Software Development Methodologies

There are two primary philosophies in use when developing software:

  1. The Waterfall Model is a traditional sequential method for developing software where one phase is completed before the next phase begins.
  2. An Agile framework is designed to be an iterative model in which requirements evolve through a collaborative effort and result in an iterative delivery approach to software.

Both methods are described below.  Accenture’s delivery model is based on a Waterfall approach.

The Waterfall Model[2]

This section is an excerpt from the Wiki page on the Waterfall Model.

“Waterfall Model

In Royce's original Waterfall model, the following phases are performed in order:

  • System and software requirements: captured in a product requirements document
  • Analysis: resulting in models, schema, and business rules
  • Design: resulting in the software architecture
  • Coding: the development, proving, and integration of software
  • Testing: the systematic discovery and debugging of defects
  • Operations: the installation, migration, support, and maintenance of complete systems

Thus, the Waterfall model maintains that one should move to a phase only when its preceding phase is reviewed and verified.

Various modified Waterfall models (including Royce's final model), however, can include slight or major variations on this process...”


The Agile Software Development Method

The Agile Manifesto was conceived in 2001 by the Agile Alliance, a group of “independent thinkers” who met to discuss an alternative approach to the existing heavyweight software development processes.  The manifesto is worth revisiting, and copied here in its entirety, along with the 12 supporting principles:

Manifesto for Agile Software Development[3]

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler

James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick

Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas


Principles behind the Agile Manifesto

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.


What went wrong between Hertz and Accenture?

As recently as 2013, Accenture delivered software using their proprietary “Accenture Delivery Methods (ADM) Framework[4]” which describes a traditional Waterfall software delivery approach, married to other tools and processes that complete the Accenture delivery suite. 

Specifically, the Accenture ADM identifies 6 key steps, which include:

  • Plan
  • Analyze
  • Design
  • Build
  • Test
  • Deploy

Accenture, according to the complaint, entered into 4 Statements of Work in Phase 1 to execute the plan-analyze-design portion of the ADM.  Accenture performed project planning services, requirements gathering, evaluation of Hertz’s existing technology and developed a “solution blueprint” to describe the functionality, business processes, technology, and security of the solution.  As deliverables, Accenture produced the “Solution Blueprint”, a “Delivery Plan”, and an “Architecture Specification” at a cost of approximately $7 MILLION to Hertz.

Subsequently, Accenture began Phase II of the effort to design, build, test, validate, and deploy the application, and Hertz moved forward receiving an additional $26 MILLION for software development.

Accenture never deployed a working solution, and ultimately spent $33 MILLION of Hertz’s money.  They did not fail fast!

The issues

The specific issues will ultimately be identified through the legal discovery process, but it is easy to speculate what may have gone awry.

The Blame Game

A buyer of custom software typically wants to know (a) what features will be built, (b) how much will it cost, and (c) how long will it take.  These parameters allow a customer to budget for the project and have resources in place to take advantage of the software as it is deployed.   The unfortunate truth is that it is very difficult if not impossible to estimate all three variables on a large project with any reasonable degree of confidence.  All software engineers with a little experience know this as fact.  Management sometimes does not.

A Waterfall strategy approaches the problem by breaking the problem into several phases, and phases into milestones.  Phase 1 determines the requirements, labor, schedule, and costs, and phase 2 delivers and tests the “working” product.  As mentioned earlier, this was Accenture’s approach as suggested by the lawsuit and the Accenture ADM.

Conflict in the relationship begins at this point.  Conflict results when the documented requirements don’t accurately represent the needs of the business, and the vendor keeps increasing the cost and postponing the delivery date via the change request process.  Accenture attempted to reduce their risk by charging $7 million up front to flip every stone making sure that all requirements were thoroughly identified and documented, and then had the customer sign off that they agreed with the scope of work to be completed.

Unaccounted for in the estimate is the fact that customers will frequently change their mind during the course of delivery.  As changes inevitably occur, the deadlines slip, and costs increase.  Few projects developed in this fashion ever finish on time or within budget. 

This approach sets the stage for an adversarial relationship between customer and vendor as each blame the other for the spiraling costs and missed deadlines.  The “blame game” results in conflict over the functional specifications, the statement of work, costs, and deadlines.

This scenario appears to be the case in Hertz vs Accenture.  Although change requests are not mentioned, it is clear that Accenture used their ADM to first define requirements, and then attempt to deliver the solution.


Agile attempts to eliminate the blame game found in Waterfall through collaboration.  An Agile framework only works when the business client and software vendor work as partners to develop a solution.  A product owner representing the business’ interests (1) works with the development team on a daily basis to identify what features offer greatest value to the business; (2) assists the developers in understanding the detail of the requirements; and (3) observes the daily stand-up meeting to be fully aware of the sprint progress and any blockers the team is facing.  This partnership between the business and vendor eliminates the blame game by acknowledging that we are in this together and we will succeed or fail as a joint team.  The vendor is given the opportunity to demonstrate a working part of the product to the business since planning is done in increments, and If it appears that the vendor is not going to be able to deliver as promised, the client has the opportunity to “fail early” by cancelling the effort and not spending a huge sum of money.

All requirements are not equal

Waterfall methods tend to treat all requirements as equal, because in the end, you must do everything in the functional specification to produce a final working product.  Developers like to start with the easier, more interesting requirements knowing that they will eventually have to get to the more difficult ones; however, all have equal value in Waterfall, so it matters not which are done first.  Delivering value early is not always a priority.

Agile approaches this problem differently.   Requirements, i.e. “user stories” are selected based on their value to the business.  Those with the highest value are tackled first, usually to support a theme, and typically the most difficult problems within the high-value requirements are prioritized over easier problems.  This approach gives the business functionality with value first.

The ultimate goal is to give the customer a product they can use as quickly as possible.  Things of little value are either done at the end, or not done at all.  The customer can stop development when they have a product that accomplishes their goals, even if all the user stories are incomplete.

The Hertz vs Accenture lawsuit seems to imply that this was also an issue.  Hertz should have received something they could use much earlier in the engagement.

Things Change

Change is inevitable on a large software project.  It is virtually impossible to determine everything you want a system to do before you begin to build it.  Changes frequently include:

  • A new requirement not previously identified.
  • A misunderstanding of what a requirement means.
  • Requirements that originally seemed important that are no longer needed.
  • A re-prioritization of what is important to the business causing a mid-stream change in direction.
  • Clarity in vision of how a user interface should work after an original design is difficult to use, even if satisfying the spirit of the requirement.

Waterfall and Agile methods approach change with significant differences.   The Waterfall method uses a formal Change Control Process to document, estimate, and schedule a change.  The customer is typically asked to pay an additional sum to implement the change.   Although change control is not directly referenced in the lawsuit, one could safely assume that Accenture asked for additional money to deliver feature changes.

Agile development methods embrace change as a core pillar of its principals.  Change control in an Agile team happens via collaboration between the team and business.  When a change is requested, the combined team assesses the change and the value it brings.  It is then given a priority ranking and if deemed important, it is assigned to a “sprint”.   This can impact the project in several ways:

  • Increase the cost
  • Extend the expected release.
  • Reduce the number non-priority requirements that are completed towards the end date of the project.

This results in collaboration and transparency between the client and vendor to decide how to deal with a change rather than conflict debating over who is responsible for paying for a change.

Show and Tell

Sprint reviews and retrospectives are key to delivery in an Agile Methodology.  The Sprint Review demonstrates work completed during the prior sprint and shows overall product status.  A “sprint” is a short 2-week to 4-week block of work (with preference to shorter) in which a selection of high priority requirements are developed.  The Sprint Review allows the team to demonstrate working code to the stakeholders and solicit feedback.

Waterfall delivery does not have a short work-review cadence similar to Agile.  Waterfall demonstrations are tied to milestones, which usually represent a large amount of work performed over months.  Errors or changes discovered during milestone reviews can result in large re-works to correct an error or integrate a change request.

In the same way that a Sprint Review demonstrates working code, Sprint Retrospectives review the team processes and allow the team to inspect and adapt which in turn helps the team to improve delivery with time. 

Hertz would have quickly recognized the lack of a responsive design that addressed the tablet format had all responsive designs been demonstrated as they were completed rather than at the end of a milestone.  This is an early fail that was missed.


A Waterfall methodology measures progress with a project plan; an Agile methodology measures progress with a burndown chart.

The project plan is a list of tasks that need to be completed and are assigned to individuals who will complete them in a given time-box.

In an Agile framework, stories (i.e. requirements with acceptance criteria) are given a story point value by the team that reflects how big the story feels compared to a base story.    The stories are assigned to the team in sprint planning, and the self-organizing team decides who should individually build each story.  The sum of all points represents the size of the product backlog.  The team begins to work the stories over multiple sprints and establish a team velocity… how many points the team can reasonably expect to finish per sprint.  This can then be extrapolated to help in planning an estimated completion date.  This burndown chart below represents the transparency provided to the customer at the end of each sprint.  It shows the work that has been completed thus far, work that has been added, and the work remaining.  Remember, the client and vendor are in this endeavor together so there shouldn’t be secrets about the progress.

Burndown chart

Testing is not an afterthought

Working software with every sprint is the goal of an Agile methodology.  Waterfall projects work towards milestones and produce “deliverables” according to the statement of work.  One way Agile differs from Waterfall is that the software to test a requirement is often written prior to the software to deliver the requirement.  This technique is known as Test Driven Development.   Any time code is checked in, all the tests are run against the system to validate that the checked-in code did not impact other code in the system.   This constant testing of the system is know as continuous integration, and it helps to improve the quality of software by finding bugs early.  This also reinforces the theme “fail fast” as it is much cheaper to fix a bug early in the process than later.   This technique can be used in both Agile and Waterfall, although it seems to be more prevalent in Agile.  Accenture was not delivering working software for many different reasons and they could have discovered this much earlier if they had adopted test driven development and continuous integration practices.

Failing Fast

As one of my prior co-workers used to say, “The sooner we get behind, the more time we have left to catch up.”  In his book “The Mythical Man Month[5]”, Fred Brooks observed that adding people to a project that is already late only makes it more late.  If a project is going to fail, you want it to fail as fast as possible.  Likewise, there is the concept of “good enough.”  Sometimes a project accomplishes all the tasks it was intended to achieve without adding all the bells and whistles that were originally conceived.

An Agile framework supports the Fail Fast philosophy.  It is our responsibility as a vendor to be a good steward of our client’s time and money.  We work as a team and succeed or fail as a team.  And, in those rare cases where we do fail, we want to fail as fast as possible.


It is likely that this lawsuit will settle out of court, but this lawsuit highlights many of the things that can go wrong in a software development effort.  Traditional Waterfall methods can get the job done and build all the conceptualized requirements given enough time, money, and man power.  Agile methodologies focus on business value and getting the most important things finished first.  The customer is a partner in the endeavor which means you succeed or fail as a team.

Next Steps

Want to learn more?  SDS can assist you in several ways:

  1. Schedule a Lunch-and-Learn tailored to your specific questions.
  2. Attend the annual Cincy Deliver conference on the last Friday in July. Organized by our Agile expert, Phil Japikse, Cincy Deliver focuses on developing software, which includes Agile methods.   (https://www.dayofAgile.com )
  3. Ask about or agile transformation and mentorship programs.
  4. Consider working with a blended team consisting of your people working side-by-side with experienced Agile developers on a project.

Contact Steve Held at Steve.Held@SDS.io or 513-218-1706 for more information.

About Strategic Data Systems

Strategic Data Systems helps business adopt technology.

We believe that letting us do what we do best—Technology—allows you to focus on what you do best.

We believe companies who can efficiently produce, process, find, and consume critical information at the exact time it is needed have a significant competitive advantage over those who cannot.

We believe information sharing among employees has great value and that highly collaborative teams enhance individual performances.

We drive business success using technology solutions.

We provide these solutions as a professional services organization providing offsite IT project execution, consulting services, system integration, and staffing services.


[1] The Hertz Corporation vs Accenture LLP, Civil Action No 19-3505.  United States District Court, Southern District of New York.  PDF at https://regmedia.co.uk/2019/04/23/hertz-accenture-website.pdf

[2] Excerpt from https://en.wikipedia.org/wiki/Waterfall_model

[3] https://Agilemanifesto.org

[4] https://methodology.accenture.com/core_prog_proj_mgt/


[5] https://en.wikipedia.org/wiki/The_Mythical_Man-Month

Still have questions?  Check out Agile Enablement.