Better Software - December 2008 - (Page 25)

much management work down to the team that the team doesn’t have enough time left to develop software. It’s a balance between building ownership and engagement and keeping people focused on the kind of work they’ve trained to do. The appropriate level of self-management depends on the context. Consider how long the team will stay together. It takes time for a team to learn self-management skills. If the team will only be together for a few months, it probably doesn’t make sense to train team members to manage team membership or involve them in setting direction within the organization. On the other hand, if team members will have a long life together, it’s likely they’ll be adding team members, so teach them to participate in collaborative hiring. A Tale of a Too-Hands-Off Manager I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible. But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand-up meeting, his reports were vague. “I’m coding,” he’d say. After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad. “What’s up?” Will asked. “Do you need some help?” “No,” Tad replied. “I’m working on it.” “But we don’t know what progress you’re making,” Sally said. “I’m working on it,” Tad replied, staring at the notebook in his lap. “Tad,” Will implored. “You agreed to report tangible progress every day. We all did.” Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.” The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information. “What exactly are you working on, Tad?” he asked. “The reset feature,” Tad replied. “When will you finish it?” the coach asked. “I’ll be done when I’m done,” Tad replied. “I’m working on it.” “That’s not good enough,” the coach said, laying down the law. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.” “I’m working on it,” Tad replied. After weeks of Tad’s odd behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us get Tad on track.” “You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.” The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s iteration goals. And as their manager continued with his “hands-off” attitude, team members’ morale plummeted. It felt like their manager had abandoned them. He had. Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the performance issue. Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own. How do you know when a light touch is called for and when action is needed? Ask: • Does the team have the knowledge to solve this problem? • Does the team have the experience to solve this problem? • Does the team have the will to solve this problem? • Does the team have the courage to solve this problem? If so, give the team some time to work out the issue. If you sense team members are stuck, coach them to use open-ended questions to recognize the resources they already have to address the issue. • Is this a new area of responsibility for the team? If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost. • What are the consequences of failure? Manager as Coach and Consultant Teams need to know how their company makes money. This may seem painfully obvious, but somewhere in my distant past, I met a group of programmers in a financial services company who suggested that the fund managers avoid trading options because programming for options was difficult. Once the programmers understood how much money there was to be made trading options, they saw the wisdom in buckling down and figuring out how to write the program. Team members need to understand how their company fits into the market and what their company’s aspirations are. For example, one manager communicated that the company aspired to handle 100,000 simultaneous users. Team members had this fact in their minds as they built the Web site incrementally. While the software they built in the first few iterations couldn’t handle the load, they made choices that made it feasible to build up to that level. When the team understands the business, the team will make better technical decisions. Some teams explicitly defer to the customer or product owner all decisions about the cost and benefit of building features. I find that the more team members know, the more they can ask intel- www.StickyMinds.com DECEMBER 2008 BETTER SOFTWARE 25 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - December 2008

Better Software - December 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles What's a Manager to Do? Six Thinking Hats for Testers The Key to Good Interviewing 2008 Salary Survey Product Announcements 10 Things You Might Not Know About … The Last Word Ad Index

Better Software - December 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.