Can Agile Methodology be adapted for stand-up comedy?

About a week ago I embarked on a little experiment that was somewhat of a melding of my professional life as a Business Analyst and my favourite recreation – doing stupid comedy videos for YouTube.  I decided to enter a competition being run by the pay TV Comedy Channel in Australia.  It was a simple enough competition; submit a video of you being funny.  This seemed to play to my strengths so I decided to give it a go.

Now, I could have simply worked on a routine and submitted the video but that would be ignoring the strengths of the system – namely being able to get feedback from viewers and using that to improve the performance before submitting a video to the competition.  And what methodology promotes itself as a way to achieve delivery via multiple rapid iterations?  Agile, of course!

It seemed as though the geek and the performer in me would finally meet and get a chance to work together.  A few disclaimers about me and Agile: first, I don’t know a damn thing about Agile in any formal sense.  Basically, I know what I’ve picked up from reading articles and blogs but I’ve had no training.  Then again, when they’re put on the spot about Agile’s lack of suitability in particular settings, its evangelists usually say “use what works – ignore what doesn’t.”  So I planned to take the “launch a prototype, get feedback, re-work the prototype, release another iteration” approach and ignore any of the finer points of the methodology.

I’m just geeky enough to be fascinated with how the process of developing a stand-up routine mirrored IT development so closely.  The essence of this routine goes right back to the first video I ever put on YouTube in those dark and far-away times of June 2006:

The URL for this video is http://www.youtube.com/watch?v=CT2rTapxI4E

So to treat this as an Agile project I looked at the three key requirements:

1. An original routine
2. Less than three minutes long
3. The video file had to be less than 5MB

In considering the first iteration I actually decided to ignore requirements 2 and 3.  These had to be met for the release version but I decided first to simply do something and refine it as the iterations progressed.  So this was the first version I released for review (regular readers may have seen some of these videos but I’m including the whole series here to illustrate the process):

The URL for this video is http://www.youtube.com/watch?v=Uph6uYz5kTE

The responses to this prototype were broadly positive and included “keep it simple” and “more anger”.  Obviously it also had to be shorter, so on to iteration two:

The URL for this video is http://www.youtube.com/watch?v=vIomX1lK1Lw

The key feedback that came out of this iteration was “lose the conversation with the cow-orker.”  The next version took this on board and worked harder on meeting two other requirements; make it shorter (mandatory) and make it angrier (optional but nice to have).

The URL for this video is http://www.youtube.com/watch?v=JrzJilgsz9Q

The “user” feedback to this iteration was overwhelmingly positive.  At this point it’s fair to say that the users’ “wants” had been met (it was regarded as a funny routine) so the final iteration had to meet the mandatory requirements: it had to be less than 3 minutes long and the video file had to be less than 5MB.  These requirements proved to be more difficult to meet than I had foreseen, especially the 5MB limit.  I’ll be exploring the “lessons learned” in detail in another post but suffice to say that leaving critical technical requirements until the last minute is not a good idea.

The important point is I got there in the end with this final iteration:

The URL for this video is http://www.youtube.com/watch?v=HFf0vuAbOJ0

So, to answer the central question of this post: Can Agile Methodology be adapted (successfully) for stand-up comedy?  Well, there are two measures of success in this case.  One is whether or not I managed to deliver something according to the requirements and the other is whether or not I actually win the competition.  To the first, I’d give a resounding “yes”!  I was not exactly surprised but certainly very pleased with how well this approach worked.  As for the competition, I should know the answer to that within about 48 hours.  I have no idea how many people have entered the competition or what the standard of my competitors is, but I think I’m in with a chance.

The nerd in me can’t resist following this experiment up with a more detailed “post-implementation review.”  It has been fascinating to me how closely this development cycle has followed my experiences in the IT world.  I know I’ve often thought my job was a joke and it appears I may have been closer to the literal truth than I realised.