Slashdot Mirror
You Call This Agile?
JoelonSoftware's most recent piece is about some of the fallacies in "Agile" software and some of the issues within it. We use Agile in some parts of the company, and have had success with that -- that said, there's always the peril that happens when development and other parts of the company have...miscommunication, which sounds like the problem described in Joel's piece.
I think one of the blessings and curses of methodologies, in this article's instance, "Agile" (ha!), is they are their own universe. So, unless there is something within the methodology that is self-contradictory methodologies don't have fallacies. Methodologies are theses, usually tepid ones at best.
Methodologies are someone's or some group's or some company's idea of a way to successfully accomplish a task, project, etc. Fortunately for all who sell these (vapor)wares, methodologies never fail, they merely suffer from those who have improperly used them.
Methodologies then become the convenient whipping boy for work not done satisfactorily. Sigh.
Peel away the layers, eventually it all still boils down to knowing what you want to do, knowing how to do it, and doing it with a strong instinct for balancing things that matter and things that don't. Methodologies won't do that for you, good project managers will.
(Some of the very best and most successful projects I worked on were with a friend who I consider to this day to be one of the best project managers I ever knew (and I knew many). He used no methodology, but had incredible instincts and a strong will. He knew how to handle time frames, important (and not-so-important) crises, difficult workers, and how to prioritize. It's a shame he didn't get better recognition - he might have had he "used a methodology". I found it ironic he was ostracized/admonished by the company, but he continued to be their go-to guy for the important work.
Bottom line, "Agile" isn't. But "Agile" is just one of a long list of bit players for methodologies in IT.
... isn't the whole issue with interuptions. That can be handled differently depending on the work (if you are making life-saving heart monitor software, you had better fix a bug the moment it comes up... if you are making some tool that other developers use once a week, a bug isn't that big of a deal)
The real advantage is illustrated in the age old swing cartoon. By using scrumm and delivering sprint demos often to the user, they can see how their money is being spent, and can present requirement changes to the user faster, thus eliminating the need to make resounding changes right away... Agile development anticipates requirement changes, instead of ignoring it like past methodologies. Is it the best? Probably not... is it a step in the right direction? You bet your ass...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
The whole point of the "stick to the plan" and "no interuptions" rules
is to focus project leaders on stopping trivial interuptions of the
" who knows how to load paper " and " could you check over my presentation"
type which will happen 10 times a day if there was no rule.
Worse the avergage program will load the paper or check the presentation
thus reinforcing the "its ok to interupt these guys there only programmers"
attitude.
If you have a rule and a fancy methodoligy its easier for the project
leader to field interuptions without appearing rude and unhelpful.
I used to go to the secure telecoms room when I had serious stuff to do
as hardley anyone had access, nearly always got a chill from the AC though.
Old COBOL programmers never die. They just code in C.
Seems like this is just another shot in the feud between Spolsky and Heinimer Hansson?
Computational Chemistry products and services.
I get a chair that has the height-adjust lever broken off, I get to pay for M&M's out of the vending machine, lunch consists of a brown bag at my desk, my computer only has 256Mb's of RAM to run bloated IDE's on, and I have a 17 inch dell CRT.
;)
Where do you work, and where can I submit my resume??
I got nothin'
Pardon the rant, I'm having a cynical week this week.
Used to be, there were generalists writing code. It was possible for one person to understand security, IO performance, database design. Not any more. Now, projects, even individual applications, are too complex to be understood by one person. This forces specialization. Back in the day, system administrators were often the in house generalists, accepted as relatively unproductive coders, but peers in the architecture process.
Nowadays system administrators are rarely asked to help in the application architecture process, most apps are rushed into production with enough crap in them so that we sysadmins are fully occupied devising clever kludges to work around bugs and security holes in already-deployed code. It's a living.
Give a man a fish and you have fed him for today. Teach a man to fish, and he'll say "WHERE'S MY FISH, YOU IDIOT?"
This article appears to be written by Captain Obvious and his sidekick, Common Sense.
But the thing of it is, you see, is that Project Management has trouble seeing the obvious, and needs a regular kick in the pants.
I am regularly asked about how long some feature or other will take to implement, and generally give a response in terms of man-days or man-weeks. What's fun is to see how this is interpreted by a Project Manager.
"This feature will take 5 man-days to implement."
Manager: "So, it will be ready on (20, 1, 2, 3, 4, 5...) the twenty-fifth. I'll put that on the schedule."
"No. I said 5 man-days. That's not the same as calendar days, and we're shut down the 24th and 25th."
Manager: "Oh, right. So, next Tuesday, then."
"No, I said man-days, which are not the same as calendar days. We don't have any one who can start on this at once, and everyone already has work to do."
Manager: "Oh. Well, can you start on this tomorrow, then?"
*SIGH* And these are the folks who are creating all the pretty PERT and GANTT charts for senior management.
It sounded nice to hear Joel debunk the agile anecdote as anti-agile and then offer his own real world example.
Problem is his example leave his own "agile" slip showing a bit. His example is as follows:
MS released IE7
This broke a proxy server DLL thingy
Which in turn broke their own Copilot app for a few customers
Which meant he had to divert Ben from a 2 week release, fix the problem, patch the server and delay the release
And this interruption of their agile development was the right decision because it served the customer better
Setting aside the issue of an individual programmer (Ben) deploying fixes straight to production, here's the thing Agile-Ben should have asked: "how the hell did we let the big IE7 release come along, hoze some of our users, interrupt me and probably cause the next release to be delayed?"
Assuming it wasn't part of Ben's agile programming job to regression test and qualify major platform changes for released products, Ben should be saying, "screw this 'it was the right decision to interrupt you' idea. We shouldn't be in the this place to begin with."