Executives provide an XP team with courage, confidence, and accountability. The strength of an XP team, shared progress toward shared goals, can also be a weakness. What if the team's goal doesn't align with corporate goals? What if the goal drifts because of the pressures and excitements of success? Articulating and maintaining large-scale goals is one job for executives sponsoring or overseeing XP teams.
Another job for executives sponsoring or overseeing XP teams is monitoring, encouraging, and facilitating improvement. Since the goal of XP is making outstanding software development the norm, executives have a right to see not just good software coming from the team, but continuing improvement as well.
Executives are free to ask for explanations about any aspect of an XP project. The explanations should make sense. If they don't, the executive should expect the team to reflect and provide a clear explanation.
Executives should expect honesty and clear explanations of options from the team in any decision-making process. The executive needs to keep perspective in the face of problems, focusing on the actual needs of the organization and requirements of the project even when faced with the need to cut scope. Because of frequent, open communication, when such a decision is required, the executive already has the information necessary to make an informed decision.
I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve.
The second metric I use is the time lag between the beginning of investment in an idea and when the idea first generates revenue. Even small organizations typically find they take more than a year from investment to return. Gradually reducing the time from investment to return increases the amount and timeliness of feedback available to the whole team.
Both post-development defects and investment-to-return are indicators of team effectiveness much as a speedometer is an indicator of speed. You don't make a car go faster by grabbing the speedometer needle and moving it over. If you want to go faster, you push on the gas pedal and then look at the speedometer to see if that was effective. Similarly, while you can set goals based on metrics, your team needs to address underlying problems. Trying to "game" the numbers directly will not result in improvement of anything but the numbers and defeats the value of transparency on the project.
XP teams may not match the organization's expectations. Part of the executive's job is presenting the team positively to the rest of the organization. The team is willing to stand or fall on its own merits. The executive needs to have the courage to proceed in the face of criticism. Once the team begins deploying new functionality frequently, the bottleneck in the flow of value will shift elsewhere in the organization. The executive needs to prepare the company to see this shift in a positive light. After the constraint shifts, executives must be prepared to stand firm in the face of demands that software development change back to keep other departments from looking bad.
People evaluating XP teams should understand what an effective team looks like. This may differ from other teams they have seen. For example, talking and working go together on an XP team. The hum of conversation is a sign of health. Silence is the sound of risk piling up. Executives may need to learn new rules of thumb to understand and effectively apply their experience and perspective to XP teams.