Agile and Its Value

Part 1: Where Is It Going Wrong?

11 September 2013


I have worked with multiple customers who have severely doubted Agile and its capabilities. However, when I talk to them about the features they require and I present the time needed to produce them, they grin. Still, a lot of people in the business community joke that Agile is for those who don't know what they are doing. May be they have read and signed off on huge requirements specs (running into hundreds of pages) and are proud about it. But it is quite possible that at the end of the project, they will have many requirements that are unmet. While documentation and digging requirements works well, control of the direction goes away with that sign-off, and every change can become a dangerous play of dependencies and escalating costs.

Most of the time, complex projects become like one of those expensive hot-air balloons: The cost is already high, and the speed at which it is climbing continues to decrease. You push the pedal and let out more gas, hoping it will go faster and rise. But the tell-tale signs are there; in your heart you're not sure whether it will reach the destination. And even if it does, you might already have missed the party. You be a little too late.

I briefly want to write about some of the compelling reasons that would make any company want to embrace Agile and one of its frameworks (Scrum, XP, TDD, etc.) to execute projects. But first I want to write about some specific numbers that are coming out of industry surveys on the points I am trying to make.

Statistics
  • 17% of large IT projects go so badly that they can threaten the very existence of the company. (McKinsey & Co., in conjunction with the University of Oxford)
  • On average, large IT projects run 45% over budget and 7% over time, while delivering 56% less value than predicted. (McKinsey & Co., in conjunction with the University of Oxford)
  • Only 40% of projects meet schedule, budget, and quality goals. (IBM study)
  • The Portland Business Journal found similarly very depressing statistics: "Most analyses conclude that between 65 and 80% of IT projects fail to meet their objectives, and also run significantly late or cost far more than planned."
  • KPMG New Zealand found that "an incredible 70% of organizations have suffered at least one project failure in the prior 12 months, and 50% of respondents indicated that their project failed to consistently achieve what they set out to achieve."
  • The failure rate of large IT projects with budgets exceeding $1 million was found to be almost 50% higher than for projects with budgets below $350,000. (Gartner)
This tells us that there is something wrong with the way projects are being done. Project management discipline is either not doing what it is supposed to be doing or is not able to accomplish its endeavor, or its support systems aren't working.

From various readings across the Web, and my own experiences, I see that there are few major differentiators that don't mean success but that do push your chances of getting out successfully at the end.

1. Size of the project. In line with the Gartner report, smaller projects are much easier to handle and hence there is a potential of better management, easier course correction, and fewer vulnerabilities.
2. Agile implementation. Agile has already started to become a differentiator in terms of market success rates and projects trying to get close to what they were intended for: value. I will return to the "value" perspective later in further installments to this paper. Notice the keywords like "what it was intended to do," "objectives unmet," etc.
3. Organizational support. The environment in which you are letting the project run plays a major contributing factor toward its success or failure. The more rigid the middle and senior management, the more difficult it becomes to bring in changes. Agile requires a leaner and meaner way of thinking, which doesn't come naturally after years of industry practices and the Waterfall way of working. Hence, organizational transformation is at the heart of Agile adoption for most companies.

In following articles, I will write about the value that Agile delivers, and why it is a promising method and mind-set change.

Article Rating

Current rating: 4 (1 ratings)

Comments

Phillip Stiby, CSM, 9/11/2013 5:11:57 AM
I like the article, just to add my two pence.

The amount of project time wasted... I mean invested in the requirements capture phase generally squeezes the development time, this causes the project to be late, fail or be of poor quality.

The Mythical man month (an engineering book over 25 years old) also points out the requirements phase drags on because those involved fear being wrong or being tied to the requirements so no decisions are made.

The sooner you start delivering functionality and people see results the fog over the requirements clears and things get done, as the first principle of agile states:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

A document is not valuable software!
Kapil Dhawan, CSM,CSPO, 9/11/2013 11:49:09 PM
Hi Saurabh,

We are basically agile in our daily life but we have forgotten to apply the same in our work.

Was wondering on, how do you estimate time needed to deliver.
saurabh mittal, CSM, 9/12/2013 1:35:29 AM
@phillip, 100% agreed with you. that is where agile takes the cake away. because the complete focus is on what is the thing of value to customer. end of the days,documentation will not help their bottomline, a work useful software will.
@kapil, can you detail your question a little more. are you talking about time needed to deliver a project or time to deliver requirements and risks associated with all this estimation
Kapil Dhawan, CSM,CSPO, 9/12/2013 5:22:47 AM
Hi Saurabh,

Let me try to detail. :)

How do you estimate efforts required to deliver the project as per the backlog especially when customer smile.
saurabh mittal, CSM, 9/16/2013 2:13:08 AM
Kapil, for the estimations, its always either a breakdown of work, with some assumptions and then putting number, and end of the day putting some contingencies. in agile way, we would go by creating buckets and assigning them weights to relatively differentiate them. then, combined together and finding how much of work could get done in one sprint, the total is extrapolated to find out roughly how much time will it.
i not sure about the 'customer smile'. may be we should talk further. feel free to drop me a email using contact form.
Kapil Dhawan, CSM,CSPO, 9/16/2013 2:43:36 AM
Thanks Saurabh. Will do that.

You must Login or Signup to comment.