Multiplexing An XP Team

All of the writings on XP that I’ve seen seem to assume that a development team only ever works on one project at a time – there’s one product to develop and deploy, one client, one timeline etc. Oh what a nice world that must be to live in.

At Ephox we work on a large number of products - all centered around the same core editor – and each product has it’s own requirements, clients and timelines that we have to satisfy. So how do you juggle these different projects so that you make optimal use of your time and keep all the products moving forward?

One option is to split the engineering resources up among projects – these people work on product A, these ones work on product B and these work on product C. That’s fine if you have a lot of engineers to divide between compared to the number of products, but doesn’t work in Ephox’s case since we have a small number of engineers and a large number of products and product integrations to maintain and develop. If we split up our team we’d have a singe person working on each product and a few integrations left unowned. To complicate matters we don’t want all our products to move forward at the same rate – integrations require far less work than the core products and quickly run out of features to add etc. Sometime we want to focus on getting a release of EditLive! for Java out the door and then later turn our attentions to EditLive! for XML. Moving engineers between teams isn’t fine grained enough for this kind of task and engineers take time to pick up the product specific information.

Instead, we’ve taken to pooling engineering resources and letting the product manager pick user stories to complete for any project whenever he wants (we fortunately only have one product manager – I’m not sure how we’ll do this once we need to share the product management workload). As he thinks of feature ideas they get written on a card and added to the pile of things we might do someday. In each planning session we pick cards out of that pile regardless of which product they are for, prioritizing them only on how much value they deliver to the business.

One key part of making this work is realizing that there is value in completing a bunch of features for one product together so that we can ship a new version of the product. Until we actually release a version to the public there’s little or no business value in any features we’ve added. The product manager has to keep track of when new releases are due and what key areas are being focussed on for that release to make sure that the appropriate stories are implemented in time.

From an engineering point of view, this means we all need to be familiar with all the codebases but that shouldn’t prove too difficult since we’ll be regularly working with all of them. Most importantly, if an engineer is hit by a bus we won’t suddenly have lost all knowledge of one of our codebases.