Scaling Agile: Organizational Factors, Management Style

by Jim Highsmith, Director, Agile Product & Project Management Practice

There are four critical areas in managing large projects: people, product, plans, and tools. In a previous Advisor, I discussed the collaboration aspect of people in teams (see "Help Agile Scale by Fine-Tuning Collaboration," 11 December 2008), and in another I covered organization and management style (see "Scaling Agile: People and Organization," 24 December 2008). The organizational issues on large projects are critical to success. This Advisor addresses the issue of management style, or how to scale self-organization.

To illustrate organizational scaling factors, let's think about two teams: one a six-person colocated team and the other 100 people divided into eight capability teams. Furthermore, let's focus on a particular task: setting up and maintaining the process and tools for build, integration, and testing (BIT). By examining how these two project teams might handle this task, we gain insight into scaling factors.

First, how would the small team handle the BIT tasks? The entire team would probably discuss the problems and solutions, a couple of team members might do some tool research, the entire team would make the key decisions about process and tools, then a couple of team members would do the initial setup. Team members would discuss how to use the tools, and key information might be put on a flip chart (and or recorded in a team document). The entire task would be handled collaboratively, with the entire team making the decisions, and knowledge sharing would be informal and interactive. Team members would rotate maintenance activities on an informal basis.

Obviously, using the above scenario for a 100-person team would be extremely time-consuming and ultimately very expensive, so a reasonable scenario might be as follows. First, three to five individuals would organize into a part-time BIT team. Members would be drawn from feature teams and would include people who had expertise or interest in BIT. These team members would discuss issues, do any necessary research, and propose a process and tools. The team would send a draft document to the feature teams, where either interested individuals or one or two people per capability team would review the draft and make comments back to the BIT team. The BIT team would make the final decisions, work to set up the BIT environment, and document the process in the team's wiki. BIT team members would be available to discuss the process and tools, or possibly make a presentation. A rotating team (members from feature teams would work part-time on the BIT for some period of time) would support BIT on an ongoing basis.

There are four key factors that come into play in these two scenarios: organizational design, decision-making design, collaboration/coordination design, and agile culture.

With a small, six-person team, there isn't much organizational design. As the overall team size grows to 100, design options range from hierarchical and functional to networked and cross-functional, with agile teams tending toward the latter.

Notice from the scenarios that in the small team, everyone on the team was part of the BIT decision-making process, while in the larger team scenario, the BIT team made the decisions with input from others -- but the BIT team made the final decisions. As team size grows, who makes what decisions is critical. Having six people involved in most team decisions is one thing; having 100-people involved is quite another.

This brings us to the crux of scaling from an organizational perspective: collaboration versus coordination. Because agile development is highly collaborative, agilists tend to be indiscriminant about labeling person-to-person interactions -- everything tends to be called collaboration. However, collaboration can be defined as working together to jointly produce a deliverable (think pair programming as an example) or make a decision. Coordination is sharing information. Collaboration is more expensive, and not always required. So, in the second scenario, the BIT team made collaborative decisions and then coordinated those decisions with the rest of the feature teams (or communicated decisions to them). Matching communications modalities to tasks (most effective for least cost) is critical to project scaling.

How to apply agile principles as projects scale is the final factor. One might argue that agile self-organizing principles dictate that all 100 people in the large team should be involved in the BIT decision, while another interpretation might be that decisions should be made at the network nodes (feature team or BIT team) to the greatest extent possible. There are agile principles and then there are interpretations of agile principles. As projects get larger, appropriate interpretation and application of those principles becomes both more difficult and more critical to success.

A 100-person team will never feel like a six-person team, but each can definitely be agile. To do so, teams must appropriately apply agile principles to organizational design, decision making, and collaboration/coordination design.

I welcome your comments on this Advisor and encourage you to send your insights on agile techniques and practices in general to me at jhighsmith@cutter.com.

Sincerely,
Jim Highsmith, Director
Agile Product & Project Management Practice
E-mail: jhighsmith@cutter.com