Tag Archives: leanchange

Processing Change

Ok, this will be a weird one. Much like zombies, the commuters I see everyday on the train (of which, i am one) stand in the same place to wait for the train to arrive and generally rush to the same seat when the train doors open.

We know exactly where the train stops, even though its not marked, and people arrange themselves accordingly on the platform.

So today the train stops about 10 feet short. Nobody moves. After 3 or 4 seconds, people start moving to the ‘new’ location. Then the train moves another 3 or 4 feet but still short of the usual stop.

The random comments start flying, “what’s going on?”, “oh, must be a new guy today” and “they do that on purpose you know.”

Then I notice the zombies wake up, some people are smiling, some are smiling nervously like the world is coming to an end and some look confused. I know I feel energized.

While this may sound like a silly observation, to me is shows how small changes cause strong reactions. It’s not a big deal to walk 3 feet to the train door but in 6 months of riding the train, at the first time I remember that happening.

I could visualize these folks flowing through the Satir change curve while they processes the initial chaos, feel confused about if the train will move to the right spot or not and finally the new status quo where folks accept the train stopped somewhere differently.

Now imagine how a massive change, like an Agile adoption or transformation or Big Bang process change, is going to affect people.

How to Build Sustainable Change

Every minute over 500 websites are created, 100,000 tweets are sent and over 600,000 ‘things’ are shared on facebook according to this infograph from Mashable.  It’s 9:50pm and if I wanted a chocolate bar, armour all wipes for my car, an oil change, some new Star Wars toys and a bag of apples, I can leave and go get it.  I can buy a trip to Paris right now.  I can order any book I want, look up a fact or article I want to read and pretty much get any product, service or information whenever I want.

Over the last 5 or 6 years the flow of information has increased dramatically given consumers instant gratification to satisfy whatever whim is top of mind.

Change doesn’t work that way.

Change takes time.  How much time?  I don’t know.  A few days?  Weeks?  Months?  Some people in organizations grab onto a change right away and run with it, others struggle (and are sometimes reprimanded for it) and others give up and go somewhere else.   When change takes too long, people get frustrated.  Is it the change agents fault?  After all, they’re responsible for the change.  No, it must be the stupid employees who just don’t get it.  Isn’t that right?  No, it must be management, after all, those Dilbert cartoons are pretty accurate.

I had a bit of an ‘aha!’ moment from PSL and AYE which sort of turned into an ‘oh shit’ moment at the same time.  At PSL we learned about open-ended vs closed-ended simulation design and through the other workshops and simulations I learned quite clearly that you cannot control change.  It doesn’t matter how hard you plan, how much you try or how much you hope, you cannot control change if you expect the change to be sustainable.  The ‘oh shit’ part was because of the pressure to change NOW and knowing that you can influence parts of a change but you cannot force change with process.  It’s not going to work and frankly, it’s just going to piss people off and they’re going to stop listening entirely.

That’s unsettling for leaders, especially management and executives.  They want timetables, ROI, justification of cost, safety and more.  It’s difficult to embrace uncertainty when that uncertainty is costing you a shitload of money in training, coaching and “productivity loss” while people learn new processes.

After a hard day today and that ‘aha’ from PSL, I was feeling a bit down and then my other ‘aha’ moment hit, from Don Gray’s session at AYE last year.  We talked about flowing with the current of power in an organization instead of swimming against it.    Dancing with the system is about finding levers you can use to build sustainable change.

Building sustainable change needs to happen within groups outside of IT which has been part of my focus where I’m currently working.   There is overlap between what our transformation team is doing and work that is being done in HR, Learning and Performance and Change Management.  So far I’ve been able to get their help with (and helped them by):

  • delivering Agile/Lean training
  • rolling out Agile management practices into their organizational wide manager and leadership programs
  • addition of our character sheets with official performance management models
  • visualizing their programs and work
  • sharing books and information

Most importantly I’m clear that there is overlap and I want to leverage what they do to help our transformation efforts.  I openly share what we’re working on and ask for their help when I need it.  It’s actually harder on us if we take managers away for training and coaching when HR is doing similar work.  That’s going to confuse managers and alienate us from the people (HR, CM and L&P) that are designed to support the organization already.    I’m grateful about how accepting they have been, it’s quite a unique experience.  Usually in this situation I’ve been met with the territory battle and I’m pleased this hasn’t happened so far.

As a change agent, my mandate is ‘to make the change stick’.  That can run counter to the mandate of a project because it needs to get released, ‘change’ can’t get in the way of work getting done.  This is another system problem with how department performance is measured.    People also have their individual performance goals that can be at odds with other people or departments.  I’d much rather see a project succeed and let my ‘mandate’ suffer.  After all, that’s why I’m doing this in the first place, what’s the worst thing that could happen?  You are more likely to influence positive, systemic change by getting support from, and influencing, existing HR, L&P and CM departments designed to support the organization in the first place.

So back to the ‘aha’ moments.  You can’t control change but you can read the organization and use the existing structures and currents to help you get where you need to go.  Stop focusing so much on IT and start working on building sustainable transformation from within.  All you need is time.  A lot of time.

Notice the black line? That's flow!

Can You Measure Your Agile Transformation?

A friend recently posed this question to me and some collegues and suffice to say, I don’t think there is any real data out there that talks about how to figure out the ROI of hiring a coach.

I have my own thoughts and it comes down to the reason(s) why you’re hiring a coach or consulting firm to help you through your Agile Adoption or Agile Transformation.   Here’s methods I like to suggest.

Let’s assume you’re bringing in Agile because you want “better, faster, cheaper”.   Typically that’s my experience, management isn’t happy with what’s being produced, customers aren’t happy or the organization is in a whole pile of trouble and at risk of going under.

Let’s start by looking at some of the problems with figuring out the ROI of hiring a coach for your Agile transformation:

  1. Any metric would be a lagging indicator: change takes time and you are not going to see measurable business results within days, weeks or even months depending on the size of your company.
  2. Progress will actually slow: the coach bringing in the change can often be seen as the one who’s creating the problems.  A good coach will explain this in advance.
  3. It’s not only the coach/consultant’s cost: a coach needs time from your people, that takes them away from their day jobs in order to learn new skills.  I guess that’s the reason why progress is slow but the coach/consultant’s cost is one piece.  Chances are you will need some tools at some point that align with a new way of working plus other training.  The most significant cost is your time.

Before I go into some methods I think are useful, here’s a few measurements to avoid:

  1. Team velocity: Velocity is not a measure of productivity and is easily gamed.  To set a metric of “let’s increase velocity by 30%” is ridiculous, don’t do it.  A team will inflate their points sub-consciously,  I’ve seen it happen and I actually tried it once, big mistake.
  2. Any other ‘Throughput” increase:  If you’re producing the wrong thing it doesn’t matter if you produce more of it.  Agile isn’t a code word for “produce crap faster”.
  3. Any metric associated with time tracking:  Isn’t it amazing that when you track time people work exactly 37.5 hours per week?  I once had an executive tell me they tracked time to know when it was necessary to hire more support people.  Seriously?
  4. Number of Defects: Any type of defect or QA metric is not helpful and easily gamed.  “In process” defects don’t matter. What matters is how many times you get a phone call or email for training or support.

Here are some alternatives:

  1. Net Promotor Score: At the end of the day, what matters is whether or not customers will recommend your companies product or services.  It’s a difficult metric to game and it focuses on customer value.  The problem is, like any metric to measure the ROI of a coach, is that it’s a lagging indicator.  You aren’t going to see the affect of this for months.  In a large organization you can still use Net Promotor Score (I use it for personal performance reviews) to see how likely your business stakeholders would recommend IT to deliver software for them.
  2. Cost per Call: If you have a consumer facing product or any product that has a helpdesk, you should be lowering your cost per call and reducing the number of calls to your helpdesk because a coach is going to help you figure out how to make better software.  Ideally it has less defects, better usability (meaning less time spent training customers) and actually solves the problems customers have.
  3. Escaped Defects:  Customer reported incidents matter.  Customer should be reporting less problems.
  4. Increased Sales:  Better software means more sales although the danger with this one is that correlation isn’t necessarily causation.  Increased sales could be the result of a market shift, a marketing campaign or other factors.
  5. Failure Demand vs Value Demand: ideally you’ll be spending less time on re-work (defects and support problems) and more time on valuable features.  The flip side is that it’s easy to start labelling “defects” as “features” to game this metric.

From my experience, measuring ROI for a coach is difficult, but not impossible.  It does imply a level of trust between you (the customer) and the coach because in shorter term engagements you’re not likely to see tangible, bottom-line business results until the coach is gone.  Again, this assumes a few months of engaging with a coach in a medium-ish sized organization.  There’s many more scenarios and engagement options that would make this post go on far too long.

Measuring progress, however, is a different story.

Before engaging with a coach try:

  1. Gallup’s 12 Questions: measure your employee engagement before the coach and after the coach.  Ideally an Agile Transformation improves the quality of work-life for people, challenges them with learning new skills and fosters trust and collaboration.
  2. Happiness Index:  Is there less stress in the air?  Are people happier at work?  Happy people are productive people.
  3. Behaviours and Gamification:  We are using character sheets and gamification ideas to energize people around building their skills, people self-measure based on behaviours we typically see when bringing in Agile/Lean practices.  For example, we’ll see collaboration happening between departments that typically didn’t talk to each other at all before the transformation.  For more, check out this post from Jeff Anderson….an hopefully soon my experiment with an online behaviour tool.  We were pushing this but have since changed tactics.

These are only a few, there are more such as lower in-process defects.  Yes, I suggest not tracking them because they are not valuable to your customer and it’s easily gamed but ideally your testers will report less defects.  Once you understand why in-process defects are a useless metric you’ve realized your metric of progress!  Get it?

The most important point I wanted to make was that your measurements of your transformation should evolve over time.  Initially you’ll want to collect process-related metrics like throughput, cycle time etc and that will help you find what your other problems are and eventually you’ll discover the right business metrics to determine the ROI of hiring a coach or consulting firm.

What are your thoughts about measuring your transformation or ROI for hiring a coach?