A functioning team is not enough. You need to have the right people working well together. You need a diverse range of expertise. Once you find the right people, trust them to do their jobs. Instead of creating a process that protects your organization from its employees, create a process that enables team members to excel.
Give the team control over its own work. They’re the experts—that’s why they’re on the team. Trust them, and back up that trust by giving them authority over the project’s success. If you can’t trust your team, you don’t have the right people. No one is perfect, but you need a team that, as a whole, you can trust.
Authority over day-to-day decisions extends to your agile process as well. Use the agile principles to change your own process rather than allowing someone to impose process changes.
Within the team, anyone can be a leader. Encourage team members to turn to the person or people most qualified to make a necessary decision. For example, when you need design decisions, ask your senior programmers for help. When you need business decisions, ask your most experienced businessperson to make the right choice.
Leadership doesn’t mean pounding on the table or shouting, “I’m most senior, so we’ll do it my way!” Leadership comes by leading. If the team thinks you’re most qualified to make a decision, they’ll follow your guidance. If not, don’t act as if you have authority over them, even if you think you do. Managers, rather than telling the team what to do, let the team tell you what they need you to do to help them succeed.
This principle has two parts: first, get the right people, then give them the power do their work right. XP supports the first part by including customers and testers on the team and involving real customers when appropriate.
XP supports the second part—giving team members the power to do their work right—with many of its practices. XP has a coach, not a team lead, who helps, not directs, team members. The planning game helps the team share leadership by acknowledging the expertise of both developers and business experts. As XP teams mature, they practice self-organization; they leave behind rules about who is in charge of what, and instead turn to the natural leader for the current task.
Adrian Howard tells the story of a team taking responsibility for its success, which helped the organization give it the authority it needed:[59]
I worked on a (nonagile) project a few years ago where we had a big cork board that had cards for the tasks each of us was doing divided into three areas:
Todo
In progress (subdivided by developer)
Done
Cards migrated from 1->2->3 over time. Big open plan office so everybody could see the board.
We were initially cursed by interruptions... we drew management’s attention to the deadline slippage they caused with very little effect. The development team was regularly shouted at for missing deadlines. Much sadness, overtime and crying into pints.
After some discussion the dev team created a new policy with the cards. As soon as somebody was asked to do something not related to an in-progress task they would get up and, taking the interrupter to the board, move their current in-progress card back to the todo area of the cork board. Only then would they go and solve the new problem.
After a couple of weeks an area below the “todo” section evolved into a[n] “on hold” section—and we asked the interrupter to initial the card when we moved it.
This pretty much stopped trivial interruptions stone cold dead. It also killed the previous blame-the-team culture for deadline slippage. People actually started apologising to us when the deadline slipped!
No new information was being gathered. We had always kept comprehensive time sheets and could always point to what we had been doing. What had changed was that the big public display of progress was visibly going backwards when we were interrupted—and the whole company could see it every time it happened, as it happened (and who was causing it).
[59] Originally posted to the XP mailing list, http://tech.groups.yahoo.com/group/extremeprogramming/message/88438. Used with permission.