I’ve discussed IT methodology on many occasions on this blog. One term that crops up regularly in IT circles when discussing how to get things done is “Agile”. I can only honestly discuss this approach as an outsider as I’ve never followed it in a work situation.
Essentially, the idea behind Agile is that rather than spending a long time designing and planning what you’re going to do, you get to the actual creating phase as quickly as possible. What comes out the first time is unlikely to be “right” but it’s a prototype that you can actually assess in a hands-on way. Then you go through iterations of the project as quickly as possible, discarding what didn’t work in the last iteration and adding enhancements.
My view of this as an IT methodology is that it includes some good ideas but I recommend practicing extreme caution around anyone who preaches its virtues in an evangelical way. And regard anyone selling books/training/seminars on the topic with deep suspicion. Having said that, I’ve decided to apply my rather limited knowledge of Agile methodology to a non-IT “project” I’m undertaking.
I’ve mentioned before that a cable TV comedy show is running a competition whereby you submit a video of yourself doing a comedy routine and if you win, you get to perform on the TV show. This would probably be viewed by marginally more people than the stuff I put on YouTube but it would sound cool to be able to say I’ve been on TV. The stuff for “The Fizz” hasn’t gone to air yet so far as I know so this would be my first TV performance if I won. I have about a week before the deadline for submission to practice.
So the plan is this: I put up a video of me doing a routine (nothing new there), then I ask for feedback (also nothing particularly new there). But then I employ Agile methodology. Based on feedback (plus what I think of the performance) I do another “iteration” of the routine and post that video the next day. I ask for feedback and review this iteration again, trimming the bits that aren’t working so well and maybe adding some new bits. I repeat this process as often as I can (or as often as seems useful) up to the point where I submit my piece to the competition.
This is history in the making, people. Applying IT methodology to the world of comedy using the vast internet as my test lab. I hope you can all join in. I also announced this plan on YouTube last night via the following video. And just for Suroor, I added a bit about how goddam angry my business shirts make me 🙂
Angry 365 Days a Year 
Just don’t start naming calling in the audience, or this might be the result: http://raincoaster.com/2006/11/23/t-shirt-o-the-day-kkkramer/
And, of course, you can talk about agile without: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html
(for the one person who has never read it in the audience)
yeah, that’s not the t-shirt I want of me! I love that piece of Stevey’s too. Maybe one day I’ll work up a complete geek routine to do at IT conferences 🙂
I’m glad I no longer have any IT design or implementation to do. The only thing that I do are my own projects.
range: that’s the future I’m hoping for too.
I have just come across your site and wet myself laughing, I am a 47yro closet angry Aussie, who regularly rants on slashdot, though we probably differ on the subject of bongheads. For some strange reason I picked you as a geek straight away (probably the heavy use of analogy thing).
I hold a BSc in computer science and have been a contract software developer for 15+yrs, I belive “agile programing” is a good aproach when you are still figuring out what the hell “it” is. The analogy works well for feeling your way into new territory, but if done badly the maintenace will kill your project before it reaches puberty.
As for large commercial software projects ( > 10 contributors ), without some sort of “manual” (ie: specs) it becomes impossible to split off an independent test team and design tests in parallel with the coding effort, either the projects elepsed time will grow (accountants hate that) or bugs will be missed (everyone hates that). The most effective method for these type of projects involves communication between all “players” formalised via a “user manual” and tested to predetermined standards.
The downside of “my” method is that it encourages PHB accountant types, these people (the ones with the money) stick to the traditional method not because it’s cheaper or even usefull. It’s because the project’s “value” is predictable in dollar terms since via the traditional method the cost of the software widget is predictable. If predictions (milestones) start to fail on a regular basis the money tap is turned off to avoid further “waste”. Another side effect of obsesive bean counting is seeing an executive in hot water because his softare widget was delivered $4.5M UNDER a taxpayer funded budget.
hopefully you won’t end up with “spaghetti comedy”, like most of the “agile” projects i’ve been involved in ended up as spaghetti code (“maintenance headaches”, as Alan implies) – loved the last 1/2 of the routine, especially the boss, the meeting, the ‘who moved my pen’, and the moment of sudden silence! i thought it was a bit slow getting into it (too much on the Agile, too much on the shirt perhaps (i’d definitely keep the shirt stuff, just s little less on it) and drop the michael richards’ reference (yuk). i’d try and find another ‘losing your shit’ analogy. but by the end you’ve really built up a nice run – had me laughing too loud and it’s 7am and i’m trying not to wake the kids :}
jus imagine the day, you turn on tv and it shows mr angry’s videos 7/24? it must be in hell, right?
btw i dont like the agile method, it’s not much useful for me, jus imagine me spending hours finishing and polishing a sample then wtf let’s try this acid on it & bang…… i wont be alive to give it a second try 🙂
Alan: check my recent “The Myth of Project Management” for my views on methodology 🙂
Tom: I hope my head doesn’t end up as far up my arse as some agile evangelists get.
hellboy: that would be hell. Moderation in all things.