TheEverybodyYesEvenThatGuyTeam

One of the original XP practices that you don’t hear much about is Whole Team. Can a Whole Team promote Simplicity in a project? I think so. Unfortunately, my experiences have been riddled with anti-patterns to Whole Team: the product manager that doesn’t want to be “too open” with the customers; the subject matter expert that barely has time for the project because they still have all of their normal job duties to perform; the end-user “proxy”. Unit tests will tell me that the code holds no surprises, but they don’t tell me that the system we are building solves the problem in the way that the customers expect For that, I need the business people who are closest to the problem, and therefore most likely, the solution.

Software is a solution – a means to a business end. Business people determine a solution, and programmers realize that solution in ones and zeros. Sure, there’s collaboration, but at the end of the day, “business people make business decisions”. A Whole Team will ensure that collaboration takes place, and is meaningful. Through this mechanism, the simplest solution to a problem is sure to be found. Simplicity at the business level is different than simplicity at the code level, but just as important. A Culture of Simplicity embodied in a Whole Team will serve all very well.

I would like to find ways to promote an atmosphere where EVERY PERSON related to the project truly feels vested in the project’s success. I want to identify anti-patterns of Whole Team, and discuss ways to mitigate the problems. I want to see automated acceptance testing tools that clearly communicate the prose around a given test case, with clear examples wired to the actual code. These tests need to be easily accessible, and extendable, to ALL members of the team. I want all statuses, schedules, roadblocks, and hurdles clearly visible because if ALL members of the team think about the problems, more creative solutions will surface.