I am sure you have given some thought as to “why” leaders think about change as a noun rather than a verb? I would be interested in your insights.

I bet it has something to do with the cost of change. If the cost is high, let’s bite the bullet, get the change over with, and get back to making money. Therefore, change becomes a noun, an event. What if the cost of change was low? I bet the argument to think of change as a verb would be much more compelling.

That is where my comment about Agile mechanics comes in. I am really just making the case the mechanics are easier and that people can get their head around them faster. Mechanics give people something different to DO rather than something different to THINK.

Once you have agile mechanics in place, you start having real data flowing from your organization. You are in better position to measure how change impacts the flow of value. Agile mechanics allow you to make smaller more incremental changes and measure how those changes impact the overall system. They allow you to keep the cost of change low (and I would expect) leaders more open to change.

I tend to think of Agile Thinking vs. Agile Mechanics this way:

If I am going to take a drive out to California, I’d need to know where I am going, how I plan to get there, and some recognition that I’ll have to adapt along the way as I learn about the route. A well running car with the necessary dials, gauges, and levers would be nearly as essential to getting to my destination as the overall trip plan.

Without the constant flow of data that agile mechanics provide, I think it would be difficult to lead any sort of change initiative with confidence you’ll deliver. Without the visibility agile mechanics afford your organization, the risk of being wrong is way too high.

This is a great discussion, thanks for the thoughtful reply.

Sometimes I’m concerned that the agile community doesn’t explore enough good ideas that came before agile — like a lot of work about change. Then again, so much of that work is unreliable, the agile community may as well re-invent the wheel. I think the value system is right to do so.

The organic change that I would want to see at the top of whatever enterprise is contemplating an agile transition is a change is philosophy about “change.”

This is fundamental and rudimentary. . .

Follow me here please . . .

Agile views change as a verb. Actually, the more appropriate terms might be “adapt”, “evolve” and “emerge.” Agile methods are designed to continuously adapt, evolve, and emerge, so that the result is valuable in ways that were not exactly predicted.

Management typically views change as a noun. Change is an event to be managed in a programatic fashion in order to alter an environment from a before image to an after image, the after image having been predetermined by management. Change requires definition, middle and end states, selling, overcoming resistance, fancy names like “Quality Leadership 2010,” and roll-out programs.

Mike, the organic change that I like management to entertain is this very view of change from a noun to a verb.

When I get the opportunity to work with a management team to support an agile transition, this is where I focus.

If this is happening, then I whole-heartedly support your contention that there needs to be a “structure” to support the enpowered teams.

I’ve been thinking about your query for a few days — maybe more like a week. I’m left with a number of thoughts which i think are core or fundamental to your question.

Here’s the first. In my studies of change, there are three basic approaches — bottom up, top down, and organic. I think most agile transformations start as bottom up, then transition to top down when some ROI is sensed. But both of those types of change are terribly inefficient because they expect, prepare for, and deal with resistance.

“Organic” change is the most successful and also the most rare. Organic change is where the top management, usually the top leader his/herself experiences an epiphany or transformation and simply shifts their philosophy and starts doing things a bit differently. Over time, these “bit differently’s” add up big time.

So you say:

“So.. what I am really trying to say is that senior leaders must buy in and lead the culture change in their organizations. Create a system that rewards empowerment and self-organization… but… at the same time help the team put structure and tools in place that encourage total transparency and drive accountability and responsibility. We have to trust the team but the team has to demonstrate trustworthiness. Make sense?”

Yes, it makes sense as long as it is a transformation happening at the top and not a change program directed from the top.

There’s a difference.

It’s not about structures and processes . . . It’s about mindsets and cultures.

Thanks for the opportunity,
Christopher

I have worked in a couple command and control companies the past 10 years. A question that is very interesting to me right now is how do you manage through an agile transition? I agree 100% with your assessment that Agile Dynamics will trump Agile Mechanics. The question I am wrestling with is that changes in thinking don’t happen overnight. It takes time to make that switch. So what do you do as the leadership struggles to empower the team and the team struggles to take responsibility and become empowered. Can a leader let go before the team is able to take responsibility?

It seems that putting a structure in place that encourages commitment and accountability will help create an environment where trust and responsibility can develop. It is the engine for the cycle of visibility, inspection, and adaptation to really take hold. To get specific for a minute, implementing short delivery cycles, sprint planning, daily standups, and sprint reviews is just such a structure. Couple that with the right tooling for managing those committments, creating transparency with senior leadership, and you begin to establish confidence in the teams ability to deliver.

So.. what I am really trying to say is that senior leaders must buy in and lead the culture change in their organizations. Create a system that rewards empowerment and self-organization… but… at the same time help the team put structure and tools in place that encourage total transparency and drive accountability and responsibility. We have to trust the team but the team has to demonstrate trustworthiness. Make sense? For another view of this, take a look at my latest post on http://www.leadingagile.com If that URL does not work yet for you, try appliedagileleadership.blogspot.com.

You said a mouthful here: “Driving responsibility and empowerment from the top and demonstrating trustworthiness at the team level seems to be the perfect formula for organizational success.”

What that statement means to me is that you want the top, i.e., executive management, to demonstrate responsibility as a “how” rather than a “what.” The “how” of practicing responsibility is the inspect&adapt cycle applied to owning one’s thoughts and actions. When that is done, then an executive leader can become more empowering, i.e., better listener, more inclusive and collaborative, and more responsive to both successes and failed experiments around them.

Do you mean something like that?

Thanks,
Christopher

Driving responsibility and empowerment from the top and demonstrating trustworthiness at the team level seems to be the perfect formula for organizational success.

As always, I appreciate your contribution and look forward to your insights.

Mike

My best,
Christopher

Surely you meant to say _low_ agile tools quotient?

Thanks again for all you do to share what you’ve learned about personal responsibilty!

-james.