Jun 25, 2007 / Erroneous and Dangerous Agile Criticism
20 commentsToday David Longstreet posted a comment in our blog with a link to the article with agile criticism. He mentioned that he doesn't like agile. It is always interesting to check opponents arguments, so I've read the article.
I should say that I was really disappointed. The article contains general speculations and almost no concrete comparisons. Common agile principles were disconsidered with strange comparisons and conclusions.
I can't resist from providing some quotes and my thoughts:
"Agile proponents believe discipline is not necessary and inhibits productivity."
This only phrase clearly shows how author is incompetent in agile software development. What the hell "discipline is not necessary"? How it relates to Extreme Programming where discipline is a KEY to success XP adoption? Extreme Programming is hard to adopt since it do require high responsibility and discipline to write all that unit tests, do refactoring, do daily meetings, track progress each day. If you've tried to release something useful and usable each month you know what kind of discipline it requires.
"Agile proponents believe documentation is an overhead cost and should be reduced or eliminated."
Documentation should be just enough. Large teams need more docs, while small teams can work almost without documentation. The main goal is to build and deliver working software. Nobody wants working documentation if software is a crap.
In fact, would you turn over 200-300 thousand dollars to have your home constructed using the same principles advocated by Agile or Xetreme programming. The answer of course is no.
What a dull example! What should I do to change color scheme on my web site? Yes, change several css styles. It will take 5 minutes. What should I do to change color of my house? Yes, buy several gallons of paint, take brush and spend next few days on that task. Changes in software are rather easy, changes in constructions are hard.
Look. If the building company may build 1 room, 1 kitchen and 1 bathroom ready for leaving within 1 month and then tell me that I may move into the house right away, I don't mind! (if they can build and decorate other rooms, cellar, garden, etc. without disturbing me). But building companies do not have such technologies. Software development companies have! That is the difference. The comparison above is pointless.
"Architects actively gather requirements and they study their clients. On the other hand, software developers passively gather requirements and often don’t have a clue about their customer or their business."
Such software development companies will die pretty soon. No way. Agile development is all about customers needs and business value delivery.
"Unfortunately the bulk of Agile software methods deal with coding techniques and testing. Those organizations that spend the least amount of time in coding are those organizations with the highest productivity and quality levels. It does not matter what you make if you spend more time testing than you did making something you have a problem. Testing should never be more than 50% of any project. In the future programming will become like welding, carpentry, and plumbing is today. The most prestigious professionals in the construction industry today are architects and the same will be true for software."
What about SCRUM? What about all these agile principles that focuses on productivity and quality? Unfortunately software industry is not in the phase to create products without coding. Model Driven Architecture (MDA) maybe promising approach, but not mature yet. So we have to code, sorry. What it means? We should optimize coding and increase productivity or invent better approach (like MDA). Why building companies still can't grow a house from a seed? I want to by a small 200 square metre house in my hypermarket packed in a nice small box!
"The primary reason why it is difficult to apply measurement to software organizations is because software organizations are chaotic. Every single time a development project is done it is done differently. [...] In other words, the entire process is just a mess."
Similar projects should be done similarly. Different projects SHOULD be done differently. Period. Agile strives for defined process that will evolve and adopt to any project. There is a deep misunderstanding of agile principles and ideas.
I don't know the reasons why the author wrote the article, but it is unprofessional. It does not show agile disadvantages, but looks like desperate attack on agile positions.
posted by Michael Dubakov @ 2:27 AM
20 Comments:
It is important to note I have a lot of experience consulting experince around the world. I have presented papers at unviersities and conferences around the world also. You can see a client list at client list
I am concerned about what is theory and what is practice. Most companies use Agile as an excuse to skip right to coding. I have presented the paper at several conferences and with little doubt most participants agree with my assessment of how Agile is actually implemented.
I have publically debated the Pro Agile, while I had fun many in the audience said if it would have been a boxing match it would have been stopped.
Most IT companies are looking for ways to continue their undisciplined habits. The best in class companies those with the highest productivity and quality levels are not using Agile. They have adopted principles from other disciplines.
Agile is much like Hoodie 911. It is the magic pill.
Sorry, I have measured and witnessed and Agile is not the answer. I got data.
I am recommending IT organizations learn to be more like other disiciplines and less "Agile." Agile is just another iteration of RAD, Iterative, so on and so forth.
If you don't like my thoughts on Agile, you are going to hate my next book!
By the way, can you measure the software process or not? Martin Fowler says no! It is too complex.
By the way, the productivity rates of software developers is abysmal when compared to other industries (contributions to gross output).
David Longstreet
Software Economist
www.SoftwareMetrics.Com.
>>Most companies use Agile as an excuse to skip right to coding. I have presented the paper at several conferences and with little doubt most participants agree with my assessment of how Agile is actually implemented.
Well, that is completely different. You did not mentioned that in article and I tend to agree with that conclusion. But it is not about agile itself, it is about agile implementation. If you'll take development/construction concept from Toyota (they are great, everyone knows) and implement them wrong - you will have awful results. Does it mean Toyota process is a crap? No. It only means you can't follow it.
>>>I am recommending IT organizations learn to be more like other disiciplines and less "Agile." Agile is just another iteration of RAD, Iterative, so on and so forth.
Do you like Six Sigma? Is it good or bad? Do you like Lean manufacturing?
I don't see any examples in your article that provide glue why agile is bad. I see only general trend that agile is bad. Period. Why it is bad? Why iterative development is bad?
>>>By the way, the productivity rates of software developers is abysmal when compared to other industries (contributions to gross output).
I am open for solutions. I am really interested in them and it would be very exciting to compare your solutions to agile development solutions of common software development problems. Are there any articles you've wrote about that? I bet you have some :)
Argile is a hoax. Everybody knows that.
Regarding constructing houses using Agile values and principles, you really need to read http://www.agileadvice.com/archives/2006/06/interview_with.html
"The best in class companies those with the highest productivity and quality levels are not using Agile."
How do you explain PatientKeeper, then?
Is that what passes for academic criticism nowadays? Completely misrepresent your opponent, offer some pale metaphor, and then insist it must be true because you have "a lot of experience" and have presented papers at unviersities (sic).
Where's the real world experience? Where are the facts? I see wild claims such as "organizations that spend the least time in codings" have the highest productivity levels.
I make no apologies for the "Agile" crowd that uses it as an excuse to not do design, documentation, or any form of requirements analysis. But painting the entire community attempting to do IID with the same brush is simply ignorant.
What I propose is simple. I want software to become a professional organization like other disciplines. Here are a couple of really "dangerous ideas," but they will help your quality and productivity.
1. Software developers, and Agile, need to learn the business they support. They need to become specialist like is seen in the field of architecture, medicine or law. Specialization -- now, that is a dangerous idea. I have not seen this idea promoted in Agile Propaganda.
2. Software developers, and Agile, need to standardize their vocabulary and stop mixing terms in documentation. Often you see them mix get, find, retrieve, fetch, so on and so forth. Look at the difference in a blueprint diagram and a software specification. I have not seen this idea promoted in Agile Propaganda.
You can do this two simple things before you adopt another methodology.
I use propaganda on purpose since one of the most popular websites for Agile is the Agile Manifesto. I thought the term propaganda would make all you Agile folks feel comfortable.
David Longstreet
Software Economist
www.SoftwareMetrics.Com
Hi all,
The author of the paper, Mr. Longstreet has managed to leave me gasping for air -- laughing.
His utter and complete lack of understanding of what agile software development practices is beyond my comprehension.
Mr Longstreet fails to grasp the concepts of cost and value (the irony, given his self proclaimed title of 'software economist').
Developing good, high quality software, is indeed possible with waterfall. The cost, however, is lower if the software is developed in an agile method. I.e., to achieve the same quality with a waterfall method is significantly more expensive than in the case of an agile method.
Producing documents, for example, is not shunned by agilists. An agile practitioner would ask for the purpose of the document and whether it worth the cost (see, that word again). Is the value in the document higher than the value in something else that the developer may be doing with their time? Assuming the document is needed, then when is the right time to write the document? At the start? At the End?
The basis for all agile methods -- either consciously or not -- are Lean and Demming's work (see http://www.netobjectives.com/why-use-us/lean-philosophy) as well as an understanding of the inefficiencies and wants of communications between humans.
Oh, lean, incidentally, is about increasing profitability through the relentless pursuit and elimination of all forms of waste.
You say, Mr Longstreet, that you have DATA. OK, lets see it. I would love to see how you've conjured up that agile methods don't work.
Agile projects do fail at times. But they usually fail not because of the fact they were agile, but because they were not really agile. They did not follow the agile practices with enough discipline and especially did not adhere to the cardinal law of agile development: study the process and improve what can be improved.
I especially indebted to the Semmelweis reference.
Ignaz Philipp Semmelweis The mothers' savior gained his fame by trying, and failing, to get the doctors in the First Obstetrical Clinic at the Vienna General Hospital to wash up before treating women in obstetrical clinics.
You, Mr Longstreet are not the Semmelweis of our story. You are one of his adversaries.
I reckon that the reason you go to such lengths to defame agility is not because you understand it or its supposed dangers. To the contrary. you do so because you do NOT understand it. The reality is that you are terrified of it because it undermines whatever credibility you have been able to build in your professional career, putting your glorious consulting practice at risk. So, you resort to what people in your position do -- you sling mud.
Go on trying to balance the four humors for your clients, Mr Longstreet, hopefully you'll retire before you kill them all...
On the bright side, you have managed to reaffirm the old saying that ignorance is bliss...
I can't tell if Longstreet is serious and ignorant, or deliberately stirring up controversy to puff up his resume and attract attention to his consulting practice.
The paper is so poorly-written and riddled with grammatical mistakes that I have a hard time believing it was written by someone who makes a living as a consultant.
Analogies can be useful to illustrate a point, but you can't base your whole argument on analogies. Removing the considerable amount of self-promotion, Longstreet's arguments distill down to:
1. Agile doesn't work because it's just more of the same, another way of developing software with no process at all.
2. Architects, interior designers, builders, etc. don't work without plans, so how can programmers expect to build anything without making a plan first?
The rest is just repeating the same unsupported opinions over and over and over. I skipped to the end to see what the solution to the agile quagmire might be but there isn't any fix offered. I guess we should just give up.
I do appreciate the little ironies. For example:
A composer does not decide to develop his own vocabulary or develop their own symbols. Individuals are trained to write music and they are trained to read music. It takes years to learn to be able to site read music.
That isn't really true -- there are quite a few different ways to write music and composers do invent their own vocabularies and notations. And it doesn't take years to learn to sight read music, at least not for most people.
Within a single IT organization they do
not accepted terminology or symbols for their documentation, so I would encourage you
to develop your own glossary of terminology and symbols.
Huh? I think that's an analogy mixed up with... something else.
A little more than halfway through the tediously long article Mr. Longstreet adds this:
The book, Handbook For Technical Writing, I used over 20 years ago when I was an undergraduate student at Texas A&M University reads, “Concise writing provides exactly what the reader needs and not a bit more or less. Bloated writing with superfluous information serves to confuse and obscure.”
Or as Strunk and White put it, "Omit needless words." It's too bad Mr. Longstreet didn't refer to that Handbook while preparing his article; if he had followed the writing advice the article would be a single page and therefore contain far fewer errors in usage and grammar that only cast doubt on the author's credentials.
I read through paragraphs of pointless descriptions of how composers write music and how librarians catalog books, all in support of Mr. Longstreet's belief that agile development means no written documentation is produced. A composer's final output is music, written on paper for other musicians to read. The final output of a software team is not a pile of documentation to catalog -- it's the code. Even if an agile team doesn't produce any documentation at all (which I've never seen advocated or practiced), the team will still produce code that serves the same purpose as the sheet music Mr. Longstreet describes.
Mr. Longstreet's understanding of statistics and probability is questionable: Perhaps it is the statistician in me, but I do not believe anything is random. Nothing occurs by random and nothing occurs by chance. The results at a casino are very very predictable.
The long-term outcomes of most casino games give the casino an edge (of course), but individual short-term outcomes (a spin of a roulette wheel) are determined by random chance. Mr. Longstreet seems to be arguing that the "law of averages" means nothing happens randomly, which is a gross misunderstanding of both concepts.
Mr. Longstreet concludes with an anecdote: I was walking in a parking lot and walk to close an automobile. I hear the words from
under the hood, “please step away from the car.” I was a bit surprised, so I to a few steps
back. I thought about this and I stepped close to the car. Again the words from under the
hood, “please step away from the car.” I wish there was a voice that could radiate from
software projects that would say, “please step away from the code.” More software
developers need to step back away from the code, lift their heads look around at their
customer.
I think he means he walked too close to an automobile, but after 12 not-too-concise pages of badly written and poorly-reasoned fluff I'm getting too tired to make the mental corrections, so I had re-read the paragraph a few times.
Once I got it deciphered I found I actually agreed with Mr. Longstreet on at least one point: software developers should get their heads out of the code and pay more attention to their customer and the application domain. In fact that is probably the single most important innovation of agile methodologies -- putting the developers in direct contact with their customers and making developers understand what business or customer problems they are trying to solve. It turns out that at least in this regard agile proponents figured things out before Mr. Longstreet did.
Hi, at least it's more constructive than the wisdom shared on my blog; "Agile is a hoax!"...
http://kw-agiledevelopment.blogspot.com/2007/06/agile-is-hoax-does-that-make-me-alien.html
Kelly Waters
http://www.allaboutagile.com
This Mr Longstreet guy seems to be a bit of a joke. He seems to have far more experience in what every other industry does, and almost none in his chosen one.
We've just started to adopt an XP agile process, and while it's not all plain sailing and not even 100% implemented yet, the benefits to the customer are already being seen. That is the only data you really care about as a software development company .. how happy/satisfied are your customers.
Almost everything in software development boils down to this simple statement.. the usual metrics: timescales, bugs, cost, performance, features, reliability, availability. They all boil down simply to "how happy the customer(s) is" with each of the particular metrics, with each affecting customers satisfation by their own factor.
And in that respect, there is nothing comparable in waterfall methodologies that allows you to determine this "happiness" metric, as quickly as in an agile methodology. You only get a perceived satisfaction (requirements captured), with a long gap until ACTUAL customer satisfaction can be realised (after tedious bouts of development, release, testing, maintenance of the whole end product). This goes for each of the above "metrics".
Maybe the only factor I can't put in that list of objectives is code maintainability, and that is something that agile processes generally put after meeting all the customer satisfaction objectives, through code refactoring.
I'd love to know how much money would be saved in these massive public sector spending frenzies, that are so often heard about, if the outsourcing companies put out smaller iterations meeting the customer satisfaction objectives first, and internal ones after (like refactoring, documentation and non-standard jargon as Mr Longstreet puts it - Agile proposes that user requirements are captured in the customers own language, not confusing technology jargon.) It normally appears to me that most of this money gets wasted on going crazy with upfront design down to a very fine granularity, over documentation, meaningless client meetings filled with jargon, and later finding that the upfront design of the whole system doesn't meet the required metrics, so starts the massive test/bug fix/maintenance process.
I'm also a bit concerned about this guys lack of knowledge about patterns and practices used in development. Most proponents of Agile (notably Martin Fowler) push the use of patterns as standards of implementing certains interactions and processes in a system. This IS directly comparable to what happens in other industries .. and is in essence our standard way of implementing the same things across different platforms and technologies.. In constuction, a doorway is simply a technical implementation of a pattern for allow inbound/outbound access. An opening window also follows this pattern. An architect is not always responsible for implementing down to the actual implementation of door used or the bolts used to hold a building together. This is in the same way that a software architect should not be responsible for the actual code used to implement a particular pattern or feature of a system, only that it meets thir requirements. This IS and should be outside of their scope of repsonsibility, so long as their requirements are met.
Agile is most often adopted by those teams where Waterfall HAS been tried (under it's many guises) and ultimately been unsuccessful as far as customer satisfaction has been concerned, and has led to adopting Agile as a successor. If I found my "diet pills" weren't working, then YES I'd look to start to look at alternatives of achieving the same end result, like doing some exercise regularly and measuring benefits regularly.
This analogy is actually quite good, in demonstrating the benefits of Agile processes: of weighing yourself each week to measure results, as opposed to taking a full 6 months supply of pills, then weighing yourself and finding no mesurable benefit has been achieved, and having to start on a different process i.e. Waterfall!!. Your kidding yourself believing the bulls##t on the packet, until you can regularly measure and see the benefits.
The root cause of not being able to define requirements is not knowing the business. Since many in software development do not specialize (like attorneys, doctors, architects), they do not understand the customer. Developers need to specialize along industry lines.
Most organizations do not know what they are capable of delivering per unit of time, so they over build requirements in hopes of solving the customers problem.
Waterfall development is the natural result of specialization. Specialization causes a waterfall development methodology. Since software developers do not specialize in task or along industry lines, waterfall cannot be successfully implemented.
Agile encourages developers to become craftsmen (focus on the code) instead of professionals planning and specification.
David Longstreet
www.SoftwareMetrics.Com/Agile
I have expanded my original article about 8 pages (it is 20 pages now). I have addressed some points and comments made and expanded on some of my original thoughts.
For those interested in reading a revised version visit
www.SoftwareMetrics.Com/Agile
There has been some strong criticism of me and background. For those who want to decide whether or not I am a credibly person in the field of software development, then please review my clients list and read my bio.
www.SoftwareMetrics.Com/client.htm
David Longstreet
Software Economist
www.SoftwareMetrics.Com
Regarding the quote you reference: "In fact, would you turn over 200-300 thousand dollars to have your home constructed using the same principles advocated by Agile or Xetreme programming. The answer of course is no."
Actually, the answer is Of Course Yes.
I simply don't trust them to get it right the first time, nor to understand my needs the first time. I have been using agile principles to hire remodeling for my house for the last several years, and it has saved me enormous pain and money.
The point is, people throw this phrase about construction around, but what they really need to learn is how construction can use agile techniques.
Alistair Cockburn
For obvious reasons I prefer to remain anonymous - but as a Consultant and external auditor for many years, I have to say that Agile has been the best thing to ever happen to me.
Agile has generated so much business for me. Most of my clients are large companies which outsourced their IT projects to failing Agile development companies, had their budgets burned and came to me to assist them out of the mess that they had been driven in too.
I have yet to see an agile project successfully delivered in the past 7 years (by success, I mean on time, on budget and 'fit for purpose' / meeting the original requirements specified in the RFP). And I strongly doubt that this will change over the next 7 years...
It is really hard to say what is best, in software industry there has been so many waves of new ideas and trends, from my experience I can say that Agile does deliver the product, but the product is kind of disposable, didn't work, didn't delivered what was expected, throw away, do it again, rebuild, refactor, re... well, that might work in some cases, but I bet medical, aerospace, military, financial, industrial control, SCADA systems and so on, wouldn't go the way of try/catch...try again. And as once said, 'There's no silver bullet'
David,
Agile done bad is bad, Waterfall done bad is bad mmkay. Lets face it anything done bad is bad.
The biggest problem with agile IMHO is that many people who claim to be doing it, aren't. I think this is a serious challenge for the agile community.
But to then criticise the methodology for the outcomes of people who arent even using it is just bizarre.
Longstreet:
"The root cause of not being able to define requirements is not knowing the business. Since many in software development do not specialize (like attorneys, doctors, architects), they do not understand the customer. Developers need to specialize along industry lines.
...
Waterfall development is the natural result of specialization. Specialization causes a waterfall development methodology. Since software developers do not specialize in task or along industry lines, waterfall cannot be successfully implemented."
You lost the thread in your argument. Specialization in industry knowledge is not the same as specialization within software development tasks.
This is only one criticism of your work to discredit Agile. Even if Agile was ineffective and Waterfall was the only way to do it right, your arguments don't prove it.
Could you at least find another writer who has skills enough to explain how Agile does not work - then quote it?
I'm a technical writer and have worked in several agile and traditional environments. In the five agile environments I've worked in, only one was capable of bringing products to market.
The six developers were actually senior and they had actual product plans and roadmaps. Agile, in my humble opinion generally appeals to peoples' vanities. Who doesn't think of themselves as senior? What firm doesn't think of itself as agile?
As a tech writer, I see when projects start to get unhealthy (usually because the documentation never gets beyond a "demo" length as no-one is able or interested in integrating their work queues into a coherent product) and agile has facilitated unhealthy projects.
Don't worry. The downturn will allow you to change acronyms, retread the concepts and sell another set of processes.
I think it's natural for lazy people to jump to some 'new solution' and become half-hearted advocates of it - while it's still generally misunderstood - in order to avoid work. I see it all the time in other areas.
It sounds like you were working with undisciplined teams, that did not follow any process.
It's my understanding that all agile methods are disciplined processes, only that they organize tasks differently than waterfall does.
I know a team that claimed to be using agile methods - but was not. They used a bug-tracking system to capture requests, then used the workflow to move the request through all the steps towards acceptance. But, there is no agile method like this.
The team I mentioned did not have a vision (roadmap), there was no release plan, they did not timebox iterations, testing did not happen first or concurrent with development, etc.
I have read about lots of different methods, and all include the above attributes.
As I said before, there are many examples of lazy people 'jumping on a bandwagon' without taking the time to learn what they are joining, mastering the fundamentals, etc. I think software development - regardless of the method - is no different.
Have you been on a waterfall team that did not use the system properly, so they failed to meet the goals?
Post a Comment
<< Home