Recently I attended a talk during which a leading agile consultant discussed implementing agile software development. The speaker waxed enthusiastically about self-organizing teams that would manage their own work and make most of the decisions about building software. The person sitting next to me squirmed uncomfortably. After a few minutes, he leaned over and whispered to me, "I'm a manager. With all this talk about self-organizing teams, what's left for me to do?"
Moving toward self-organizing teams--whether driven by adopting agile methods or not--doesn't mean that all the managers are out the door. There's still plenty of management work to do; it's just different work. And, for many managers, it is also more satisfying work.
In this article, I describe how self-organizing teams are different from manager-led teams and lay out how that changes the manager’s role.
All well-functioning teams serve their clients, meeting or exceeding expectations. But cross-functional, self-organizing teams can enhance both creativity and commitment. An effective self-organizing team increases the capability of the individuals and the team as a performing unit. Managers of self-organizing teams don't track day-to-day progress or set individual goals. They work to remove obstacles that prevent the team from achieving success. They work to optimize the team's ability to achieve the organization's goals.
Most of us have an image in our minds of what "team" means. That image affects how we think about teams, how we structure teams, and what we expect of the people on teams.
Manager-led teams are often like ski teams. Each person is selected for her individual skills and abilities as a skier. Each excels as an individual. All the members of a ski team are working for a common goal--winning the competition. Each contributes to success by making it down the hill as fast as she can, while passing through all the gates on the course. The coach's job is to improve individual performance skills. A ski team trains together, but when the meet comes, each team member is on her own. They don’t win by working together; it's the sum of the individual scores that wins the meet.
Self-organizing teams are more like soccer teams. Each player has a position on the team based on her skills; however, the team must work together in order to win the game. In addition, each team member constantly adjusts her position and actions to create the best opportunity to score (or to prevent the opposition from scoring). If the team doesn't constantly coordinate and adjust to the current circumstances, it doesn't stand 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 Self-organization 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, 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</FACE="ARIAL">
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, self-organizing 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 one- to two-day chunks of work than to step in and take over planning. Coach and show rather than do.
Managing Team Membership</FACE="ARIAL">
Some self-organizing teams manage their own membership throughout the life of the team. In some companies, 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</FACE="ARIAL">
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 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.
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 intelligent and relevant questions that hone not only their own thinking but also that of their customers.
Team members still need coaching to improve their technical, interpersonal, and collaboration skills. Managers of self-organizing teams still meet with people to coach, address HR issues, and facilitate career development. They help by providing context, developing skills, and helping people see new options.
I’m a big believer in one-on-one meetings. But with a self-organizing team, the timing and focus are a little different. For example, on one team, a team member distressed another team member by listening to his voice mail on speakerphone--even when the messages included intimate details of his relationship with his girlfriend. The manager used a one-on-one meeting to coach the team member to give feedback directly to the offending colleague.
Beware of discussing task progress with self-organizing team members in one-on-one meetings--unless you are coaching on how to accomplish tasks. Monitoring progress in a one-on-one meeting sends a mixed message. It conveys that team members are still making performance commitments to you and not to their teammates. It says you don't really trust the team to manage its own task accomplishment.
With self-organizing teams, weekly one-on-ones usually aren't necessary unless there is a specific coaching issue. With self-organizing teams, monthly or bi-monthly meetings seem to be about right.
Because self-organizing teams are cross-functional and most organizations have functional career ladders, members often struggle with career progression. When members are encouraged to broaden their skills rather than deepen them in specific areas, managers need to help team members see how their cross-functional and collaboration skills will fit into the future of the organization. (And managers may have to influence the possibilities for that future by working with HR to change the way people are compensated and promoted.).
Work on the Process
Edwards Deming describes an approach where staff works in the process and management works on the process--using the detailed knowledge of the people doing the work. Managers of self-organizing teams work on improving the organization's processes so that everyone can perform better.
Functional organizations tend to focus on specialized skills and excellence at the detail level. Managers of cross-functional, self-organizing teams see their organizations as systems of interdependent parts. An overall system view leads to improving the entire system, rather than focusing exclusively on individual performance. Companies still need to hire competent and skilled people, of course. And managers need to make sure that those competent and skilled people are supported--not hindered--by organizational structures, policies, and procedures.
Lean manufacturing suggests three things a manager of a self-organizing team should do. The first job of management is to reduce overburden. In manufacturing, overburdened machines break down. In knowledge work, overburdened people make mistakes, fall ill, or burn out. So help the team hold to a sustainable pace by managing the amount of work flowing into the team.
The second job is to eliminate unevenness in the work load--to create a steady flow. One way to do this is by using team velocity to allocate work (velocity is a measure of the work a team can finish within a specific time period). Create an even pace by allocating work in timeboxes based on measured ability to complete work. Over time, as the team matures, velocity may naturally increase. Even flow of work means predictable delivery.
Finally, managers need to eliminate waste. Anything that does not directly add value to a product is considered waste. Extra processes, task switching, and partially completed work are examples of waste in software development.
These three things--reducing overburden, eliminating unevenness, and eliminating waste--work synergistically to increase the capacity of the system to produce software.
When managers focus on eliminating waste without attending to reducing overburden and eliminating unevenness, they may actually do damage by eliminating slack. When slack is eliminated, people cannot respond to unexpected events and things fall apart.
Managers of self-organizing teams have plenty to do. People will still want to develop their skills and further their careers. And you'll work to improve the organization and the process to enable teams to deliver software. Manager, your work has just begun.
via http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea&id=115
Posts
