Practice: Coaching and Team Development

Practice Coaching and Team Development

Objective

The objective of coaching and team development is to unleash the capability of the team by helping team members continuously improve their domain knowledge (technical, business), self-discipline, and "teaming" skills.

Discussion

This practice works in close conjunction with the Get the Right People practice. Many project managers view their job as getting the best utilization out of the staff assigned to them, but that's not enough. Ongoing staff development is every manager's job, whether she is a project manager or team leader. While project managers strive to get the right people, with both the right skill set and attitude, there is also a pervasive belief in agile projects that we can always improve performance, that we continually strive for excellence.

As I mentioned in the introduction to this chapter, the six key building blocks of coaching and team development are focusing the team on delivering results; molding a group of individuals into a team; developing each individual's capabilities; providing the team with required resources and removing roadblocks ; coaching the customers; and orchestrating the team's rhythm.

Focusing the Team on Delivering Results

Every team member gets mired in details and forgets the goalat least periodically. Good project managers remind the team about the goals from time to time by revisiting the key constraints and tradeoff parameters and by reinvigorating the group with the ultimate purpose of the project. This is part of encouraging exploration, which might be considered a leader's cheerleader role, but it's one that must be based in reality rather than fantasy. Team members want a boost every now and then, but they don't want meaningless rah-rah speeches. Team members want the facts, even negative ones, so they can help figure out how to deal with the situation.

One of the key motivators for individuals is understanding what is expected of thembut in terms of outcomes, not steps. Great managers and leaders manage outcomes, not activities. "Define the right outcomes and then let each person find his own route towards those outcomes ," Marcus Buckingham and Curt Coffman (1999) recommend. If you have the right people, they want to know what needs to be accomplished and their role, but they want to figure out how to deliver the results. They want to understand why what they do is important, and they want to work with a team that is committed to delivering quality work. [3] Individuals assume accountability for delivering certain features, while the team as a whole assumes accountability for delivering all the features planned for an iteration. The project manager holds both individuals and the team as a whole to their commitments.

[3] According to Buckingham and Coffman (1999), these are two of the twelve core elements needed to attract , focus, and keep key employees .

On large projects it is difficult to keep the end goal in sight without giving in to the worry "I don't know how we're ever going to finish this." Part of the value of an iterative approach, which needs to be reinforced by the project manager occasionally, is that it breaks very large development efforts into manageable chunks . While facing a two-year development effort seems daunting, trying to deliver a handful of features in the next few weeks doesn't. The project manager needs to help the team balanceunderstanding the end goal but working hard in the present iteration. She begins each iteration by reminding the team of the overall vision and constraints of the project and reiterating the vision box and project data sheet information. The vision provides a context for day-to-day decisions about current work. She then rapidly focuses on the next iteration and, in particular, the theme of the iteration.

The manager helps the team focus on both the overall goal of the project and the iteration themes. This may appear to be an easy task, but with the high rate of change and the pressure to deliver quickly, the task is a difficultand constantone.

Molding a Group of Individuals into a Team

Tom DeMarco and Tim Lister (1999) use the term "jelled team" to define when individuals make the transition from a group to a well-functioning team. But getting a team to jell isn't easy (few teams actually make the transition) because it involves four things that are difficult to achieve in any group of people: trust, interaction, satisfactory conflict resolution, and participatory decision making. Teams with little trust interact on only a superficial level. Lack of interaction fosters a focus on individual rather than team goals. Unsatisfactory conflict resolution reduces trust. Win-lose decision making undermines people's commitment to the team.

Trust is an easy word to bandy around, but it is a difficult thing to achieve. "Trust is the confidence among team members that their peers' intentions are good, and that there is no reason to be protective or careful around the group," says Patrick Lencioni (2002). Trust enables team members to share half-baked ideas without the fear of ridicule. Trust and respect are also closely tied togetherit's difficult to respect those we don't trust, and vice versawhich is one reason that getting the wrong people on the team can have such a detrimental effect. Respect comes from understanding other people's roles on a project. Engineers need to understand how product marketing contributes to project success, and product marketing likewise needs to acknowledge engineering's contribution. Frequent interactions help generate understanding, which in turn can lead to respect and trust.

Managers have to trust also. Authors Buckingham and Coffman (1999) have an interesting twist on the common view of earning trust. They contend that great managers reject this view. "They know that if, fundamentally, you don't trust people, then there is no line, no point in time, beyond which people suddenly become trustworthy." Managers who fundamentally don't trust people will jump at the first failure to impose strict controls: "See, I told you we can't operate without rigorous controls." Conversely, managers who do trust people know some failures will occur because of human nature. For the few truly untrustworthy individuals, the great managers have a solutionget rid of theminstead of abusing the entire organization with burdensome controls. As I've observed , "Managers in organizations either have a fundamental trust of people or they don'tthere is no middle ground" (Highsmith 2002).

Jelled teams often have fierce debates and conflict over technical issues. Part of the project manager's leadership role is to channel the debate so that it builds trust and respect rather than undermines them. The leader can facilitate this by focusing the discussion on the issues and not on individuals. Managing the "mood" of the team (mostly by managing one's own mood) is one of those "soft" leader skills that are so hard to do well. While self-discipline comes from within each team member, a leader can help the team build its discipline of debate, conflict, and decision making to further "jell" the team.

Interaction drives innovation. One of the tenets of adaptive organizations is that innovation emerges from the interaction of diverse individuals, each with ideas, who bring information and insight to the development process. Product development projects usually involve teams whose members possess a complex mix of information and talents. Engineers, product specialists, and scientists from diverse domains must consolidate their expertise into a consistent, high-quality product design. To accomplish this goal, individuals balance time alone to develop their particular piece of the product puzzle with face-to-face time with others to fit the pieces together. When team members don't interact, there is no synergy of ideas, and innovation suffers. Interaction can take many forms (brainstorming sessions, hallway chats, technical design reviews, online group discussions, and, in the software world, pair programming), but the objectives are the same: to share information, to co-create a product feature or development artifact, or to make a joint decision about an issue. Project managers must encourage this peer-to-peer interaction, particularly as pressure mounts and individuals have a tendency to "go dark."

There is more to successful interactions than talking. From time to time in any project team's development there are "crucial conversations," characterized by varying opinions , high stakes, and emotional intensity. These are the make-or-break conversations, the ones in which the character of the team is forged. Do these conversations degenerate into personal attacks and finger pointing, or do these conflicts help jell the team? There are a couple of things that determine whether the team has the self-discipline and character to have successful crucial conversations. First, each and every member must take the initiative to confront others when they are not performing, or behaving, according to team rules. This includes the administrative assistant calling the project manager on her actions when the situation dictates. No one should be exempt. Ignoring the problem, letting it fester, isn't acceptable behavior. The second critical thing is that the conversation be directed toward getting all the relevant information out on the table. Without this, crucial conversations cannot be effective. The process I describe in the section on participatory decision making is intended to do just thisextract relevant information that is devoid, for a while at least, of individual biases. [4]

[4] The research information in this paragraph comes from several sources, but the best is (Patterson 2002).

Several years ago I was working with a project team that was under enormous stresstight delivery deadlines, constantly changing requirements, and high pressure because of the revenue implications of the project's outcome. The team leaders and many staff members thought the ambiguity and anxiety within the project should somehow be mitigated, that the environment should be less chaotic and more stable. I pointed out that this kind of project was always borderline chaotic and, furthermore, that attempting to stabilize itwhile it might make everyone feel betterwas unlikely to lead to successful completion.

What ultimately helped the situation was to show the team leaders how they were making the situation worse by reflecting, rather than absorbing , the team's frustration. Each time a team member would come to a team leader and say something like, "Wow, things are really screwed up," the lead would counter with, "They sure are, and I wish someone would fix it." This exchange magnified the frustrations. While the team leaders needed to acknowledge the reality of the situation, they also needed to respond positively, to defuse the situation by remaining calm themselves . Just my telling the team leaders that a degree of ambiguity and frustration was a natural part of this type of project helped reduce their anxiety and kept the emotion and frustration level below a "constant crisis" level. They were then able to convey this new mood to team members.

Recent management research shows that mood or "emotional intelligence" in leaders has a much larger impact on performance than we may have imagined. "The leader's mood and behaviors drive the moods and behaviors of everyone else. A cranky and ruthless boss creates a toxic organization filled with negative underachievers who ignore opportunities," say Daniel Goleman, Richard Boyatzis, and Annie McKee (2001). These authors describe how a leader's emotional intelligence is contagious, racing through an organization like electricity through wires. Researchers at the University of Michigan found that in 70 work teams in diverse industries, team members picked up the same moods within a couple of hours.

Project teams are groups of people who respond to emotions and whose emotions may experience wide swingsfrom despair to euphoriaover the life of a project. Encouraging appropriate moods and discouraging others can help create group interactions conducive to generating emergent results.

Finally, managers should assist the team in developing a set of "rules of engagement," ground rules for how team members are expected to treat each other. The team should participate in developing, enforcing, and adapting these rules over timeit is a part of being self-disciplined.

Rules of engagement are not meant to reduce conflict and contention but to direct them in positive ways. Great teams froth with tension, contention, and diverse ideas directed at delivering a high-quality result. Poor teams froth with tension, contention , and diverse ideas directed at each other.

These team norms can include such rules as:

• Everyone has an equal voice.
• Everyone's contribution is valuable .
• Attack issues, not people.
• Keep privacy within the team.
• Respect each other and your differences.
• Everyone participates.

The team should decide on the list of rules, post it prominently ( especially during team meetings), and add to it freely during the project.

While making mistakes enhances learning, it only does so if those mistakes are identified. One of the most difficult tasks of working well within a team is confronting team members who violate behavioral or performance standards, but if they aren't confronted, the mistake isn't identified, and no learning occurs. Failing to address these issues head on is one of the greatest complaints against project managers (Larson and LaFasto 1989).

Developing Each Individual's Capabilities

Buckingham and Coffman have a nice little mantra that reflects the beliefs of great managers:

People don't change that much.

Don't waste time trying to put in what was left out.

Try to draw out what was left in.

That is hard enough (Buckingham and Coffman 1999).

Encouraging each individual's development is another of those key characteristics of great project managers. They try to understand people's inherent talents and build on those rather than trying to put in something that was left out. Developmental coaching comes in three flavors: technical, domain expertise, and behavioral. Project managers may not do the technical or domain coaching, but they facilitate its happeningoften by pairing less experienced team members with more experienced ones or pairing people with different technical skills in order to broaden each person's technical capability. The leader also coaches individuals in how to help the team jell. The leader may help some overbearing team member lighten up, while encouraging reticent ones to participate more fully.

Individuals contribute by applying their technical skills and engaging in team-enhancing ( self-organizing ) behavior. This self-disciplined behavior includes:

• Accepting accountability for results (no excuses)
• Confronting reality through rigorous thinking
• Engaging in intense interaction and debate
• Being willing to work within a self-organizing framework
• Respecting colleagues

Not all of these behaviors come easily, particularly for engineers. However, developing the self-discipline to do these things is critical to creating jelled teams. Helping individuals learn these skills can be one of the highest-leverage activities a project manager can engage in.

Providing the Team with Required Resources and Removing Roadblocks

Project managers contribute directly to delivering results by making sure team members have the resources they need. When individuals are waiting for resources, they lose productivity, but more importantly, they lose time. Examples of resources include computers, lab equipment, and staff assistance. Providing resources can also include ensuring that critical dependencies between feature teams or with outside sources are well managed. Rather than doing the work, the project manager ensures that everyone has the resources to do his or her work. This style of project management is one of providing services to the teaman approach Robert Greenleaf called "servant leadership" (Frick and Spears 1996)rather than having the team "work for" the manager.

Project managers also remove roadblocks that impede the team from working efficiently . For example, project managers need to quickly and effectively resolve impediments that are voiced in daily team integration meetings. Roadblocks can be things such as resources (the team doesn't have them), information (the team can't get it from a customer), or decisions (a stakeholder manager hasn't made them in a timely fashion).

Coaching the Customers

Another critical coaching jobthat of coaching the customer teamgoes to the product manager. Many internal IT projects have crashed on the shoals of poor customer involvementfor the last 30 to 40 years! The problem is simple, the solution complex. The fundamental problem is a poor customer-developer partnership caused by one of any number of factors:

• Development's lack of credibility in the eyes of customers
• Lack of customer involvement
• Poor accountability on the customer's side for making decisions and accepting the consequences
• Long development schedules, exacerbated by delivering meaningless (to the customer) intermediate artifacts
• Unrealistic project schedules based on poorly articulated requirements
• Lack of acceptance criteria and testing by customers

Individually, any one of these factors can doom a project. Collectively, they almost always lead to project failure.

Various APM practices and concepts address these issues, but just as engineers are accountable for building better partnerships, so are customers. Furthermore, just as the development team needs coaching in both technical and behavioral skills to meet their responsibilities, so do the customers. Customers may not know how to write acceptance tests or participate in requirements specification sessions or take part in the decision-making process of setting feature priorities. Just as the project leader facilitates the smooth running of the engineering team, the product manager must facilitate the smooth running of the customer team.

Consider an IT project that is building a business software application for multiple customer departments, each of which can identify requirements for the application. These requirements are gathered and documented, usually by a business analyst from the IT department. The analyst often inherits, because no one else wants it, the task of reconciling differences between multiple customer departments and trying to determine feature priorities. This approach leads to requirements bloat because the analyst has little power to say no to feature requests , and customer departments feel no obligation to make difficult priority decisions.

With a product manager appointed from the customer ranks, many problems are lessened because the customers, through the product manager, must accept accountability for identifying, defining, prioritizing, and accepting features. One of the product manager's jobs is to coach the customer team through this process. For industrial or consumer product development projects, the product manager has to work with (coach) internal "proxy" customersmarketing, executivesas well as gain information about the external customer base through periodic customer involvement, beta testing, and other means.

Orchestrating Team Rhythm

At times, the project manager's job mirrors that of a maestro, keeping the players in rhythm while bringing each into the music at the right time. At other times the team operates more like a jazz band , with each player improvising around a common structure. Working with the rhythms of agile projects can be a difficult transition for many individuals. People are used to linearity , at least in the way projects are usually planned. Execution is never linear, which is one reason people constantly complain that how they actually work never matches the plan.

Agile projects are rhythmic, not linear. Furthermore, there are rhythms within rhythms, which makes describing agile projects difficult to those who are used to seeing linear project task plans. There are the rhythms of iterations, which alternate between intensity and reflection as teams work to deliver features and then pause to reflect on the results. There is the rhythm of daily integration meetings and interactions with customers on feature details. There is the rhythm of peer-to-peer interaction as engineers meet at whiteboards to thrash through a design before retreating to more private reflection and work. There is the rhythm of constantly thinking, designing, building, testing, and reflecting on small increments of work. There is the rhythm of anxiety and euphoria as people try to solve, and then succeed in solving, seemingly intractable problems.

Project managers orchestrate the beat. They help team members learn to slow down to reflect after high-pressure delivery work, they help them find the right rhythm of working alone and working collaboratively, and they help them deal with anxiety and ambiguity. Creating task lists and checking completion boxes characterize one kind of project managementorchestrating rhythms characterizes another.