Here we go, here we go, here we go …

I’d like to make a small prediction. At about 4am this Sunday morning at the Wellington Convention Centre, 18 webbies will be typing frantically, laughing hysterically, sweating profusely, and possibly being forced to do star jumps.

That’s because they’ll be 16 hours into FullCodePress, an international competition that sees teams of web developers compete to build a fully functioning website for a charity in 24 hours.

The 2010 event is the third in FullCodePress history. In 2007 and 2009 it was a trans-Tasman affair, with the Kiwi Code Black team returning triumphant from Australia on both occasions. This year the event is being held in Wellington for the first time. In another first, a team from the United States will join the Code Blacks and Team Aussie.

The set-up is simple. Teams of six (a project manager, a UX advocate, a graphic designer, an HTML/CSS integrator, a programmer and a writer) from New Zealand, Australia and the States are formed. They gather on the morning of the event. At about 10am they are introduced to their clients – representatives from the charities they will be building a site for. And then from 11am on Saturday to 11am on Sunday they will work like demons to design, build and fill with content a brand new site. At 11am tools are downed, and the judges called in. After deliberations, a winner is announced (history would suggest this is the New Zealand team). Celebrations ensue.

In 2009 I was lucky enough to be part of the Code Blacks team, taking the writer role. As a competitor, the FullCodePress experience is exhilarating, exhausting and rewarding. We were blessed with awesome clients in Clint and Daniel from Rainbow Youth, and I’m still proud of the site we built for them. (I’m still not proud about whining when Darren made us do star jumps at 4am.)

The way I saw it, FullCodePress was like a massively sped-up Agile project. I don’t think I would have coped with the concept of delivering a website in 24 hours if I hadn’t been part of the Digital New Zealand project (which has been committed to the Agile project management methodology since it began two years ago).

Perhaps we didn’t have formal user stories and acceptance criteria and burn-down charts and retrospectives, although we did have a stand-up every couple of hours. In fact, Haydn Thomson, our project manager, took on a textbook Scrum Master role, keeping everyone in the team appraised of where we were at, what everyone was doing, where the dependencies were between us.

My feeling though is that the most valuable aspect of Agile is what it teaches you about communication. The more projects you’re involved in that use Agile, the better you get at talking honestly and constructively about how things are going. Agile teaches you to pay attention to what everyone in the team is doing, rather than just focusing on your component of the task. It also teaches you to work in the moment: while you learn from what happened in the past and reserve a tiny slice of your attention for the future, you get better and better at saying to yourself ‘This is what I’m here to do right now’.

So my best piece of advice to the 2010 teams is: keep talking.  I wish you the best of luck – you’re in for one hell of a ride.

To everyone else: the competition is being held at the Wellington Town Hall, and (quiet) spectators are welcome on Saturday afternoon. You can follow the action and the trash-talk on twitter using the hastag #fcp10, and follow @fullcodepress for updates. And don’t forget, there’s the mysterious FullCodeGhost to shadow.

Related Posts:

  • No Related Posts

Post Tags

3 Comments

  1. Joel Hughes
    Jun 17, 2010 @ 17:34:33

    Hi,
    Interesting article – can I ask how you (or “if you”) explain Agile to your cliients, how it fits in with a clients need for a traditional proposal/specification and how it fits in with billing?

    Thanks

    @joel_hughes

  2. courtney courtney
    Jun 17, 2010 @ 17:44:40

    Hi Joel

    Thanks for the questions!

    When we’re working with a client who’s used Agile before, or committed to trying it for the first time, it works well.

    For clients who are new to Agile, we talk them through the process, provide introductory material that explains Agile terms, tools and processes, and lend them books.

    We find that once you’ve built a good long-term relationship with a client you can start introducing the idea of working in an Agile way. And even on projects that are being run using traditional project management methodologies, internally we continue to use Agile tools and processes to manage our own work.

    I guess that, like I said above, it’s all in the communication!

    — Courtney

  3. Joel Hughes
    Jun 17, 2010 @ 17:58:46

    Thanks!

    When the client has bought into Agile – is billing more likely to happen on hourly rates rather than predicted fixed costs? I know it depends but, from what I can see, agile allows you to discover as part of development and, if some cool opportunity comes up, then how is that tranlsated to the client and costed?

    Thanks for your thoughts – as you see I’m interested in agile (none of my clients would have heard of it though!) – especiallly for the bigger, bespoke development projects. I like avoiding the the all in specification stage but only if hours don’t go out of control and world delivered greatly out weighs monies billed.

    @joel_hughes

Leave a Comment

*