When do you not want an agile team?

For the past few years I’ve been an agile enthusiast, and I still am. But when we talk of scaling agile to the organization, it is easy to forget that agile practices work well under certain conditions. Many teams in an organization will not be able to create those conditions, and standard versions of agile rituals will not work as well for them as other “project management” approaches. This is old news, going back to the 1994 classic “The Wisdom of Teams” at least, but I don’t see it shared in most descriptions of “how to scale agile”.

In “The Wisdom of Teams”, the authors describe a productivity curve — the Y axis is productivity, and the X axis is how close a team is to being “real” or “high-performing”. The most interesting thing about the curve is that there is a substantial dip in productivity just at the start. To the left of the dip, a team is not really a team — it is a working group, with a clearly defined leader coordinating the work. The dip represents a period of self-organizing (often described with the classic Forming, Storming, Norming, Performing cycle). On the other side of the dip, we have teams with progressively more of the qualities we would consider to be “agile” today, enjoying ever-greater productivity.

The key is, if your team cannot work closely together in the same physical or virtual space, with constant easy informal communication, with every member taking responsibility for the work of the whole, then your team cannot make effective use of agile practices. Formal delegation and differentiated roles are necessary if the team’s ad hoc coordination takes more than a few seconds to arrange. Literally three seconds! I think the process of making a phone/VOIP call is long enough that it requires a context switch, and that means that the work stops. When I say “the same virtual space”, I mean working with the IM chat window open or conference call running, for hours at a time.

There are hacks available — for example, arranging work sessions where everyone is online at the same time, or working from the same office (or cafe). But unless this is the only way your team works, you will still need to divide up the work, which implies more structure than is usually part of “best practice” agile.

The approach used in sociocratic organizations represents a good example of how you can scale agile with a mix of team / working group types. Each team (in Sociocracy, a “circle”) meets at least once a month to do the team learning and decision-making that makes agile or lean teams into “guaranteed learning organizations”. At that time, they have the characteristics of a “real team”, setting their methodology together and taking ownership of their outputs as a team. Between these “circle meetings”, however, some sociocratic circles use agile ritual, and others use classic approaches such as PRINCE2, with a high degree of coordination and direction from an “Operational Leader”.

In sociocratic organizations, a double-link connects teams up and down the functional hierarchy. It provides guidance from the general teams to the more specific and provides feedback from the specific to the general. A lead link (the “Operational Leader” just mentioned) provides a downward connection from the more-general circles to the more-concrete ones; a measuring link (a “Representative” elected by the more-concrete circle, who participates in the monthly “circle meetings” of both lower and upper circles) provides an upward connection. Thus, each circle has a well-defined structural connection to the circles above it (and below it). With the structural feedback loop built into the organization by these two roles, each circle is tightly coupled and dynamically steerable — whether they use agile processes internally, or more elaborate formal structures.

Does my description of “when you can’t use agile” match your experience of working in various teams? Are you familiar with other ways of scaling agile which don’t require every team to use the same methodology? Let me know!