Sep 23 2009

Thinking Of Agile - XP Please Read This first

Posted by Mike Brunt at 2:31 PM
57 comments - Categories: .NET | CloudComputing | ColdFusion | JRun-J2EE

This is a verbatim email from the Guerrilla Capacity Planning mail list. I am posting this here because it states my reservations very well and I advise any thinking of Agile or XP or frustrated with the results of either to read this.

" I was at a company that still embraced the agile software model. I have a negative impression of agile development for a number of reasons.

1. Agile programming emphasizes programming over engineering. This results in software that does not have clean interfaces and is intertwined with other code. Of course, such code is difficult to maintain, debug, and replace. Expensive code bloat is the consequence.

2. Agile programming emphasizes coding. The more code that a programmer produces, the more productive he/she is. This emphasis on production introduces unnecessary bugs. Studies show that for every 100 lines of code written by a good programmer, 2.7 to 3.2 bugs are introduced. Many of these are edge cases and not detectable by testing. The more code that is written, the more bugs that programmers introduce unless they perform comprehensive function and unit testing; unfortunately, this is a skill that is rarely taught. The consequences are bizarre intermittent failures, Heissenbugs, and unpredictable interactions and other undesirable side-effects.

3. Agile programming is inappropriate for product development where companies will live with an architecture for a long time. It's better to engineer an architecture and design clean interfaces than to crank out code that will soon become problematic. The agile model may be appropriate for making incremental changes to mature software products.

4. Agile programming deemphasizes designing performance into products. After all, the packages and libraries can be replaced in the future. The problem is that the future never comes unless there is a crisis.

5. Agile programming never views a program or project as complete. There's always room to tinker and add new levels of abstraction and modify the mechanics of a program. Expenses around programming become a sucking black hole.

6. Agile programming is a model that rewards software churn. It's a great model for building fiefdoms in a corporation and employ busy programmers; it's terrible for corporations who want to produce maintainable stable quality products that will not incur high
overheads.

7. Agile programming deemphasizes quality. Deploying software that works after a fashion "rather than waiting for perfection" introduces a dangerous slippery slope. I doubt that many managers can define "acceptable imperfection." Quality should be job one. Apple demonstrates that customers will pay a premium for well designed and implemented software.

8. Agile programming over emphasizes schedules. Production schedules and engineering requirements should be balanced by management.

9. When there are many projects to add asssorted features to a product, code become difficult to manage. Code merges and inconsistencies become difficult to manage so all the pieces play together. Merging code down can take several days given high rates of code churn. Costs associated with code management are not linear as the number of projects increase. I suspect that the cost function is exponential.

10. Agile programming uses customers as the test bed. Customers don't appreciate being treated as guinea pigs.

11. The agile programming model creates an unstable expensive house of cards. The house of cards will eventually collapse despite efforts to keep it standing."

Comments

Bob Hartman wrote on 09/23/09 3:29 PM

I'm stunned at how strongly I disagree with all 11 points. If this is how agile was implemented at a company I wouldn't call it agile at all. In my courses I state what agile is in two ways:

1. Deliver the highest value software with high quality as quickly as possible.

2. Deliver high value quickly now and deliver high value FASTER in the future.

Taken together a lot of these 11 issues go away. For example, issues 1 and 2 go away because the focus is on HIGH VALUE and HIGH QUALITY, not programming or coding. Issues 3 and 4 go away because we have to be able to deliver faster in the future which means we have to have an architecture which can be easily modified for future needs and yet be stable. You can go down the rest of the list and see how they compare to my two statements above. I see that every single one of them is debunked by the two statements, but maybe it is just me.

Agile has a bad name in some places based on some poor results. I'm ok with that. Quite frankly some people should not be agile trainers or coaches. The bad taste from those engagements stick with people for a long time. My courses and coaching (and those of a lot of others I know) concentrate on the real driving principles so statements like these 11 aren't even possible.

Hmm, now that I think about it I might have to take these 11 statements and work them into course exercises just so course attendees recognize how wrong they are! Thanks!!!

-Bob -

Elisabeth Hendrickson wrote on 09/23/09 3:46 PM

Whatever the company that "embraced the agile software model" is doing, it's not agile, nor is it Agile.

Agile teams deliver a continuous stream of potentially shippable product increments at a sustainable pace while adapting to the changing needs of the business.

They're clearly not doing that. My bet is that they're also not doing any of the Agile engineering practices (from XP): TDD, Continuous Integration, Collective Code Ownership, automated regression testing, etc.

In short, if this email truly described Agile I would share your concerns. Fortunately, it's another instance of someone in an organization exalting the buzzword "Agile" over the substance of the practices.

Brian Panulla wrote on 09/23/09 3:59 PM

With all due respect, my experiences almost complete contradict yours. I think you either 1) have had a *very* bad sample of Agile development and/or 2) have control issues. And I have to admit it was a struggle to read beyond point 2 because you'd by that point lost me.

Agile does not equate to "no design" or "bad design". It's an iterative approach that tries not to get bogged down on OVER engineering systems. The goal is to build robust systems, not optimal ones, right out of the gate. If you're not doing *any* design up front, of course you're going to have a disaster.

And any organization that calls themselves "Agile" and does not have good Unit Testing discipline is in for a world of pain. After instituting a reproducible build process and version control, developing good Unit Testing habits should be your top priority. These three practices (and maybe a good bug tracker), if followed, will keep you from backsliding into chaos. Which is apparently where you spent your time.

But one thing that I sense in your writing is that you never had time to get to the things you left for "later". That sounds to me like a problem with management. If you take on too much work, and everything is "top priority" of course you're not going to be able to iterate enough to get something useful out of your development cycles.

Justin Freitag wrote on 09/23/09 4:01 PM

I won't spend much time commenting on this one, however if you're walking away from a company that "practices" agile in such a fashion, it's good that you left so that you can experience a real agile project! Every point you've made is anti-agile...

Mike Brunt wrote on 09/23/09 4:22 PM

@Justin, @Brian, @Elizabeth, @Bob, thanks you very much for your comments. I did not write this but I agree with it. I have been in the software business for 16 years, before that I was a business manager at various levels. In the past 10 years I have seen thousands of applications in 100's of companies, I state these things simply as an illustration of why I have these feelings. The problem with Agile and many predecessors is that it is not a magic wand nor a panacea. If processes, organization are bad because of indemic problems they will remain bad after the adoption of Agile practices etc, I can tell you, I have seen it. On the other hand I have seen incredible teams create marvelous results without the use of Agile-XP. Agile will come and go as others before it, I am convinced of that.

Mike Brunt wrote on 09/23/09 4:23 PM

@Justin sorry to leave your name of my response and thanks for taking the time to comment.

J.R. Garcia wrote on 09/23/09 4:41 PM

I don't think you read their comments properly. You stated, "If processes, organization are bad because of indemic problems they will remain bad after the adoption of Agile practices etc, I can tell you, I have seen it." If your "seen it" are those 11 things you mentioned above, then you didn't see Agile or XP. You saw bad practices being called Agile or XP. The things that you mentioned don't reflect Agile or XP in any way.

It's kind of like someone showing you a beat-up, decade-old, dying Ford Taurus and saying it's a new Lamborghini and then having you say Lamborghinis suck. It doesn't really work that way.

Ben Fulton wrote on 09/23/09 4:44 PM

Amazing! Couldn't disagree more.

Elisabeth Hendrickson wrote on 09/23/09 4:45 PM

Hi Mike - Just so you know I'm not some noob infatuated with Shiny! New! Methodologies! - I wrote my first line of code in 1980, had my first paying sw gig in 1984, and have also seen hundreds of projects.

While not every Agile project I've seen has been a success, I can testify that in the 5+ years that I've been working with Agile teams, I've seen a whole lot more successes than in the whole previous 20 years combined.

Agile works. It's not marketing hype. But it only works when the organizations adopting Agile go beyond the buzzword to understand the practices and *why* they work.

Ben Scheirman wrote on 09/23/09 4:48 PM

All eleven points are deeply flawed. I wouldn't want to work in an environment like that either.

Your doing yourself and the community a disservice when you equate those traits with tht of an agile project.

Mathias wrote on 09/23/09 4:53 PM

Score +1 for originality! This is really an odd post. Every methodology has its limits and its critics, and Agile has become a bit too much of a buzzword lately, with the usual problems around that, but I don't see any intersection between your list and common criticisms of Agile.
Out of curiosity, what methodology/process do you advocate?

Mike Brunt wrote on 09/23/09 5:19 PM

@Ben, @Ben, @Elizabeth, @Mathias thank you for commenting and I am not suggesting anyone here is new, although there is nothing wrong with that either. My main point is this, Agile is not going to solve endemic issues if they exist, just as frameworks do not magically correct bad coding. Are you all saying that Agile is something incredibly special that is totally different from anything similar that preceded it and it will endure for ever because I am saying it is not and will not.

Bob Hartman wrote on 09/23/09 6:12 PM

@Mike, I too have seen all 11 of these items, but they didn't happen in an agile shop. They happened because people did not know to do it any differently. Agile tries to stop all 11 of these items by taking an approach centered around delivering value and working collaboratively with customers to deliver the best possible results. Then learning from that and improving next time.

I believe agile will be around forever, but not in it's current form. Part of the beauty of agile is the practices can (and should!) change as we learn things which are better.

Has the waterfall methodology not changed over time? Just look at the multiple revisions of the PMBOK for an answer. Of course it has been improved over time. Agile will be similar.

I do agree with one of your statements - it is not a silver bullet. Most good trainers say that up front. If it were everyone would be doing it and be successful. That is not the case and never will be the case. However, studies do show a significantly higher percentage of agile projects completing successfully compared to any other methodology.

I believe you have seen issues with implementations which called themselves agile. I also believe they were not at all agile compared to any reasonable definition of agile.

Finally, your statement that "Agile is not going to solve endemic issues if they exist" may be true, but staying the same won't solve them either!

Stefan Moser wrote on 09/23/09 6:25 PM

@Mike I didn't read any of the comments to mean that agile is a silver bullet that will magically produce good software out of bad organizations. The point is that most teams will produce better software with an agile methodology than without. The points in the email do not correspond with the values in the agile manifesto, so I fail to see the point of the email other than to say that bad teams produce bad software.

Jeff Langr wrote on 09/23/09 7:09 PM

Greetings Mike--

One of the most interesting posts I've read in a while, if only because my notion of what agile should be is in opposition to almost every point stated here. Sounds like a really bad experience, and sadly I'm not surprised--the bulk of teams doing agile take the Oprah magazine route (read one cheesy article, mis-interpret however you feel, and call it agile).

At its core, agile is simple: build software incrementally, get it to the market sooner, get feedback, adapt (i.e. figure out how to do the next chunk better). There are of course trade-offs in taking an incremental approach; the biggest risk would seem to be quality as it relates to incrementally growing a design (as you suggest). But quality is essential to such an incremental process. Agile builds on ideas from things like TPS (which in turn builds on Deming), things that insist on high level of quality in order to work well. (And yet, despite your contention that they are guinea pigs, customers would much rather have working software sooner than perfect software much later.)

So, there are ways to approach incremental/iterative development with high quality. They require high levels of attentiveness to design, far more than the typical non-agile team. In the shops I've seen that know how to do agile well (they exist), the team produces around 1/2 as much code as in other teams.

I can attest to real examples that refute your claim, shops where the software does exactly what the marketing department asked for, has been up for a year with no downtime and less than a dozen bugs. And the reason is not just having assembled a great team, it's a good team that learned how to use a process to its advantage. It can work, but you're right, in most places it's corrupted beyond the point where it can work.

Mike Brunt wrote on 09/23/09 9:42 PM

@Jeff you hit the nail right on the head I am not saying Agile or any other methodology is wrong just that it will not cure the biggest problems that we face if those problems relate to misconceptions and unrealistic expectations. There is a central debilitating issue which still causes high rates of failure in software projects, it is a lack of adherence to all application life-cycle good practices, testing, testing and testing. Functionality, performance, scalability etc.

Mike Brunt wrote on 09/23/09 9:48 PM

@Bob and @Stephan, far too many software projects fail, I personally know of a shop there were badly managed so brought in an expert on Agile techniques now they are badly managed in an Agile way. The problem is still there. And I hope your beliefs that Agile will always be around have merit because if Agile methodologies are what you believe they they will stay around because they help to get us out of the mess of continually failing software.

Ian Cooper wrote on 09/24/09 12:35 AM

Unfortunately none of what you describe is agile. I suspect you have been told it is agile by the companies involved. Unfortunately that is just disguising a lack of process under the agile brand. It happens a lot. It has done a lot of damage to agile, but it is not agile.

Scrum is somewhat to blame for this, because it only covered the project management aspects of agile, and not the engineering aspects. Folks need to look to Crystal or XP for those

Good agile methodoligies are high discipline with strong engineering processes.

They have an emphasis on design and architecture - although they defer it to the last responsible moment.

They have a a high emphasis on quality with a mandate for automated testing and continuous integration.

They ensure only needed code is written, because they focus on delivering to acceptace criteria authored by the customer, through ATDD or BDD approaches.

They enculture regula code reviews, sometimes using techniques like pair programming.

I have used agile for a number of years to produce long-lived, well-maintained software, regularly in response to failed waterfall project approaches.

Yes I am still using agile, and its because I have a commitment to quality.

Mark wrote on 09/24/09 2:07 AM

I'm very surprised by points 1 and 2 as agile is about avoiding over engineering and only building what's needed.

Also I don't agree that it emphasises coding, it does emphasis frequent refactoring and reviewing which is a good thing on any architecture that you intend to live with for a long time.

I think many the problems described relate to the fact many companies say they're agile as a form of buzzword bingo. In truth there a lot who don't know what it means or how to make it work.

Ultimately agile companies need agile developers to implement it, and that does rely on education. For me it was the excellent book Agile Principles, Patterns, and Practices in C# (Robert C. Martin) that made me think more about how I develop, and I don't think you need to be in an agile environment to benefit from the advice it contains.

http://www.amazon.co.uk/Principles-Patterns-Practices-Robert-Martin/dp/0131857258

Mike Brunt wrote on 09/24/09 6:06 AM

@ Mark and Ian, I appreciate your's and everyone else's inputs here and as I think I stated several times my main point is no methodology can fully mend endemic deficiencies in procedures and they exist all around us. The "failure" rate in software development is still unacceptably high and really getting things right is not that difficult. Once again, I have seen companies turn to methodologies like Agile in the belief that it will magically fix things when a lack of methodology is not the issue at all. Look at the final paragraph in the comment by @Jeff above.

Mark Kruger wrote on 09/24/09 7:23 AM

Mike,

Next time just stick you head in a hornet's nest and get it over with (ha).

I tend to agree with your point (the one you have been trying to make... not the one everyone here seems to think you are making). Here's my 2 bit expansion of it.

I think most methodologies are caught between their "pure" form and whatever companies make of of it. I can think of a number of good of methodologies where I've never (never ever) seen an "pure" implementation. The rules are virtually always broken.

So one of the things that makes a methodology a good methodology is how "adaptable" it is to the nuances of business curture, team dynamics, and even personal esteem.

When methodologies are attacked or criticized you can usually tell how adaptable they are (and therefore how much staying power they have) by how vehemently their adherants insist on orthodox implementations. For example by saying "Your version of X isn't really pure X and if you were 'really' doing X you would get a different result" (Wher X is your favorite methodology, framework, design pattern or whatever).

(I always enjoy reading your stuff Mike - as you would say "bloody marvelous")

Mike Brunt wrote on 09/24/09 8:03 AM

@Mark thank you for taking the time to comment and I agree with you re "pure, purist" etc. The closest thing I ever found to a development lifecycle methodology that could work was the Flip process, which came out of the FuseBox initiative. In those days, incidentally, wireframes were wireframes, clickable site models with no graphics, wireframes should not have graphics, otherwise they are prototypes. Oh no another controversy erupts ;o)

Russ wrote on 09/24/09 8:26 AM

Milke you don't actually seem to be taking note of what the responders are saying to you, which are all valid points rather you seem to be sticking your fingers in your ears and going "lalalalla Agile is crap because I say so and I am not listening and I will just keep asserting myself". The commenters have not actually had a go at you or blasted you in any way, in fact they have not even disputed your opinions they in fact been very polite and all of them have pointed out that the negative points you have made would only result within an organisation who do not know how to implement Agile\XP and have have simply done a total bodge job which is not in fact Agile or XP at all. In fact no-one has said or implied that Agile is a silver bullet either, you seem to have just plucked that one out of the air.

The problems and issues you have quoted could exist anywhere regardless of any methodology, it is simply down to bad management, bad practices and poor planning and is really not anything to do with Agile. No framework or methology is a silver bullet if it is not properly implemented, but if it is implemented properly and correctly managed then it can resolve an existing problem.

You said "my main point is no methodology can fully mend endemic deficiencies in procedures and they exist all around us", however this is clearly not the point that your article is making, so if this is the point you want to get across then perhaps you need to rewrite your article and make if=t generic as it currently is simply an Anti-Agile bash.

Interesting wrote on 09/24/09 10:13 AM

One thing I will say from having worked with various Agile / non-Agile teams is that there is a certain self-selection that can happen with the teams who choose Agile.

To be clear, it's definitely not Agile's fault (I have no problems with the methodology), but I have seen a pattern of teams that are performing poorly adopting Agile, in lieu of solving their performance problems (which are largely due to poor leadership, or guys who just aren't 'A' players). This substitution of process for leadership is almost always fatal, and leads to things like endless "hardening sprints".

I guess, in my experience, poor leaders are more likely to develop an unhealthy affection for process, as it provides some obfuscation of the real issues going on in the team. Again, this doesn't mean that the process is bad, just that it can be a magnet for people who can't lead.

Mike Brunt wrote on 09/24/09 10:24 AM

@Russ I am refraining myself from being more strident in my response to your somewhat rude assertions, I will thank you for taking the time to comment in such a quantitative way. Firstly, I did not write the article, as I state, I am posting it verbatim. However I agree with the thrust of it and I admit to being anti-hype and unfashionable. The proof of the pudding is in the eating. Time will tell if Agile is as valuable to successful software application development and lifecycle as many here attest, I hope it is but am far from convinced. We can agonize and finger point to the enth degree, nevertheless time will tell.

Mike Brunt wrote on 09/24/09 10:26 AM

@Interesting you are stating so accurately what I am trying to say

"I guess, in my experience, poor leaders are more likely to develop an unhealthy affection for process, as it provides some obfuscation of the real issues going on in the team. Again, this doesn't mean that the process is bad, just that it can be a magnet for people who can't lead."

Very, very well said and exactly my point.

J.R. Garcia wrote on 09/24/09 11:46 AM

Mike,

I don't think anyone is disagreeing with your comments. We are all in agreement that all methodologies will have flaws if you don't fix management, practices and planning. The problem is that your article is saying that Agile/XP is bad. It doesn't say that methodologies won't work. It says Agile/XP in particular won't work.

Now before you say that you copied this article verbatim, your comment before hand is, "I am posting this here because it states my reservations very well and I advise any thinking of Agile or XP or frustrated with the results of either to read this." Also, your post is titled: "Thinking Of Agile - XP Please Read This first".

What we are saying is that you never said anywhere in this post or in your title that methodologies will not fix problems. You said, Agile/XP will not.

If someone is doing Waterfall or Flip or whatever and they are looking at Agile/XP and reading this, they are going to say, "That's a waste, it doesn't work." That's not what they should be saying. They should be saying, "Oh, so our methodology isn't where the problem is. Our problem has a better chance with being in management, practice, skills, planning, strategies, etc."

Mike Brunt wrote on 09/24/09 2:23 PM

@J R Garcia, I fully agree with you here and perhaps I should have been more explanatory in my pre-amble. I feel a genuine level of frustration as we should not as an industry or a sector be turning out so much poorly performing or non-functional software, the failure rates are still far too high and I have seen shops employ Agile and other methodologies to no avail, in the sense that no improvements ensue. The real issue is that we should not be turning out so much shoddy product and I suspect that the people here who say they got great results with Agile would get great results with other things too.

Daniel Sobral wrote on 09/25/09 4:46 AM

While points 7, 9, 10 and 11 and flat-out incorrect, the other points are well-taken, even if expressed in a derogative manner.

So, I'll post a conclusion to the other points:

Non-agile methods are only useful to companies who have flexible, lazy schedules, whose systems can be designed from a well-defined set of requirements which will never change, and then continue to use those systems as originally planned for years.

So, except for those incorrect items, I guess I generally agree with the points.

Mike Brunt wrote on 09/25/09 6:35 AM

@Daniel thanks for taking time to comment and leave your thoughts here. I feel my preamble was sorely lacking and rather than trying to expand it here I am going to create a second post to add some better context.

Neil Middleton wrote on 09/25/09 8:25 AM

I guess at the end of the day, whether or not you like Agile depends on whether you want to get stuff out the door or not.

Personally, engineering and discussing architectures etc detract from shipping, which is why, ultimately, you're there.

If you've got developers who can't build decent code in an Agile form - you've got crappy developers, or are using crappy tools.

Mike Brunt wrote on 09/25/09 9:19 AM

@Neil, I agree with that fully and I happen to think or perhaps know that developers do not want to release shoddy products so it is not necessarily developers who need an unending parade of methodologies but supervisors/managers who need to get more professional in my opinion.

Igor Macaubas wrote on 09/25/09 10:35 AM

Mike, I'm sorry. You just don't know what you're talking about. I suggest you to begin from the beginning, by reading and UNDERSTANDING the agile manifesto. You suck, and that makes me sad. Sorry, you're wrong, just plain wrong.

Mike Brunt wrote on 09/25/09 10:42 AM

@Igor, thank you for taking the time to comment here. Like the old saying goes, "sticks and stones etc" it really demeans human beings to resort to insulting terms. You have absolutely no right to tell any one they do not know what they are talking about, unless you can prove 100% that they really do not know. I respectfully suggest you read all of what the link in my subsequent blog post points to.

http://www.cfwhisperer.com/post.cfm/an-agile-xp-debate-the-whole-story

Igor Macaubas wrote on 09/25/09 2:25 PM

Hi Mike! It's good to know how you felt when you saw my comment. I insulted you, and I'm sorry for that, but now that you're in my shoes, I can make a point: That's exactly how I felt when I first read your post. You basically said that Agile is wrong and doesn't work, not that YOU, in YOUR work experience, saw many failures in many agile implementations, and the 11 points you enumerated referred solely to your very own experience. You basically insulted me, my team and my whole company who uses agile in a very, very different way, by generalizing your experience. I'm sorry, but again, you can't do that - it's just wrong. That's not the way that I and many people I know, practices agile development. Please, please please please, be careful when you try to generalize your experience. You might just had a bad one. One last thing, about the "insult", many people will take this as a joke, because I just paraphrased a cartoon made by Mike Vizdos, that is widely know in the scrum community. You can see it here: http://tinyurl.com/bksbrb

Igor Macaubas wrote on 09/25/09 2:45 PM

Oh, and one last thing: It's very, very easy to blame a methodology. The methodology just can't argue back. Have you ever tough that the _people_ you were working with were just reckless about their jobs? Were these people embracing agile or just doing it because management said so? Or was it the other way around? Was the people fighting with management, and management was doing everything they could to sabotage this "agile thing"? This all has to be taken into account. You just can't say that agile doesn't work, as I can't say that the project management guidelines published by the PMI doesn't work. They do work, but a methodology alone will not produce good products. I read the thread you pointed, and I can't see many agreements. Most people are disagreeing with the guy who originated the email.

Igor Macaubas wrote on 09/25/09 2:56 PM

Another thing: Agile won't solve your problems, as no other methodology will solve your problems. YOU have to solve your problems. Agile just makes it easy to detect: your problems just pop out on your face. And if you have nasty, nasty problems, of course you'll put them on agile's account. Again, agile is just a tool to help you to figure out your problems, and see your problems going away when you take actions to solve them. And a fool with a tool is still a fool, just more dangerous.

Mike Brunt wrote on 09/25/09 2:58 PM

@Igor, I appreciate your taking the time to respond and thinking about the the fact that I may have insulted others, of course that was not my goal. And your third comment directly above is very well said because it gets to the root of my main feelings. I am not at all against methodologies but I am very much against shoddy software and there is far too much around. My badly stated point was that no methodology can make up for badly managed projects and I have seen such companies jump from one methodology to another when that is not the problem at all - Thanks again for your time.

Uwe Schäfer wrote on 09/26/09 1:36 AM

"Agile programming deemphasizes quality."

most radical misunderstanding possible.

Dagfinn Reiersøl wrote on 09/26/09 3:54 AM

Let me quote you again: "My main point is this, Agile is not going to solve endemic issues if they exist, just as frameworks do not magically correct bad coding."

It just so happens that Ken Scwaber, one of the originators of Scrum, also agrees with you. "Scrum won't solve [the software development difficulties in your enterprise]. Scrum is simply a tool that will relentlessly and ruthlessly expose them." Solving them, then, depends on management's willingness to acknowledge the problems and do something about it. He also says that "The effort required to adopt Scrum is huge, and only enterprises with compelling reasons will make the effort." If management doesn't really want change, they can re-interpret "Scrum" or "agile" to be whatever they need to be even more effectively dysfunctional than they were before. And that will happen even more frequently as "agile" becomes a buzzword that almost everyone wants to pay lip service to.

Mike Brunt wrote on 09/26/09 10:43 AM

@Uwe thanks for your passing comment, the person who made that assertion is not a person whom would have radical misunderstandings. I posted up a follow on to this piece with more information...http://www.cfwhisperer.com/post.cfm/an-agile-xp-debate-the-whole-story

Mike Brunt wrote on 09/26/09 10:49 AM

@Dagfinn thank you for taking the time to comment and point out the comments relating to scrum. I could no doubt search and find critical comments to all methodologies and frameworks and this point "Solving them, then, depends on management's willingness to acknowledge the problems and do something about it" is the biggest problem of all." What I have seen is Agile (and other constructs) used as a diversion, almost a smoke-screen to draw attention away from mis-management of software projects.

Manoj Vadakkan wrote on 09/26/09 5:38 PM

Mike,
Ok, so Agile is not good, in your opinion.
Can you please tell us how would you run your project?

Thanks for the interesting discussion here!

Manoj

Thomas Ferris Nicolaisen wrote on 09/27/09 10:03 AM

I'd like to add my voice to the "opposition" here. Agile practices aim to improve efficiency and increase transparency. Very often the organizational and technical problems unveiled by agile practices are misunderstood to be consequences of the methodology, while they were in fact problems that were hidden in the organization all along.

Saying that agile methods provide a "smoke-screen" is as far from the intention of agile as you can get. The same goes for agile methods leading to bad prioritization. Exposing problems and solving the most important ones first is the essence of agile.

The original post applies negative traits to agile as if they were factual and general to the method. This is highly misleading and hurtful for people looking for management advice on the web.

Mike Brunt wrote on 09/27/09 10:37 AM

@Thomas thank you for your comments and I have seen Agile used as a smoke screen to allay the realization that basic endemic processes are flawed, in fact I am witnessing it now. The reality is that most methodologies can be very helpful and if your point is correct and Agile does reveal deficiencies and nothing is done about them, then what worth is that?

I feel this thread is greatly useful to those looking for management advice, the advice is simple, get the basics right first. Do not buy a Rolls Royce to run on a dirt track road, it will still be slow and uncomfortable and you will end up frustrated.

Mike Brunt wrote on 09/27/09 10:46 AM

@Manoj thank you for your comment and thank you for asking that question, as I have been thinking very hard about how to run projects successfully and have done so several times because it is not good enough to critique things with no alternative. I had already outlined my approach here -

http://www.cfwhisperer.com/post.cfm/the-application-lifecycle-vital-at-all-times

I am going to amplify this and will have something available within the next week. I am not sure I can come up with a catchy word like "Agile" though which in Miriam Webster means "quick and well-coordinated in movement; lithe:" this assumes though that there is somewhere stable to be quick and well-coordinated in movement; lithe: and that is the part that seems missing to me. We cannot design software in a development vacuum there has to be well engineered infrastructure; more soon.

Manoj Vadakkan wrote on 09/27/09 6:13 PM

Thanks Mike for sharing your thoughts and describing the process that you think is the best. And btw, IMHO, you don't need to think that hard to invent a name of the process you described. Some one has already named it! If you look thru the literature, you will find it.

I am not going to spend my time on writing the flaws of your approach and why your views of Agile is wrong. In many of the last 48 comments, many people I know and respect have already tried that in vain - and btw, your views on Agile is wrong. I am sure there are wrong implementations of Agile - I have seen some myself. That doesn't mean Agile is bad.

Thank you for letting me voice my opinion!

blue wrote on 09/28/09 11:40 AM

The comments to the post exemplify the dogmatism inside the Agile movement, ironically it's the movement which manifesto declared "people over processes" but its follower will fiercely attack any person who doesn't like the process they propose. Maybe if the leaders of the movement didn't make $$$ off consulting and certification courses, there wouldn't have been as many mediocre managers that depress everything good and productive in the name of "Agile". So, to all agilists here - stop pointing fingers at people who "don't do Agile right" and start looking in the mirror. Great post, Mike, and what a remarkable patience!

Sean Corfield wrote on 09/28/09 4:13 PM

I think the problem here is that the quoted email is pretty inflammatory and illustrates a fairly typical misapplication of Agile principles (indeed, if you go read the full thread on the GCP list, the author of the 11 points takes a strongly anti-Agile position and quotes all sorts of anecdotal connections to make Agile sound "wrong").

Mike's mistake was not making it clear enough what his position really is upfront although he's tried to do so repeatedly during the comment-fest that has ensued.

Cedric Beust picked up on this post and comment thread as part of his commentary on Joel Spolsky's "Duct Tape" post (which has gotten coverage on other mailing lists I subscribe to). Couple that with Bob Martin's response to Joel's post and you've got all the ingredients for a long-term flamewar on the subject!

When I read the 11 points Mike quotes, my thoughts were "Well, that's not Agile! And that's not Agile and nor's that. Nope, that's not Agile either" and so on. If I'd had the author's experience and someone had told me that was Agile (and I didn't know any better), I would certainly be very down on Agile as well.

Mike's repost rings true: poor management and poor developers will fail regardless of their methodology, tools, technology, whatever. It's a sad fact that we have a lot of inept people in our industry and the colossal growth of our dependence on software has led to our industry's inability to keep up with the demand for skilled practitioners - and so there's a lot of warm bodies churning out mediocre code (at best), driven by more warm bodies with poor-to-mediocre management skills. No wonder we have so many failures!

I do take issue with Mike's condemnation of Agile / XP practices tho' (and he's taken pot shots at it before and will no doubt continue to do so :) Agile principles can definitely help improve software quality and speed up delivery of functionality - as long as they're applied properly (just like any other tool / methodology: if you apply it poorly, it won't help you!). I'd go so far as to say that Agile / XP represents the best evolution of software practices today. It's just that so many shops are so far behind the curve that if they try to apply the latest new shiny whatever, they'll fail just as surely as if they'd kept doing the same old thing - they have a more fundamental problem to solve.

Years ago, I worked at an actuarial firm that actually had some fairly advanced thinking going on. It was leveraging CASE where it made sense, doing quite a bit of parallel programming (Transputers) and had a Prolog group solving problems that didn't lend themselves well to traditional languages. It still ran over budget and over schedule. Why? Because it had promoted its best software engineers into management roles and hired rote programmers who had little understanding of good software practices. At my exit interview, the very traditional IT department manager asked if I had any parting advice for him... I suggested firing half his staff and letting the really good software engineers do what they were best at: designing and building software. Essentially they had let process overcome people but they felt they needed a traditional management structure to be a "serious" IT department.

That experience is why I believe Agile *is* an improvement.

Mike Brunt wrote on 09/28/09 5:04 PM

@Manoj thank you for coming back to comment and I am going to amplify my previous post as I said I will, later. I am not wrong, nor are you, my point of view is simple and it is based on seeing hundreds of applications over the past 10 years, nothing and mean nothing in methodologies or just simple software development processes have been compelling enough to me, to totally recommend them. As Sean C says in his eloquent comment, we cannot go on churning out failed software projects and products it is not necessary, it is as easy to get things right as it is wrong and it costs so much more to put wrong things right than to get them right in the first place, that is my point and as Sean says I did not state that clearly enough at the outset of this post.

Mike Brunt wrote on 09/28/09 7:43 PM

@Anon yes that be interesting to see for the education of all.

Mike Brunt wrote on 09/28/09 7:54 PM

@Blue thanks for taking the time to comment and thanks for your kind words. I think one of the problems that afflicts software development is "religious" wars. I am all for passionate programming and really like the book The Passionate Programmer but passion is different from elitist dogmatism in my opinion. In my community, the ColdFusion community there is a similar elitism characterized by the term "5 taggers" which I detest. As developers we are here to provide required functionality to users or other functionalities. We need great developers and we need great managers even more.

Mike Brunt wrote on 09/28/09 8:09 PM

@Sean thank you very much for your very detailed comment and for taking the time to create it. It seems that Agile development methodologies can be interpreted in many different ways. I am absolutely adamant that infrastructure/capacity engineering should come early in the software design/development process not after everything has started to fall over. I agree with you that we are lacking enough really good developers and IT managers and one solution to that is adequate training which many companies have cut back on. I will recommend another great book that can help in this regard, "Smart And Gets Things Done - Joel Spolsky".

Mike Brunt wrote on 09/29/09 11:09 AM

@Anon and anyone else who is interested, Stephan Schmidt listed his opinions and rebuttal to all 11 points cited in my original post here...

http://codemonkeyism.com/agile-quality-rebuttal-mike-brunt/

This is a good read, thanks for taking the time Stephan.

Mike Brunt wrote on 09/30/09 7:04 AM

@Cedric thank you very much for your comments and your blog post. I think anything in life that has a good deal of detail and rules etc can be used "properly" or otherwise and if the Agile proponents assert that all the problems come from inappropriate use then perhaps Agile can be misapplied too easily. All of this has got me thinking a lot more about why so many software projects are still failing and what can be done, as you say very well "Let's move to something more pragmatic and more flexible in what should and should not be done."

Jefferson P. Gray wrote on 10/11/09 1:05 PM

I absolutely agree with your points. The point is that programmers have a different idea of quality. Code quality is not the same thing as product quality (although there is a correlation). Besides, most products (except for what goes on in small start-up shops) are developed on a platform, and nothing is worse than a bunch of "agile teams" in such environment.

Besides, any methodology "works" as long as you hire best experts. I have seen large waterfall projects performing excellently for a number of consecutive releases, just because they hired best experts around. Nothing was "agile" there - but everyone was happy to participate in such a professionally managed project (it was an IBM project). From my experience (30 years in the IT, went through all hypes, light-weight and heavy-weight processes) I think that good processes, managed by top-level managers with a strong IT background, are definitely a better bet than some kind of "agile" ideology that was born as a result from a failed Chrysler project.

Generally, IMHO agile ideology is being sold to developers, hoping that they put pressure on their bosses to hire an agile consultant. There is nothing wrong with that, but it should be pointed out more clearly.

Tathagat Varma wrote on 10/13/09 11:16 PM

There has been a healthy debate, to say the least, on the original post, so I won't add more to it, but just offer my own perspectives (that I also blogged about in "Why Agile Doesn't Sell with Management?" avilable at http://managewell.net/?p=550 and some other earlier blog posts).

My biggest difficulty has been the Dogmatic Agile that simply refuses to grow in keeping up with the times. Scrum happens to be the most 'laminated' framework around - you are simply not allowed to change it, come what may (that's what my CST also told me in the CSM class). To me, a process / methodology / framework itself (and first and foremost) be subjected to the 'inspect and adapt' than the products which are being produced using it - if something is not working, we should be 'allowed' to throw it away and move on.

Producing good software is almost always more important than sticking to Agile Principles verbatim. We software professionals must learn to understand that Agile exists to serve software development and in turn, business, and not the other way round. To that end, anything that works and improves the way of working should be embraced, and everything else should be discarded, Agile or otherwise.

Monthly Archives

Search Archives

Favorite Links

AsFusion

CFWhisperer conversations from the server side of ColdFusion CFWhisperer

Thinking Of Agile - XP Please Read This first

Comments

Write your comment

Categories

Monthly Archives

Search Archives

Favorite Links