Tag Archives: change management

Make Change Easier

Change Management, ,

More and more organizations are looking to adopt Agile practices in order to transform their organization.   In my experience, people in organizations are overly focused on how to motivate people to “be more Agile”.

How can we get those pecky testers to “be more Agile?”  How can we can those control-freak PM’s to “be more Agile?”

If we boil away Agile and all the associated methods and tools, we’re left with wanting people to behave differently and many people focus on motivation being the key to behaviour change.  Plenty of people cite Dan Pink’s Drive (mastery, autonomy, purpose) as being the keys to motivation.   Motivation is important, however without ability to do things differently, change isn’t likely to happen. Continue reading →

2 Things that are Killing Your Transformation

Leadership and Management, ,

In my last post I referred to a few studies that show only 30% of change initiatives are successful.  The US Air Force recently cancelled a 6-year program that cost in excess of $1,000,000,000.

One. Billion. Dollars.

Seriously.  One.  Billion. Dollars.

So naturally I expect the reaction to range from “what a bunch of idiots” to pundits speculating why this massive program failed with little to no data or insight into the actual problem.  Who knows, maybe they were only ‘doing Agile‘ when they should have been ‘being Agile‘.   Disclaimer, I have no insight into whether the US Air Force uses Agile methodologies, I simply thought it would be funny to take my usual jab at the useless endless ‘being vs doing’ arguments.

I have no doubts there were tremendously intelligent people at the Air Force working on this program.  I’m sure many, or at least some, of them throughout the 6 years wanted to stop the program because of the high risk and un-certainty.  Inertia is a hard thing to stop. I remember trying to stop a resume-building project at a small company that for some reason we just couldn’t kill.  And we all thought it was useless.  It’s hard to let go of that sunk-cost plus how crappy it feels to think you’ve just wasted a chunk of your life doing something.

Anyway, because I like to solve problems I want to find out why only 30% of change initiatives are successful.  My latest stance on this problem came from a bunch of discussions at LESS 2012 this year.  What are these 2 things that are killing your transformation?

1) A Name: Putting a name on your transformation almost certainly takes the focus away from transforming and puts it squarely on a performance scorecard that, while designed with good intent, is actually working against your transformation and organization. After all, people have proven they are to be distrusted and must be measured, that’s the only way they’ll do the right thing right?

Why is it working against your transformation?  Well, because most people know the traditional organizational scorecards designed to ‘measure outcomes‘ are bullshit.  Employees despise those annual rituals where you compare what you thought you’d accomplish a year ago with where you are today.  Then you justify why you didn’t get to where you thought you would, complain about it and then do it all over again because, well, that’s the process.

I’ve spoken with many folks who are mandated to create those performance programs and they don’t like them either.

The solution?  STOP DOING THEM.  Duh.  And yes it’s that simple, the only thing you need is an Exec with the stones to throw them out and find something that works better.  Management 3.0 has a whole bunch of options.  If you’d like, I can run a class for you.  ;-)

2) A Deadline: Putting a deadline is effective for setting a target but remember you cannot control implementing a massive transformation by attaching some magical date somewhere in the future that sounds good.  That will certainly undermine your efforts as people figure out how to game whatever ‘metric’ you’ve put in place to ‘ensure’ the deadline is met.

The solution?  Think of deadlines as targets.  And set shorter time horizons for those targets.  If you need help with that, check out The Rockefeller Habits.  If you’re undertaking a large transformation and think you can plan (upfront) your way through it, you are out of your mind.  Either that or you should buy a lottery ticket because you have some gift for seeing the future.

So what’s with all the snark in this post?  I guess I’m sick and tired of hearing “we can’t do that because <some bass-ackwards policy> says we can’t” or “it’s out of our control…we can’t do anything“.

Let’s be clear, YOU and the people in your organization make those policies.  Change them.   Those are the speed-bumps on the road to your transformation and they’re not the problem.  The actual problem is the status quo that has led to responses like “we can’t do that because…”  People in your organization have been beaten down by the system so many times they stop questioning it.    I think some nut named Deming has something to say about that.  Google it.

Well, what have I accomplished with this post?  Will people read it and feel inspired to start questioning the system and status quo?  Hopefully.  Will it piss some people off?  Probably.

That’s what great and what sucks about being a change agent.  You get stuck on a named transformation with a deadline that you can’t control and a lot of your work ends up being waste because you cannot control what will happen in a complex system when you introduce a change.  Often the change agents get the blame, well at least from my experience that happens.  I’ve been fired before and many of my colleagues have been too.  It’s easier to do that than figure out why the ‘transformation‘ didn’t work.  Since all employees are bad, someone has to be blamed.

The only solution I can come up with, that will of course create more problems, is to focus on whatever process or rule is mentioned when someone says “we can’t do that because <this stupid process> says we can’t.”  Forget the name, forget the deadline, start fixing that problem and see what happens.

Evolving Change Management

Leadership and Management, ,

The Agile community talks a lot about “agile failure” and I’ve seen more than enough debates about “doing vs being Agile” to want to shoot myself, but what about failure of change initiatives?  Let’s face it, Agile is simply a trigger for change, not a destination.

Change efforts have a lousy success record according to this article.  Here are the success percentages with respect to change initiatives from the article to save you some time.

1995 – Kotter: 30%
1998 – Turner and Crawford:  33%
2005 – Procsi: 29%
2008 – Mckinsey: 30%
2011 – Standish Group: 34%

At the Toronto Agile Tour this past Monday (Nov 26), Andrew Annett and I presented  “Managing Resistance to Change” and our desire was to change that to “Managing Responses to Change”.  The important distinction is that people do not “resist” change.

What we label as “resistance” is simply a response from someone who, for a variety of reasons, doesn’t understand the need for the change.  I won’t go into details for the purposes of this post, but obviously it’s more complex than that.

Is there a better way to manage change?  Can you actually manage change?  The metaphor I like to use is about managing the ensuing chaos after the change, not necessarily “managing the change” itself.

Oh no, not another model

I want to keep this post at a high level of developing a more cohesive change management strategy.  Given the article I mentioned talked about lack of structured change management process and a simplistic view of human behaviour as the two major factors, I think this approach to creating a change strategy addresses both.

1) Understanding Change: Learn about the Satir Change model, Interaction model and Human Validation Process model.  This will prepare change agents for what to expect from people and teams.  Along with understanding how people process change, I’ve run sessions that map MBTI temperaments and function pairings on top of the Satir change model.  As a quick example, someone with a Guardian (SJ – Sensing, Judging) preference will appear to be resistant when change is pushed on them.  They rely on past experiences and value stability, hierarchy and process.   You can also use models like SCARF and the Fogg Behaviour Model to understand the human behaviour side of change.

2) Prepare for Change: This is where classic change management comes into play.  Using the ADKAR tool (awareness, desire, knowledge, ability, reenforcement) , collect data and filter by layers of hierarchy, teams and departments to paint a picture of where trouble spots may lie.  For example, you could discover that the “Ability” score is low meaning that more time may be needed to support people through the change.  You may also find out that certain teams, groups or people have lower desire to change than others.  This data will help you figure out your change strategy.  There are other methods like interviews, walking through Kotter’s 8-step change model, cultural assessments (William Schneider) and more.

3) Trigger the Change: For this post I’ll use an Agile Transformation.  Depending on what data emerges from step 2, the trigger may be a manager training program for example.  You may discover there is no desire to change and stop the initiative altogether.

You could use “Agile Transformation” as the trigger or “Agile Adoption” as the trigger or the 4 Disciplines of Execution.  There are many more triggers depending on what problem you’re trying to solve with the change.

4) Manage the Response:  We’ve been experimenting with using Lean Startup techniques (Lean Change) to manage introducing change into organizations.  Lean Startup shortens the feedback loop as much as possible, allows you to validate the “minimum viable changes” before introducing them and involves the people affected by the change earlier.

During this step you’ll see your organization move from complex to chaotic and you won’t be able to predict how people will respond and naturally, those who struggle with the change will be labelled as resisters.  This is where it’s important to put reenforcing structures in place to help people elevate themselves into the new status quo.

Using Management 3.0, Speed of Trust, complexity thinking, systems thinking, 5 Dysfunctions of a Team and other frameworks can help people learn new techniques for managing this chaos.  I suppose this could fit into ‘Prepare for the Change” but I’d prefer to wait until I’ve poked the bear before spending too much time, money and effort over-planning for a reaction you cannot possibly predict.

I haven’t mentioned the other hoards of models and instruments that can be used during these stages.  All I know is there are enough models and thoughts from the change management world that can merge with the ideas in the Agile community to help organizations evolve into organisms that can adapt to their constant changing environments.

Stephen Hawking said that we are entering the age of complexity and the average life expectancy of corporations has shrunk from 70 years (1938) to 15 (2010).  Organizations that learn how to adapt will survive.  Organizations that don’t will die.

There must be a better way to help organizations learn how to change.  I’d love to hear your feedback and thoughts about how we can bridge the gap between change management and “Agile” and start focusing on fixing real problems.