Many people's perspectives must come into play for effective software development to occur. The XP practice Whole Team suggests that a variety of people work together in interlinking ways to make a project more effective. They have to work together as a group for each to be successful. Everyone on an XP team has linked his future in the realm of work. XP started out prescribing effective ways for programmers to behave on a project. Here are the beginnings of prescriptions for each member of an XP team.
The principle of flow suggests that more value is created in a smooth, steady stream of software than in occasional large deployments. Flow is particularly important in structuring the different kinds of work that go into software development, but it can be difficult to apply. I remember sitting in an all-day meeting planning how an organization wanted to develop software. The programmers and executives were there at the beginning of the day. Representatives of different specialities were scheduled to join the meeting throughout the day to give their perspectives on what style of development was needed.
The programmers started by talking about XP: risk management, immediate return, feedback, and why we favored activities over phases. Heads were nodding. It all made sense.
Then in came the architects. They explained that, while XP was okay for programming, if they designed the architecture in a phase at the beginning of projects everything would run much more smoothly. They were showered with the arguments for flow and how that meant that they would have to continuously refine the architecture as they went along, starting with just enough architecture to get going. They reluctantly agreed that they could do so, but it wouldn't be as good as an architecture phase.
Next came the interaction designers. They explained that, while XP was okay for programming, if they designed the interaction in a phase at the beginning of projects everything would run much more smoothly. The programmers, executives, and architects came back with all the arguments for flow. The interaction designers supposed they could continuously refine the interaction, starting with just enough interaction to get going; but it wouldn't be as good as if they could do their work at the beginning of the project.
By the time the infrastructure planners proposed that we let them make all the infrastructure decisions at the beginning of the project, the meeting was getting comical. It didn't take long to get their reluctant agreement to work incrementally.
There was no happy ending to this story. You can't be convinced against your will. None of the groups saw themselves as part of a larger whole. Under stress, they reverted to trying to do all of their work up front.
It was as if the different perspectives were roped together walking up a glacier and all they wanted to do was argue about who got to be first in line. It didn't really matter who was first. What the whole team was missing was a sense that they were roped together. Walking abreast, they could make more progress than if any one group tried to force the others to follow.