The thing that was just so ridiculous was that we spent three months working on the design of this project. I always remember it as three but it might have been even more. We produced all these documents and then we started writing the software and doing something. It became very obvious that until anyone got to play with the system, knowing what we really wanted, it may all change. For a while we tried to maintain the designs. After a while we gave up because it was too much effort for no reward ….

At the end of the day actually we did this big design and then we planned several milestones. Some bits were end to end and those were always the most successful. It wasn’t thought through because no one had told me “Oh this is the way to go.” So we were the ones we learnt the most from. It was getting the feedback, when things were actually in front of the customer “Oh yeah, okay, that’s great and no this is that” that made the difference.

We’ve had a history of not having a much of a problem with getting work. Basically, as we’ve put out proposals they’ve been accepted. We’ve had a very high acceptance rate in our sales process, which means that in a sense the development team has always been a bottleneck.

As we have grown we’ve basically been doing more and more paid work as opposed to our product development. Product development is an area we’ve gone through a phase of neglecting and are now having to re-establish.

It has been quite hard work bringing that back in, it having been a core of our business when we started. And strangely a lot of our practices evolved out of the fact that we were our own clients. We didn’t really adjust our processes particularly in light of the fact that we shifted to actually having real projects with real clients, expecting real delivery dates and so on. Partly that was because in the early days that worked and we were able to deliver on time and so on, but that was in the mix of the work we were just developing by ourselves. So effectively that gave us slack if necessary, though I don’t think we ever realised that.

We gradually built up a business, gradually building various mobile internet services, but initially it was all self-funded. We effectively had a pool of projects that we were working on and we’d be prioritising what we wanted to do, because our clients weren’t paying. It was up to us how we prioritised things. We had a pool of developers and developers were not dedicated to any particular product.

So we might complete one task: we’d take the first prioritised story, work on that and get it done. These tasks really would be prioritised by the business team in discussion with the developers. Early on we adopted a two-week iteration and we’d just take tasks as they came. One task might be to do with one product and the next priority task might be to do with another and that’s the way we’d work.

I remember going “Hey, this is fantastic, we’re pairing.â€? I remember that there were all sorts of things about pairing, but one of them I remember was that we could work on a task and when we’d worked it we’d go and work on another task. And so we had that code ownership. I remember just how fantastically liberating that was to finally not be a bottleneck. But certainly having that sense of this task is completed: when we’ve just designed, implemented it, tested it and we’ve got the test to prove it. There was a real sense of liberation in this way of working. I’ve done really good, you know, I can go home. I’ve got this thing that works, these tests to describe and show that and this… The whole intensive working environment was exhausting but immensely satisfying. It was like a drug. I mean both [T] and I… well, all four developers went away going “This is the way we want to work.”

The one example that I must have seen on about five projects now is the testDatabase(); testDatabase() has meant five different things on all of them, a different thing for each of the projects I’ve been on. Sometimes it’s been a couple of classes and meant two different things. It doesn’t describe what it’s actually testing, or give you any information about what it is that the task is doing. Whereas when you start talking about behaviour, about the responsibilities of your task - that’s interaction with things that play particular roles and you get the notion of role-based interfaces.