- Avoid politics: Everyone on the team was always thinking of ways to improve the quality of the product and the code. There was no sense that people were motivated because they were trying to impress a boss.
- Do not over-engineer: The focus was on getting results, not on stroking one's ego or on doing software engineering for its own sake. All too often in the OO world, I see over-engineered code that seems to be developed out of some desire to be clever or to copy something from a book.
- Remain critical: There was a strong desire to root out problems in the design. In other words developers did not fall in love with their designs, regarded the code critically, and were eager to make changes to improve it.
- Allow some slack: Developers were able to negotiate periods of time to focus on cleaning up the design of the application rather than pushing forward with user stories. Sometimes it is necessary to go in and thoroughly clean up, especially when dealing with a legacy codebase.
- Maintain discipline: Discipline and focus was very good. Planning was done in 2 week sprints and people were not getting constantly interrupted during a sprint. One could count on the estimates provided for stories.
- Have a separate QA group: A separate QA group producing automated end-to-end tests was very useful. Together, the end-to-end tests produced by QA and the more granular tests produced by the developers provided a high degree of confidence in the code and allowed fairly significant refactorings to be done.
- Promote a team culture: Developers maintained high morale by taking an easy-going approach to the project, even at times of high pressure. On our team, the developers and QA people played video games at lunch and during the last half-hour of the day. Any kind of activity along these lines promotes a sense of team-identity. Whatever it might be, it is a good idea to come up with something non-work related the team can do together on a regular basis.
Saturday, February 12, 2005
What makes a successful XP team?
I've recently had the experience of working with a productive team and I thought I'd share the characteristics that I believe were important to its success at delivering on time with a low defect rate: