When Agile Projects Go Bad

blackbearnh writes "CIO Magazine has an article up looking at some of the ways that Agile projects can fail, or Agile can be misapplied in organizations. Some of the issues raised may not be new, but folks might want to pay special attention to these, since the people throwing the stones are two of the original Agile Manifesto signatories, Alistair Cockburn and Kent Brock. From the article: 'Once individuals become familiar with Agile, either through training or practice, they can become inflexible and intolerant of people new to the process. Cockburn has seen this in action. "I'm one of the authors of the manifesto, so if I say something 'weird,' they can't tell me I don't understand Agile. But if someone else — and it doesn't matter how many years of experience they have — says something funny, they get told they don't understand Agile."'" Here's another recent article by the same author on the perils now besetting Agile.

Comments

It's taken root.

[Surreal Puppet]

Several of the more business-oriented programming/software development courses on my (Swedish) campus is being taught in project groups using agile.

No way!

[Anonymous Coward]

You mean when a good idea is elevated to an inflexible ideology, it can become a bad idea? This has never, ever happened before. :)

Re:No way!

[Anonymous Coward]

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

SHOCKA

[kevination]

Bad management leads to bad results, no matter the methodology.

Re:SHOCKA

[tgd]

In my experience, bad management coupled with agile programming leads to dramatically worse results, however.

Agile programming requires good management and very experienced engineers to work effectively. Very few organizations have both.

In the several organizations I've been at that have toyed with it, its been a total failure because of that reason -- a failure clear to the engineers involved, and people like myself looking at the mess from the outside, but the management directly involved can't seem to see that time to deliver has gone up and quality has gone down.

Re:SHOCKA

[Anonymous Coward]

Inexperienced managers take trendy catch phases (like agile) and do what ever they want in the name of being progressive.

Currently, I'm stuck in a job working one of the worst code bases I've ever seen, but that's okay, because we're agile!

BTW, in this environment if you suggest improvements to the process or code, you're likely to be fired to improve company moral.

Re:SHOCKA

[MadKeithV]

Sure it wasn't a failure because the engineers involved wanted it to fail? Because the number one thing that should be added to a team is responsibility - those engineers should have been screaming at management that it was failing.
Of course, they probably did, and management probably ignored it because the Agile Consultant had a nice suit and a cool car...

Re:SHOCKA

[Nelson]

I'll agree with that. Bad management, a top notch team and agile can not only lead to worse results but effectively dismantle the team as well. From the rest of my career experience, assembling that "right" team is a very very hard thing to do. I'd trash almost any product if it meant keeping a high quality, high functioning team.

Agile sort of masks management mistakes for a while and creates the illusion that it's not as important, it places emphasis on the team, encourages team responsibility and the breaking point is when the team is so overloaded that they start to fail. A lot of really good teams will absorb that load for a while though, you'll hear some rumblings but the management mistakes will continues to build. When the load starts to break the team, it's way way too late to fix, the team will fracture and break apart.

I don't like the "2.0" moniker, so I won't call it "web 2.0" or whatever but the current generation of top notch software, lead by Apple and the very few similar companies (come to think of it, I can't name one that is truly similar so much as wants to be and pretends to be, except maybe google) is kind of different. You really have one shot to win or lose the customer, the expectations are exceedingly high, and every product has to pretty much be "lights out" from the start. The old MS "fix it in 2.0" doesn't cut it, there can't be much that needs fixing and in 2.0 you need to further raise the bar, not continues to get in to the game. Web services are a bit different in that you have a little bit more room for mistakes, but not much, the web crowd won't use crap while you figure out the "right way." To put together an itunes or an iphone you need excellence throughout the organization, not a razor sharp dev team and a bunch of morons surrounding them playing iterative games to mask their own incompetence. I think as the rest of the industry wakes up to it and realizes what they have to do they'll realize that it is much harder than it was before. You need a very cohesive management team with vision and high standards that is all on the same page and you can't just pick that up at some seminars. If you have that then maybe Agile might work for you.

Re:SHOCKA

[geekoid]

If they were doing Agile development then the management would have been responsible.

What agile needs is buy in. with buy in, bad managers become better managers, developers get work done faster, and with fewer bugs.

I was amazed at the work we got done when I did Agile, but we had buy in through the whole chain.
Our application had 1(ONE) bug found in the year I was there after we finished.
1 bug, 287000 lines of code.
In a vain attempt to keep the "Idiot pedantic"* at bay, yes in was in sue during that year,. It was used by engineers and 1000's of customers, yes we had a bug reporting program. No, that count didn't include white psace, and yes I know Perl would ahve done it on 1 line.

*Idiot pedantic is a special breed of pedantic that looks for 'technical' excuses to be pedantic and ignores all practical, contextual, and previous dialog just to be pedantic.

These are the same people who will use vagaries to lie to you.

Re:SHOCKA

[DutchUncle]

>>You really have one shot to win or lose the customer, the expectations are exceedingly high, and every product has to pretty much be "lights out" from the start.

Welcome back to: The Mainframe Era. In the days of the IBM 360, we were slow and careful because the costs of anything going wrong were astronomical (percentage-wise, at least). Changes or installations couldn't require a reboot because downtime was expensive - and long. Like a rocket, everything had to work right the first time it was deployed.

As I read about Agile, it isn't about being "fast" - it's about being slow and careful in a more rapid way. Do things a little at a time so you can be confident in each step, and can add lots of little steps rapidly with similar confidence.

Re:SHOCKA

[doom]

The old MS "fix it in 2.0" doesn't cut it

You're being generous. It was more like "fix it in 3.0", and that strategy has never worked for anyone but Microsoft.

Extremist Programming

[composer777]

We've had quite a few people around my workplace promoting extreme programming and (fr)agile software development. It's not going to replace lack of talent, lack of planning, or not knowing what the true costs of things are. I think many people in management have taken in only the parts that they want to hear, and ignored the rest. The results of this kind of misapplication are fairly obvious.

My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.

Re:Extremist Programming

[Anonymous Coward]

I think many people in management have taken in only the parts that they want to hear, and ignored the rest. The results of this kind of misapplication are fairly obvious.

My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.

as a part of a company that only does things the agile way, we have a saying "you cannot do agile, you can only be agile" in short it is completely dependent on the kind of people you have on your team.

Re:Extremist Programming

[famebait]

Fair enough. I just don't defend the tried and broken ones, like many do.

Re:Extremist Programming

[wrook]

My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.

But can you provide proof that the "tried and true software methodologies" work?

Our biggest problem in process improvement is that we can't easily measure productivity. If we could, then it would be a walk in the park to determine if one way of doing things was better than another. Instead we can say that project A was successful at meeting its targets while project B was not. Even then management always games the system to claim that their projects were successful. How else would they get promoted?

Lately I've been hearing from a lot of people who claim to agree with agile principles and therefore feel that they must be agile. Whether or not they actually achieve results seems to be secondary. A good example would be, does your team *actually* welcome changing requirements? If not, then I would argue that you aren't agile.

If you read through the agile principles and think to yourself, what would you do to actually achieve this, I hope that people start to realize that becoming agile isn't trivial. In fact, I think many people would argue that it's impossible. Having worked on a couple of teams that were actually agile in this respect, I disagree.

I think scepticism is healthy. But when we're comparing development methodologies it's hard to find ways of comparison. Even though I'm retired from professional programming, if I were to take it up again I wouldn't work in a more traditional setting. Especially one of the XP teams I worked on, while not being particularly exceptional in terms of talent, was one of the most amazing experiences of my career. I highly recommend others to try to get the same feeling. But it is by no means easy.

Re:Extremist Programming

[Hognoxious]

I think many people in management have taken in only the parts that they want to hear, and ignored the rest. The results of this kind of misapplication are fairly obvious.

It's pretty clear that there's a risk that "we're doing agile!" can be used as a justification or smokescreen when what you're really doing is blindering through and making it up as you go along.

Re:Extremist Programming

[Anonymous Coward]

>My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.

Agile programming only covers up weaknesses in a programmer's skills. I have never seen a project were multiple programmers working on the same code ever successfully delivered a high-quality, well-commented piece of code. This is reminiscent of the 100 monkeys in a room with typewriters eventually being able yo produce the works of Shakespeare. Nonsense. Agile programming promotes the worst practices including lack of planning and forethought.

Re:Extremist Programming

[Esther Schindler]

>>This is reminiscent of the 100 monkeys in a room with typewriters eventually being able yo produce the works of Shakespeare. Thanks to the Internet, we have demonstrated that this is not true.

Re:Extremist Programming

[ClosedSource]

"Our biggest problem in process improvement is that we can't easily measure productivity."

Perhaps the difficulty in evaluating processes' efficacy should lead to the conclusion that process improvement is not a worthwhile endeavor.

Ironically, if a test-first approach were used to develop an agile methodology, you'd have to stop because
you can't write the test.

Re:Extremist Programming

[chromatic]

Ironically, if a test-first approach were used to develop an agile methodology, you'd have to stop because you can't write the test.

What about "Can we release a new version of the software with new feature per user specifications in the next iteration?"

Re:Extremist Programming

[geekoid]

"(fr)agile "
The cfact that you put that there indicates you don't actually understand Agile programming.

"My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies."

There is a bigger issue there, can you figure it out?

Personally, I've seen it work a lot better then waterfall. With far superiour results. Obvious my few dozen large projects(150,000 line) is a very small pool to draw a sample from.

Re:Extremist Programming

[geekoid]

There are several ways to measure productivity.

It's just complex and requires looking at design, not just 'coding'.
Of course, since most software projects are not done correctly, and inconsistently it can be difficult.

Re:Extremist Programming

[jgrahn]

It's pretty clear that there's a risk that "we're doing agile!" can be used as a justification or smokescreen when what you're really doing is blindering through and making it up as you go along.

"Making it up as you go along" seems rather attractive to me, as long as *some* kind of compass needle is pointing towards the goal. I'm no agile fanboy, but planning everything first and then executing The Plan -- that's not realistic.

Re:Extremist Programming

[shutdown -p now]

But what is Agile, really? Aside from the "do whatever works" (which obviously isn't new)?

Re:Extremist Programming

[HeronBlademaster]

I worked for a manager for a while who has had some problems with agile development. He stressed constantly that Scrum was the way things were to be done, but often his behavior contradicted that. One day, he arbitrarily decided something that all of his employees as well as *his* boss thought was inappropriate - the boss' comment was "That's not how Scrum works."

The manager's response? "Fine, then we're not doing Scrum for this task."

My observation, in retrospect, is that Scrum and similar systems only succeed if all the people involved are actually going to work by it.

And I want to quote one of the original post's articles, because it has been completely true in my experience:

But because Scrum works in short cycles and doesn't include any engineering practices, it's very easy for teams using Scrum to throw out design. Up-front design doesn't work when you're using short cycles, and Scrum doesn't provide a replacement.

The same manager has problems letting his employees spend time actually designing things for the long-term. One project in particular was completely rewritten (starting from scratch) four times simply because the manager actively refused to plan ahead more than one Scrum iteration. If that weren't bad enough, the results were entirely his fault because he did not share information only he was privy to that would have eliminated the need to rewrite the project in the first place.

Anyway, I completely agree with composer777 when he says "It's not going to replace lack of talent, lack of planning, or not knowing what the true costs of things are. I think many people in management have taken in only the parts that they want to hear, and ignored the rest."

Re:Extremist Programming

[MillionthMonkey]

It's a canned approach that worked for other people, so it is guaranteed to work for you.

You all meet once a day in these meetings that are referred to as "scrums". :P Then, various feature additions, major refactorings etc. are labeled as "stories", and each "story" is further broken up into "tasks" which are also meticulously labeled and tracked. Every piece of code is pounded by unit tests that nobody has any time to write because of the proliferation of stories. There's a lot more BS to be found on the web about it, most of which boils down to a set of formally prescribed methodologies that have a significant overlap with basic common sense but with some omissions and extras.

The best thing Agile has going for it IMHO is that it is not Six Sigma. I worked at a Six Sigma company for over a year and I still couldn't describe it to you. Nobody had the faintest idea what it was.

Re:Extremist Programming

[doom]

My biggest objection is the lack of credible proof that it actually works any better than the tried an true software methodologies.

Whoa. You want people to actually prove their claims? The next thing you know you're going to demand that Computer Scientists learn how to do science.

Anyway, see you at the next "my language is better than yours" flamefest.

Re:Extremist Programming

[doom]

Our biggest problem in process improvement is that we can't easily measure productivity. If we could, then it would be a walk in the park to determine if one way of doing things was better than another. Instead we can say that project A was successful at meeting its targets while project B was not. Even then management always games the system to claim that their projects were successful.

Actually, I think this is a lazy cop-out by people who don't want to do the work of getting the answer.

Myself, i can think of ways to get real data on these questions: MODEST_PROPOSAL.

And there are other methods that could be applied: Plat_forms Contest.

Re:Extremist Programming

[wrook]

Actually, I think this is a lazy cop-out by people who don't want to do the work of getting the answer.

You are right. I was lazy.

There are several problems with measuring productivity:

    1) We have no good measure of objectively assessing the ability of the team members before they start. We don't even have a unit of measurement to report it in.

    2) We have no good measure of objectively assessing how well team members will be able to work together before they start. Again we don't even have a unit of measurement.

    3) We have no good measure of objectively assessing how complex a problem is before the team members start. Again... lack of units, blah, blah

    4) We have no repeatability of problems. Since we can't measure the ability of the team members, nor the ability of the members to work together, we can't simply give the same problem to a several groups using different methodologies and see which one works better. Caveat: we could ignore this problem if we are willing to repeat the problem a HUGE number of times (probably 200 to 300 times would be sufficient)

    5) We can not have the same team trying different methodologies. Their ability to work together will change over time in ways we can't measure (although it certainly would be something we'd like to measure since it's part of the point of some agile processes)

    6) Even if we have teams doing the same problems, we are interested in non-trivial problems. Thus they will certainly come up with different solutions. Part of the methodologies deals with requirements collection after all. So we must find a way to relate the effectiveness of the solution and weigh it against productivity. Again, no units, yada, yada, yada...

    7) We have no objective measure of productivity itself (except maybe the infamous KLOCs).

    8) Again we are interested in large difficult problems -- ones that take at least 8 months of work. So even if we do the best that we can, do *you* have enough money to fund 200 6 person teams for 8 months?

These aren't just difficult questions. They are questions that have been posed in the literature over and over again for the past 30 years. There are *no* answers (that I know of anyway). And unfortunately your links shed absolutely no light on the matter either :-(

When I said that measuring productivity in terms of methodology was difficult, I was understating things by a long way. I actually don't think it will ever be possible to measure well.

Good management can build a good solid team and help them develop a working method that is best for the team. It can be a critical factor in success. Unfortunately, good management is pretty damn rare, more's the pity.

Re:Extremist Programming

[doom]

I'm not accusing you of being lazy, I'm accusing the field of "computer science" as a whole of shrugging off the admittedly hard job of trying to answer these questions.

I think you're greatly exaggerating the difficulty of the problem: there are ways these things can be hashed out, however crudely, and the links I provided should at least suggest some ways they might be hashed out.

Nearly every objection you raise can be dealt with by (a) by abandoning the quest for perfect certainty and just trying to be reasonable about it and (b) an increased number of trials -- hundreds probably wouldn't be strictly necessary, but it's not like a hundred trials is all that much really.

Uhm...

[NaCh0]

Alistair who ??

Re:Uhm...

[Anonymous Coward]

Sometimes pronounced Coe-burn for obvious reasons.

Re:Uhm...

[jeroenb]

Actually, it's pronounced Coburn because he's from Scotland and apparantly that's how they pronounce it there. He starts nearly every talk by explaining how to say it correctly :)

Re:Uhm...

[danieltdp]

And because Cock Burn should hurt a lot

Re:Uhm...

[PingSpike]

And after every talk, people still refer to him as superstar cock burn.

Kent Brock - s/ro/e - Kent Beck

[Z-MaxX]

Hello, McFly! It's Kent Beck, not Brock.

Name misspelled

[mdm42]

That should be "Kent Beck" in the summary, not "Brock".

Re:Name misspelled

[Anonymous Coward]

This just in, /. summaries contain errors. I've said it before and I'll say it again, /. editing simply doesn't work. And I, for one, welcome my replacement Kent Beckman.

Project steps

[Anonymous Coward]

I constantly see so many adhoc dev teams operate with almost no formal processes and I would be very interested to see a basic list of steps that you perform to manage your project from the start to production deployment.

At the moment the most common methods for small teams seems to be the following

    - Customer asks for a change to some software, website etc
    - Programmer may do basic class designs
    - Progrmmer codes the changes
    - Pushed into staging envrionment
    - Customer gives ok
    - Pushed into production

I would be very keen to hear from people who have very clean, clear well defined processes to list the steps from requirements gathering right through to production deployment.

Re:Project steps

[famebait]

list the steps from requirements gathering right through to production deployment.

That would not be agile :-)

Re:Project steps

[Anonymous Coward]

- Customer asks for a change to some software, website etc
        - Programmer may do basic class designs
        - Progrmmer codes the changes
        - Pushed into staging envrionment
        - Customer gives ok
        - Pushed into production

I would be very keen to hear from people who have very clean, clear well defined processes to list the steps from requirements gathering right through to production deployment.

That sounds like you have a pretty clean, clear, well-defined list of steps in your process right there. What do you feel you need to add?

Re:Project steps

[LingNoi]

- Progrmmer codes the changes
        - Pushed into staging envrionment

You're missing a stage there where it is reviewed by someone else and accepted or rejected.

I don't understand why more companies don't employee someone to review everyone's patches/commits.

Writers have editors for a reason, so should programmers. Much easier finding the problems on the way in then debugging the problems on the way out.

Re:Project steps

[jguthrie]

Oh, I understand completely why people don't review code. It's because the reviewer has an impossible job. It's tough enough to figure out what the code does after hours of study, but your typical reviewer has a few minutes not only to understand the patch in the context of the code around it, but also to approve or reject each patch. Since that isn't enough time to determine whether or not the code is actually any good, my experience has been that most patches are approved because they're most likely correct. Add to that the fact that inspection of the source code has proven time and again to be the poorest way of finding defects, and one must conclude that code reviews are a pointless time-wasting exercise

While you are right that writers of prose have editors, the job of an editor of prose is not even approximately the same as the job of reviewer of software patches. At the grossest level, an editor's job is to issue syntax errors like the compiler does when you write programs in a compiled language. Also, the editor represents the publisher's and the readers' interests. Since books have to be within a fairly narrow range of sizes or they sell poorly, and magazines have a limited amount of space for editorial content, the editor might suggest that a story should be shortened in order to be salable or would have to reject articles due to the fact that they don't fit in well with the rest of the issue. There are equivalents to those jobs in the software industry, but they're not filled by a reviewer of source code.

Re:Project steps

[LingNoi]

wine does that exactly, if the code can not be understood then it is rejected and told to be made into smaller patches.

Inspection of source code when it's already in the database isn't the way to do it. However, it's very easy to review code coming into a repo.

Holding code up to a certain standard and rejecting the rest does work because it gets rid of a lot of time consuming errors that you will debug later and keeps the code base clean.

When you're working with someone who is a really crap programmer this works extremely well and there is no need to assign them to "documentation".

Re:Project steps

[jguthrie]

I'm glad it works well for you. Still, I can't help but wonder what you would find if you gathered statistics about those errors found by inspection as opposed to those errors that inspection failed to find and had to be found some other way. Would you determine that the effort is worth the time? I wonder.

As it happens, last Friday I had occasion to do review some code. You see, I had discovered that something was causing an error in my client-facing API code and by reviewing the thrust of all of the changes in Subversion, I concluded that the error had to be in a particular function and the code that had been last changed in that function was not too long, only a dozen lines or so. The code was written by someone who is perhaps the best programmer in the place, and it was properly formatted and in the same style as the rest of the code. However, I knew that the change in question was badly broken as I was reviewing the code and I couldn't see the error.

It was only as I dug deeper than a review could cover, and took advantage of the additional information from my knowledge of the symptoms to conclude that a particular branch that should have been taken was not, in fact, being taken, which lead me to realize that a particular variable was not being properly initialized in a loop. That code should have been moved out of the loop when the code was reorganized and simplified, but it had not been, which resulted in the error.

In addition to the timing, I find this defect interesting for two reasons. First, because an inspection would have utterly failed to detect that the change was broken. I mean, I looked right at the code and couldn't see it despite being familiar with the context and such and armed with the knowledge that it contained an error. Second, this sort of flubbing up a reorganization is a common error when writing prose.

I hope i'm not the only one who thought this...

[Anonymous Coward]

s/Agile/Linux/g

(AC because this will be modded troll/flame bait, when really if the same story were about Linux it would easily be decried flame bait and bashed)

XP is a cult

[Anonymous Coward]

It's intellectually lazy, without proof that XP techniques are more effective than other systems development methods. They rely on repeated assertion and abuse of people who dare to ask them to prove their case.

This book gives a good overview of the case against XP.

http://www.amazon.com/Extreme-Programming-Refactored-Case-Against/dp/1590590961/ref=sr_1_1?ie=UTF8&s=books&qid=1227079014&sr=8-1

Some of my favourite XP cultist quotes :
"Unacknowledged fear is the source of all software project failures"

"Extreme programmers are not afraid of oral documentation"

"Dependencies between requirements are more a matter of fear than reality"

"I think maybe concentration is the enemy"

Re:XP is a cult

[chromatic]

This book gives a good overview of the case against XP.

I've rarely found that writing silly songs is a sign of intellectual rigor.

Re:XP is a cult

[Anonymous Coward]

I've rarely found that writing silly songs is a sign of intellectual rigor.

What were the exceptions? Monty Python's Philosophers' Song? Always Look On The Bright Side Of Life?

Re:XP is a cult

[chromatic]

Also Tom Lehrer. Unfortunately, neither he nor anyone from Monty Python worked on the anti-XP book.

Re:XP is a cult

[doom]

Here's a famous case.

Cockburn?

[BountyX]

Cockburn has seen this in action.

I have personally experienced cockburn and assure you will become "become inflexible and intolerant".

Re:Cockburn?

[skeeto]

Wow, that's a real name? I thought it was completely made up when they used it in Tropic Thunder.

pft

[sneakyimp]

Gimme a break. 'Agile Programming' is just an appallingly pretentious buzzword describing a myopic development process which misappropriates components built by other people to a task they were never intended to solve. I.e., a circle jerk running down a blind alley, smearing lipstick on a colossal pig with terminal cancer.

I know, flamebait. Flame away!

Re:pft

[convolvatron]

no, i think agile programming is what everyone does by default when there is no thought about what one is doing or why

Re:pft

[famebait]

no, I've done both and they are very different.

If your impression is that agile methods are directionless then you have met poor practitioners or read negatively selective descriptions. It actually quite rigorous, but on other axes than traditional methods. They focus on process and feedback and controlling uncertainty as you go rather than pretending you can plan away uncertainty.

Of course like any buzzword it attracts unwarranted 'namedropping' use, and like any subculture it attracts overzealous idiots who just want to be 'part of it' and look down on others. But that doesn't really say a lot about what it can offer or not.

Re:pft

[SharpFang]

Agreed; Agile is a specific methodology that is quite orderly and efficient.

Too often, though, sloppy managers let the project run wild, zero specs, zero plans, do what you feel like doing how you feel like doing it, the deadline is yesterday, so there's no time to plan anything, the customer is our alpha-tester - and they call it "agile development" because "total brothel development" doesn't have the right ring in the name. And people who see such projects really believe this is what Agile is all about.

Re:pft

[Hognoxious]

I'd never heard of "total brothel development". Is it related to this?

Or perhaps you literally translated from the French, who use "bordel" to mean "Hmm, this situation is somewhat less than optimal, isn't it?"

Re:pft

[internerdj]

Must be nice to live in a world with clearly defined requirements. Traditional processes are a big fail if you are dealing with customers who won't know your full requirements until 90% of your development time is gone. Here is my separation between the two methodologies:
1) Traditional - get everything working, time and money are flexible(to a degree)
2) Agile - Hit our deadline, how much needs to be working can be changed as we go along(to a degree)
Even the approaches by the customers aren't the same. If you think that every project is a nail because you have your traditional hammer, you are at best a bad software engineer and I don't want to be on your project. Conversely agile doesn't fit everything either. If you can't be bothered to know all the tools relevant to your job, you have already been promoted too high for the team's good.
Good, fast, cheap. Choose two. is an good old adage. You aren't doing things wrong if your customer wants the last two and you are giving it to him. You are only being bad project managers when you aren't matching your customer's set.

Re:pft

[jguthrie]

The whole "clearly defined requirements" thing is a straw man, as you well know. I have found that specifications are always subject to change and so you need a methodology that can deal with that. The thing is, I have not found that the popular descriptions of agile programming provide much guidance on how to go about doing that.

There's also the fact that software development isn't a sprint, it's a marathon. It's like you're going to walk to a baseball game in a distant city. When you set out, you may not know what section, row, and seat number you're going to sit in, but it's kind of important to know whether you're going to PETCO Park or Soldier Field. (And, yes, I am fully aware that Soldier Field is a football stadium.) Big projects are made up of small decisions and each one of those decisions must be made in full awareness of the path you're walking.

So, as near as I can tell, the two essential rules are these: First, one should implement the essential functionality first. The problem, of course, is that "essential functionality" is hard to define. Second, it is vitally important to guess the complexity of the ultimate result before you begin, and if you are going to guess wrong it's better to guess that the job will be more complex than it turns out to actually be.

Putting those two rules together, I get "design complex, implement simple". This goes along with most of the design advice you see (avoid global variables, abstract things into functions, break your program up into logical chunks, define interfaces and then stick to them, and so forth) and also matches XP's don't implement stuff that's not in the requirements right now. It's not that you implement features in advance of their need, it's that you try to make it easy to implement whatever it turns out you need to implement.

Re:pft

[internerdj]

Agile isn't about providing methodologies to deal with changing specs; it is about tying the stakeholders into the project so they know when, why, and how much they can change their product and providing an open communication structure to rapidly shift to new requirements. Agile change management: Put your customer on your team and don't overdesign your system because it may change.
I agree that those two rules are useful, but I think that traditional leans heavy on #1 and agile leans heavy on #2 and a successful manager knows where to put the emphasis to make a successful(not necessarily perfect) project.

Buzzword Boredom

[Anonymous Coward]

In my thirty years of design and programming on projects big and small, high level to low, I've seen this crap come and go. It's always more or less the same, and it's always instigated/pushed/proposed by those who cannot code, or those who are looking for something to do besides code.

Re:Buzzword Boredom

[Anonymous Coward]

Agile is often pushed by people who want to do nothing but code. Unfortunately, those people are usually managers and architects, who are supposed to be doing lots of things that aren't coding, like, say, planning, managing, or designing.

Re:Buzzword Boredom

[famebait]

No, agile really is different from the old methods. And it's not that much about how to code it's about how to run a project, maintain control, and be able to deal with changing requirements.

You still need good coders, it won't magically improve anyone. But you need more than that. There is no lack of failed projects staffed with good coders. If your projects regularly succeed, you are also employing some planning and management skill that is evidently not obvious to everyone.

Re:Buzzword Boredom

[Anonymous Coward]

In my ten years of working on and designing projects big and small, high level to low, I've seen crap programmers come and go. It's always more or less the same, and they always hide/moan/deride by pushing their ability to code when they are really looking for something do do beside code.

Fear the BOFH!

Re:Buzzword Boredom

[saunabad]

My experience then again tells that agile methods such as xp are actually quite coding oriented. What I've seen as a huge problem is that while the whole idea is to help the project adapt to changes, it also makes doing them far too tempting. People who are in charge can use it to avoid making difficult decisions.

Re:Buzzword Boredom

[Anonymous Coward]

Verity Stob calls it the "First Law of Meta-Methodology".

"Evangelists of new techniques often get that way because they can't write code for toffee."

My take is the good programmers know just how much planning is required - they know where the line is between detailing single detail and plan-nothing-upfront. IMHO, you start with a vague idea and plan, and keep refining until you're comfortable that the plan you've got can be implemented without having to be detailed any further.

Re:Buzzword Boredom

[ozphx]

Yeah I'm in the middle of a huge truck of agile fail at the moment. Its good for people like me - the sort of contractor who is called in to "save the project" when its too damn late.

People seem to think you can easily refactor a completely broken domain model for a complex system. Requirement capture via user stories is only going to work when you have a clearly defined problem domain and precise terminology. If at 90% into the project timeline you are still having trouble getting questions answered like "Is a system point a participant in a route, or metadata attached to a participant in a route?", or "So, you thought you'd just go and agile in all the redundancy and clustering later hey?" then you are going to have to get quite agile with your sphincter for the angry client.

Re:Buzzword Boredom

[Shinobi]

Agreed. Despite some successes, generally speaking mostly small or low mid-scale projects, "Agile" is to software engineering what Red Bull Flugtag contraptions are to aviation engineering.

Re:Buzzword Boredom

[Anonymous Coward]

i want to have your babies

Re:Buzzword Boredom

[Precipitous]

Code needs continuous improvement. Technology wants continuous improvement. Process wants continuous improvement. Agile / lean are the latest improvement. Concepts and patterns want names - buzzwords if you will - so we can agree what we are talking about.

Agile and lean were wildly successful methodologies long before they anointed with a buzzword. Is it crap? Evidenced by the rampant success of Toyota (lean) vs GM (conventional methodology), it is not crap. Agile and lean are not "new" at this point - they are now the minimum bar in most industries. Processes even better than the agile / lean methodologies sure exist. Those companies will thrive and a new buzzword will come into play.

Fortunately for you, you don't have to be interested in process improvement to be a programmer (only code improvement). You do have to be interested to be a successful manager or lead, though.

Re:Buzzword Boredom

[Anonymous Coward]

Agile is an excuse to implement management best practices (iterations, work items, scheduling, etc) and engineering best practices (source control, continuous integration, unit tests) for great justice.

It's OK if you only do bits and pieces but if you have poor management activities or poor engineering activities, of course relative quality of work suffers.

--Robert

Out of context

[n3tcat]

Cockburn has seen this in action.

Did anyone else giggle like an 8th grader when they read this?

Not the Same Author!

[chromatic]

James Turner and James Shore are two very different authors.

print-view

[Anonymous Coward]

Here's the article without most of the ads and in a much nicer way to read it..

http://www.cio.com/article/print/464169

-Deepone

All development processes have cult following

[PinkyDead]

There isn't one of them that doesn't have individuals that follow the processes blindly.

I think this is the point of TFA, you need to think about what you are doing and never assume that you have a silver bullet.

This is actually where XP/Agile have a major advantage over other more formal processes - the Agile processes try not to promote rigid thinking and if applied correctly should be self-correcting or applied in more than just name only (but you would know that if you had read TFA).

Oooh, the irony!

[Anonymous Coward]

XP is probably the most prescriptive of all methodologies I can recall.

If you aren't following all 12 practices, you're not doing XP. It's ironic that the people that want to shy away from CMMI's use of the term 'discipline', requires more of it than any other. Even RUP is more flexible (albeit bloated on an altogether different scale). CMMI is a model, not a standard, but with XP - it's all 'do it our way or you're not doing agile'. If you dear criticize some practices, there's a chorus of fanboys crying 'Blasphemy!'

Personally, I prefer Scrum and Lean development - they really tickle my senses.

Scrummed to death

[Anonymous Coward]

Having worked on a Scrum-managed development project for 3 years in a large French/Canadian software house, I am happy to have the opportunity to get it off my chest that Scrum SUCKS the big one!!! and Scrum slowly strangled a decent project over 3 years until death. Finally our company was bought out, and the project was consigned to the trashcan by accountants due to faiure to show any results after such massive investment. Due to the fact that it was a project for a new product, using new development technologies, and with a new team, we were all initially on the learning curve. As required we had to give estimates on how long our tasks would take, blindly. Of course we got it wrong and soon had a massive backlog, and finally we became slaves of this massive backlog. We had many overlapping scrum groups based on vertical and transitional concerns, resulting in seemingly non-stop scrum meetings and backlog meetings. Scrum masters were incapable of passing useful information and alrets between scrum groups, because they had little technical savvy. End result: people just lying about the completion level of their tasks, backlog explosion, lack of coordination, demos not working, a massive drop in morale, massive infighting and politics and blame game, massive quality problems - components not working meant testing was limited, etc. In that 3 years over 50% of the original development team just left the company and so we were slowly sinking into the mud of failure. It was micromanagement gone mad.

But these scrum idiots just kept flogging that dead horse with religious zeal and in the end they blamed everything but themselves. Perhaps the fact that the company spent so much money on having these people trained, they could not admit defeat and stop the madness.

Re:Scrummed to death

[BotnetZombie]

You were doing this wrong. Developers should only be in one scrum group at a time, and only have short (10-15 mins) meetings daily. We're doing scrum at my company now, I think it's still a bit too many meetings sometimes, but at least here it's nowhere as bad as you have described. The backlog is actually one of the things I like about this scrum thingy. It allows you to prioritize relatively small tasks, exactly so that you get the most important things out of the way first. It's good for keeping focus, good for getting something out of the door early.

Re:Scrummed to death

[Hognoxious]

You were doing this wrong.

I'd worked that much out before I'd finished the first sentence.

Re:Scrummed to death

[geekoid]

Maybbe it failed becasue your team sucked? Clearly you weren't doing scrums..sure, they may ahve called the scrums, but they aeren't.
Scrums should last less then a minute a person.

Scrums work very well.

In your case you need to ask youself.
A)Did they tale longer then a minute a person?
B)Why was technical savvy required among they Scrum masters?

"people just lying about the completion level of their tasks,"
You can not do that with actual Agile programming, everyone knows when you fail to finish your piece when expected.

Don't blame scrum for the fact that your company wasn't using it.

Re:Kent Brock - s/ro/e - Kent Beck

[cosmocain]

Meh, it's Clark Kent, you insensitive clod!

Measuring productivity

[Kim0]

Measuring productivity is easy:

Just give the same projects to 2 teams,
with randomly given different methodologies,
and then see how often and how fast they succeed.

One can then use the usual statistical tools to analyze these results.

Of course this costs a lot.
But not knowing also costs a lot.

Kim0

Re:Measuring productivity

[dodobh]

It also depends on the team members. If one team has people in the top 10%, and the other team has average programmers, the methodology will be mostly irrelevant.

Re:Measuring productivity

[h4rm0ny]

Furthermore, you can't consider a group comprised of people in the top 10% (however you determine that they are) to necessarily perform X amount better than a group that comprises people in the bottom 10%. Supposes your top 10% group contains two genius prima donnas who grow to hate each other? Suppose your bottom set contains a group of jobsworths who don't show much initiative and consequently follow the design plans of the power-hungry one and consequently follow a cohesive and well-delegated plan? How complex is the task? If it's simple code-assembling, an office full of plodders might have little significant disadvantage compared to the creative geniuses. Or if it's highly complex, they might botch the whole job. You can't easily prove the effectiveness of different methodologies and I don't think it's possible at all without significant resource.

But supporting the argument that comparing methodologies can be difficult is not me personally arguing for the effectiveness of "Agile" which I view as some common sense, some ideas that would be bad if applied in the wrong circumstance and a lot of vague principles that should be read to stimulate insights and then forgotten about.

Re:Measuring productivity

[Anonymous Coward]

Well thanks for pointing that out, Poindexter. While you're at it, better inform all the people running clinical trials, just in case they didn't grasp this new breakthrough in experimental methodology.

Re:Measuring productivity

[MadKeithV]

I think the most effective test would be to keep throwing terrible programmers at a problem and see which methodology fails the least badly.
Because in real life you rarely find enough of the top 10%-ers to do all the work that needs to be done.

Re:Measuring productivity

[maxume]

Any top 10% bottom 10% ranking system that doesn't include 'ability to work with others' isn't worth very much.

You will never bake an apple pie by measuring strawberries.

Re:Measuring productivity

[geekoid]

wow, only a developer would think that's how to do it...or a crazy person.

There are many, many matrices you can use to compare productivity to different projects.

Re:Measuring productivity

[Kim0]

You did not supply any evidence for your claim.
Absence of evidence is evidence of absence.

Kim0

Re:Measuring productivity

[dodobh]

They built technology for that. It's called Java.

Re:Measuring productivity

[dodobh]

AFAIK, most medical trials assume a Gaussian distribution for reactions in humans. With programmers, the distribution is not Gaussian. There is a short head of extremely good programmers, and a long tail of average ones (and a few bad ones).

The good programmers massively outperform the average, so if you have a few good programmers in your team, you can see massive productivity gains.

Accidental complexity today is dominated by the overheads of communication. Most agile methods require increased, frequent communication. This keeps the knowledge to be absorbed at one shot to a fairly small value.

Re:Measuring productivity

[MadKeithV]

Well I can certainly confirm that many of the terrible programmers I've seen work in Java, if that's what you mean ;-)
(I jest, I jest).

Re:Measuring productivity

[doom]

Measuring productivity is easy:

No, not easy, but certainly doable.

Just give the same projects to 2 teams, with randomly given different methodologies, and then see how often and how fast they succeed.

Yes, I'm inclined to agree... the people who are arguing with you are essentially quibbling about details. There are different ways you could do tests like this with different populations -- the results would certainly differ for the different populations, but that's also something worth knowing about.

If you do your experiments with teams of undergraduate volunteers, then you've got a sample set of relative beginners, albiet young, energetic, and mentally flexible ones. If you do it with more experienced programmers, then you have a different selection, and ideally you'd do the same tests with both.

The one impediment to this, as far as I can tell, is that it's "social science", and computer geeks don't like social science (or social anything). You're average "computer scientist" is a mathematician that doesn't want to hear about doing anything but math.

You guys were using Scrum the wrong way

[Qbertino]

Just reading your post shows me that you guys where using scrum the wrong way. Most people don't understand the true purpose of Scrum. We do Scrums every day at 11:30 and they take about a minute ot two per team-member (just did todays and I'm checking on slashdot while adding my new tickets to mantis).

Scrums are stand-up meetings. Everybody stands and keeps his turn short. You say what you where doing since yesterday, what you achieved and what you are going to do today. It's mostly about self-awareness and being able to judge your capacities - it's a mental exercise, not a classic meeting (we have those too, but only like once every 8 weeks).

Agile came out of the need to deal with controll-freaks who didn't do their homework and tend to weigh down things that should be lighweight with to much bureaucracy. Where human interfacing is a key point of your software, Agile is a very good method to handle things. If the pipeline has skilled people at each section, that is. Our company is technology driven with managers that actually wrote code at some point in their career. I'd call our process somewhat agile - we get changes every odd week - and everybody deals with it without a single hitch. ... Coming to think of it, maybe that's why we dominate our market.

Bottom line:
You guys got Scrum and Agile all wrong. Maybe you should've steared clear from the get go.

Re:You guys were using Scrum the wrong way

[sheepweevil]

I'm currently on the tail end of a 6 month internship doing software development. Our team is one of the few in the company practicing a form of agile development. This turned out to be a huge benefit for me. If we were using a waterfall model, I would have to spend my entire time here doing one thing, depending on what stage of the waterfall we are in.

Agile gives me more experience in most steps of the development process; I do design, implementation, and testing. We are getting a lot done, and there is very little process bloat.

Re:You guys were using Scrum the wrong way

[Anonymous Coward]

As many people point out, Agile is partly comprised of good practices from past projects and methodologies. Scrums aren't new, but they are effective. When working on a very large Ada military project in the mid-90s, we saw most meetings evolve into a scrum style. People were expected to distribute relevant information to one or more meeting invitees, be well versed with the materials (problems, bugs, status), and then speak only about issues that the meeting could deal with effectively. Time limits were enforces and "long" issues were dealt with by ad hoc meetings and smaller groups.

My point is that scrums are illustrative of a broader point that affects all methodologies. "managers that actually wrote code a some point in their career..." is really saying that the overall team must be balanced and experienced for any methodology to succeed. At each level, people have to understand their jobs and the jobs of other team members, and appreciate who does what and why. If ever an "us and them" attitude is established, no methodology works for long. Managers who don't understand and don't have the experience for the work their people are doing are likely to make poor decisions. Moreover, they likely do understand management things and as such will be driven to deliver those things to their managers/boss, not understanding that being disconnected from the team makes that tough. Non-managers (programmers) who don't understand and consider management drivers also become disconnected, and some of them, being intellectually proud of their skills ( geeks ;-) tend to be dismissive of others not in the tribe.

At the risk of getting flamed, coders/engineers must remember that their customer is "marketing", management must remember that software dev is the most complex process we know of, and then ask themselves how perfect their latest DIY project at home turned out and what their significant other said about it.

Go Agile, Go Common Sense, Go Humbly.

Re:You guys were using Scrum the wrong way

[winomonkey]

I love it when a person uses their own non-standard definition of a word to tell everyone else that they are wrong and have quite simply missed the point. While qbertino is quite right to say that there is a stand-up meeting portion of scrum (frequently called a "daily scrum"), it is not the entirety of the scrum process. A quick look to wikipedia shows that perhaps there is a better definition out there than qbert believes.

Our team uses some of the artifacts of scrum - the daily meetings, burndowns, backlogs, but we fall into the "scrum in name and not in spirit" category of many others. The team has a tendency to push back against any definition and any documentation. Cowboyisms overpower agile engineering practices a little too often, which is a dangerous thing.

I am also curious what company you work for ... I know a lot of "technology driven companies" that let the tech of the day drive their agenda, which is not always where your customers want to be. It is always good to find a company out there that can live an agile life while playing with the latest and greatest technology AND be top of their market segment.

Bottom line;
What has worked for you and your team does not always work for all other teams, nor does it mean that you get to redefine the definition of scrum for all other folks out there. That is the big problem - people making grand and dogmatic statements about how things work or do not work. Finding something that works for you is more important than finding something that works for somebody else.

yes, but here it's funnier

[Moraelin]

There isn't one of them that doesn't have individuals that follow the processes blindly.

Yes, but here it's funnier, since you were supposed to trust it without any proof, and in fact in spite of proof to the contrary, from the start.

Since the topic is agile projects gone bad, you only need to look at the original Chrysler C3 project that became the poster child for XP: from Chrysler's point of view, the project was an abject failure. By the time it was _years_ overdue, it still hadn't delivered a tenth of the promises. At least one of the managers involved as client-representative in that project got stress-related health problems during it. Chrysler not only cancelled the project, but forbade XP. It's something you'd normally call "EPIC FAIL!" as projects go.

But in true CCCP fashion, a failure got redefined into a smashing success, and presented as such in the books. In fact, turned into the poster child for successful XP.

So there we have our answer already: when XP projects go bad, failure gets redefined as a smashing success.

Later studies into, well, how much better _is_ pair programming, actually showed that such a pair is somewhat better than a single programmer for inexperienced freshman year programmers, but barely marginally better than a single programmer when done with experienced programmers. Both cases delivered actually less than the two programmers working separately on different parts of the problem.

Again, it won't stop anyone from still pretending that it's the opposite.

XP also redefined what "bug" is, by pretending that only stuff caught by the client's automated tests are bugs. Hence, if your tests for my "int add(int x, int y)" method only test for x = 2 and y = 3, and the whole method is just a "return 5;", it's not buggy. If you wan it changed, that's a change request, mate.

Hence making possible the claim that XP delivers 100% bug-free code. Now, if you want to redefine what "bug" means, you could do the same for any other methodology, but XP zealots like to ignore that. (I mean, seriously, if "not caught by the acceptance tests" doesn't mean "bug", then Windows 3.0 was 100% bug free too. Dumbly enough it was only tested internally on identical Compaq computers, but it ran flawlessly on those and with the particular software mix used in the test. If it doesn't work on your computer, though, XP would call it a change request.)

So, heh, it's mildly funny to hear the same guys who did that reality redefinition complain about others doing the same.

Seriously, it reminds me of a joke by Vince Ebert, translated loosely from memory: If you think there's a beer in the fridge and go look, that's science. If you think there's a beer in the fridge but don't look, that's religion. And if you look, see there's no beer, and still think there's a beer in the fridge, that's esotheric.

That's what XP is: something that started as a religion, and ended up an esotheric cult.

This is actually where XP/Agile have a major advantage over other more formal processes - the Agile processes try not to promote rigid thinking and if applied correctly should be self-correcting or applied in more than just name only (but you would know that if you had read TFA).

I'll be the first to say that flexible thinking is great, and that XP even has some good ideas. The point where it fails is that "turning all the knobs to 10", to quote the authors.

Essentially what they do is discovering something like "hey, some salt in a soup tastes nice, and a bit of vinegar makes it even better"... and from there formalizing an ideology in which all soup is done only with salt and vinegar. In fact, by boiling a kilo of salt in 5 litres of vinegar, since that's the turning all knobs to the max point.

Re:yes, but here it's funnier

[mhelander]

Hence, if your tests for my "int add(int x, int y)" method only test for x = 2 and y = 3, and the whole method is just a "return 5;", it's not buggy. If you wan it changed, that's a change request, mate.

I guess you could look at it that way, but it could also be interpreted simply as an added emphasis to the importance of testing.

It's not really "not a bug" because it wasn't caught in a test - rather, the fact that a bug was not caught in a test is in itself a bug! Tests should cover the agreed upon functionality. When they don't, that's a bug.

So, when the customer comes to me and says "there's a bug here, see. This thing we agreed on (that the add method should add the integers passed to it) doesn't work - it always returns 5" I don't get to reply "No that's not a bug - because I don't have a test for it! Supply a change request for such a test, mate". What I have to do is fix my tests so that they cover the agreed upon functionality, and then fix my code so that the tests pass.

The question is what functionality I and the customer have agreed upon - that's what decides what is a bug and what is a change request. That agreement should be captured in the tests, but leaving something out of a test doesn't change that agreement.

Re:yes, but here it's funnier

[Moraelin]

I see your point, but it's not just a matter of looking at it that way. There have been and are people running around making that exact claim: that XP never produces any bug, in fact it's the only _guaranteed_ way to have a bug-free product. I've occasionally had people throw that exact idiocy at me both in person and here on slashdot. And it's almost invariably based on exactly that redefinition. They can't have a bug, because their whole contract is in the client's automated tests, and the only way to have a bug would be to not pass that automated test.

Basically you sound sane enough. There are people out there who aren't :P

Re:yes, but here it's funnier

[Ideally Nowhere]

Agreed. It's easy to just "blame management" alone but what's often left unsaid is that XP/Agile works best with experienced, quality developers. Test-driven development requires a high level of discipline and it's extremely easy to stray and start throwing in a tiny, tiny features & optimizations above-and-beyond satisfying the test scenario(s). Really, this is no different from a special-forces squad. Not everyone's cut out for it and the team's not NOT usable in all situations.

Re:yes, but here it's funnier

[svnt]

And if you look, see there's no beer, and still think there's a beer in the fridge, that's esotheric.

Honest question:
Does that joke originate the word esotheric?

m-w.com has no entry. Google suggests witchcraft, but there are few links of any value. The sentence (I guess) suggests blind & willfully ignorant faith, which does not quite specify witchcraft. Does the word have a history?

Re:yes, but here it's funnier

[geekoid]

"programmer for inexperienced freshman year programmers, but barely marginally better than a single programmer when done with experienced programmers. Both cases delivered actually less than the two programmers working separately on different parts of the problem."

except that's not what it's about.
Shared knowledge, consistency, and predictability is what it is about.

"If you wan it changed, that's a change request"
A completly impractical scenario, that shows quite a bit of ignorance on your part.
They do define acceptance test, you know. AS well as the way you get features prevent that from happening by it's nature.

Why don't you try to understand it and come up with some actual practical issues instead of groping at impracticable situations? and yes, there are problems with it.

Re:yes, but here it's funnier

[ByteSlicer]

I assume he meant to write the word esoteric (no 'h').

Re:yes, but here it's funnier

[Moraelin]

I see ByteSlicer already pointed you at the definition.

The point was the many esoteric movements that, yes, are all about believing in magic. Witchcraft, occultism, new age, etc. A lot of which aren't as much about blind faith that it is that way, but the other way around, that you can make it be that way by just believing in it hard enough. Or by being initiated enough in some mysteries. E.g., that you can make a beer appear in your fridge by just refusing to acknowledge its absence. (Though sometimes it's not as much about a physical thing that can be disproved, but about vaguer notions like "luck", "success", "good fortune", etc.)

I think IT and programming have too much of both (A) people acting as if they can redefine reality by PR or consensus or management memo, and (B) people trying to tell you that if you their hyped process of finding beer in a fridge and got none, it's only because you're not initiated enough in its mysteries.

The context in which Vince Ebert used it... well, he's a comedian. I think it was just supposed to be funny.

Re:yes, but here it's funnier

[svnt]

Ah, thanks. I thought I knew fully what esoteric meant, and it didn't really make sense in this context.

Thanks to Wikipedia apparently I can blame that on my "Western, English-speaking society" where "the term 'esotericism' is not necessarily used in the sense of mystical knowledge or practice."

Re:yes, but here it's funnier

[Raenex]

I think IT and programming have too much of both (A) people acting as if they can redefine reality by PR

Or badly misspelling words like esoteric and using them in an awkward fashion, and then trying to justify it?

The context in which Vince Ebert used it... well, he's a comedian. I think it was just supposed to be funny.

Well, I searched, and couldn't find the joke online. You're probably just be retelling the joke badly.

Sorry for the swipe, but you're being a little hypocritical here.

Re:yes, but here it's funnier

[Moraelin]

Or badly misspelling words like esoteric and using them in an awkward fashion, and then trying to justify it?

Considering that English isn't my mother tongue, if that's all you found to pick on, I'll take it as a compliment.

What's _your_ excuse? That you could do well in a spelling bee in your own native language? Heh.

Well, I searched, and couldn't find the joke online. You're probably just be retelling the joke badly

The original joke is in German, actually, so no wonder you didn't. If you need a link, look here: Vince Ebert bei Nightwash

But as long as it served to make a point, your contribution to the discussion is... what? That you can find an irrelevant detail to nit-pick on, completely irrelevant to the point being made?

Sorry for the swipe, but you're being a little hypocritical here.

Nah, no need to apologize, in fact thanks for sharing the above with the world.

See, the funny thing about spelling nazis is: everyone points at whatever most useful skills or achievements they have. Additionally, whoever has achievements of their own tends to brag along the lines of "look at what _I_ know" or "look at what _I_ can do" not "look, I found someone whose spelling I can pick on." If you need to drag someone down between you and the bottom of the proverbial barrel, you already know where you are in relation to that bottom. It's that simple.

If all you can contribute there is picking on the spelling of one word in the whole message, you already told me who and what you are. Your big skill and achievement is being able to spell an 8 letter word in your own native language. Well, gee, your mommy must be proud. Thanks again for sharing your complete uselessness with the world.

Re:yes, but here it's funnier

[Raenex]

It wasn't just the misspelling, it was also using the wrong word in a confusing way. Finally, when asked for clarification you went through great pains to justify the use of the word -- like the people redefining what a bug means. Hence, hypocritical.

Lots of ragging on Agile here

[Qbertino]

I'm reading lot's of ragging on Agile here. Maybe you guys should actually f*cking read the agile manifesto. It's only a few sentences after all. You'll notice that it's actually quite a good thing that tries to rid the software devprocess of bloat and get close to the people for whom software is written.

Whenever I've used agile with the right people, it was a breeze getting the job done. It's basically common-sence systematically applied to software developement in my book.

Re:Lots of ragging on Agile here

[Anonymous Coward]

All the buzzwords started out as good ideas I bet. They aren't ragging on what Agile was *supposed* to be, they are just upset with what it actually became in common practice. Thank you for pointing me to the good idea behind the nonsense the buzzword has started. I think I'll make it my IM note at work, sans the title, just the four lines. And wait for one of our self appointed agile experts to ask where I came up with such drivel.

Re:Lots of ragging on Agile here

[RobinH]

Whenever I've used agile with the right people, it was a breeze getting the job done.

Well, whenever I've done anything with the "right people", it's always been a breeze. The problem is that those projects are few and far between. The methodology that will eventually work the best is one that takes the wrong people and makes them productive. (Like assembly lines making cars - if you had a bunch of skilled mechanics, they could make a good car, but if all you have is a bunch of high school drop outs, and you want to build good cars, you need an extremely rigid process to make them useful.)

Re:Lots of ragging on Agile here

[Hognoxious]

whenever I've done anything with the "right people", it's always been a breeze.

If you have programmers in the top 10%, then it's not guaranteed to work. However in the absence of factors like impossible requirements, bad management or personality clashes the odds favour success much more than they would with less capable ones (who aren't immune to those factors either).

The problem is that those projects are few and far between.

Rather, it's "right people" who are rare. Not every project can hire only programmers that are in the top 10%. There just aren't that many to go around. Maybe as low as 1 in 10, by some estimates...

The methodology that will eventually work the best is one that takes the wrong people and makes them productive.

Or at least, pulls the mass in the middle up a bit. Methodologies won't help the superstars much, just like diet supplements aren't much use if you already eat healthily.

Re:Lots of ragging on Agile here

[MadKeithV]

The problem is that those projects are few and far between.

Rather, it's "right people" who are rare. Not every project can hire only programmers that are in the top 10%. There just aren't that many to go around. Maybe as low as 1 in 10, by some estimates...

That can't be right - over 75% of the developers that I've asked rate themselves in the top 10%!

Re:Lots of ragging on Agile here

[MrMickS]

Well, whenever I've done anything with the "right people", it's always been a breeze. The problem is that those projects are few and far between. The methodology that will eventually work the best is one that takes the wrong people and makes them productive. (Like assembly lines making cars - if you had a bunch of skilled mechanics, they could make a good car, but if all you have is a bunch of high school drop outs, and you want to build good cars, you need an extremely rigid process to make them useful.)

Nope. The sooner we getting out of the idea that anyone that wants to be a computer programmer can be one the better. I'm not a musician, I'm tone-deaf, so I don't pretend that I can be a rock star. Why do we spend ages trying to get those people with a talent for coding to help people to whom its just a job and have no talent for it? All it does is generate mediocrity.

Re:Lots of ragging on Agile here

[Gazzonyx]

Good. That means that you've discovered the top 25%. Anyone who considers themselves the top 10% has never read code or seen a top 10% developer. I thought I was great until I met one of those guys. It's humbling, but a carrot at the end of the stick, nonetheless.

Next time someone tells you they're in the top 10% compare their code to the Samba, Linux, or Subversion code base; they won't stack up. The problem is that the people who think themselves great aren't reading other peoples code, so they're not getting any better. Also, contrary to popular belief, preferred language means absolutely nothing. I'm sure there are VB.NET programmers out there that are excellent (Jeff Atwood, perhaps?), and I've read two books on Perl where the authors were simply lousy programmers.

Finally, formal education also has almost no bearing on talent. A developer with a formal education might know a slightly more low-level technical definition for something that a self-taught developer will just refer to "...just the way that seemed most logical to do it..." I've met a good many self described developer that really don't quite 'get' the concept of an interface, but can rattle off a textbook definition of it. For that matter, I've also seen that many programmers don't know what a library is, or they're stop reinventing the wheel for every trivial task.

Re:Lots of ragging on Agile here

[Ideally Nowhere]

Mainly because there is a shortage of quality developers. I know where you're coming from but it's a fact of life. Development is at an artisan level, much like the craftworkers & masons prior to the industrial revolution.

Re:Lots of ragging on Agile here

[Precipitous]

Double amen.

The article was beautifully insightful - where the rags are just inciting. It actually addresses many of the rags against agile.

Agile thrives when people get past the initial learning curve (past the checklist, as Cockburn points out in the article), re-read the agile manifesto, and intelligently apply the principals.

Re:Lots of ragging on Agile here

[geekoid]

True, but agile works well with any group of programmers that are competent.

Re:Lots of ragging on Agile here

[MadKeithV]

Oh hell, mediocre developers reinventing the wheel...
I can't even remember the number of times I've told a hot-shot young developer "you know, you could google it before trying to impress me with a bunch of waffle"...
Another gem is them trying to make something "as complicated as can possibly be mustered in the time alotted". Why don't these people understand "the simplest thing that could possibly work", I wonder...
But I have to work with the average developers because we simply can't find enough of the good and excellent ones - and that too is a great learning experience.
I'm learning to teach, coach, and coax the best out of these people, and often one of the "average" guys will really surprise you if you have a bit of guidance and a bit of trust in them.

Re:Lots of ragging on Agile here

[Anonymous Coward]

Manifesto: Individuals and interactions over processes and tools.
Means: Don't code, talk about it instead!

Manifesto: Working software over comprehensive documentation.
Means: Code first, decide what you're trying to accomplish.

Manifesto: Customer collaboration over contract negotiation.
Means: So what if you agree to do the imposible, it's not like people can sue you for breaking a contract.

Manifesto: Responding to change over following a plan.
Means: Never ever ever actually stick to what you set out to do.

Re:Kent Brock - s/ro/e - Kent Beck

[fbjon]

The typo was in the article before it got updated.

Team Agile? F*** Yeah!

[Anonymous Coward]

I'm sorry, but I got as far as "Alistair Cockburn and Kent Brock" and had to stop.

The lesson of Agile:

[liquiddark]

If it works, it's agile. If it doesn't, it's not. That's the problem most try-to-be-agile practitioners have with the method: It doesn't work a lot of the time, but people are happy to tell you you're doing it wrong instead of acknowledging the brittleness of the process.

Amen

[Giant Electronic Bra]

Agile works fine for us. Maybe we don't do it by some 'book', and I have no use for consultants, but what we do WORKS.

And I disagree that you have to have some exact certain people to implement it. Not that you can just take some random collection of developers and send them off to do agile development, but with one or two key people that can actually communicate and teach people how to do what needs to be done it works fine.

I've taken groups of nothing but myself and interns and done it, people with no industry experience at all. If you explain things to them and forget about being all up tight about exactly how things are structured you can build an agile work process that WORKS every time.

Re:Kent Brock - s/ro/e - Kent Beck

[Anml4ixoye]

And the article is not by Jim Shore, who wrote the linked article at the bottom of the summary. TYPO TYPO TYPO

As Usual, Scott Adams Has The Last Word

[BigBlueOx]

http://accidentaltechnologist.com/general/dilbert-goes-agile/

Comment removed

[account_deleted]

Comment removed based on user account deletion

Agile as a defense mechanism

[Jahf]

As someone who had the "fun" of becoming a scrum master at a company that was trying (and eventually failed) move off of waterfall I got to be the main Agile advocate with our management.

This company failed from both ends. Developers began to use Agile as a shell to protect them from the problems that were in the old system. That's understandable given how badly they were overworked during deadlines. However what they didn't see was how this poisoned upper management to the entire concept. Management was willing to give a little to get a LOT (they wanted projects to miraculously start to "just work" as one put it) but wanted to have the process be open. Development wanted ANYTHING to shelter them from the hell they had been going through.

Both parties were going into Agile for the wrong reasons. They both thought they were the right reasons.

By the time I got fed up and left we had everyone calling our process "Agile" because we did scrum meetings, but all the processes behind the scenes had reverted back to waterfall at the core. And when I would tell management -or- development that they were doing things for the wrong reason. I tried to avoid saying "you don't understand Agile" so that I wouldn't get defense mechanisms raised and funny part was the more I avoided using that phrase the more they would toss it back in my face (both sides). We had multiple meetings, even bringing in outside consultants, and the meetings always ended with them agreeing to the points brought up but then a week or a month later caving back to their old ways (this was a shop that was VERY entrenched in old ways, having done web services for financial companies for well over a decade).

The point here being ... it isn't always just management that doesn't "get" Agile. Sometimes the devs don't "get" it either (and very often the middle group of PMs has plenty of "wtf" left as well). Agile isn't a defense mechanism that allows you to block people from giving you work or to let you work on only the things you find interesting. And if -neither- side wants to be Agile for the right reasons it will fail hard and fast.

PS. Me? I went back to being a Sales Engineer / Field PM for companies in other timezones ... however the company I went to DOES do Agile and does it WELL. My scrum master time left me with a bad taste for ever doing it again and I will -never- try to lead a transition to Agile, but it was nice to see my opinions on processes and reasons work. I had convinced myself when I left the scrum master gig that -I- didn't "get" Agile ... but I did ... the company just did not -want- the changes required. Only the benefits.

Yet Another Fad, Misapplied

[Dragoness Eclectic]

XP, Scrum, etc. have some good ideas--however, as TFA mentions, they require *thought* to implement well. They are also not new, just re-packaged. Ed Yourdon was talking about interviewing users to find out how the system/process *really* works over 20 years ago. (His "Structured Analysis" is an excellent on-line book for learning how to design systems)

However, any method that relies on your team members being in the top 10%/experienced programmers is only going to be useful for a few, high-profile or specialized projects where you can actually hire or have available those top, experienced programmers. What the world really needs is an "Army method": something that gets useful, productive work out of any coder who isn't literally retarded. You won't get that with any method that leaves the design specs between the lead programmer's ears; the average person needs a road map and instructions. However, with sufficiently detailed, simple step-by-step instructions, a hick fresh out of high school can maintain a tank. The same thing is true of the "average" coder: with adequate design specs, any idiot who knows how to code can be productive.

The trick is coming up with those design specs, just like the brilliance of Army training is in designing the courses and instructions that enable any idiot to repair a tank.

Re:Kent Brock - s/ro/e - Kent Beck

[Anonymous Coward]

It needs Kent Brockman's two cents.

Software is about the end user, not the process.

[Richard Steiner]

Waterfall, agile, who cares?

Any process which gets the job done so the software runs well and the defects which impact the end user experience are minimized is a good process. Sometimes that process is highly formalized, sometimes not. Sometimes the process is something which an organization simply made up from common sense and experience. It doesn't matter.

Programmers shouldn't have to worry about special keywords ... let the compilers worry about that stuff. :-)

Here, Here

[Mycroft_514]

Agile does reduce some of the work on the developer staff, but we tried it here and it INCREASES the workload on the support staff by just about TRIPLING the workload. We threw it out.

Really successful techniques

[sjames]

The number one strategy for a successful project is to admit once and for all, any time estimate that happens in the first few weeks is a pure unadulterated lie. You don't know how long it takes until you know exactly what it is you're doing. In turn, you can't do that before you have the FULL specs. AFTER you have the specs AND have designed the system, then you know how long it should take.

Hint, well done software development will devote 50-90 percent of the total time to design. Translation: Time estimates are wild guesses until the project is 50-90 percent complete. If management takes the initial estimate and casts it in concrete, the project will fail.

Hint 2, those specs you got when beginning the project? Those aren't the full specs. There'll be many 'clarifications' necessary as design begins. You will know how many such clarifications are required once you have them all and not before.

Second, the first one is scratch. Inevitably once some early coding happens based on the preliminary design, tough corner cases WILL be discovered. These will require anything from a serious change to fundamental elements to a complete redesign. Any time estimates based on that design? Out the window!

Third, a good way to find the scratch early and to discover that the specs are NOT what you thought they were IS an iterative process. That won't magically make that wild guess in week one come true, but probably will make the process take less time than it would have otherwise.

Agile gets some of that right, but unfortunately wraps it all up in buzzwords worthy of a crazy cult (hint, cults love to invent new words that mean the same thing as old words AND to overload old words with new meaning. Unlike simple slang, they tend to rigorously define the buzzwords), and encourages turning 'the process' into a religion. Of course, many managers seem to turn every trivial policy into religious doctrine anyway.

Look at all the pretty colors...

[Anonymous Coward]

http://stochasticresonance.wordpress.com/2008/04/06/dropping-hits-of-agile/

Re:Kent Brock - s/ro/e - Kent Beck

[Tablizer]

Hello, McFly! It's Kent Beck, not Brock.

Don't worry, it will be fixed in TFA version 2.0.
     

Many, many monkeys

[Krishnoid]

I'd think that test-driven development would work well in this case. With debugging being more difficult than development, debugging short unit tests is still manageable. Then when poor programmers write poor-quality short unit tests, the damage they can do is limited to the test itself, which can be quickly debugged, verified correct, and 'sealed off'.

Once that's done, the other poor programmers writing the app will have a harder time diverting blame for their poor code. Then:

• They'll either fix the code, or
• standard operating practice: release the product with known bugs

In the latter case, the test suite provides customer support with a convenient list of known, on-the-spot reproducible (by running the test suite against the released software) bugs, which they can convey to their customers from day one of the release so the customers can:

• start working around them from the release date instead of
• standard operating practice: spend hours struggling with the issue
• standard operating practice: call customer support and wait for them to set up a test case and reproduce the problem

This way everybody, er, 'wins'. Your point was also reflected in 'Good To Great' (I think) when mentioning Toyota -- they 'get great results by having average people follow above-average processes'.

Hilariously 'Agile'

[Criminally Insane Ro]

I guess it's not so agile after all: apt or ready to move