Baseball Game

Teams and situations require different management styles.

Every team may leverage several styles of management to deliver value most efficiently. In Agile teams, some styles are used more often than others. The default management style for Agile teams tends to be participative, but management style is affected by team size, context, and role.

Team Size:  The number of people on a team affects possible management styles.  The larger the team, the less participative the team can be due to the sheer number of connections and conversations required.  I have participated on “teams” of 30 or 40 people earlier in my career (I use the term “team” with reservation). With large teams like that, the possible number of interconnections between individuals is limited, where the formula (n(n-1))/2 defines the possible number of combinations.  A 35 person team requires 595 connections, most of which would have to exercise to generate the consensus needed to execute participative management. Frankly, that is impractical. Agile teams are fairly complicated even though there are aren’t an infinite number of moving parts.  Scrum teams are typically 5 to 9 people including a Scrum master and product owner, while XP teams tend to be in the 4 – 12 person range.  A team of 12 would have 66 possible connections.  Teams with larger numbers of connections tend to favor directive approaches ranging from the somewhat participative negotiative style to delegative management, or the command and control favorite, the authoritarian style.

Role: Role power is a concept that rarely gets discussed in most Agile conversations; however, different roles often represent a differential in power. For example, the product owner will tend to have more organizational power than a typical tester or coder.  Teams often premise interactions and decision-making on members checking their titles at the door.  Checking titles at the door is code for assuming equality of power at the team level. However, that equality is rare.  Product owners, tech leads and even the scrum master’s opinions tend to have more weight than someone that is one amongst equals.   These types of power imbalances tend to foster the use of negotiative or delegative management styles.

Context: Context is the most important rationale for using different management styles.  Most adherents of Agile would be quick to extol the virtues of collaborative management.  Collaborative management is very supportive of self-organization and self-management, however, there are occasions when collaborative management styles do not make sense.  In times of great stress, more direct authoritative styles are typically more appropriate (when there is a fire in the airline cabin, decisions must be made). How the team adjusts behaviorally, integrates the new decision or direction change and then settles back to its preferred style says a lot about the maturity of the team. A mature team typically recognizes the need for the management style diversion or urges the team member back toward the team norm (through peer pressure or discussion). At other times, Agile teams use delegative approaches to allow a member (or subgroup) to make decisions within their specialty areas.  For example, I recently observed a team that tapped two members to review and purchase print modules for an application.  The team agreed upon a broad set of criteria, then charged the subgroup to operate within that framework.  Whether addressing decision-making in emergencies or areas of technical expertise, context-dependent changes in style are typically short term. Afterwards, the team reverts almost immediately to their preferred style as soon as the need for an alternative style passes.

Teams always have preferred management styles but, as with potato chips, an Agile team can’t just use a single style. Getting work done is complicated. Teams reflect a chaotic environment of roles, team size and situation.


Management / Leadership Thread