We saw last month that just because somebody is the manager of an Agile team does not make that person an Agile manager. The Agile manager does specific things: advances the understanding of the domain, has a symbiotic relationship with the do-ers, creates and adjusts the processes and social systems, and protects the team’s execution. By virtue of doing these things, the Agile manager is a leader, whereas the traditional manager is just an administrator.
I have been fortunate to watch the rise of Agile competencies over the last two decades. I have been less fortunate to watch Agile management competencies erode as Agile has spread in popularity. Although there are undoubtedly numerous reasons why, one immediately stands out: while the value system that underlies the behaviors described in the previous post is highly compatible with the creative company mindset, it is highly incompatible with the operating company mindset.
The creative company - e.g., a studio that yields original work, anything from entertainments to custom software assets - benefits from how much it exposes itself to environmental uncertainty and how effectively it internalizes relevant learnings from it to create a successful, if unique and one-off, solution. In contrast, the operating company - a firm that mass produces products or provides mass volumes of labor to deliver solutions - benefits from environmental certainty that allow it to apply patterns that create consistency enabling repeatable solutions at scale. The greater the consistency, the greater the automation, the lower the labor proficiency level required, the lower the cost of execution, the higher the margin and cash flow. Whereas the creative studio model thrives on chaos, the operating company thrives on consistency.
This is a tectonic fault line in the application of Agile management practices. When Agile is brought to bear in an operating company context with an overriding mission to provide consistency of outcomes, the value system that fosters the management behaviors that get things done through people in the face of a volatile set of circumstances is simply ignored. The words remain - adaptive planning, continuous feedback, and the like - but the values that give rise to them in the first place simply dissipate.
The presence of Agile terminology twined with the absence of the Agile value system gives license to people in management roles to do pretty much anything under the aegis of “being agile”. Take “adaptive planning”. In practice, “adaptive” is used to mean anything on a spectrum from no management and no plan (“we’ll figure it out as we go, on somebody else’s dime”) to dictatorial management-by-plan (“the team is free to meet the commitments they make during the planning exercise.”) Planning itself is an exercise in plausible deniability for managers: if the do-ers create the plan, management is the act of holding people accountable for the plan they came up with, not for the continuous adjustment of the plan or refinement of the business outcomes in the face of what is learned through execution. And reporting against a plan is somewhat perversely passed off as “governance”, itself an overloaded term with no actual meaning beyond “fancy word for management reporting.”
The net result is that managers of Agile teams have found ways to make themselves passengers in Agile teams because they only do administrative, communication, and reporting tasks. Former IBM CEO Lou Gerstner referred to these kinds of managers as “presiders”. Mr. Gerstner deemed presiders to be useless. Do-ers in Agile teams deem presides to be useless as well.
I wrote a decade ago that Agile gets corrupted when it goes corporate. That phenomenon is not unique to Agile, of course. By way of example, look at cloud computing: who knew that “migrating to the cloud” was as simple as moving a data center from owned on-prem to leased in somebody else’s facility? Yes, people still pass this off as “cloud migration”. Enterprise scale, enterprise politics and enterprise vendors have a tendency to dilute concepts - cloud, Agile, you name it - to a point of rendering them inert. ‘Twas ever thus.
Yet while Agile concepts are bound to be co-opted, this does not have to be the case for Agile execution. Managers can choose to be drivers of outcomes rather than plans, work with the team rather than outside of it, create social systems rather than schedule meetings, and protect the team’s execution from external forces rather than allowing them to steamroll the team. These, among other things too numerous to list here, define excellence in management.
Pursuing excellence is a choice that always rests with practitioners. There is a reason why the administrative burden of Agile has always been defined as “lightweight”, and isn’t to ease the workload of managers: it is to give managers the bandwidth to take a leadership role in a peer relationship with engineers, designers, analysts, and all the other do-ers in a team. That door is always open to managers in an Agile team, but the decision to walk through it or not rests with the individual manager.
Choose wisely.
