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!
He has capacity to speak his mind, as he took intensive courses on writing and expression in university, but that doesn't detract that his ideas are his and to each idea there is the opposite side that has just as many positives, if presented correclty.
Aglie development works, but only if people can be trained. Training is something that is omitted when it is decided on whatever model you want to adhere to. Remember we are all just animals and the more training we get, the better we are at it.
Agile process is based on feedback, and therefore programmer must be trained to appreciate and nuruture feedback from his practices too. Programmers need candy too, for rewards, and that candy is a feedback from wroking code. Given, if you are writing a disk driver, feedback is limited, compared to game developer, writing graphics or sound enegines. What Agile brings, is that rewards come at a steady pace, therefore propping up motivation of developer from development side of things. Disk driver developer must find his way to recieve rewards from developing driver code, perhaps thats why compensation is higher for the driver developers, because work has no immediately accessible of stimuli and chances to get negative stimuli, like corrupt disk of the user, are quite high.
If you code not for the sake of itself, I pitiy those people. But then they aren't on the slashdot.
Leakage from an alternate universe far from our own?
Okay, it's a universe very close to our own.
--Rob
Towards the Singularity.
I can write any program you want within any time limit you want provided ...
a. I don't have to support it.
b. It doesn't have to work.
Yes, that's funny, but it is not a joke. Processes are supposed to be about functionality and maintenance. A one-off app for a critical issue today doesn't need a process (except how to delete it tomorrow so it doesn't become part of they real system).
And that is where marketing and development differ. Marketing sees the opportunities in selling "support contracts" for code that was rushed out, filled with bugs and features that don't work.
Development only sees problems that they're going to have to fix. And fix today. And fix in the quickest possible way because the customers are complaining about a critical issue. And so forth.
So the various processes (and project managers) are supposed to translate/support both views. Get it out in time to make the sales, with a stated minimum level of functionality and no more than X bugs of various levels.
But, as you noted, it is easy to follow the process as the religion instead of recognizing that it is just a means of getting product ready for shipment so it satisfies marketing, the developers and the customers.
In the hypothetical scenario the customer introduces a critical story in the middle of an iteration. This can and does happen in Agile projects. The only problem is that the team may not be able to deliver something that it thought it would because it will be spending effort on the new story. That is ok. The primary goal of Agile is to give the customer the ability to prioritize work and manage the creation of business value.
Also this aversion toward "context switching" isn't particularly Agile. The idea behind TDD, evolutionary design, and small time-boxed tasks is to work in small chunks. I would argue that the ability to "context switch" developers while still developing value incrementally is the whole point of the Agile approach.
So why not become a programmer? Apparently, you'd work less hours, have better conditions, a better defined job, and not get interrupted all the time.
After all, I'm sure programmers' jobs are easy. Just make the switch.
In the meantime, junior, pipe down and fix the mail server.