Published yesterday by The Cutter Consortium. Thanks for their permission to share it with you in it’s entirety.

Easy Executive Change

by Christopher M. Avery, Senior Consultant, Cutter Consortium

Want to make change a lot easier on yourself and develop a winning and happy organization at the same time? It might be easier than you think. I’ll tell you how.

Last week was Agile2007, the annual conference for those practicing agile software development. It attracts mostly developers and project leaders, but more and more executives are attending with an interest in applying the principles of agile enterprise-wide. One of my missions last week was to attend sessions from Monday through Thursday morning that promised good content on agile leadership, agile organization, or agile enterprise. Then, on Thursday afternoon, I invited attending executives to a 3.5-hour think tank to consider how to apply agile principles to make change easier for executives.

First, a fast consensus was reached among the VPs, CTOs, and directors in the room on the major risk. It shouldn’t surprise you, but if you had not thought about it, it’s time to start:

• An agile front line — i.e., development teams — with a traditional management approach (read “silo” mentality and culture) over them is not sustainable.
• An agile development environment deserves and requires a collaborative executive leadership that treats change as easily as does the front line.

On these points, everyone agreed. What was interesting to us is that the messaging to executives from agile folks during these growth years has been about selling decision makers on the value of agile development in order to increase adoption of the practices. What is different with the consensus reached in our think tank is that for agile development practices truly to be adopted, executive teams must become more agile as well.

Where development organizations practice agility and the executive management operates traditionally, the organization will develop an invisible inversion layer between the two different contexts (the agile front-line context and the traditional management context) such that very little information, truth, or trust crosses between the contexts. Development managers will be pinched in-between and do their best to operate in both worlds, but will be increasingly seen as incompetent by each world for their inability to make things happen in the other.

Why?

One excellent way to view this is to examine how each context (or “world”) understands change. Let’s start with the traditional management world. It views change as an event to be managed. This context actually avoids change in an effort to remain efficient. Then when the altered environment presses in, the traditional management decides that a change is needed. They name it (e.g., “Quality Leadership 2010″), mandate it, program it, assign a change team, role out the change infrastructure, sell the change, and overcome the expected resistance. Thus change is an event to be managed from the before state to the after state. I’ve written about this at length in a Cutter Executive Report called ” Responsible Change,” (Vol. 6, No. 10).

The shorthand we reached in our Thursday session for this mentality is “change as a noun” because of it being a named event on which everyone focuses and pushes. Success is, of course, declared at the end of the event.

So what about change in the agile world? The principles and practices in agile development generate a mentality where change is easy, expected, and continuous — no big deal. The time-boxed iterations, value focus, backlogs, retrospectives, and so on, all work together to make change a verb rather than a noun. Change is achieved as a matter of course. It is not focused on, not resisted, not named, not programmed, and not sold. The discipline pulls change into each iteration, each daily stand-up, each release, and each retrospective. The result is that great value is produced rapidly, and work ceases when the value stops flowing from it. We began referring to this world as “change as a verb” because of its emergent nature.

How?

This group of executives examined agile principles and practice and recommended steps any executive team can take to make change easy and amplify success. First, they suggest setting up a meeting rhythm like that in agile development process. Such a rhythm includes daily stand-ups, iteration planning, retrospectives, and the like. This facilitates cohesion, transparency, information sharing, dealing with reality, and building trust. Then you add in priority backlogs so you can get a shared sense of priority and the ability to measure executive team velocity. Executives can pair, too, on initiatives to drive innovation and learning.This may sound too straightforward and simple to be true, so what’s the catch? The catch is confronting yourself about what it means to be a successful executive and executive team.

I’ll be happy to help you with that!

I’ve had lots of fun writing these monthly advisors and am going to take a break for a while. I’m still interested in receiving your questions. Write me at cavery@cutter.com.

Sincerely,
Christopher M. Avery, Senior Consultant
Agile Product & Project Management Practice
E-mail: cavery@cutter.com

And of course you can write me at ChristopherAvery@ChristopherAvery.com but I bet others would like to see your comments here.

Easy executive change is an issue I’ll be working on. What do you think?