Better Software - December 2008 - (Page 24)

much chance of winning, even with star players on the team. Once the team is on the field, the coach can only observe and diagnose problems. He directs the team during timeouts and adjusts strategies through substitutions. Most of his work comes before the game, building individual skills. But even more importantly, he teaches team members to work together to achieve their goal. Enough with sports analogies. What does this mean for you, a manager in a software organization? Managers take a step back—but not too far back—so they can analyze performance on the team level, not just the individual level. Then, to make it easier for the team to produce software, managers get to work on the organization that surrounds the team. How Much Selforganization Is Right for a Team? Sometimes I see teams that reject all direction and go their own way, declaring, “We are self-organizing.” They are missing an important fact. When someone is paid by a company to be part of a team, that team exists within the organizational context. The team has a customer—someone who desires and will pay for its output (or not, in which case the team should cease to exist). If a team doesn’t have a customer who eagerly awaits its product, that’s a management problem. On the other hand, some managers hear the word “self-organizing” and believe the team is on its own—that they can go into semi-retirement. But that’s not the case, either. In fact, it’s a risky oversimplification. I talked to a manager in an organization that had expended millions of dollars to train teams to self-organize and self-manage. The division then eliminated all but a few management positions. But the division wasn’t seeing greater creativity and engagement as it had hoped. Instead, highly trained technical people were leaving the organization in droves. Alarmed, the remaining managers started exit interviews. They learned that people were leaving for other companies that had traditional, 24 BETTER SOFTWARE DECEMBER 2008 manager-led teams—not because they loved being told what to do, but because they wanted to focus on the technical work that they loved. In the rush to embrace self-organizing and self-managing teams, top management had loaded too many management tasks onto the teams. Team members were spending less than 50 percent of their time on actual technical work. Now that’s a management problem. In reality, it’s a delicate balance, and the “right” level of self-organization depends on the context. Most self-organizing teams take on management in these three areas: • Managing work and monitoring progress • Managing team membership • Setting direction within the organization Managing Work and Monitoring Progress On self-organizing teams, the team creates the iteration plan, breaking down the tasks and activities to turn requirements into working software. And team members manage and monitor their own task accomplishment. But, selforganizing teams aren’t relieved of the responsibility to report their status to management. Self-organizing teams use burndown charts and task walls to make visible both progress and problems. Task management is usually the starting point for self-organizing teams. And for some teams, this is where they remain. There’s nothing wrong with that, and it actually makes sense for teams that won’t be together a long time. Managers can help teams attain this level by refraining from continually asking about progress and from adding more tasks. If team members aren’t yet able to plan and monitor their own work, it’s more helpful to coach them to identify the steps and break tasks down into oneto two-day chunks of work than to step in and take over planning. Coach and show rather than do. management announces the projects, and the developers (the programmers and testers) with the relevant skills and understanding of the project form their own teams. It’s far more common, though, for managers to assign people to teams, at least initially (although calling a group of people a team doesn’t actually make them a team). I recommend that managers use a collaborative hiring process for self-organizing teams once they’ve formed. Sticking people onto a team without consulting existing team members is a recipe for ungelling the team. Members of mature teams may themselves remove people from the team. A colleague told me a story of how they managed a lone-wolf off the team. One engineer had committed to follow Extreme Programming engineering practices but later violated his agreements with the team. When two team members confronted him, he informed them they’d be lost without him and threatened to find another job. His teammates offered to help him buff up his résumé, and he was gone within a week—no manager involved. If an employee who is unable or unwilling to work within the team will not leave of his own accord, then the manager needs to step in and deal with the situation from an HR perspective. Don’t count on this happening early in the life of the team. Before team members can manage someone off the team, they need to be able to manage someone onto the team by giving peer-to-peer feedback and constructively dealing with unwanted behavior. setting direction Within the organization Self-organizing teams make commitments, but they don’t set product direction. The vision and definition of the product comes from the customer or product owner. As a team matures, team members may influence and even help co-create the product as they develop trust and a collaborative relationship with the customer. But this is a relationship that requires high domain knowledge as well as technical knowledge and a high level of trust. It seldom makes sense to push so Managing teaM MeMbershiP Some self-organizing teams manage their own membership throughout the life of the team. In some companies, www.StickyMinds.com 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.