Thursday, June 13, 2019

This is why Accenture couldn't build a responsive ecommerce web app for Hertz

This story is newsworthy and even amusing because of the big sum involved - $32 million. But imagine, if you were in Hertz's shoes and the amount was only $3.2 million, or even $320,000 - would it still hurt if this happened to you?

You bet it would! And that is why it is crucial to take apart this case study in modern web app development failure and learn the crucial two principles that were disobeyed on the path to this colossal cock-up. Laughing at someone else's misfortune can be cathartic, only because we know it could well have been you. Maybe it was you, in a previous life or project.

This is what happened, according to Hertz's lawsuit

  • Accenture was hired by Hertz to build a responsive ecommerce web app that could be used across its global operations
  • Accenture couldn't deliver a working ecommerce web app, leave alone a responsive one, even after two lengthy delays
  • By the time Hertz aborted the project, it had already paid Accenture $32 million
  • To top it off, Accenture wanted another $10 million to deliver the original requirements
  • "Accenture’s developers wrote the code for the customer-facing ecommerce website in a way that created serious security vulnerabilities and performance problems," it says before noting that "the defects in the front end development code were so pervasive that all of Accenture’s work on that component had to be scrapped."
  • To compound its woes Accenture told Hertz it would have to use RAPID to fulfil the original requirements.
  • But it is claimed that Accenture had little experience with implementing RAPID and spent much of its time on firefighting this integration
So how is it that a global powerhouse that hires the best and the brightest could deliver an ecommerce web app in $32 million, when most smart and efficient web development companies could've done it in 1/100th of that cost?

But first, why is this case study important for you

Because the statistics paint a very bleak picture. This study from 2018 says that you will have more unsuccessful IT projects than you will have successful ones:

So is it worth your time if learning two principles that can drastically reduce the chances of your software projects ending up in the "failure" column?

You see, the two principles below aren't just specific to the Hertz and Accenture story, they are the bedrocks of all successful, or at least productive, agile software projects.

You will benefit even more if you your team has managed to take the leap into DevOps. These two principles must be part of your DevOps strategy and every decision should be assessed against these principles.

So here's what prevented Accenture from delivering a functional ecommerce web app even after raking in $32 million from Hertz and these are also the two principles you need to apply to supercharge the performance of your software projects:

A lack of empowerment

It all starts with the right leadership. Leadership that allows others to feel empowered to make the right decisions based on fact and evidence, not just hunches. What type of leader are you for your team?
Leaders instil in their people a hope for success and a belief in themselves. Positive leaders empower people to accomplish their goals.
Be careful here because the myth about empowerment is that it's just about delegation. It is not.

Real empowerment gives your team a structure or framework to make the right decisions more often AND to find and resolve potential issues before they become a source of frustration, embarrassment or even a lawsuit.

Effective empowerment in this situation would have allowed Accenture's team to plan the project in a way that allowed them to ensure that the house they were building actually looked like what was drawn on the plans.

Effective empowerment will ensure that the right sets of tools and people found and resolved weaknesses so that end-users don't become frustrated and angry at not being heard, when seemingly everything was written in a plain English in a requirements document.

Effective empowerment also helps you "shift left" by giving your team the space and responsibility to undertake activities (like real software testing) early and often during the project. In an agile development setting like the one within your team, the old approach of people simply doing their job role and only their job role will lead to more of your projects ending up in the 19% category in the infographic above.

Last but not least, effective empowerment will help you take care of attitudes in which developers are the only people that matter and everyone else is just an extra. Team cohesion is a critical part of your agile software development practice and there is no cohesion if one group of people think of themselves as a higher class of species.

Empowering each member of your team will enable you to build transparent checks and balances to ensure that only bug-free and secure applications are deployed to production. Your checks and balances should come in the form of clearly articulated processes where decisions are made based on objective metrics, not just someone's gut feel.

Take a moment to think about how you empower your team at the moment? You do empower them, don't you?

An absence of discipline

You see, software development is really a creative exercise. It's the creation of something out of literally nothing or at best the manifestation of someone's dreams into a sellable product. Most creatives will tell you that discipline isn't their dominant personality trait, but the successful ones all say this:
Creativity is a combination of discipline and childlike spirit.
Would you agree then, that your role as a leader of software development teams is to coach, cajole and, even, coerce your team to inject a dollop of discipline to their daily activities?

At this stage you might be asking, "but how?" It's actually easier than you think, as long as you put in place the right structures where discipline is in the very fabric of the activity, rather than a conscious choice to be made (or not made).

Let me put it to you another way: the reason buggy releases make their way into production is not because your team is full of unprofessional sods, it's because YOU haven't created the structure that cajoles (and compels) them to find and fix every bug before they commit a new version to production.

This lack of structure is leaving a lot of teams, probably even yours, overwhelmed and stressed, which can only lead to more lapses in discipline, more mistakes and more bugs in production:

Instead of thinking of discipline from a carrot and stick angle, think of it as a set of processes that help your teams focus on the areas that need their attention. Trust me when I say that this mindset shift will transform your culture from middling to high performance.

A great example of this is automated software testing, which is often evaluated only in terms of dollars and time saved. What you might not have realised is that a successful implementation of test automation actually helps to uplift your testing team from glorified data entry operators to expert software delivery managers and trusted liaisons between business and IT teams.

These transformations are not science fiction, but provable realities. What could it do for your business?

If you need help in solving these challenges, or in cutting software testing time and finding more bugs before your application's users find them, speak to us understand how we will be able to help you. Download our Secret Toolbox and then book in your test automation mastermind session to help set you on the right path to achieve your goals.
SaaS Brief