XPDay 2010 – moving Forward or backward?

Who stands before the bar?

This was the first session I went to on Monday, and I think it’s fair to say that it turned into something a lot closer to a Q&A than a ‘standard’ Open Space.

The session was organised by Fred George from Forward, an internet development firm who specialise in generating ideas and bringing them to market rapidly. They’ve got their fingers in a load of pies – everything from an internet marketing-specific search engine to cornering the UK market in parrot cages (basically they’re reselling and using drop-shippers to supply the goods). They’ve been pretty successful – last year they purchased uSwitch, the energy comparison site.

Anyway, the focus of the session was on the somewhat controversial (given we were at XPDay) way they run their development team.

Of what are they accused?

The statement that drew us all into the session – and I figure maybe half the attendee at the conference were in the room – was that they’d ditched a number of agile practices (TDD, automated testing, pairing, stand-ups…), they had no BAs, no testers, no managers, and they considered themselves “more agile” as a result.
Cue gasps of in-drawn breath from the attendees – heresy!

For all the drama, as we started talking and questioning Fred it became obvious that what they’re doing works for them.

In our defence, m’lud…

They’ve modelled their business around rapidly rolling out new applications, and the statement was repeatedly made that they didn’t do automated testing. What came out later on, though, is that they’re defining ‘application’ in a very specific context – most of their applications are 200-300 lines of code!

Their model is to create a lot of small deployables, each of such a small size that errors are hard to hide, and to always consider rewriting them rather than spending time debugging. It’s an interesting approach, and made even more sense when we elicited from them that they rely on rapid, consistent, automated deployment a la Continuous Delivery. They’re making heavy use of Capistrano, and they’re deploying dozens of times a day across their systems.

(Later discussion revealed that really crucial systems, and anything with significant complexity, does have tests – but the tests are focussed on problem areas so overall coverage is low)

They have a separate IT team, who have a couple of primary function; they own the uSwitch servers (around which there is some change management, mostly as a result of pre-existing business practices from before the takeover) but when it comes to the environments (cloud hosted, usually) they use for hosting their other apps, IT primarily support the developers, who are responsible for keeping the environments working. Definitely a DevOps flavour here.

In terms of process, they’ve dropped a lot of the overhead that other companies maintain. They’ve just fired their last 2 Project Managers; their management structure is pretty much a CEO and a series of teams, with responsibility spread across individuals but little to no management hierarchy.

Decisions around hiring, interviewing and so forth are handled more or less by consensus – the interview process is a phone chat with Fred, then a day of pairing with a team.
The ultimate expression of this was outlined in the fact that they had a CTO… but the teams reckoned he wasn’t up to speed technically so he was let go too!

Judgement and sentencing

Personally I’m very interested by their approach, but I’m intrigued (or should that be ‘concerned’?) by the very lightweight approach that seems to be taken to process in all aspects of the business; the prime example is HR. When I’m told that the main means to resolving problems is “peer pressure” it raises some flags for me; if, as Fred described, they only hire the best, and their staff is largely made up of ex-lead consultants and so forth, then maybe I can see it working, but to me it sounds like they’re skating on thin ice if anyone takes offence or considers themselves to have been bullied.

By the end of the session there was an emerging consensus that was carried forward (no pun intended) across the conference; it’s all about context. We need to realise as a community that while there’s real value in our methods, practices and habits, blindly applying all of them in every situation may not be the best way; the guys from Forward were explicit in stating that they pick the practices they use depending on context, and they’re always looking to see what they can leave out in order to move faster, because their business model relies on speed.

(By the way, the guys from Forward were kind enough to sponsor XPDay – kudos.)