Build Adaptive (Self Organizing, Self Disciplined) Teams

Adaptive teams form the core of APM. They blend freedom with responsibility, flexibility with structure. In the face of inconsistency and ambiguity, the team's goal is to consistently deliver on the product vision (including adaptability) within the project's scope. Accomplishing this requires teams with a self-organizing structure and self-disciplined individual team members . Building this kind of team is the core of an agile project manager's job.

A simple definition of a team is that it has a defined goal, consists of two or more people, and requires coordination among those people (Larson and LaFasto 1989). Beyond this definition, there are numerous variations in team composition and structure, but the self-organizing team seems best fitted for exploratory work. In a self-organized team, individuals take responsibility for managing their own workload, shift work among themselves based on need and best fit, and participate in team decision making. Team members have considerable leeway in how they deliver results, but they are accountable for those results and for working within the established flexible framework.

Self-organizing teams are not, as some perceive, leaderless teams. Any group left to its own devices will self-organize in some fashion, but to be effective in delivering results, it needs to be steered in the right direction. Self-organizing teams aren't characterized by a lack of leadership, but by a style of leadership. There is a big difference between the terms "self-organizing" and "self-directing." Self-directing usually implies self-led, as various team members assume the leadership role depending upon the situation. The self-directing model runs counter to much research that indicates good leaders are a major ingredient of project and organizational success (Larson and LaFasto 1989).

Creating a self-organizing framework entails:

In Michael Kennedy's (2003) wonderful book on the Toyota lean product development system, he states, "This book is about the interaction of people and how to manage or influence that interaction." Ultimately, APM is also about people and their interactions and about creating an environment in which individual creativity and capability erupt to create great products. It's people, not structure, that build great products.

Getting the Right People

The organization, through the project manager or other managers, has the responsibility to staff the project with the right people. At the team level, getting the right people means finding those with appropriate technical and behavioral skills. At the project level, the project manager works to ensure that the right leaders are assigned to each team. The project manager should have the authority to reject any team member that other managers might want to assign, unilaterally, to the project.

The agile value of people over process drives the need to get the right people. Process proponents argue that a good process will compensate for less capable staff, and therefore getting the right people isn't as critical to success as getting the right process. Agilists believe that process can provide a common framework within which people can work effectively, but it cannot replace capability and skill. Products are built by capable, skilled individuals, not by processes. Effective project managers focus on people, product, and processin that order. Without the right people, nothing gets built. Without a laser focus on the product, extraneous activities creep in. Without at least a process framework, there can be inefficiency and possibly a little chaos.

Getting the right people (which implies, of course, getting rid of the wrong ones) and the right managers determines project success more than any other factor. (I will cover the issue of getting the right people in more detail in Chapter 5.)

Articulating the Product Vision

The project manager ensures that every individual understands the product vision and his or her role in the project. The vision might include a vision box (described in Chapter 5) and an architectural overview to help team members grasp the big picture, as well as component descriptions and interface definitions to help them get a sense of their piece of the product. In addition to understanding product responsibilities, individuals need to understand their roles with respect to the others.

Comprehending the product vision also includes understanding the project's boundary conditions. For example, the project manager (or product manager) needs to help the team grasp not only the actual schedule, but also why the dates are critical. She needs to convey to the team a sense of what the few high-priority areas are and why they are high priority. The better the team members comprehend the reasons for project constraints, the better they can help in meeting those constraints and making tradeoff decisions in their day-to-day work.

Articulating the product vision is not a one-time activity. Products evolve . New people are added to a project. In the heat of daily activity, visions become blurred. Articulating the vision, the end result desired, should be an ongoing task of project and product management.

Encouraging Interaction

The capability of self-organizing teams lies in collaborationthe interaction and cooperation of two or more people to jointly produce a result. When two engineers scratch out a design on a whiteboard, they are collaborating. When team members meet to brainstorm a design, they are collaborating. When team leaders meet to decide if a product is ready to ship, they are collaborating. The result of any collaboration can be categorized as a tangible deliverable , a decision, or shared knowledge.

The quality of results from any collaborative effort is driven by trust and respect, free flow of information, debate, and active participationbound together by a participatory decision-making process. When any of these components is missing or ineffective , the quality of the results suffers. In a collaborative team, one of the key leader roles involves facilitating, coaching, cajoling, and influencing the team members to build healthy relationships.

At the core of healthy team relationships is trust and respect. When team members don't respect the knowledge and capabilities of others, meaningful debate falters. The line between confidence and arrogance can be awfully narrow, and individuals sometimes bluster to cover up lack of knowledge. The project manager melds a group of people into a working team by working through these types of issuesand getting the wrong people off the team when necessary.

Complex systems, such as large project organizations, thrive on interaction and information flow. The project management team should be constantly asking questions such as, "Are the right people coordinating with each other about the right things at the right times?" and "Is the right information available at the right time?" These are critical questions whose answers can help the team operate smoothly or bog the team down. The design engineer who fails to include the ideas of the manufacturing engineer ends up with products that are too expensive to make. Software engineers who fail to work closely with QA build code that is difficult and expensive to test. Too little coordination and information, and teams will diverge so far that integration becomes a nightmare (hence the need for frequent integration). Too much coordination and information flow, and teams become mired in constant meetings and information overload.

Project managers need to focus on interaction, collaboration, and coordination first and appropriate documentation second, because documentation discourages conversation. One of the problems with serial product development, and one reason why companies have moved to cross-functional teams, is that it tends to discourage people from interacting by suggesting, implicitly at least, that documentation provides the information they need. Complex, tacit information is primarily conveyed by interaction and conversation (probably in the range of 70% to 75%) and only secondarily by documentation (25% to 30%). Understanding, not documentation, is the goal of information transfer. Documentation-heavy teams will have difficulty achieving agility.

Although collaboration and interaction drive effective agile development, not all engineers (and other team members) are effective communicators . [5] This fact gives rise to another key role for agile project managers and team leaders: coach. Agile project managers will assist team members in developing the interaction skills they need to become effective collaborators.

[5] Ken Delcol makes a sobering point about collaboration. "Most people in product development are not collaborative; they do not like to talk to each other. Innovation requires interactions and exchange of ideas, and if you don't like talking to people, this becomes difficult. Companies need to develop environments, both physical and cultural, that prompt/demand/expect collaboration. Part of the reason for lack of collaboration is the education system for technical people."

Participatory Decision Making

Decision making is the heart and soul of collaboration. Anyone can sit down and chat about a product design. Collaboration means working together to build a feature, create a design, or write a product's documentation. Collaboration is a joint effort. So whether you are designing with another individual or struggling with feature priorities or deciding if the product is ready to ship, there are literally thousands of decisions, large and small, to be made over the life of a project. How a team makes those decisions determines whether the team is a truly collaborative one. Some teams are driven to quick decisions by a senior technical individual, while others are driven by those with the loudest voice. Neither situation is conducive to true collaboration.

Several years ago, I wrote an article on distributed decision making. In researching that article, I reviewed six books on project management and found only one paragraph on decision making. Many, if not most, process-centric approaches to both product development and project management seem to spend no time on decision-making processes. But for all the general neglect, team decision-making capabilities are absolutely critical to successful project management, agile or otherwise . From feasibility go/no-go decisions, to whether or not to release a product, to each and every minute design choicethe way teams make decisions will have a major impact on their performance.

Leadership is also critical to good decision making. In innovative product development work there are thousands of decisions to be madeand the information available to make those decisions often remains fuzzy. Customer preferences may be fuzzy. The new technology being used may be untried, and therefore fuzzy. For every clear decision to be made there are ten others that require "fuzzy" logic. Teams can become paralyzed by this fuzziness and oscillate back and forth over decisions. When all the discussion, debate, and dialogue have reached an impassewhen the ambiguity of the situation overwhelms the decision-making capability of the teamthe leader often has to step in and say, "Well, the direction isn't abundantly clear, but we're going East." An effective leader "absorbs" the ambiguity, takes responsibility for the decision, and allows the team to get on with its work. Knowing when and how to carry this off is one mark of an effective leader.

There are two words that engineers seem to hate most, maybe because they see a relationship between the twopolitics and compromise. Compromise results from win-lose thinking, in which I am right and you are wrong. An alternative model is win-win thinking, in which reconceiving replaces compromise. [6] Reconceiving means combining ideas to create something better than any individual could create on her own. It isn't giving up, but adding to. Innovation and creativity are emergent, not causal , properties of teamwork. There is no set of steps that guarantees innovation; it emerges from a melding of gradually expanding ideas that are the results of interaction. In this process there are pieces of your ideas, and pieces of mine, that contribute to the eventual solution. This process of melding ideas, of subjecting them to discussion, of analyzing them in the light of our product's vision and constraints, is not a process of compromise, but one of reconceiving. Compromise polarizes. Reconceiving unites.

[6] Colleague Rob Austin originated the use of the word "reconceive" in this way.

However, win-win or reconceiving should not imply consensus decision making. Participation doesn't mean consensus either. Self-organizing teams have managers who make unilateral decisions on occasion, but their primary style is inclusive, to encourage wide participation in decision making in order to make the best decisions. Self-organized teams have a lot of discretionary decision-making authority, but it is balanced with that of the project manager. As in other areas, balance is the key to agility in decision making.

Insisting on Accountability

Responsibility and accountability create self-organizing teams that work. When an individual commits to delivering a particular feature during an iteration, he accepts accountability for that delivery. When the team commits to a set of features by the end of the second project milestone, all members of the team accept accountability for that. When the product manager is involved in iteration planning, she has agreed to be accountable for providing requirements information to the team. The project manager agrees to be accountable for resolving impediments to team progress. When a team member commits to provide some information to another the next day, he has agreed to be accountable for that action. When team members commit to each other, when the team commits to the customer, when the project manager commits to provide the team with a particular resource, they are all agreeing to be held accountable. And it is incumbent on each and every team member and the project manager to hold each other to those commitments. Trust is the foundation of collaboration, and meeting one's commitments is core to building trust.

Steering, Not Controlling

Leaderless teams are rudderless teams. Managers who want to create an adaptive, self-organizing project teams steer rather than controlthey influence, nudge, facilitate, recommend, assist, urge, counsel, and, yes, direct in some instances. They view themselves as teachers (Larson and LaFasto 1989).

Micromanagers will always have to micromanage , complaining the whole time about staff members who are unwilling to take responsibility. But what about individuals and teams that don't have experience working in a self-organizing manner? Surely they need a heavier managerial hand until they are self-disciplined enough to fulfill their part of the freedom-responsibility bargain, right? Alas, destructuring rarely follows structuring. Managers whose fundamental beliefs tend toward structure rather than flexibility rarely give up the power and control necessary to create an adaptive organization.

To achieve an adaptable, self-organizing team, the project manager grants the team as much autonomy as possible, destructures to the extent possible, and then coaches individuals and gets rid of those who don't fit.

Steering is not abdication of decision making. Self-directing (as opposed to self-organizing) teamsthose that theoretically don't have a single leadertend to drift and procrastinate, which is not appropriate for fast-moving product development teams. Steering means the manager makes unilateral decisions at times and makes decisions with team involvement at other times, but primarily delegates decisions to the team.

Self-Discipline

Self-discipline enables freedom and empowerment. When individuals and teams want more autonomy, they must exercise greater self-discipline. One of the acute dangers of process-centric development and project management is that they remove any incentive for self-discipline. When managers impose discipline through detailed processes"follow this process or else"they stifle initiative and self-discipline. These same managers then turn around and complain, "Why doesn't anyone around here take any initiative or accept any responsibility?" Imposed-disciplined teams gets things accomplished. Self-disciplined teams accomplish near- miraculous things.

Self-disciplined individuals:

Dialogue, discussion, and participatory decision making are all part of building self-discipline. A series of words scattered throughout Jim Collins's book Good to Great (2001) creates an image of the rigorous thinking and debate that are core to self-disciplinetruth and brutal facts; dialogue and debate, not coercion; a penchant for dialogue; questioning. Collins found that individuals in great companies were extremely interactive, engaging in debates that often lasted a long time.

Self-discipline is also built on competence, persistence, and the willingness to assume accountability for results. Competence is more than skill and ability; it's attitude and experience. Get the right people involved, and self-discipline comes more easily. Get the wrong people, and imposed discipline creeps in, destroying trust, respect, and the egalitarian atmosphere. "The point is to first get self-disciplined people who engage in very rigorous thinking, who then take disciplined action within the framework of a consistent system," says Collins (2001). One reason would-be agile teams don't succeed is that they fail to realize the self-discipline required. There is no binary switch to go from no discipline to self-discipline; it's a journey that some individuals get right away, while others need to take a longer trip.

Related

Категории