Jim Tremlett – Thoughts and confessions of an agile transformation consultant

Enterprise Tipping With an Agile COE

May 3, 2016 by Jim Tremlett Leave a Comment

This was initially posted at CA Agile Blog.

As a transformation consultant, I’ve had the opportunity to work with many agile Centers of Excellence (COEs). And along the way, I’ve developed a model for an agile COE that I have applied in both small and large organizations. I’ll introduce that model in this blog and provide more details in follow-up posts.

But first, some background. The first agile COE that I worked with served a 4,000-person IT organization and had almost 20 full-time professionals. This experience was great because it taught me the components to consider in an agile COE. However, the biggest lesson from this experience was that the only true measure of an agile COE should be the number of business units/delivery groups you transform to an agile approach. For a multitude of reasons, this COE focused more on adopting the Rally application lifecycle management (ALM) platform (now called CA Agile Central), developing a bespoke agile framework, and creating and delivering training—and less on transformational coaching of the business units and delivery groups.

Where the agile manifesto states a preference for working software over comprehensive documentation, a manifesto for an agile COE should state a preference for agile delivery groups over COE capabilities. An agile COE should remember that its value happens when the organization incorporates agile development into the way the organization works—into its organizational DNA. Everything else is a means to that end.

A Model for an Agile COE

With the caveat of the last paragraph, let me describe a model for an agile COE—a means to the end of tipping the enterprise. The model has eight components that are organized into three areas.

Process

The process area involves the framework (e.g., Scaled Agile Framework®, Large Scale Scrum) that the organization will employ, coupled with the training and coaching that will be provided to the organization. One lesson I learned in working with the agile COE described above was the need to align the framework, training and coaching. The coaching hub of that agile COE employed external coaches who needed to be corralled to coach the approach that was documented in the framework and taught in the training. The best way to ensure that the framework, training and coaching align is to have the same group handle all three. That way, the framework and training reflect the needs that the coaches see in their work with business units and development groups.

Healthy Adoption

I tried using different titles for this section, including “sustained adoption.” But I finally settled on “healthy adoption” for the combination of platform, community and metrics—because the goal of healthy adoption is continuous improvement.

CA Agile Central is an ALM platform, and as such, is a component of most of the agile adoptions that I’ve worked on. Even if the ALM tool employed is not CA Agile Central ;-(, the platform should be considered part of the COE offerings to the organization.

There are benefits to centralizing the administration of the ALM platform, including consistency in its application and sharing useful customizations. But I’ll share a word of caution: The COE needs to guard against constraining the process being followed by the organization. For example, the platform employed at the COE mentioned previously made the administration of Kanban flows more onerous than the administrators liked. As a result, the platform team pushed back on using Kanban in the organization—it was a little too much of the tail wagging the dog.

The aforementioned COE taught me the importance of community building: communications, events such as lunch-and-learns, and establishing a community of practices. While the COE is focused on transforming the enterprise, part of its job is also selling successes. I’ll never forget the impact of a video disseminated by the COE in which a well-respected business owner said, “We will never do anything other than agile in the future.”

Metrics can be a tricky area, and they’re often used to communicate the extent of the enterprise’s agile adoption. I suggest that metrics contribute to a more important goal of continuous improvement for how a team, delivery group and business unit use agile in their daily work. When continuous improvement is the objective, the metrics should correlate behaviors to desired outcomes.* Luckily, CA Agile Central was involved when the Software Engineering Institute created the Software Development Performance Index. Tying those outcomes to behaviors helps guide continuous-improvement efforts.

Transformation and Learning

The middle area, transformation and learning, focuses on transforming the enterprise and affecting the culture of the organization.

As stated in my previous blog post, I believe in transforming an enterprise by one business unit/delivery group at a time, and that it takes three such “tips” to fully tip that business unit. The transformation side of this equation entails a measured, purposeful transformation of business units within the enterprise.

The first step in successfully changing culture is changing behavior. That’s why I pair the two at the same level in the COE. That said, in any transformation that I’ve facilitated, the existing culture is often raised as a barrier to the transformation. So, in addition to changing the way delivery groups behave, it’s important to align the leadership of the organization with the new behavior.

I’m a big fan of the learning organization work of Peter Senge, author of the Fifth Discipline series of books, and founding chair of the Society for Organizational Learning. Recently, I discovered the book, “The Lean Machine. How Harley-Davidson Drove Top-Line Growth and Profitability with Revolutionary Lean Product Development,” in which Dantar Oosterwal describes how Harley-Davidson applied the lessons of the Fifth Discipline.

The reason I split this level into transformation and learning is that over time, the COE will shift from being transformation-dominated to learning-oriented.

The COE and the Rule of Three

The following figure depicts how a COE changes as a business unit or delivery group tips, and illustrates the focus on transformation to one of learning. At any point in time, the COE’s work within the enterprise will be a mix of transformation and learning.

The Learning COE

COE_interrelate Over time, an agile COE should work itself out of the transformation business and shift to being a learning amplifier for the organization.

This graphic illustrates how the three areas of the COE interrelate in a learning-oriented COE.

Communities of Practice

Over time, the COE should be replaced by communities of practice where the practitioners within the organization communicate and learn from each other rather than from the COE.

Measured Change

I’m a fan of measured change methodology, such as the Lean Change Method by Jeff Anderson. These change methods employ a Lean Startup experimental mindset to learn from each transformational activity.

As the big lift of the transformation is complete, the focus should shift to metrics-driven continuous improvement, which should follow this same experimental mindset established during the transformation work. In fact, it’s during this continuous improvement that the experimental approach of such change methods find their greatest traction.

Process

While I believe in starting with an industry-proven process framework, such as the Scaled Agile Framework, I also trust in ShuHaRi where the organization adjusts the framework over time. To empower learning within the organization, the presentation of any framework should support the practitioners’ comments and conversations about the framework—because that’s where the organization will start to contribute its HAs and RIs to the process.

Stay Tuned …

In my next blog post, I’ll provide more details about each of the COE model areas and describe the COE’s role in a learning organization.

*A shout-out to my CA Agile Central colleague, Ryan Polk, for introducing me to the six boxes approach to performance thinking (www.sixboxes.com). The “Connect Behavior and Outcomes” graphic is based on six boxes performance chain.

Enterprise Tipping and the Rules of Three

January 15, 2016 by Jim Tremlett Leave a Comment

Originally posted at rallydev.com

Enterprise tipping is NOT the corporate version of cow tipping, although it is fun to play with the analogy. 😉

Consider rewriting the following description of cow tipping (Wikipedia) replacing “cattle” and “cows” with “business units.”

“The urban legend of cow tipping relies upon the presumption that cattle are slow-moving, dim-witted, and weak-legged, thus easily pushed over without much force. Some versions of the legend suggest that because cows sleep standing up, it is possible to approach them and push them over without the animals reacting. However, cows only sleep lightly while standing up, and they are easily awoken from this state. Furthermore, numerous sources have questioned the practice’s feasibility, since most cows weigh over half a ton, and easily resist any lesser force.”

We often approach agile adoptions in large enterprises as if it’s possible to “approach them and push them over without the animals reacting.” For example, I often run into an enterprise agile adoption objective of transitioning 90 percent of the enterprise to agile development in 12 months. The reality is more involved; more like a sports or dance team getting great at what they do, as described by Peter Senge1:

“At some time or another, most of us have been a member of a ‘great team.’ It might have been in sports, or the performing arts, or perhaps in our work. Regardless of the setting, we probably remember the trust, the relationships, the acceptance, the synergy—and the results that we achieved. But we often forget that great teams rarely start off as great. Usually, they start as a group of individuals. It takes time to develop the knowledge of working as a whole, just as it takes time to develop knowledge of walking or riding a bicycle. In other words, great teams are learning organizations—groups of people who, over time, enhance their capacity to create what they truly desire to create.”

As an agile transformation consultant, I’ve developed two rules of three to remind myself and my clients about the challenging, yet rewarding work of tipping the enterprise toward a new way of working.

Muscle Memory Rule of Three

Scrum coaches are well aware of the muscle memory rule of three. It takes at least three iterations for a team to get comfortable with the rhythm of Scrum and its ceremonies, and develop a sustainable practice and velocity that allows it to plan and execute longer range. Think of Scrum as square dancing. It’s not enough to go through the dance moves just once; it takes multiple repetitions for the rhythm and coordination of the dance to sink in—the dancers need to develop muscle memory.

When scaling this iterative, incremental approach to a team of teams in frameworks such as the Scaled Agile Framework® (SAFe®), this same muscle memory rule of three applies. The team of teams needs to experience the rhythm and coordination of SAFe at the program level to get familiar with it.

Think of SAFe at the program level as a troupe of square dance teams that needs to dance together with moves between the teams (e.g., passing bandanas or cowboy hats). The planning event is where the dance of the upcoming program increment and the moves between teams are discussed. Like square dancing at the team level, it takes multiple passes at dancing at the team of teams level for the troupe to develop good coordination. In other words, it takes multiple program increments for the team of teams to get good at coordinated development and at handling dependencies between teams.

Here at CA, Agility Services has developed an approach to launching a program (a team of teams) called Ready > Sync > Go. During the Sync phase, each team gets good at dancing as a team while the program-level folks plan the coordinated dance of the team of teams. Once the teams and the coordinated dance plan are ready, the program holds its first planning event to launch the coordinated development of the team of teams. CA Agile consultants make sure the client organization builds its muscle memory for this coordinated dance by applying the rule of three.

Before moving on, I want to make a caveat. The muscle memory rule of three is not sufficient for a team or a team of teams to get great at the dance; merely good enough to improve on their own. I do believe in Malcolm Gladwell’s assertion (from his book “Outliers”) that it takes roughly 10,000 hours of practice to achieve mastery in a field. Finally, mastering agile development involves more than the iterative, incremental process pattern of Scrum and SAFe.

Organizational Learning Rule of Three

Personal change is hard; changing how we work as an organization is harder. As a transformation consultant, I frequently hear comments like, “We’ve been doing development this way all of my career, what’s wrong with it?” I’ve learned through experience that this reaction is not a request for the rationale behind a new way of developing, it’s a request for empathy. Organizational change is threatening. No amount of rational argument on my part, as an external consultant, is going to ease that discomfort.

I developed the organizational rule of three while addressing this resistance to organizational change. There’s a progression to overcoming this resistance even in the face of successfully launching programs, and here’s what it often looks like:

With the successful launch of the first program, I hear, “Well, we got lucky, we picked a good set of teams and an application area that is well-suited to agile development.”

The second successful program launch helps dispel the “we got lucky” rationale.

With the third successful program launch, the organization starts to own the process and make it part of its DNA.

Only when we reach this point has the organization reached the tipping point, that is, the point of no return. In his book “Tipping Point,” Malcom Gladwell describes it as:

“The tipping point is that magic moment when an idea, trend, or social behavior crosses a threshold, tips, and spreads like wildfire.”

When I work with an organization’s Agile Center of Excellence (COE), I describe this tipping point as the moment when the center stops pushing agile development and the organization starts pulling the center’s coaching services.

I don’t believe in big-bang transformations. In an enterprise with multiple business units, tipping the enterprise entails tipping individual business units. And like the progression of overcoming organizational resistance with respect to successful program launches, you have to tip multiple business units to tip the enterprise as a whole.

In this figure, the red down arrow represents the tipping point for that organizational unit and reaching that tipping point entails the rule of three with respect to the subunits.

Implications of the Rules of Three

The principal implication is that the urban legend of cow tipping is a bad mental model for enterprise tipping. We should dispel the myth that this is a simple, quick methodology change.

Enterprise tipping (truly changing the way an organization works) requires patience, focused effort and leadership.

It’s why John Kotter’s 8-Step Process for leading such a change starts with:

1. Create a sense of urgency

2. Build a guiding coalition

3. Form strategic vision and initiative

And ends with:

6. Generate short term wins

7. Sustain acceleration

8. Institute change

An Agile COE can help focus an enterprise’s agile adoption tipping initiative. I’ll talk more about them in the next blog post in this series. Stay tuned.

1. Senge, Peter M., The Fifth Discipline Fieldbook: Strategies and Tools for Building a Learning Organization, The Crown Publishing Group, 2014.

Jim Tremlett