(originally published 24 January 2008 by the Cutter Consortium Agile Email Advisor)
by Christopher M. Avery, Senior Consultant, Cutter Consortium
Activate Your Personal Agility Christopher Avery wants to be your personal agility coach. Please accept this invitation for priority access to a FREE live 70-minute tutorial "Master the Four Magical Skills that Activate Your Personal Agility. Build Any Team Any Time, Generate Abundant Goodwill, Cooperation, Trust, and Get RESULTS." This tutorial is packed with valuable content you can immediately use. Click here for your free access.
In his ongoing Agile Advisor series on agile transitions, Cutter's Agile Practice Director Jim Highsmith referenced Cutter Senior Consultant Michael Mah's extensive database showing the actual performance characteristics of companies pursuing agile methods adoption (see "Agile Transitions, Part 6: Rollout Strategies for Your Culture," 17 January 2008). Jim wrote:
The highest levels of performance are reserved for those organizations that have altered their culture from top to bottom, and not just tried to "change" the individual contributor levels (developers, QA staff, product managers, etc.). Those companies that have accomplished changes in management style and altered their performance measurement systems to encourage agile development have gained the greatest rewards.
Is anyone surprised? I bet not.
It's fantastic to have Michael's evidence for confronting the true problem with agile adoption; i.e., that agility is really about mindset and culture, not about process and tools. But the overall finding isn't news. Industry insiders, experts, and analysts have opined for years that the real problem in scaling agile beyond a few teams is cultural. Agile processes and tools — i.e., the "mechanics" — just don't flow well in command-and-control cultures.
What's missing? The dynamics of Personal Agility.
As a student of organizational agility — not just project agility — for the last 20 years, I've seen the same pattern time and again across a variety of productivity movements, including at least:
- Total quality management, continuous improvement
- Concurrent/simultaneous engineering
- Business process reengineering (flattening)
- Cross-functional teaming
- Team-based organizing
- Supply chain partnering
- R&D consortia
- Joint venture collaborations
- Lean enterprise
- Agile, Scrum, XP
Each of these productivity movements has required an identical set of cultural features for success. Those features include the following propensities:
- For collaboration, partnering, and trust
- For openness, transparency, and visibility
- To adapt, iterate, and evolve
- Toward heightened human awareness, learning, and the courage to confront reality
- Agility requires it even more so.
Consider arranging results in a classic 
two-by-two matrix that measures agile tools quotient (i.e., mechanics) on one axis and personal agility quotient (i.e., dynamics) on the other. The scaling trend I've seen has been that most agile adoption efforts today attempt to move from quadrant 1 (low agile tools quotient, low personal agility quotient) to quadrant 2 (high agile tools quotient, low personal agility quotient) by teaching and installing agile tools and processes — i.e., the mechanics. The result is much pain. When enterprises instead focus on developing the leadership and people dynamics of agility, what I call personal agility, they move from quadrant 1 to quadrant 4 (low agile tools quotient, high personal agility quotient). From there, it is a much easier and more successful move to install the mechanics.
So What Is Personal Agility?
Personal agility has two major components, the first of which is "personal responsibility." Let's start there.
I've studied personal responsibility since 1991 and have found that it is not just a character trait (or character flaw), as society teaches us to believe. Instead, responsibility is a mental process that each of us uses naturally either to avoid or to take ownership of our lives and choices. Frequently, it takes guts to own up to responsibilities. As a highly responsible person, you know this, and there are probably plenty of things you aren't owning (the same is true for me). So the truth is that even highly responsible people do irresponsible things every day.
These little things make a huge difference in individuals, teams, and organizations. Unfortunately, there are more psychic rewards in most cultures for avoiding responsibility than for taking it!
It seems that when individuals at all levels opt-in, engage, and own their behaviors and results, then really great stuff happens. You don't need to focus on driving people, because they are driving themselves.
The second component is "shared responsibility." Shared responsibility is a natural shift in behavior whereby you and I are both willing to fill the gap between us (i.e., between our roles) when one of us drops the ball or when something goes wrong. I'm not talking about just mutual back-watching or reciprocity. I'm talking about when you absolutely know that helping me moves you toward your goal, and I absolutely know that helping you moves me toward my goal. In the language of team-building, shared responsibility is what "breaks out" when we fundamentally realize that we are in the same boat together, and that the only individual win comes from a collective win.
If you are interested in understanding more about how responsibility works in the mind, I have written extensively about both personal and shared responsibility in my Advisors and articles for Cutter as well as other places. What most people seem to want to know about it is how to develop it. The good news is that it is relatively easily developed in individuals, teams (even families), and enterprises willing to study and apply the principles and practices to leadership and decision making.
Popularity: 2% [?]
Related Posts
“quadrant 4 (high agile tools quotient, high personal agility quotient”
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.
James, that is indeed how it should have read and it is now corrected. Thanks for the catch, and you are most welcome.
My best,
Christopher
To reach quadrant 3, it seems you need to score high on both personal agility and tools. Without personal agility, any effort toward agile adoption will fall short. On the other hand, tooling gives us a structured mechanism to make commitments, manage those commitments, and then demonstrate that we have delivered. Consistent delivery builds trust.
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
Mike, thanks for weighing in.
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
I was just getting ready to post a note to my blog the other day on Agile Mechanics when I read your post about Agile Dynamics vs. Agile Mechanics. Your post was timely and influenced my thinking on this.
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.
Hi Mike,
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 thought I would add another snippet . . .
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.
Hi Christopher,
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.