Starting over.

I’ve been thinking alot about, if i were to start a team from scratch again, what would i do differently. As I’ve been looking for a replacement for my role at de-construct, you ponder around these things, musing, trying to learn from your experience, and if given a blank slate – whilst there aren’t a huge amount of things i’d do totally different, there are certainly a number of approaches i’d take in the future from learnings over the past few years. One of the biggest – and this spans the entire agency – would be resourcing. We’re quite effective at having a number of developers working on a single project. We’re about to launch the Crafts Council site (check it out tomorrow at, and everyone on my team, at some point, and to differing levels of involvement, has had their hand in the code at some point. Its been a really great project. Having several developers working together means you get naturally occuring peer-review, and great iterative discussions moving the code forwards. It helps developers keep their work tidy (as there is nothing better to keep your code clear than thinking about what your collegue will say when they find your inelegant hacks), and its a fantastic way of learning.

Taking that a step further, what if you extend the model to work across your entire agency? All of the projects within the technology team are worked on by all of the team. Rather than Developer A being assigned to Project B, each project would be broken into its functionality elements, or user stories, and Developer A gets to choose which bits of work he wants to do across ALL of the projects in the studio – not just the ones he is pencilled in to work on.

Rather than having to worry about resourcing clashes (“Oh, but i need matthew to work on X all week”), your developer works on user stories of a manageable size in the time you can book him/her in for, and then the next chunk of their work may be on a totally different project. The project itself doesn’t really matter, its just delivering on the functionality which is key.

The benefits:

- All your developers will be aware of all of the projects (or thereabouts), so if someone falls ill, there isn’t a knowledge gap.
- Your developers get to work across a wider range of projects
- Your developers get to put their hand up and volunteer for pieces of functionality they’re interested in developing
- Reuse of functionality/code becomes more apparant
- If two developers are vying for the same piece of code, you might get a fight over who gets to do it. Isn’t that a good thing?
- All developers will have an interest in the overall architecture of the projects, and a consistant shared tone and approach to your code will naturally occur.
- No-one should end up getting ‘mop-up’ work, as the units of work should be discreet that a developer will always finish what they started (as well as testing it!)

I’ve seen this approach discussed before within the realms of scrum and agile – all work just get managed as a single project, and the entire workload is on the backlog, regardless of who the work is for, but i think it can exist in non agile situations also.

Leave a Reply