Home > Archive > Software Engineering > September 2007 > Disadvantages of agile software development
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Disadvantages of agile software development
|
|
| kelly.waters 2007-09-04, 7:09 pm |
| I'm a big fan of agile development principles. But there are trade-
offs.
In the past I've been accused by some readers as being too
evangelical. As evangelising 'Agile'. Actually I have a lot of
experience in more traditional waterfall approaches to development and
think there are pros and cons. It just so happens that agile really
suits my current environment rather well.
Anyway, to balance things up a bit, I've written this. If you're
thinking of adopting agile development, it's a good idea to know what
you're in for...
[url]http://kw-agiledevelopment.blogspot.com/2007/09/di vantages-of-agile-software.html[/url]
Kelly Waters
http://www.allaboutagile.com
| |
| Tcagley 2007-09-05, 8:05 am |
| There is nothing wrong with evangelizing agile if that evangelism does
not cause myopia. I have come to the conclusion that most IT
organizations need to have a palette of methodologies including xP,
SCRUM and waterfall. I have recenly been investigating Lean. I
recently posted an interview with Mary Poppendieck on my podcast in
which she talks about Lean and recounts a conversation with Barry
Boehm that attributes many of the great requirements woes to him. The
podcast is the Software Process and Measurement Cast
(www.spamcast.net).
On Sep 4, 4:19 pm, "kelly.waters" <allaboutag...@googlemail.com>
wrote:
> I'm a big fan of agile development principles. But there are trade-
> offs.
>
> In the past I've been accused by some readers as being too
> evangelical. As evangelising 'Agile'. Actually I have a lot of
> experience in more traditional waterfall approaches to development and
> think there are pros and cons. It just so happens that agile really
> suits my current environment rather well.
>
> Anyway, to balance things up a bit, I've written this. If you're
> thinking of adopting agile development, it's a good idea to know what
> you're in for...
>
> [url]http://kw-agiledevelopment.blogspot.com/2007/09/divantages-of-agil...[/url]
>
> Kelly Watershttp://www.allaboutagile.com
| |
| H. S. Lahman 2007-09-05, 10:05 pm |
| Responding to Kelly.waters...
> Anyway, to balance things up a bit, I've written this. If you're
> thinking of adopting agile development, it's a good idea to know what
> you're in for...
>
> [url]http://kw-agiledevelopment.blogspot.com/2007/09/divantages-of-agile-software.html[/url]
Unfortunately I think there are some other issues that you did not
mention. These are mainly about how agile processes interact with the
rest of the business. [BTW, as the paper in my ID tag suggests, I think
agile practices are fine. My concerns below are limited to the better
known OOP-based agile processes, which tend to be rigidly defined around
a rather narrow set of developer-centric assumptions.]
User involvement is often a potential problem. In many shops the
Marketeers are the customer surrogates. However, the lowest paid
Marketeer is often paid more than the highest paid software developer.
So holding the hands of developers is usually not very high on their
list of priorities. This is especially true when the expectation is that
the Marketeers be readily available on an as-needed basis to clarify
things for developers. To the extent that the Marketeers limit their
accessibility, the agile process will suffer.
Another problem is the way requirements are formed. For modern
commercial products the company usually has some sort of Rapid Product
Development process (RPDP) in place. Such processes invariably define
requirements fully up front because the company needs to be selling the
product while it is under development so they need to know exactly what
will be in it. (They also need firm commitments on time-to-market, which
is only possible if all the requirements are defined.) Any changes in
requirements are deferred to the next product because short
time-to-market dominates. IOW, the developers' IID increments are
irrelevant and only the final product delivery counts.
In theory that is not a problem because the developers need requirements
anyway. In practice, though, it is significant because it negates many
of the assumptions of agile processes. IOW, the practices that are
specifically designed to deal with changing requirements are wasted and
that is likely to translate into inefficiency. In addition, most agile
processes do not provide for the necessary up-front planning and
estimation OTB.
Yet another problem is testing. The emphasis on testing as a product
quality gate in agile processes is a pretty neanderthal view that dates
from the '70s. The 4-Sigma quality that was then the software industry
mean is no longer acceptable. But pure testing can only approach 5-Sigma
and cannot possibly provide 6-Sigma reliability. So the modern view
(since the late '80s) is that testing is a process monitoring tool
rather than a product quality gate and high reliability is achieved by
having development processes that focus on preventing the insertion of
defects in the first place. So the OTB agile processes are really only
applicable for products where reliability is not very critical.
[Unfortunately, from the limited sampling of agile testing I've seen,
the quality of testing is pretty atrocious even in that context. In the
shop where I worked before retiring it would have been regarded as
plausibility or proof-of-concept testing. Moreover, there doesn't seem
to be anyone in the Agile Community who understands testing in depth.
When correctness is defined solely in terms of passing tests there is an
enormous conscious or unconscious temptation to provide fewer unit
tests. Since acceptance tests are at the system level, combinatorial
problems prevent their having good coverage so they will only find the
more egregious problems. The result is a lot of escapes for large
applications.]
At least as important IMO is that the agile feedback mechanisms can
easily be abused as the developers essentially use the customer as an
alpha tester of the software. Then everything they didn't take the time
to do right in the first place becomes a new feature for the next cycle.
The OOP-based agile processes do not provide built-in mechanisms to
prevent that sort of abuse.
Which segues to another divantage. The culture around the OOP-based
agile processes relies a great deal on individual developer
professionalism. The agile processes go out of their way to avoid
placing constraints on how developers actually do their thing. That's
fine so long as the developers (a) are professionals and (b) already
know how to avoid such pitfalls. Unfortunately, those are two very big
assumptions. Without any objective metrics or built-in process
improvement mechanisms, the business is placing a whole lot of faith in
the developers.
Yet another problem is related to frequent delivery. It is one thing to
use IID in the development process and provide the customer with the
/ability/ to review the product incrementally. It is quite another to
force the rest of the organization to adjust to the very short cycles of
agile IID.
Probably the place where this is most obvious is in documentation. The
actual production of the documentation after writing is complete is
usually a fairly complex process and it usually takes 3-10 days in a
given doc environment. More important, it will not vary much with size.
That is, to a first approximation, it doesn't matter whether one is
producing 10 pages or 1000 pages. Requiring the doc people to perform
such a production cycle every 2-3 w s to match the developers puts a
strain on doc resources. It is also a morale buster because most shops
are too small to have a dedicated production person so the writers have
to do it and most writers I know hate production.
However, the real problem is that the quality of the documentation takes
a major hit. That's because the stories are so small that the doc
changes are at the level of individual sentences sprinkled throughout
the doc set. As a result there is no one looking at the Big Picture for
how the overall documentation looks to the customer. More important,
there is no room in the schedule for that sort of overall effort (e.g.,
maintenance of style sheets) even if someone felt compelled to solve the
problem. The result is invariably really crappy product documentation
overall.
That can cause severe morale problems among writers with a sense of
professionalism. One writer in an agile shop commented to me, "I don't
have a chance to really write; I'm doing the equivalent of online help
squibs. The doc is crap and everyone knows it but there is nothing we
can do about it in these short cut & paste cycles. And if I leave this
job, I won't even have any writing samples to show people."
The bottom line is that documentation doesn't work well at all with very
short product cycles. Doc groups often employ IID, but it is internal to
the tasks they have and does not match up with development (e.g., their
IID may be around the doc set organization, not the feature set).
Separate SQA groups have a similar problem. Tests for individual
requirements are defined one-at-a-time but they need to be integrated
with other tests for automation, setup efficiency, and whatnot. IOW, the
world of system test is quite different than the world of agile unit tests.
The final problem with the agile processes is that they effectively
remove all accountability from the developer. Overall product schedule
and feature set? That's the customer's problem to "steer" the project by
defining and prioritizing stories (whose size and content the developers
negotiate to ensure the stories can be completed in the increment!).
Reliability? That's the customer's problem. The software is working
correctly if the customer acceptance tests pass -- by definition. IOW,
the developers code to what the tests are rather than what the customer
needs. Productivity? The agile processes are designed so that there is
no objective measure to compare agile teams much less agile with other
approaches unless everyone develops exactly the same software. Again,
agile processes require a rather substantial act of faith in developer
professionalism on the part of the rest of the business.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
| |
|
| Tcagley wrote:
> I have come to the conclusion that most IT
> organizations need to have a palette of methodologies including xP,
> SCRUM and waterfall.
Friends don't let friends use Waterfall!
--
Phlip
| |
| David Lightstone 2007-09-06, 10:06 pm |
|
"Phlip" <phlip2005@gmail.com> wrote in message
news:h5WDi.294988$5y.87670@newsfe18.lga...
> Tcagley wrote:
>
>
> Friends don't let friends use Waterfall!
Get with the program, Phlip, managers don't let employees use waterfall. Not
enough time to do it right
>
> --
> Phlip
| |
| xpyttl 2007-09-07, 7:06 pm |
|
"David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
news:5L1Ei.1847$Sd4.867@nlpi061.nbdc.sbc.com...
>
> "Phlip" <phlip2005@gmail.com> wrote in message
> news:h5WDi.294988$5y.87670@newsfe18.lga...
>
> Get with the program, Phlip, managers don't let employees use waterfall.
> Not enough time to do it right
Actually, managers who have a clue insist on waterfall, and allow the time
to do it right.
Admittedly, those managers are a rare breed. But there is no other way to
make the decision on price versus function up front. One advantage of XP is
that you can control the price, but you have no idea what it is going to buy
you. The problem with waterfall is that most managers set the price and
function based on wishful thinking rather than data. Then when they run out
of budget they are left with nothing.
...
| |
|
| xpyttl wrote:
> Actually, managers who have a clue insist on waterfall, and allow the time
> to do it right.
>
> Admittedly, those managers are a rare breed. Â_But there is no other way to
> make the decision on price versus function up front. Â_One advantage of XP
> is that you can control the price, but you have no idea what it is going
> to buy you. Â_The problem with waterfall is that most managers set the
> price and function based on wishful thinking rather than data. Â_Then when
> they run out of budget they are left with nothing.
My - that's just like saying, if you have a really large project, the longer
you take to carefully collect requirements, the more likely you are to
deliver them all, on-time and under-budget, so they are used in their
specified form!
Got any facts, citations, or case studies to back this up?
--
Phlip
| |
| David Lightstone 2007-09-10, 8:05 am |
|
"Phlip" <phlip2005@gmail.com> wrote in message
news:0CdEi.239313$BX3.4551@newsfe13.lga...
> xpyttl wrote:
>
>
> My - that's just like saying, if you have a really large project, the
> longer
> you take to carefully collect requirements, the more likely you are to
> deliver them all, on-time and under-budget, so they are used in their
> specified form!
Is it? (that was sarcasm)
>
> Got any facts, citations, or case studies to back this up?
>
> --
> Phlip
| |
| David Lightstone 2007-09-10, 8:05 am |
|
"xpyttl" <xpyttl_NOSPAM@earthling.net> wrote in message
news:PodEi.8$Dz3.4@newsfe02.lga...
>
> "David Lightstone" <david._NoSpamlightstone@prodigy.net> wrote in message
> news:5L1Ei.1847$Sd4.867@nlpi061.nbdc.sbc.com...
>
> Actually, managers who have a clue insist on waterfall, and allow the time
> to do it right.
>
> Admittedly, those managers are a rare breed. But there is no other way to
> make the decision on price versus function up front. One advantage of XP
> is that you can control the price, but you have no idea what it is going
> to buy you. The problem with waterfall is that most managers set the
> price and function based on wishful thinking rather than data. Then when
> they run out of budget they are left with nothing.
>
> .
There is no data. It is raw decision making in the presense of significant
uncertaintly.
XP is just pandering - the uncertainty and cost can managed. That is just
what the naieve manager want
..
>
>
|
|
|
|
|