Advertisement
*
Reproduction permitted for personal use only. For reprints and reprint permission, contact reprints@wistechnology.com.

Agile Revolution: A new era of software delivery

IT initiatives continue to experience high rates of failure. As a result, many organizations are losing faith in IT as a valued partner. The result stifles innovation, growth, and a company's competitive advantage.

Returning value to IT requires shedding the flawed processes of yesterday, and introducing methods that create greater alignment between IT and business by promising incremental delivery of functional software.

Evidence

Software development is hard work, so we have been taught that the best way to solve the difficult challenges inherent to IT initiatives is to treat software development as an engineering discipline. Yet we continue to fail.

• After five years and $26 million dollars, the University of Wisconsin System discontinued implementation of a system-wide payroll and benefit initiative.
Advertisement
• The Department of Workforce Development recently canceled the EnABLES project. Overall, $23.6 million was spent on the project, including approximately $10 million on the phase II appeals system that was never completed.

• Wisconsin is attempting to recover $2.1 million after a failed Oracle-based e-mail installation.

• In 2005, after spending more than $170 million, the FBI canceled development of it's Virtual Case File (VCF) without deploying it.

I can promise that many other organizations not subject to public scrutiny experience failure rates with equally staggering numbers. Why do we fail? In the case of the VCF, failure was the direct result of poorly defined and evolving requirements and overly ambitious schedules.

The original CHAOS report, published by The Standish Group in 1994, supports the claim that the primary impediment to successful software delivery surrounds requirements. Since the publication of that report, more evidence has emerged to support its findings:

• 35 percent of requirements change throughout the software lifecycle (Jones, C. 1997. Applied Software Measurement. McGraw Hill.)

• 45 percent of delivered features are never used. (Johnson, J. 2002. Keynote speech, XP 2002, Sardinia, Italy.) (Also see Feature Driven Development.)

• 82 percent of projects cited incomplete and unstable requirements as the number one reason for failure. (Thomas, M. 2001. "IT Projects Sink or Swim." British Computer Society Review.)

• Large projects, those costing more than $10 million, are successful exactly zero (0) percent of the time. (Johnson, J. 1999. "CHAOS Into Success." Software magazine.)

Unfortunately, many organizations attempt to rectify this situation by applying traditional software development techniques that emphasize early requirements elicitation and stabilization. While a noble goal, it is not possible to stabilize that which is inherently unstable, and organizations are typically left with processes that are little more than slight variations of the faulty practices that have plagued the software industry for decades.

Clearly, a more nimble and adaptable approach is required.

The Agile Revolution

In 2001, a group of luminary experts convened in Utah to discuss the dismal state of software development and delivery. What emerged was The Agile Manifesto, a symbolic proclamation denouncing the traditional development methods and practices that have led the software industry astray.

Today, we are feeling the affects of the agile software development movement as it redefines software delivery and continues to prove its value on enterprise IT initiatives.

• 88 percent of projects cited improved productivity after applying agile techniques. (Corporate Report, 2003. Agile Methodologies Survey Results. Shine Technologies Pty Ltd., Victoria, Australia.)

• 84 percent of projects cited improved quality after applying agile techniques. (Corporate Report, 2003. Agile Methodologies Survey Results. Shine Technologies Pty Ltd., Victoria, Australia.)

• The most recent CHAOS report published by Standish Group included agile practices as one of the top 5 factors influencing the success of software related projects.

Agile methods separate themselves from traditional software development practices through elegant simplicity. By stressing frequent and incremental delivery of functional software through intense collaboration, teams realize increased alignment between IT and business, reduced risk, greater adaptability, and increased quality.

In an age where IT services are viewed as an easily obtainable commodity, the onus is on IT to earn back the trust of our most valued partner. To do so requires innovative use of technology that exceeds the desires of our customers. Such is the benefit of agile processes and practices.

But how? Over the next few months, we will explore the values, beliefs, principles, benefits, and characteristics of agile software development.

Kirk Knoernschild is the chief technology strategist at QWANtify, Inc., a Madison-based information technology consulting organization. In addition to his work on enterprise development projects, he shares his experiences through courseware development and teaching, writing, and speaking at regional and national conferences.

He is the author of Java Design: Objects, UML, and Process, and a frequent contributor to The Agile Journal, where he writes The Agile Developer column. His personal website is www.kirkk.com, and his planet is http://planet.kirkk.com.

The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.

WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.

Comments

TeamMember responded 7 years ago: #1

I'm curious, of the "Evidence" you state above. How much of it comes from first hand knowledge? I have first-hand knowledge of one of the projects you list as "Evidence." To imply old methodologies are the reason that these projects failed and that Agile practices are the savior is very irresponsible (and my guess, also very self-serving). In fact, we did use many Agile practices on the project I was associated with. Our development process is not what lead the project to be canceled. Agile practices are great, but not the holy grail. Any practice/methodology is only as good as the people putting it to use. Please be more responsible in the future when trying to promote yourself.

Kirk Knoernschild responded 7 years ago: #2

I cited the statistics because they are indisputable. While these numbers are well publicized, it's doubtful one would have to search far to find supporting numbers. The article is not self-serving, but should definitely serve to motivate. It's imperative we begin to search for a way to deliver IT solutions successfully. We have certainly proven over time that the traditional approach does not work very well. As business continues to lose faith in IT and view IT services as a commodity, it has a tremendous negative impact for the IT professional. I believe it's professionally irresponsible that we so easily accept failure as a viable contingency.

TeamMember responded 7 years ago: #3

You used "statistics" and "indisputable" in the same sentence. I wont even touch that. :) The point I was trying to make to you is you shouldn't be referencing projects that you have no knowledge of when trying to make the point that the process failed. That is irresponsible.

Sorry, I can't help myself. I have to touch the statistics. You state many impressive statistics, unfortunately you don't cite valid references for any of them. You cite the CHAOS report but the only stat that can even remotely be matched up is "82 percent of projects cited incomplete and unstable requirements as the number one reason for failure." Which, if you look at page 2 of the report and adding up "Incomplete Requirements" and "Changing Requirements & Specifications" comes up with 21.8%, a far cry from the 82% you state. Please post valid references to ALL of your "statistics."

Despite my comments, I do believe that Agile development practices are good, but like I said before, they are not the holy grail. Good developers can succeed with bad methods and bad developers can fail with great methods. (And projects can be canceled without regard to development). I also think the best way to promote Agile practices (or any thing for that matter) is by valid arguments, not scare tactics (we should leave that trash to the politicians and media).

maz responded 7 years ago: #4

All points of view should be questioned including statistics. Why? Humans are not rational and disinterested. On the contrary we are emotional creatures who seek to enhance our standing: status, wealth etc. So we pick a point of view that serves our self interest and then out of the universe of 'facts' and 'statistics' we select and highlight those that serve our interests, our point of view.

I venture that in years to come Agile methods will also fall by the wayside. What software methods and business in general do not take into account is the human being. Primarily the way he/she/we deal with the world, including information processing.

Robert Merrill responded 7 years ago: #5

Welcome to the murky world of software methodology. "Success" and "failure" are not clearly defined, and statistics are often results of surveys, so it's no wonder that numbers don't match up.

I agree with maz, with a nod to George Orwell. "All people are self-serving, but some are more self-serving than others." I tend to trust the CHAOS Reports from Standish, and put a little less stock in the Shine results just because of how they were obtained.

Most firms don't really have any way to gauge productivity, so they have to rely on results like these to make choices about tools and methodology.

-Add Your Comment

Name:
E-mail:

Comment Policy: WTN News accepts comments that are on-topic and do not contain advertisements, profanity or personal attacks. Comments represent the views of the individuals who post them and do not necessarily represent the views of WTN Media or our partners, advertisers, or sources. Comments are moderated and are not immediately posted. Your email address will not be posted.

WTN Media cannot accept liability for the content of comments posted here or verify their accuracy. If you believe this comment section is being abused, contact edit@wistechnology.com.

WTN InGroup
FusionCIO InGroup
Advertisement
SupraNet Communications

-More Stories

WTN Media Presents