Extreme Programming Challenge Twenty Four

Disparate Teams to Integrated Product

A company produces a set of highly individual very customisable productivity products. Each of those products has been developed by a small team. There is also an "infrastructure team" that produces components and libraries that promote a common look-and-feel, common clipboard formats, and other shared functionality. All existing code is written in C and C++, but each team has its own source code repository, and except for the infrastructure team, the teams have not coordinated their efforts or previously worked together. The teams don't use XP, but are all accustomed to lightweight informal "whatever gets us to market fastest" methods.

The teams are located on different floors and different ends of the company building. One of the teams works in a different city. The teams also have some members that telecommute. Some reorganization of office space is feasible, but it is unlikely that it will be possible to get everyone in the same place.

Management has decided to sell the set of products as a fully integrated productivity suite. They have developed a set of user stories detailing the types of tight integration between products they envision. In addition to the integration stories, there are also new-feature stories for each of product components that management wants to have ready for the next major release, naturally all to an aggressive timescale.

The sales force has already started talking to potential customers about all these new features, and is (surprisingly) offering some useful feedback about which stories seem to be most exciting and which ones are duds.

There is a small QA team over at one end of the building that has been responsible for testing, documentation, packaging, and customer support of all products. Some customers are willing to act as beta testers and would like to try out new stuff whenever it is available.

Your Mission...

You have been brought in as a consultant to give advice about how to manage this effort. Management and developers are open to XP, but aren't sure how to apply it to their situation. Some of their questions are

How should the existing teams' work be brought together?
Should we eliminate the existing teams in favor of one big team?
Should we create a new integration team that handles the integration stories?
Should all the code be brought together into one big source tree? ...
Would you like to be put in charge of this?

Intention: This example is intended to explore how to use XP principles to integrate the efforts of multiple teams who have not worked together due to history, geography, or organizational issues.

Try in a small way first... Hmm. How about starting off in a small way, trying to focus on increased cooperation between teams? Discover what the right approach is incrementally (the Xp way). Train up members of the existing infrastructure team in Xp and then have them work with memebers of the other teams to get to see more of how their infrastructure gets used from the other side of the fence.

Bring those sales guys over at least weekly. At the moment they are the nearest thing you have to customers.

If there's any kind of a delivery schedule you are going to have a big problem with teams trying to push back work onto other teams. Deal with it right from the start by getting the team leaders to understand and buy in to the approach. Get team members used to the idea that if a 'problem' gets shifted off to another group they will likely find themselves seconded to the other group to pair-program and assist with that group.

Try and get a sense of fun into the whole process. This will help the people who welcome change to sway over the grouchers.

Clarifying The User Stories:

Hmm2. Your biggest problem is going to be architectural. You'll end up with a baroque collection of sort-of cooperating tools, or very 'light' integration. Keep asking how you can shrink your codebase without losing functionality. Are the user stories going for light integration or full integration?

For pair programming to even get started, the teams involved must have a (reasonably) uniform development environment. It won't be enough to say "We all use C++". Choose some simple tools for compiling, building, testing, source code control and editing. Make sure no one just assumes certain tools or third-party libraries are in use, even check the versions.

Let your QA folks know what type of machines to buy and what platform to install.

See ExtremeProgrammingChallenge