Thoughts on The BMC Agile Transformation: A Seven-Year Perspective

Israel Gat (@agile_exec) (Cutter Consortium Fellow and Director of the Agile Product & Project Management practice), who is recognized as the architect of the agile transformation at BMC Software, socialized “The BMC Agile Transformation: A Seven-Year Perspective” article. Please see Rally Software’s Case Study and the Agile Journal’s Case Study for more information.

Without doubt, Israel Gat among others must be commended for their tremendous impact on BMC Software!

BMC Software’s Journey

The article emphasizes “deeper reasons behind the success of the BMC rollout”:

This Executive Update represents my current understanding of the deeper reasons behind the success of the BMC rollout [2004-2008]. It reviews past decisions in light of knowledge, experience, and insights that evolved a long time after the decisions, for better or worse, had been executed. In general, it’s about my making sense of things and sharing my insights with Cutter clients.

The article addresses “why agile”:

Agile offered an effective antidote to the “loss of heart” problem; if we did it well, we could demonstrate results quickly.

The article provides contextual background:

The scale of the rollout was determined by organizational considerations; the business unit I was heading had more than 400 employees in seven countries.

Not much was known in 2004 about deploying agile at such a scale. In many ways, we had to roll on our own. We were aided by a few outstanding consultants and coaches, including Dean Leffingwell (@deanleffingwell), Ryan Martens (@RallyOn), (now) Cutter Senior Consultant Hubert Smits (@HubertSmits), and Jean Tabaka (@jeantabaka).

The article introduces “the ‘secret sauce'” and ever-so-briefly identifies its ingredients: Leadership, Know-how, Flexibility, and Patience. The article emphasizes:

At a certain point in time in 2009, I came to the realization … that numerous executives are reluctant to adopt the secret sauce without a clear handle on how they will govern the software process.

It’s quite surprising that “governance” (or oversight) was a later “realization” versus being a foundational aspect of the transformation journey!

The article then emphasizes the value to BMC Software:

After a couple of years of “agiling” day in and day out, I thought we were doing pretty well. However, I did not know that we were indeed doing pretty well.

The Ultimate Benchmark: Transformation

The article then introduces the “ultimate benchmark for a transformative rollout”:

Successful as the agile transformation at BMC was, it completely failed in what I today consider the ultimate benchmark for a transformative rollout: it did not alter the company’s philosophy and modus operandi beyond the level of “How do we make the sausage? We use agile methods.”

To “alter the company’s philosophy and modus operandi” is what we commonly refer to as a Transformation — a value/principle-based change that focuses on the DNA of an enterprise (collectives, individuals, etc.) — versus a Transition — a practice-based change that primarily focuses on surface level behavior (“How do we…” and “We use…methods”). Furthermore, such a journey at-scale must be more holistic and go “beyond the [mere] level [of] agile methods”.

The article then introduces three levels of “agile implementation”.

First-level Agile: Development & Test

First-level agile implementation involves “Development” and “Test”:

From my perspective today, this means that I was primarily concerned with two strands: development and testing. I was able to “merge” these two elements so that testing could start before development was complete — and testing informed development through tight feedback loops.

Fundamentally, balance among three core perspectives (define-detail, build, and test) is crucial.

Second-level Agile: Strategy & Delivery

Second-level agile implementation involves “Strategy” and “Delivery”:

In my humble opinion, the very same agile principles hold at the strategic level. The only difference is that the interplay is not between development and testing but rather between strategy and delivery. One merges the two so that delivery can start before strategy is complete — and delivery informs strategy through tight feedback loops.

Fundamentally, focus on both value discovery and delivery (essentially, “strategy”) is crucial.

Third-level Agile: Problem & Solution

Third-level agile implementation involves “Problem” and “Solution”:

At this [third] level, one merges the problem and the solution so that the solution can start before the problem has been fully understood — and the solution, incomplete that it might be, informs the problem through tight feedback loops.

Fundamentally, as discovery organizes around the problem and delivery organizes around the solution, they co-orient on one another’s targets via their integration.

The BMC Experience: Transition

The article then considers the BMC experience relative to the “Ultimate Benchmark”:

The BMC transformation was quite successful at the first level but did not really make it to the second level, let alone the third.

The inability to reach second-level agile implementation perplexes me to this very day. My hunch is that this probably reflects a lack of readiness at BMC at the time to accept unpredictability at the strategic level.

What I probably did not quite understand at the time was that BMC conceived strategy as largely fixed for prolonged periods of time. Rightly or wrongly, continuously grooming strategy (in a manner conceptually similar to the way one grooms the agile backlog) was perceived as too radical.

BMC’s journey really focused on “development” and “test”; it seemed to insufficiently encompass the define-detail perspective, however, “Requirements Architect” is briefly discussed in the Case Studies.

BMC’s journey really focused on “delivery”; it seemed to insufficiently encompass discovery (or “strategy”).

BMC’s journey really focused on a technology-based transition; it seemed to insufficiently encompass a more holistic (business and technology) transformation.

Artful Transformation

Our approach, which we call Artful Transformation, is intentionally holistic and transformative!

Enterprise scale is not merely about “size” but about the whole enterprise (its wholeness, including all its aspects and dynamics)!

Agility is much more than “Agile Methods”! Boydian Agility readily trumps mere Agile Methods (or Agile Software Development)!

Transformation involves value/principle-based change that focuses on the DNA of an enterprise while Transition involves practice-based change that primarily focuses on surface level behavior.

Again, without doubt, Israel Gat among others must be commended for their tremendous impact on BMC Software (and the BMC Agile Transition), however, that success could have been so much more with a more holistic perspective and transformative approach!


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s