Building large teams, either traditional or agile, requires careful design. Bigger teams involve more communication, more decisions, more meetings, more documents, and, of course, more politics.
Agile principles of collaboration, simplicity, responsiveness, and minimally sufficient documentation can be applied to building larger teams but the application is far from simple. Building effective, efficient large agile teams takes a concerted effort in the four areas mentioned earlier: organizational design, decision-making design, collaboration/coordination design, and applying agile principles.
Although collaboration, coordination, and knowledge sharing are critical to large projects, the downside of too much communications can be endless meetings and wading through tons of documentation and emails. Too little or poor communications, however, means no one understands the project nor their part in it. So whether we are doing organizational design or collaboration/coordination design, agile teams always balance on the side of "just a little bit less than just enough."
Organizational Design
In general, as projects escalate from large to very large the number of specialty teams will increase and a few members of the specialty teams will be full-time members.
In addition, as size increases, feature teams will be organized into a structure, product area team, capability team, feature team based on the product's component architecture.
Whereas in a traditional large-team hierarchy the teams might be functional (requirements analysts, developers, testers), large agile teams maintain their cross-functional and product orientation. Where very close coordination is required between feature teams (or between certain feature and specialty teams) cross-linking should be used in which one person from each team sits in on key meetings of the other.
Another design criteria is that a large agile team maintain the flattest structure possible (more nodes, less hierarchy).
This organizational structure focuses on the collaboration and coordination between autonomous but linked groups. As the team size increases to encompass several feature and specialty teams, there is a critical combination of team self-organization and self-discipline required. Individuals have responsibilities within a team structure, and teams have responsibilities within an overall project structure.
This network structure isn't a hierarchically controlled one, but neither is it a pure network structure in which all control is delegated to the nodes. The structure might be labeled a "modified network" structure in which a significant amount (but not all) of the power and decision making are distributed to the feature teams.
Collaboration/Coordination Design
In Agile Software Development, Alistair Cockburn discusses various communications modalities and indicates each one's relative effectiveness.
For example, a two-way face-to-face discussion at a white board is more effective than sending a document to someone. However, for large and especially distributed teams, the enemy of effectiveness remains cost. Although it may be very effective to have a face-to-face design discussion at a white board, the cost of doing it when the individuals are located 5,000 miles apart may be prohibitive, although new Web 2.0 collaboration and project management tools are continually reducing these costs.
So the real question is not just effectiveness, but cost-effectiveness for the particular job at hand. What makes communications design so difficult is that it rests on a foundation of relationships of trust, respect, appreciated cultural differences, and shared context.
A team that is "in sync" can get away with lower effectiveness communications modalities because they have a good relationship context for sharing information. Another team distributed across countries in which there is little respect, trust, or multi-cultural understanding will need higher effectiveness communications modalities.
This also means that the collaboration/coordination design will probably change as projects progress and relationships become better established. Communication modalities that might not work early in a project may work fine toward the middle and end.
Two factors in designing collaboration/communications practices and tools for a team are relative effectiveness of the modalities and the foundation of trust, respect, and understanding of different cultural norms.
Decision-Making Design
How is a large agile team different from a large traditional team from an organizational perspective?
• First, a large agile team has a flatter, less hierarchical structure fewer layers of managers.
• Second, to the greatest extent possible, decisions are pushed out to the feature teams or specialty teams.
• Third, feature team members participate in specialty teams to ensure their input is heard and to take part in the decisions.
• Fourth, team decision making, whether project or technical decisions are being made, are accomplished in a participatory fashion.
• Fifth, specialty teams are encouraged to issue guidelines, not fiats, and furthermore (like managers) they are encouraged to make as few decisions as possible.
• Sixth, peer-to-peer (feature team to feature team) interactions and dependency management are encouraged.
• Seventh, the team embraces agile principles.
Knowledge Sharing and Documentation
Documentation and knowledge sharing are two important issues in scaling agile projects. A 6-person team needs different documentation practices than a 100-person team does.
The Agile Manifesto states, "Working products over comprehensive documentation." Large, front-loaded projects that spend months, and even years, gathering requirements, proposing architectures, and designing products are prone to massive failures.
Documents support communication and collaboration, enhance knowledge transfer, preserve historical information, assist ongoing product enhancement, and fulfill regulatory and legal requirements. They are not unimportant, just less important than working versions of the product.
Understanding comes from a combination of documentation and interaction, or conversation, the conversations among people who have domain knowledge. Furthermore, as the complexity of the knowledge to be transferred increases, the ability of documentation alone to convey that knowledge decreases and the need for interaction with knowledgeable people increases dramatically. Documentation provides content (partially), but conversations are necessary to provide the necessary context.
A little research into the field of knowledge management shows that early efforts to document best practices (software development, engineering, or otherwise)—filling reams and reams of web pages with details—has generated marginal benefit. In thinking about knowledge transfer, one must distinguish between transferring explicit knowledge (written down) and tacit knowledge (in someone's head). "
Tacit knowledge cannot be transferred by getting it out of people's heads and onto paper," writes Nancy Dixon in her book Common Knowledge "Tacit knowledge can be transferred by moving the people who have the knowledge around. The reason is that tacit knowledge is not only the facts but the relationships among the facts—that is, how people might combine certain facts to deal with a specific situation."
In summary, documentation should be designed in a lean, barely sufficient manner, both formal (for retention) and informal (temporary), highly visual and visible, viewed as support for collaboration and coordination, and vary considerably by project size and type (regulated environments for example). Ultimately the issue isn't documentation but understanding.
Self-Organizing Teams of Teams
An agile team consists of individuals who interact within a structure of self-organized and self-disciplined rules of engagement. Individuals have a degree of autonomy within this loose structure, and they, in turn, exercise self-discipline to be accountable for results and behave as responsible and thoughtful members of the team.
Larger agile teams, those consisting of multiple feature and specialty teams, operate the same way, individuals are the agents in teams, whereas feature teams are the agents in a larger project.
In building large agile teams, a network replaces the common hierarchical structure, decision making and collaboration must be carefully designed, and discipline reflects rules of engagement across teams.
Team Self-Discipline
Just as individuals have responsibilities to their teams, teams themselves have to be self-disciplined to work within a larger self-organizing framework.
The behaviors required of teams closely parallel those for individuals:
• Accept accountability for project results.
• Engage collaboratively with other feature teams.
• Work within the project self-organizing framework.
• Balance project goals and team goals.
A team that is unwilling to work within the established framework disrupts the work of the larger project in the same way that individuals who are unwilling to work within the team framework do.
Teams have to align their own goals with those of the project. There will always be too much to do and too little time, and the tendency will be to work on one's team goals rather than on project goals.
Process Discipline
We all know the saying "Don't fix things that aren't broken." For larger teams, we need to give this advice a twist: "Don't always fix things that are broken." Although smaller teams are not immune to excessive process, this tendency becomes more prevalent as teams get bigger.
Just as agile teams don't try to anticipate future requirements or design, choosing instead to let them emerge over time, they shouldn't attempt to anticipate every problem and put processes or practices in place to prevent them. It's often cheaper and faster to fix an actual failure than to spend excessive time anticipating failures that may never occur.
references:
- Cockburn, Alistair. Agile Software Development. Boston: Addison-Wesley, 2006.
- Highsmith, Jim. Agile Software Development Ecosystems. Boston: Addison-Wesley, 2002.
- Rueping, Andreas. Agile Documentation: A Pattern Guide to Producing Lightweight Documents for Software Projects. New York: John Wiley & Sons, 2003.
-Dixon, Nancy. Common Knowledge. Boston: Harvard Business School Press, 2000.
No comments:
Post a Comment