Tag Archives: agile transformation

Making Time for Agile Transformation

Coaching tips,

Today I’m planning on painting the living room so I figured I’d get a few things done early in the morning.  I still have a bad habit of checking my email first thing in the morning and at the top of my inbox was my personal coach’s Monday morning message.

It’s a short post, feel free to check it out but don’t forget to come right back!

It’s 8:18am, I can hear the cyclone of activity as my kids are getting ready to leave for school in 10 minutes.  As usual, my wife is flustered, my daughter is singing My Little Pony songs right behind my office chair and my son is drawing pictures of skyscrapers.

The clock is ticking to leave and I can feel the stress in my shoulders and neck as my wife is doing the last minute lunch bag and backpack check while belting out “c’mon kids, time to get ready to go!!!”

After I read Cynthia’s post I realized I was doing 4 things at the same time and rushing through all of them just to “get them done” so I could get ready to start painting.  All of a sudden a certain calmness fell over me as the words of Cynthia’s post made their way through my neural network. 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.

Recovering from Failing Miserably at Agile 2012

Agile 2012,

“HUGE DISAPPOINTMENT” were the words sprawled across one of our feedback forms from Shaping Your Agile Adoption Path that Don Gray and I presented at Agile 2012 yesterday.

“I can’t remember a time where I scheduled a 3.5 hour session and received less value.  These two instructors provided nothing – the participants did ALL the work.  The session description should have said that was the approach.  This session is a great example of why  agile gets a bad name, it felt un-planned and chaotic from the start, no solid content/insights were delivered.”

This was the first time I have received bad feedback for any session I’ve done.  There were a few ‘very goods’ and ‘satisfactory’ marks but overall the average score was between ‘satisfactory’ and ‘poor’, although I didn’t calculate the exact scores.

So what happened?

Let’s start with our session description:

Adopting Agile usually involves massive change for organizations. Making matters more complex, there are a whole bunch of paths to explore many of which generate resistance. Some people consider Agile to be a mindset. Others feel Agile is simply the adoption of processes and practices. During this experiential session you will learn how to:

  • understand where resistance comes from and how to deal with it
  • use a greater level of awareness about your people and culture to shape your path to Agility.
  • leverage your preferred leadership style and understand its impact on the change

What We Thought Would Happen

Don ran this session 3 times locally, I ran it twice to great reviews and feedback.  This session started at AYE last year when I asked Don “hey, I have an idea, wanna chat?”

First we break people into like-minded groups by asking them to self-select into groups based on figuring out which of 4 statements most closely reflects each participants view of themself.    This is based on MBTI function pairings, and by getting people into like-minded groups we would amplify the differences between the groups to show where resistance comes from.  We thought the “Green Groups” (based on the NF function pairing) would bring a more touchy/feely mission statement, which they did, and the “Red Groups” (based on the ST function pairing) would bring a more process, rigid and plan driven mission statement, which they also did.

We would also show the impact of a leader with certain preferences can have on your Agile Transformation.  For example people with ESTJ preferences tend to not like change because they can struggle with un-certainty.  They like control (when in leadership positions) and plans and can appear more resistant because they progress through change at a slower pace than people with other preferences.  An ENTP, for example can drive an ESTJ nuts by piling on too much change because they embrace change and love generating new and different ideas.

During the de-brief we expected the people in the Red Group object strongly to the Green Groups “touchy/feely” plan for an Agile Transformation and then we would lead into how resistance forms, not because people are being resistant, but because they process change differently and at a different rate than others.  Resistance is a response from our brains to protect us from physical or mental pain, and change can be perceived as a threat.

What Actually Happened

If you’re not about the details, skip to the “what I learned and what I’m trying next” part.   I suspect certain types will skip these details.  I know I would.  First of all, we moved our session to a bigger room because of the demand.  The bigger room had no chairs in it so when we had them delivered, we asked for the room to not be setup.  We wanted to send the group into chaos right away and see how they would respond.  We thought that would lead to some interesting discussion about change, which it did.  Some people were confused, some people didn’t care.  One person wanted to arrange neat rows of chairs and his collegue wanted to scatter the chairs around the room.

We did 3 exercises, each with a de-brief.  Come up with your mission statement, use your mission statement as a guide to create an agile rollout plan based on a made-up scenario and cross-examine plans with other groups.

That’s where it all went to hell.  Despite their differences and despite the differences they listed in the mission statement exercise, all groups largely came up with the same plan.  All were plan driven (except one) and they followed the same pattern of “training -> do pilot – > generate continuous improvement -> rinse/repeat”   During the debrief we got the “green groups” to examine the plan from the “red groups”, and vice-versa, and have the participants answer these questions:

– what parts of the plan made you say “right on!”
– what parts of the plan raised red flags for you?
– what did you notice about your reaction to the red flags?

Well, that bombed because they all had generic, best practice plans about building collaboration through training, self-organizing teams and all the generic Agile rhetoric you hear.  There were subtle differences, but overall absolutely no discussion was generated from any of the de-briefs.  I wanted to jump in and start telling them my observations but I wanted to practice running an experiential session so I kept my mouth shut.

After that we showed the culture, change and behaviour models we used and that’s where people found value.  We talked about how if your organization is a control culture and you come in with Agile Values and Principles, you’re more likely to be met with resistance.  Unfortunately they were so bored during the previous exercise most people had already filled out the feedback form so we didn’t get the benefit of having them validate how smart we are.  One participant tweeted that our handouts were the best part of the session!  And being a ‘greenie’ (NF function pairing), she feels bad every time I mention it, so…sorry about that!

What I Learned and What I’m Trying Next

  • We said our session what ‘experiential’.  Next time I’ll do a better job of explaining what experiential is, although when we told the attendees what we were going to do once person literally got up and ran out.  I will assume he was an ISTJ.  If you know MBTI you should think that was funny.
  • The feedback from colleagues and other practitioners was positive, they felt creating an environment that allowed participants to learn by thinking was great and thought the negative feedback was a sign we did the right thing by getting our participants to think and experience chaos instead of peddling easy answers
  • Next time I am bombing with an exercise, I’ll stop and say something like “I’m not feeling much energy from the group around this, I had planned to do ABC.  Some other options are going in this direction or that direction, what do you think?“
  • Next time I’ll draw more attention to the differences by pointing out observations I see with ‘pulling’ questions.

Most importantly I learned that change is painful.  Really painful.  An Agile Transformation can be one of the biggest changes an organization will ever go through.  The negative feedback we received leads me to believe we didn’t make our audience feel good because we didn’t give them any easy answers.

We didn’t do that because there aren’t any.

I want to understand why organizations try transforming multiple times without success.

I want to understand why people want to be given best practices instead of wanting to understand what change is and that Agile isn’t the point, it’s the trigger to change.

I have started a Linked In group about Agile and Organizational Change so I can help organizations understand that an Agile Transformation is a trigger.  It’s not the goal, it’s not the problem, it’s simply the trigger that exposes how broken your organization is.  I want to learn how to transform human resources and other departments that are designed to bring and support change.

Sustainable change can only come from within your organization, not from sending somebody to a 4-day conference or brining in a consultant for a week.    Or a month.  Or maybe longer.

I am also releasing a video series on Safari Books Online about Agile Transformation in late 2012.  My goal with these Live Lessons are to give you a framework to guide you through Agile Transformation by understanding change and the impacts it will have to your organization, free of Agile BS and buzzwords.

I am happy I had the opportunity to work with Don on this session and I’m also happy that Johanna Rothman inspired me to turn this colossal failure into something positive.

Finally, I want to say thank you to the 5 people I talked to afterwards who appreciated the session.  In my mind, you are the people who ‘get it’.  You are the people I want to reach because you care enough to know how difficult this is, you understand there are no easy answers and you stress about how to make your organization better.

You are the reason I do what I do.