It’s suggested that the web has changed everything. Whatever requirements there were for delivering desktop applications, the requirements for delivering web applications has changed. For the web, the thinking goes; delivery of new features to customers is paramount to remain competitive. Maybe it’s true, but what’s the evidence? My own experience with popular web sites does not support this conclusion.
Agile doesn’t work in the real world is essentially the conclusion of David Starr, an Agile proponent, in his article “Why Agile Doesn’t Work.” First, he informs us of what is the primary objective of Agile software development methodologies:
Sure, TDD works, so does continuous integration, and a host of other great development practices. The truth is, though, that the real Agile value proposition was never about code. Better software with higher quality and excellent craftsmanship is a great side effect, but Agile is really about changing how products are created and delivered. Agile intends to fundamentally change the model of your relationships with clients and coworkers.
I’m reminded of an interview I had with a young company for a Software Director role. They were at point where they were ready to begin rapidly acquiring new customers. When a new customer signed, there was customization required to have the system operate according to the customer’s demanding requirements. The turnaround time from signing the new customer and having them productively using the system was approximately four weeks - at least that was the goal.
One of the difficulties I have with the Agile software methodologies and its proponents is that they go to far. They are often susceptible to hyperbole while hawking their methodology like used car salesmen. Their embracing of the practice of refactoring is one example of this. Of course, we should refactor, but refactoring isn’t a design methodology, it isn’t a way to be agile, and it doesn’t help deliver software faster. Refactoring as advocated by the Agile processes is essentially a design methodology. A team following Agile arrives at an optimal design and implementation via a series of iterations and refactoring efforts. Refactoring as a design methodology is incompatible with the Agile goals of delivering faster and accommodating change anytime in the project life-cycle.
The Agile software development practices are in their infancy stage as evidenced by the number of variants that are being promoted in popular print and usage today: Scrum and XP being two popular variants. Clearly the Agile practices are still evolving, and I believe what will eventually emerge are a set of Agile practices that look awfully familiar to traditional approaches. The question is, is once the Agile community arrives there, will the conflict cease?
Have you ever wondered why software process has yet to flourish in the software industry? Why, after many decades of industry growth, there is no consensus on a process methodology or even best practices? Why specious Agile approaches have captured significant mindshare in the software community? Why when you mention the words software process, software professionals cringe?
In other industries process innovation has been the contributing factor in the explosive growth. Where would the industrial revolution be without the innovation of assembly line processes? Where would the auto industry be? A predictable, repeatable process has been the cornerstone of innovation and quality for many successful industries. Did you ever wonder why a hamburger and french-fries at McDonalds taste the same no matter where in the world you purchase it? It’s all about process.
It’s an enigma to me and others who have had great success with software process that we continue to debate the need for formal process in the software industry. Yet the software industry continues unabated with a record of late deliveries, budget overruns, missed expectations, and low quality. In this article, I’d like to explore the factors that contribute to software process adoption failure.
There’s a lot of activity and promotion of the Agile software methodologies that can be found on both the Internet and in books today. Its adherents are zealous in their commitment to the Agile principles codified in the principles behind the Agile Manifesto. I first became interested in the Agile development practices when the Extreme Programming practices began generating a lot of interest in the software community. My first reaction to this was to be turned off. The name conjured up images of chaos, cowboy programmers, and death march development projects — practices I am all too familiar with. I found the advocacy of pair programming to be unnatural and impractical.
After reading many articles published by Agile proponents, I remain steadfast in my beliefs that something is wrong, and rather than advancing the state of the art practices in Software Development, Agile proponents are setting us back, and in this world where jobs easily cross international boarders, especially easy in software, we need practices that demonstrate the value proposition for keeping teams here in the US: practices that deliver reliably and predictably on commitments and practices that can demonstrate improvements in productivity and quality.
This work is licensed under a
Creative Commons Attribution-Noncommercial-No Derivative Works 3.0 United States License.
You Want IT When? © 2007 All Rights Reserved. Using WordPress 2.5.1 Engine
Entries and Comments.
Prosumer 1.4 made by Nurudin Jauhari
