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.
Gradually we’d come to the point where we were too big to work as one team. We also moved premises into the centre of London. We split into two separate development streams - we’d assign particular projects to each stream, but each stream would still be managing several projects. We still had no sense of developers being associated with this project or that project.
We also didn’t have any people who were formally project managers within the organisation. Someone would be nominated as the tech lead role on a project and they would have to do the project management. They would work on that in conjunction with someone else, whoever was the account manager, though they probably didn’t use that name. There was therefore notionally someone on the development team who was associated with a particular project, but otherwise it would be whoever was available to pair having finished a story.
And things went on in that mould for a while. We grew and expanded and added another development stream. But it was only probably around the beginning of last year that we became big enough that we started seeing the problem. Some of the things that we were doing that should have been problems in a way but actually weren’t, we had been able to cope with when we were smaller. They now were problems. So we had to start saying “Actually…”
We still have development streams and development streams still have responsibility for more than one thing, but normally they’ll be focused on just one client and, wherever possible, one main project. Typically part of the point is that we are an application service provider, which means we are responsible for the running and maintenance of these services, not just “Oh, yeah here you go, now get on with it”.
We don’t have any separate part of our organisation that deals with that. There’ll be the project where something took a bit longer to approve or didn’t go live when we expected, so there’ll be some follow up.
We went through a phase where we’d often take the simplest solution if we had problems rather than thinking it through completely. We seem to be trying to rectify that, though some things are harder to rectify than others.
So, for example, we were finding that, with all those different projects, trying to organise the work between the developers and between the streams was taking a lot of time. So, the solution we came up with was to extend our iteration period from two weeks to three weeks. [LAUGHS]
The three week cycle still exists in our organisation. What it means though now, is that with some exceptions (and we do make exceptions, we do recognise if there is a problem), normally developers will be assigned to a stream for a three week period. The projects that are assigned to those streams are assigned on a three weekly basis.
But from time to time we have to change things. From time to time we arrange that developers - if we know that a project actually will be finished after the first week - are in this stream until that project is finished and then they’re reassigned to another stream for the remainder… So we try and show some agility. [LAUGHTER]
delicious
digg