A Potential Problem with Two-Pizza Teams – Compartmentalizing the solution
I have been thinking about Two-Pizza Teams and some of the potential pitfalls companies might fall into implementing this idea. And I think I have found one based on the last project I was on.
The last client I worked with had a factory style, compartmentalized view of software. They spent months working on the design and when they thought they had it right, they sliced it up into small components and farmed them out to the lowest bidder. When it came time to integrate those pieces back together, they were stunned when they didn’t fit and the application refused to run. Six teams then spent months fixing everything up to release a very fragile, but working, product.
Part of the problem was that they tried to implement and solve too much too quickly (well, in combination with the whole lowest bidder thing). The final application basically implemented the same thing four times. Instead of solving the problem for one product line and implementing a working, stable solution then moving on to the next product line, they did all four at once.
Moving this idea forward to two-pizza teams, I have a fear that companies could do the same thing. One trick to making small teams work is how you divide the problem. Each team, and thus each problem, needs to be completely atomic. Therefore, no two teams are implementing the same ideas.
If you have an application that does basically the same thing across multiple product lines, have a single team do the initial vertical implementation (i.e., end to end across all integration points). Once the initial implementation is completed and working, other teams can then build upon it sequentially, implementing the remaining product lines upon a proven solution. This will also provide business value back to the company earlier rather then later and give the user’s something to test.
I think the best way of dealing with this is to be constantly breaking up teams and not letting any team work on more then one problem together. As soon as a team has solved their problem, that team is disbanded and the team members move on to new groups. This way, you maximize knowledge sharing and allow everyone to learn about what that team did.