Israel Gat - The Equipoise of Agile

August 31, 2008

Over the past couple of years I have tried very hard to distill the BMC success in Agile to a set of best practices that I could share with anyone who is thinking of starting an Agile project. Unfortunately, after I examined the various “secret sauces” that I concocted, presented, and discussed since 2006, I had to conclude that all of them – including my recent Post, A Social Contract for Agile, in Agile Thinkers – somewhat missed the mark. Having said that, everything stated to date in my secret sauces is true, relevant, and hopefully useful to other Agile executives. What has been missing, however, is the deeper truth that binds together the many ingredients– the equipoise of Agile.

Equipoise is the equilibrium formed by offsetting conflicting forces. The equipoise of Agile is the skill of an Agile leader to orchestrate conflicting forces and pressures in and around Agile in a manner that utilizes Agile principles, without denying the realities of the non-Agile world. It is the ability to function and get teams to function amid contrast and ambivalence that are systemic.

The systemic conflicts to which I refer are the inevitable outcome of Agile being a disruptive methodology. When you apply Agile, you are trying to align two worlds that exist in parallel. In one world is the set of core competencies, practices, procedures, policies and cultural norms that made your company successful. In the other world are the origins, life, and momentum of the Agile movement. Both worlds evolve, but at a different pace and at a distance.

A good way to think about how the two worlds affect each other is to study the chapter in Japanese history that started with Commodore Perry steaming into Tokyo Bay in 1853. Bringing gunship technology in touch with the Samurai sword technology (and culture) started the difficult process of the modernization of Japan. The modernization process has been traumatic to the degree that made (Commodore Perry’s) Black Ships a term of art in the Japanese culture--expressing the surprise and confusion induced by such two dissimilar worlds, as the Japanese world and the US world touching each other.

In the way that the people of Japan maneuvered through the duality and contrasts that followed Commodore Perry’s visits to Japan, Agilists must often strike a balance between two parallel worlds. The measurement of Agile maturity at BMC is a splendid example of striking this kind of balance. After about a year of practicing Agile, I became increasingly anxious to know how the teams were performing. At my request, Dean Leffingwell and Becky Strauss devised a self-assessment methodology for the BMC Agile teams. Effective that it was, there was nothing revolutionary about the methodology itself. What was revolutionary was our decision to treat the self-assessment as privileged data that was owned by the respective teams -- separate from the overall set of measurements that we used at BMC to evaluate projects, teams and individuals.

From a traditional management perspective, the decision to exclude these self-assessments from the official measurement system was quite problematic. We were investing a fair amount of money to convert to Agile; many forthcoming products were critically dependent on the progress we would make assimilating Agile; certain commitments to customers could be met only through good progress on the Agile learning curve. Clearly, Agile maturity was an important metric by traditional Balanced Score Card standards.

Our decision to exclude Agile self-assessments from our official measurement system stemmed from our belief the data was too important to be used as part of a system that associates accomplishments with monetary rewards. Because we were betting the business unit on Agile, we could not afford team maturity to be gamed in the usual manner in which CPM metrics tend to get gamed by everyone and his grandmother. The Agile assessment data had to be pristine in the sense that there was nothing “good” or “bad” about the attained level of maturity -- it was what it was. The teams needed to be able to use their assessments of maturity as baselines for self-induced improvement. We empowered them, in collaboration with their Rally Software consultants, to look in the “mirror” of their self-assessments and determine what to do about this Agile “wrinkle” or that Scrum “wart.” We trusted the Scrum teams to use the data to drive their Agile maturity and to own their Agility.

Managing the friction between the official corporate hierarchy and Agile structural constructs is another good example for the equipoise that an Agile leader must orchestrate. For Agile to scale at the enterprise level, the Scrum team needs to cascade--like fractal building blocks spanning multiple levels. Consequently, responsibility and accountability get vested in the network of Scrum Masters and Scrum of Scrum Masters, obsolescing in many ways some traditional job definitions, like QA Director or Senior Engineering Manager. Due to these dynamics, the Agile world at BMC created its own de-facto Scrum hierarchy that existed parallel to the formal corporate hierarchy. Corporate inertia being what it is we did not believe we could successfully consolidate the two hierarchies into one in a short period. Hence, we depended on the equipoise that we struck between the two worlds, enabling the Scrum hierarchy to be focused on the delivery of value to customers, and the traditional corporate hierarchy to be focused on the administrative aspects of “life.”

You too will need to strike the kind of balance that we at BMC struck with our measurement systems and with the corporate hierarchies. To succeed, you must teach your teams, as well as yourself, to live with duality and ambivalence without feeling torn apart inside. Do keep in mind that you are dealing with two levels of conflict that accentuate each other – the visible conflict between the two worlds, and the invisible one that is likely to evolve in your heart as to where your allegiance lies.

The Equipoise of Agile as a critical skill, which enables the Agile methodology to be effective in corporate setting in spite of conflicting belief systems, might seem a little intangible. Yet, whatever you do, maintain the equipoise. It will keep your projects going even if the multi-faceted answers that you provide to various tough questions are considered lacking by some purists.

Acknowledgement: I am indebted to Dean Leffingwell and Becky Straus who created the Agile self-assessment methodology at BMC and provided very useful comments and insights to this post. I am also most thankful to Melody Locke who helped me immensely clarifying and articulating my musings.