A warning about Agile methodology in early-stage development

Late last year, I helped Dan Morris with a project called “Geekmap“. The idea was to create “a social infrastructure for geeks”, as he put it, which resembled a social network like LinkedIn in that it allowed people to make professional contact, but the whole interface was focussed on navigating via geography and people’s skills. The original idea sounded pretty cool when Dan described it in March, but we didn’t start doing anything serious with it until November. Three months later, in February 2009, we launched the first version and followed it up in March with another release.

geekmap v2

The problem is, we haven’t done anything significant since that March release. In fact, we had a crisis of confidence when we realised that despite our best efforts, the people who we had in mind to first use the site didn’t have a reason to use it. Our reaction was to plan to add some things for some different people and see how that went; except, with the wind already falling from our sails, this lack of encouragement made it very difficult to maintain any momentum and we put the project on hold shortly thereafter.

Today, just over three months since that second release, I think I know why that momentum died – it comes down to our use of Agile methodology to guide our development. Agile starts from the people using the site and their goals, and encapsulates these in “User Stories“, which are your units of development. Having used it all the way through Geekmap and in other projects, I think it’s great for prioritizing your development energy and keeping close to all the non-developers.

I think that the problem was that we used Agile right from the start.

With the best intentions, we used User Stories to figure out the most basic goals of the people using Geekmap and built from there. The eventual outcome was that the site received a fair amount of development attention, but crucially, without any compelling features being built. This was becuase the Agile approach encouraged us to choose the lowest-complexity solution for any given problem – the innovations conceived in the seed idea were always tabled for some time in the near future (always the near future…).

Building to throw away

I think the answer lies in prototyping. We should have started by building a prototype from the original, visionary ideas.

With hindsight, it seems like this would have been very useful for three reasons:

  1. unknown or complicated ideas could have been explored in order to find their real utility, which would have made them candidates for fulfilling User Stories
  2. people other than Dan could have used the prototype to get to the point where they believed in what they were building and shared the vision
  3. it’s a lot easier to find people prepared to become the first customers and become a part of the development if they can see you are making exciting things

I’ve heard plenty of times that the best thing to do with a prototype is to throw it away. I can understand that now in terms of the benefits of starting fresh with all the experience of making that prototype. (Maybe don’t throw it away, open source it…)



  1. alex
    Posted June 9, 2009 at 11:55 am | Permalink


    I think that problem has been solved by GeekUp. I think Dan was involved in that.


    • san1t1
      Posted June 9, 2009 at 7:57 pm | Permalink

      My philosophy boils down to this (thanks to El K) –

      Make it work
      Make it right
      Make it fast.

      No pointing making something fast, that isn’t built properly.
      No point building something properly unless you know what you want.

      Prototype again.
      Refactor. Throw away lots of code, get rid of the worst hacks and architect sensibly.
      Then, if you need to, make it scale and optimize speed.

      • Posted June 11, 2009 at 4:47 pm | Permalink

        Have you used a particular methodology to help with that? It does sound good in principle but may be hard to get a group to work together on?

  2. san1t1
    Posted June 11, 2009 at 4:51 pm | Permalink

    Whether this is a formal method or not I don’t know.

    However, rapid prototyping in early stages, before a “well engineered” delivery commences is very useful to show customers the art of the plausible, and used quite often. However you have to be careful that your early prototype doesn’t look finished, and still has bugs, or else a client will just tell you to stop. Explaining this can be tricky.

    As with any agile practice, you change your process to suit you. This is just what has worked for me, and a few others I know.

  3. Posted June 11, 2009 at 6:46 pm | Permalink

    Thanks for the comments chaps, I think it’s very helpful to have other people weighing in who’ve already done this kinda thing.