The first session I attended was about managing change and it was hosted by Steve Smith.    Since I’ve written about this before, I’ll give you the reader’s digest version.  This post will make more sense if you have a basic understand of the “J curve” that is the Satir Change Model.

Steve broke us into groups, Old Status Quo, Foreign Element, Chaos, New Status Quo.  He selected a “star” and the objective of the session was for the Old Status Quo (the group I was in) to keep the star in one corner of the room.  The objective of the New Status Quo was to get the star to move to the opposite corner of the room.  Chaos’ responsibility was to disrupt everything and the Foreign Element’s responsibility was to trigger the disruption.

Long story short, here are 70 or so highly enlightened Agile practitioners, for the most part, building walls out of tables and chairs, pushing and shoving each other, tossing chairs aside and trying to meet their groups objective.  The experience had escalated to the point where Steve had to interject and yell “STOP!”.  If you’ve never met Steve, he’s about 6 foot 4 and has a deep booming voice so that snapped all of us back into reality.

Over the last couple of years I’ve spent most of my time studying and experimenting with change management, organizational change and neuroscience tools, methods and techniques to try and figure out why there is so much emphasis on managing change and if it’s even possible to “manage change”.

The message at AYE was quite clear to me.  You cannot control change and that, to me, is implied with managing change.

I have seen too many instances of plan-driven approaches to change fail when they’re driven by budgets and timelines.  They’re driven this way because executives need to budget for a change team which means the change team has to come up with a plan that makes the executives feel like everything is under control yet the change team knows the plan is a pile of, um, you get the idea.  Not a great place to be starting from.

A couple of weeks ago at the Art and Science of Change in Toronto I gained some insights into how plan-driven the traditional change management world is.  To be clear, I am using the term “change” in the context of transformational change.  There was much talk about 12-step change programs, driven by schedules and budget, as well as talk of ROI and other non-sense (to me!) that cannot possibly deal with the complexity of transformational change.

There is no shortage of change methods available and many studies from organizations that developed these methods show a 30% success rate yet they still cling to plan-driven approaches to change all the while wondering why it doesn’t work.  And these are some incredibly smart people I’m talking about.

So how does transformational change start?  From my experiences it’s usually brought in by management or executives with a top-down approach.  I’ve seen bottom-up approaches as well but for this post I’ll focus on large-scale transformational change brought in from the top.

The executive initiates the change, the change team comes up with a nice plan, wiki, intranet and newsletter based on some ‘best practice’ and the change plan starts.

The problem is, there is no ‘start’ to change.  Once the rumour mill is ignited with this transformational change, the change team is working on the plan while the worker bees are already freaking out about the impending change.   The organization is already in chaos before the ‘change project’ has even started.

The change team then executes the plan that was developed at a point in time that is no longer relavent.  I’ve been tinkering with a visual to explain this and, as usual, I recently found out something already exists.  It’s called the Fragmentation Prime.

The change plan breaks down when there is fragmentation across different levels of the organization.  I’ve worked in organizations with visionary executive leadership that were too far ahead of the rest of the organization.  I’ve also worked in organizations with the opposite fragmentation.   Teams are kicking ass with Agile and executives are completely un-aware or they get wind of it and try to control and standardize the new process.

I have ‘aha!’ moments to this day from AYE 4 years ago.  Managers in today’s organizations are not change agents, they don’t have the skills, experience or education to execute change because that’s not their focus.  Their focus is expertise and experience in their domain whether it be testing, development, infrastructure or what-have-you.  They’re simply not equipped with the tools today’s change managers, organizational development and (some) agile coaches have.  This isn’t a knock on managers, I’ve been in those situations many years ago and remember feeling terrible that I had no idea how to deal with change and how it affects people.   I used all the ass-backwards performance models and scientific management styles that are irrelevant in today’s knowledge work.

Compounding the problem is when the executive that initiated the change leaves within a year or two and their successor decides Agile wasn’t the right thing and goes back to the old way.  In that case, managers and staff are more confused and develop an apathetic attitude over time because they know whatever change is mandated will die when the initiating executive leaves.  I’d be interested to find out the average tenure of a CTO or CIO, I suspect the churn is more frequent than managers or staff.

When it comes to change, some take the perspective of changing behaviours or developing a new mindset or changing the culture.  Some take a brain-based approach (Results Coaching) to organizational change by focusing on developing capability with managers.   Some take the approach of using frameworks like the 4 Disciplines of Execution or Rockefeller Habits for creating focus and direction.  Some use traditional, linear and plan-driven methods such as Prosci’s ADKAR or McKinsey’s 7S.  Some say Kanban or Scrum is the best and try to create a cookie-cutter approach to change.

There are no shortage of approaches to how to bring about transformational change but you’ll discover that people are fans of what they know and are quick to dismiss other ideas and approaches.  Looking at Jung’s Ladder of Inference it’s possible to see why that’s the case.  People attach beliefs to their method of choice and filter out possibilities from other methods.  It could be their method of choice worked once or their method of choice sets their confirmation bias light in their brain explode.  We are all biased in some way so this is natural.  The key is to become aware of your own bias‘!  As an example you’ve probably seen debates in the Agile/Lean communities where one camp says Kanban is the best and everything else sucks and the other camp says Kanban sucks and Scrum is the best.  That may be true from their perspective but that doesn’t make it a universal truth.  That phenomena is called yelling from the top of the ladder.

It’s also important to consider how people process change and the temperament of the change agent and change sponsors.  To generalize, if your change sponsor has a strong Guardian (SJ) preference, they may be more inclined to push a plan-driven approach because that’s their preference.    Using feedback-driven approaches to change by learning about systems thinking and complexity science might not make a lot of sense to someone with a strong Guardian preference because it may appear to be too passive and the change team is sitting around waiting for something to happen or waiting for people to ask for help.

We must balance the art and science of change and use different approaches from a variety of methods because of these reasons:

• Complexities of organizations (systems thinking, complexity science)
• How people process change (Satir)
• Our own bias’ (there are hundreds of them)
• How people’s preferences contribute to the complexity of change (Keirsey – Temperaments)
• How change agents are biased (Jung – Ladder of Inference)
• What neuroscience tells us (SCARF – David Rock)

These are reasons why I’m a proponent of Lean Change.  Lean Change is method agnostic although I supposed you can call Lean Change it’s own method.   Lean Change takes the customer development aspect of Lean Startup and applies it to change.

Can Lean Change help “manage change better”?  Maybe, maybe not.  At the end of the day people cannot create a method or process that is more complex than the human brain which is why Lean Change minimizes process, isn’t linear and is completely feedback-driven while allowing you to pluck ideas from different methods.  Check out these resources about Lean Change:

Lean Change – The Book

Lean Change Lightening Talk by Jeff Anderson at the Toronto Agile Tour

Lean Change at Agile 2013

Back to the question, can change be managed?  In the traditional change management sense?  No.  Change agents must involve the people being asked to change in the change execution.  People don’t like to be fixed, and forcing change on people generates a threat response which manifests itself as resistance.

Remember, Darwin said the species that survive aren’t the smartest or strongest, they’re the ones that learn how to adapt.

Without hesitation I replied, “change the world” to which he responded by looking at me like I had 12 heads.

Over the years I’ve developed a stance of helping people make sense of change and if I can help someone become aware of more effective ways to manage work and people, I’ve done my job well.   My measure of success is when I get thanked or when I help someone either change their crappy organization or change their crappy organization.

The first event that helped me shape my stance was AYE.  I vividly remember so many events from AYE 2008, one of which was Jerry Weinberg’s session on how to say no.    He started with getting everyone to say no aloud.  We all did and then he replied, “was that so hard?”.

In that session he asked someone to tell a story when they said yes to something they wanted to say no to including what happened.  What was amazing about that session was Jerry’s stance, or at least my perception and observations about his stance, of holding the space.  He did very little talking and created a space for learning to occur by asking powerful questions.

Another event was my one-on-one with Esther Derby when I was trying to figure out how I could make the organization I was with “more Agile”.   I remember her saying “remember, it isn’t about you.”

I could write a book about the other experiences I had there as well as the next 3 AYE’s I would end up attending.

Over the years I learned that Agile isn’t so much about Agile at all.  It’s about change and I’ve spent most of the last couple of years developing my stance for helping organizations better manage work and people with Agile practices.  For me, it’s about dealing with the stress and anxiety caused by change whether it be evoked internally or externally.   I’ve made the mistake of putting the emphasis on Agile processes, practices, values and principles over the emphasis on simply helping people solve problems with the tools available in the Agile toolkit.  I’ve had more success taking the latter stance and I realize sometimes a different stance is necessary.

I recently presented at The Art and Science of Change and that opened my mind to the stance that people in the change management world seem to take when approaching transformational change.   There were many discussions around 12-step plans to transformational change, how to schedule and budget for transformational change, how to deal with resistance and how to measure ROI.  Perhaps that’s why 70% of change initiatives fail according to various change management studies over the last couple of decades.

To me, that is a dangerous stance to take because it implies people are linear and there is a direct connection with cause and effect when organizations are going through transformational change.  I was pleasantly surprised to hear Daryl Conner talk about the dangers of progressing down the science aspect of change and using tools and methods alone for transformational change.  His stance was that we, as change agents, need to balance the art and the science.  We, as change agents, need to become chefs, not recipe-following cooks.

Change agents must have a passion for the people side of change and must be passionate about change that matters otherwise we should get off the path and pick a different career.  Daryl defines “change that matters” as change that positively affects the lives of people which I whole-heartedly agree with.

My stance for approaching change is helping people in organizations understand change and how to make sense of it.    Some of my stance can be attributed to who I am as a person.  I’m a helper.  I like helping people see that things don’t need to be the way they are.   Sometimes I feel that’s the best approach, other times I don’t, but overall, my stance is to listen to people, understand the problems they face and how I can help them get past those problems.

Sometimes that means teaching people about different processes like Scrum or Kanban, sometimes that means teaching people how to have more effective meetings.    Under the covers it’s always about listening to the other person.  People don’t like to be fixed and people don’t like change being thrown on them, I’ve yet to see that tactic work in any transformational change I’ve been part of. It might feel good for a while but eventually old habits will return once the shininess of process X wears off.

Your stance is important and there are many models and methods you can pick from including brain-based coaching through to communication coaching and agile coaching.  To me, the most important part of coaching is understanding that, as a change agent, my job is to listen to the organization and its people and take the stance that I feel is the most appropriate.

I’ll leave you with one last story.  Recently I was facilitating a retrospective with a team that was struggling with estimating.  When the time came to decide what to do, I asked them a question: “would you like to brainstorm your own options or would you like me to tell you what I think you should do based on my experience?”  They chose the latter.  The point is, I asked them for permission because I sensed that their experience with agile estimating techniques was low.  I gave them the choice thus reducing the threat response which dramatically increased the energy during the ensuing conversation.

To me, that’s a win and that’s how I approach changing the world, one person (or team!) at a time.

The argument I usually hear in this case is either the project is committed to the customer and it can’t be stopped, or staff will be de-motivated if months of their hard work is all for not.   What is usually is the case is that the staff want it stopped and could care less about the wasted effort and they think management is clueless because they don’t understand that.  From a management or executive perspective, they may feel the project team is under-performing or not being transparent about their problems.

Call it silo’d mentality, lack of trust or lack of communication but what I’ve described is a reality many organizations face.

Using this example, let’s assume this organization is going to transform to Agile because Agile can fix these problems.   Let’s put aside the fact that Agile won’t actually fix this problem, it’ll simply make it visible so the organization is forced to deal with it.

Starting with retrospectives across the hierarchy of the organization can be a powerful, and safe, way to explore the good, bad and ugly from multiple perspectives.   In smaller organizations you can probably deal with this problem with a company-wide retrospective, in larger organizations that will be difficult to co-ordinate.   In the past I’ve used this method for collecting data from staff, managers and executives and then explored the similarities and differences through Perspective Mapping.

Conceptually it’s simple but can be difficult to co-ordinate in a reasonable amount of time in larger organizations.

Start by running a “happy, sad, mad” retrospective with multiple project teams and/or functional groups.  Given a theme and time horizon, have people in the retrospective write down things that made them happy, sad and mad.  Group similar items together and look for themes.  Finish off the retrospective as you normally would and keep the data and themes that emerged to use in your Perspective Map.

Run that same exercise with management and executives.

Now you’re ready for a Perspective Map.  There are a couple of ways to visualize this and the objective is to look for areas where perspectives across multiple levels of the organization converge and diverge.  Here’s an example:

The columns on the map are the themes that emerged in each retrospective.  It’s likely each level (staff, management, executives) will have different themes but there will be some common themes such as process, communication and transparency.

The rows visualize things that made the staff, management and executives happy, sad or mad.   By grouping the feedback in these rows and columns, you’ll notice that things that are making one group happy are making the other groups sad or mad.   Looking at the third column, you can easily see divergent perspectives on transparency.  In this case it could be that executives (purple stickies) think they are being completely transparent while the managers and staff (blue and maroon stickies) think they aren’t being as transparent as they could be or worse, they are being transparent but feel the executives are squashing the negative problems.

Here’s a different visualization of a Perspective Map:

This example flips the visualization around showing positives (things that made us happy) on the left and negatives (things that made us sad or mad) on the right.  The perspectives are split vertically making it easy to spot themes and problems from different levels of the organization.

If you’re getting started with Lean Change and you’re collecting Insights, this is a powerful visualization to start with.  It’s likely the coach or team you’ve hired is going to do some type of assessment by interviewing people, running retrospectives or other group exercises and starting with a Perspective Map is a great way to visualize the dynamics in an organization.

It’s also a good idea to have the coaches map their insights onto this Perspective Map because as outside observers, they will see dynamics people in the organization don’t see.

From running similar exercises in large organizations, the most common feedback I get is that staff are sometimes happier to be more open and honest with the coaching team than their managers.    I’ve had managers say things like “I had no idea our staff felt like that!! Why didn’t they tell us??” when they see this data.  There’s a reason why staff are unable or unwilling to give honest feedback and from my experience it’s usually fear.   Fear that they will be punished or worse, apathy that they feel management doesn’t listen. Using a Perspective Map can be a safe way to start to break down communication barriers between different levels of hierarchy or departments.

Once you’ve generated your Insights, it’s time to move on to creating Options and then MVC’s to implement changes that will help solve this problem.

The 7:45am train is an express from where I get on and it gets to downtown about 10 minutes earlier.

Today the 7:45 was late so many zombies that where waiting for it hopped on the 7:50, the doors closed and we were ready to depart. Suddenly the 7:45 train showed up and what happened was interesting.

The doors on our train opened again and panic ensued as people shoved their way to get to the express.

Did I mention the express gets to downtown 10 minutes earlier? 10 minutes.

People were literally running and jumping off the 7.50 to grab the express. When the late 7.45 express’ doors closed, guy who was just about to jump off the 7.50 said “this is fucked up, I’m pissed!” And grudgingly went back to his seat.

The first question in my mind was, why do people behave this way? What was it about this minute disruption that made them act seemingly panicked?

That’s just it, it’s a disruption to routine. Some could have had a meeting they needed to get to. Some could be habitual travellers who stand on the same spot everyday and sit in the same seat everyday. Some could simply hate having to make that one stop.

People all react to change in different ways whether it be moving departments or something that is massively disruptive like bringing in Agile.

What’s the first thing on the mind of many people who experienced this hiccup this morning? GO Transit sucks. Check the #gotransit hashtag on twitter and you’ll see how people react to trains being minutes late. Apparently this wasn’t the only late incident this morning either.

“Man what’s the point of the 6:40 pm bus if the 6:50 bus manages to reach maple first? #GOTransit”

The fact I’m paying for a 30 min late bus is unacceptable @gotransit #gotransit

Disruption to routine and cultural Norma put our brains in ‘protective’ mode. When user stress your emotional reaction causes a secretion of Cortisol (AKA the stress hormone) and you generate a ‘flight or flee’ response.

Then when stress subsides and the ‘leaning’ part of the brain takes over we point our guns at whoever or whatever caused the disruption. In today’s case, it’s GO Transit that sucks. When disrupting organizations with change triggered with Agile, it’s the change agents fault.

No amount of rationalization will change that. Once we’ve attached meaning and belief to an event we’ve climbed up to the top of the ladder of perception and its extremely difficult to come back down.

First we start with a fact: the train was late

Second we start filtering facts: man, the train is late a lot (even though this could be the first time you experienced it)

Then we start attaching meaning and belief to that fact: this stupid train is always late.

Once we live in assumptions and jump to conclusions we’re left with GO Transit sucks!

This is a simplified version of Carl Jung’s ladder of perception but I think you get the point.

This is why I am a firm believer ( top of the ladder! ) that you cannot put a deadline on change because people are involved. People must practise new skills in order to integrate the change into their new self and, push as you might, I will not work.

If your organization thinks Agile is he solution to your problems, expect a dramatic drop in productivity and and dramatic rise in stress as a result of all those nasty organizational secrets that will start coming to the surface.

Forget Agile, Lean, Kanban or whatever method you’re picking. At the end of the day you’re dealing with a massive disruption. Focus on understanding how people are going to react to the change, involve staff in the change decisions and most of all, be congruent.

By the time I wrote this, we had a second delay because trains were a bit backed up, nobody freaked out this time though. I guess they accepted the fact we’re going to arrive late.

The ‘dumb-terminal’ operators had extremely low proficiency in web-browsers since most of them had never used browsers before.  Over the next year they hired people who were rated as having much higher proficiency in using browser-based systems.

Later in the year they measured the proficiency of the new hires and the results were surprising to me.  They actually rated themselves lower in browser proficiency and much closer to the proficiency levels of the people who had been working solely on dumb-terminals.

He explained some of the behaviour behind this to which I’m sure most people can relate.

Operator: “oh, we can’t change that date here.  It just gets messed up so we have to back out of two screens and change it somewhere else.  And, oh, we can’t type in the date, sometimes it just doesn’t save right”

The dreaded workarounds.  I’ve seen this in many places where the culture of the users of the system gets paralyzed by crappy software.  New hires will have energy to try and make changes but in a culture that doesn’t value craftsmanship and competence, they’ll simple become part of the collective because it uses less energy to learn the workarounds and deal with them than try to change anything.

In this particular organization, he mentioned the staff had been there for decades and that culture is extremely difficult to change.

Have you ever heard how hockey players that play with elite player like Crosby and Gretzky say things like “these guys make everyone around them better”?  There’s something about working side-by-side with incredibly talented people that is motivating.  For me anyway.

The next time someone in your organization tells you “oh, that’s just the way things are around here” question that assumption.   Maybe you’ll become apathetic and dis-engaged like over half of all workers in the world over time but maybe, just maybe, you’ll inspire others to challenge the status quo and create un-believably wicked awesomeness.

We’ll show you examples of Insights and Options we’ve used and we’ll dig a little bit into the softer side of change.  While many (all?) change management models are primarily plan-driven, we’ll explain how Lean Change is feedback driven and how people are affected by change.

Get Lean Change on Leanpub

Originally we were tracking projects only and then expanded into tracking MMFs (minimal marketable features) with the goal of figure out our capacity and throughput.

We wanted to get to a state where teams would be able to establish a monthly throughput and them long-term plan accordingly.  What was actually happening was that teams were shoving features into the schedule based on due dates.  So if their throughput was actually 4 features per month but they needed 38 to meet the schedule, they’d cram 38 in “1 month away”.

Over the year it’s been re-built 4 times and tweaked often.  At one point we purposely let it die because no one was getting any value out of it or using it.  One day one of the managers thought it would be great if we could visualize all the releases that were coming up and voila! EKB was re-born and back like a bad rash!

Ok, that’s enough context…once we moved to a new model for delivering work which is now focused on lines of business (not really a product focus, but close to it), we needed a different way to visualize the work.

Duh, Ask the Customer!

What a crazy idea…we started by asking people in the organization what they need and want to see.  We asked the PMO, directors, stakedholders and the leads on a huge program we’re starting on.

They all wanted a higher-level roll-up of information for these purposes:

• raise issues, risks and dependancies sooner
• remove the need for weekly status reports
• a snapshot of various portfolios
• overall health with a bunch of parameters

The first thing we did was mockup a new version:

We posted the mockup, including a video walk-through on our Yammer site and sent it to all the people who would need to review it.  Given our early feedback, we knew we were on the right path.

In parallel to that, we identified our core customers:

• IT Stakeholders and Chiefs
• Business Stakeholders and Chiefs
• PMO
• IT Directors and Managers
• IT Staff - Application Services
• IT Staff – PMs
• IT Staff – Other

We sent these cohorts a short survey and asked them to answer this question:

• When I look at the EKB, I want to see…

We looked at the results and validated our assumptions, given our initial feedback, and the end result was finished:

Instead of measuring flow, the columns on our board are:

1. New Requests: brand new stuff no one has looked at yet.
2. Intake:
   1. In Progress: IT Planning group is doing its thing
   2. Submitted for Funding
   3. Funded, Not Committed
3. Service Queue: work has been accepted by service owner
4. Health/Risks: this shows the health of the service group around scope, schedule, budget, “quality” and other factors.
5. In Delivery: 0% to 100% as measured by features delivered in business acceptance testing.  This is like a visual horse race so you can quickly see progress
6. Transition: handed off to business
7. Done

After talking to consumers of the data and the survey, we found out most people wanted higher-level information for this board and we realized we could satisfy the vast majority of consumers with a portfolio level board.  We still use project Kanban boards for all the gory details but this view now answers more important questions:

• what projects don’t have money?
• what projects have money but aren’t committed?
• what projects have been committed?
• what’s the overall status on delivery?
• how healthy is the service group?
• what risks and issues need to be talked about?

This new portfolio level board is going to remove the need for weekly status reports and we’re encouraging people from the business to come down and look at it weekly instead of relying on other status reports.    We see this new version as a conversation provoker because the data is more relavent to the audience.

Management is an often overlooked aspect of Agile.   More and more organizations are adopting Agile practices and struggling with how to create an environment that fosters innovation and collaboration.  Management 3.0 brings knowledge from complexity thinking, Agile and more to help leaders in organizations energize people and empower teams.  Join me for Management 3.0 in Toronto on June 3 where I’ll co-facilitate Management 3.0 with its creator Jurgen Appelo!

It was cool and emotional for me to be back in Dearborn where I spent many summers at my Gramma’s house in a nearby neighbourhood. I remembered riding the elevators at the hotel when she was working at the mall across the parking lot. One of those summers I saw Return of Jedi 9 or 10 times so that was pretty awesome!

The only session I was able to attend was Jean Tabaka’s talk about complexity and design thinking since I had 2 sessions to deliver myself.

What I enjoyed the most about her session was that someone with her standing in the Agile community was talking about more advanced topics. That tells me that the community is maturing and looking outside the 4 values and 12 principles for how best to help organizations.

Given how quickly information flows today and the nature of today’s knowledge work, organizations that continue with a mechanistic approach to managing their organization will not survive and organizations that embrace complexity will.

The S&P’s average life span of companies has shrunk from 70 years to 14 years over the last 70 years. Look at Nortel, Rim (now Blackberry), Motorola and more former powerhouses. Organizations that insist on using scientific management to build bureaucratic, hierarchical monstrosities will die.

Jean’s delivery was energetic and engaging and I hope more topics like this make it into mainstream conferences, I think the time is right for another shift.

Jim Benson’s keynote was fantastic! I enjoyed the rants, especially the “rules kill awesome” statement. Nothing destroys creativity and intrinsic motivation more than over-emphasis on rules. Rules are important to create constraints, but not to the extreme of thinking you can create enough rules for standardization. No two teams, projects or organizations are alike, creating guidelines and encouraging experimentation will help organizations thrive in this age of complexity.

I did manage to see the tail end of Matt Barcomb’s learning organization session after I finished mine. Matt is awesome to watch, great flow and quite engaging.

I had some great hallway and dinner conversations with people who came to my sessions, particularly around Lean Startup and Lean Change. There was a great deal of energy in both of my sessions with Gerry Kirk and Andrew Annett.

We received overwhelmingly positive feedback from attendees which was nice after totally bombing at Agile 2012 last year!

Feedback from Managing Response to Change:

Feedback from Lean Change:

Overall, it was extremely well organized and the session selection was quite diverse.

Likes:
- very well organized
- wide variety of topics
- fantastic venue
- good mix of 90 and 45 min sessions
- open space area

To make it perfect:
- having session review cards so speakers can get feedback
- I liked how LESS 2012 had awards for best talks per track (I won best Lean Startup session!). That would be pretty cool, or have attendees vote on best talks
- maybe extend to half of Sunday? I think next year will be bigger!

Thanks again to all the organizers, speakers, sponsors and attendees as well as my road trip buddies Andrew Annett, Sue Johnston, Chris Gow and finally Ardita Karaj who has been accepted into Lean Dog society!

More about Agile and Beyond:

official website

Eventifier Archive

Summary from Ardita Karaj