Tag Archives: change management

1,000% improvement is a statistical outlier

Posted on by
Reply
Reading time ~ 3 minutes

This cautionary tale came up a few times at Agile 2010 (yes I know this may be old news!) – including one of the keynote speeches.

“For a million dollars we’ll make you Agile.

Here’s a list of previous clients whom we helped achieve a 1,000% performance improvement. Lead times halved, profits doubled and everyone was AWESOME!.

Here’s some REAL DATA …”

A graph going "up and to the right"

Axis titles shamelessly acquired from a recent company presentation

What you’ve not been told is that those testimonies are statistical outliers!

These are the top 1-5% of companies that have successfully undergone a major transformation. (or the bar was set very low to start with) There are thousands of companies out there that don’t reach these lofty heights.

The journey is longer and harder than the marketing will ever tell you but that’s fine as long as you know what you’re investing in and why.

Your organization is unique. There are many factors about your organization that will make significant improvements hard to achieve and most of them will not be technical. The forces of resistance will be many and will be a mix of institutionalized and personal.

Let’s replay this with a more realistic conversation…

A consultant visits your site, and does a “free” one-day Agile Assessment of your teams.

“OK Boss. Right now you suck at developing software. Give us a million dollars, a year of your time and a willingness to drop productivity for a while and we can make you suck a bit less.”

Furthermore, they won’t actually be able to tell you just how much less you can suck and by when.

Why not?

Back to all those forces of resistance – how many of those can you really prod, assess and quantify in a day or even a week?

Every company, organization and site differs.

The investment may still be worthwhile but it’s time to manage expectations better. Those assessments should highlight where unexpected limitations lie. Maybe they could offer alternative higher priority areas to tackle (rather than up-selling scope).

If product development and software engineering was like cutting coke cans, there really would be a “one true right way” of producing software products.

Moreover. There wouldn’t be a thousand consultancies promising you the moon on a stick, there wouldn’t be conferences on improving the state of the art and there wouldn’t be hundreds of books full of great ideas on how to do/be agile or perform software engineering a little bit better.

In fact chances are there wouldn’t be a competitive software industry.

Or would there?

• Maybe there really is a one true way and the entire software, consulting, authoring and conference industry is in on the joke.

• Maybe all those leading lights on their skiing trip a decade ago came up with one of the world’s greatest “Long Cons”

• Oh and they invited 3M to the party and agreed to promote stickies in the 21st century in exchange for a marketing budget.

Probably not…

There are no “best practices”. Stop looking for them, stop asking consultants and Scrum Masters to implement them.

There are only “best known practices for your current state, knowledge and context”.

When your state, knowledge and context change, it’s time to look at what’s next and more importantly – what’s beyond your current focus – what have you missed or not considered yet?

What did you discard previously because there were constraints or issues preventing them working? (I learned a great term for this from Chris Matts &/or Dan North – I can’t remember which – “Idea Wombling” – seeking out great ideas that were previously discarded)

You may reach a point where your organizational immune system (politics and process) blocks progress.

Sometimes you’ll need outside help to see what’s “better” or learn new ways of working. That outside help can often be more effective at delivering hard truths than you can yourself. It’s worth investing in “straight-talk” from strangers sometimes.

Figure out what is holding larger improvements back (and where) and determine who you could pair with either externally or in a different part of the organization to make a real difference!

Rapunzel’s Ivory Tower

Posted on by
Reply
Reading time ~ 3 minutes

“If the problem exists on the shopfloor then it needs to be understood and solved at the shopfloor” – Wikipedia

Some years ago I took on an agile coaching role at a very large corporation. Like many stereotypical large corporations, they were seen as data-driven, process and documentation-heavy. Management culture was perceived as measurement-focused, command & control and low-trust.

They had a very well established set of Lean practices and managers promoted strong values around empowerment. Despite Lean training for all staff, there was still a very limited “Go See” culture.  Above a certain level it was still traditional management-by-numbers and standardization – mostly by apparent necessity through scale.

James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view)

At the start of the transformation the leaders wanted to know “who’s agile and who isn’t”.

Disturbing as the thought might seem, their motivation was sound. We’d all put our careers on the line to “go agile” in order to turn around a struggling group. The last thing needed was a disaster project with “Agile” being labelled as the cause of failure.

(Nearly 2 years further down the line, we managed to have at least one project fail early and be recognised as saving over a million dollars).

We developed an extensive “agility assessment” in order to teach all those involved that “being agile” wasn’t a binary question and wasn’t just about Scrum practices.

The measurement system for the assessment acknowledged that whilst there may be “good” answers, there are no “right” answers or “best practices” – teams could actually beat the system. (If there were “one true way” of developing software, the industry would be very dull).

Beyond measurement, the big challenge I and my team faced was the pressure to “operationalize” agile. To develop common standards, procedures, work instructions, measurements and tools worldwide. The Quality Management System (QMS) culture from our manufacturing background meant that interpretation of ISO accreditation needs was incredibly stringent and was required in order to do business with many customers.

Ironically that requirement kept us almost entirely away from the teams delivering software!

Operationalization was what our managers were asking for and it was very difficult to say “no”. Traditional corporate culture defined this as the way things should be.

So from stepping into a role where we expected the gloves to come off, where we could get out of the management bubble and start making a real difference with teams; within a few months my entire team found themselves unwittingly captive in an ivory tower.

We saw it coming and felt powerless to stop it but as permanent employees fresh into our very high-profile roles, those painful home-truths could not be comfortably raised.

I and my team spent that first period doing what was asked of us and helping teams out for the odd few days at a time wherever we could.

Fortunately all was not lost. At the same time, we invested in a highly experienced external group to engage on each of our sites and drive some of the changes we needed to achieve from within the teams.

Was the value I’d hoped to add in my role lost? – Actually no.

The managers got what they wanted – heavily seeded with a our own more balanced agile/lean understanding and experience.

We weren’t perfect but made a significant series of improvements. The teams actually delivering products had far more experienced consultants supporting them, who as contractors could take the right risks that permanent staff could not have done at the time.

This 2-tier approach actually gave the delivery teams more air-cover to find their own way whilst we worked on coaching the management.

The teams still had a long way to go but were heading in the right direction and getting progressively better. At the same time, the management team learned that Agile isn’t simply a case of running 2 days Scrum Master training, developing a set of procedural documentation and expecting that everything will show 1,000% improvement.

After the initial bedding in period, I and my team were able to build up sufficient trust with our leaders that we could set future direction ourselves.  The kick-start needed on change within the teams had already been made. (far more effectively than we could have achieved alone). 

With our leadership trust established, after being holed up in a tower for too long, our coaching team were able to reach the real world again. This time it was entirely within our own control, with the management support we needed and enough credibility remaining with the teams we had interacted with to move forward.

We were free, able to step in, learn more, tune, help out and spend months at a time properly embedded on teams taking them forward – reaching that point of empowerment for our team was a coaching journey in itself.

If you’re in the fortunate position to be an agile coach or in a similar role in a very large or more traditional organization, make sure you recognize that your coaching efforts will often be as much (if not more) necessary in coaching your leaders first.

Acting on Difficult Advice

Posted on by
Reply
Reading time ~ 2 minutes

There’s a time & place for external consultants in organizational transformations. They can help you in unique ways but you have to pay attention and act.

Some years ago I had a game-changing conversation with an exceptional guy we’d hired in. Everyone loved his straight-talking, he had a way of talking common sense that resonated all the way from individuals on teams to our execs. We knew that one or two conversations would never be enough so I asked him to join us permanently – he was exactly what we were looking for.

His response (paraphrased)

“I’m flattered and I’d love to – but one of the great things about what I do is that I can tell you the painful things you don’t want to hear – knowing I’m right – without having to worry about losing my job and knowing my boss has my back.”

We managed to get him to speak to our local leader at the time about what we were trying to achieve.

“…you do know that the level of change you need here is going to have an impact on productivity for a while right? Are you ready for that?”

“…absolutely not, we have to complete our transformation with no impact on our current delivery commitments to the business”

It wasn’t that his advice was wrong. It was that the boss didn’t feel safe to take the hit. Needless to say the rollout stumbled. Fortunately we knew it was coming and corrected as best we could.

If you invest in a consultant, It’s your responsibility (and risk) to act on their feedback. Be prepared for painful input and… please …do something with their advice – that’s what you paid them for in the first place right?

If there’s a risk or impact, weight it up, bring your stakeholders in, explain the situation and reset expectations. You are empowered to act but here’s the trick you’re missing! It doesn’t all have to be just on your shoulders.

In fact, you don’t have to have the difficult conversation yourself at all, you’ve just paid for someone to do it on your behalf. If they’re really that good, they’ll be more than capable and willing to do so and probably more credibly than you.

That kind of ROI is priceless.

Black Holes & Revelations

Posted on by
Reply
Reading time ~ 3 minutes

Have you ever had to deal with a black hole on your team?

“As predicted by general relativity, the presence of a large mass deforms spacetime in such a way that the paths taken by particles bend towards the mass. At the event horizon of a black hole, this deformation becomes so strong that there are no paths that lead away from the black hole” – Wikipedia

I’m not a physicist so here’s a simplified view that I can fit in my smaller brain:

Black holes are like huge “gravity traps” sucking in all energy from the surrounding area. Energy and mass are drawn toward the event horizon, sucked in and lost forever. The more they take in, the larger or denser they get.

Here’s some cool stuff I learned from Karl Schoemer a few years ago.

A team undergoing change can be coarsely divided into 3 behaviors: Design, Default and Defiant/Detractor.

• The “Design” population are your role models; your supporters & change agents – but be aware, some may have short attention spans or become zealots. This is up to 20% of your population.
• Those following the “Default” behavior will sit on the fence; “What.. …ever”, “it doesn’t apply to me”, “I’ll carry on as I am thank you” are all common “default” responses. Typically this is 70% of your population!
• “Defiant/Detractor” behavior exhibits extreme symptoms including shouting, arguments, tantrums, sabotage, threatening to leave and pulling everyone else down with them. Less extreme responses include focusing on the minutiae, public cynicism and endless debate without action. In many cases, whilst this may seem prevalent, often this is actually as little as 10% of your population!

Now let’s return to the Black Hole. In space, black holes are invisible – only their effects can be seen. In change management, we simply fail to recognize and identify them.

Human black holes must be understood and handled with extreme caution.

For those inexperienced with black holes, your instinct will be to try and defuse them. You must spot when you are feeding a metaphorical black hole, rewarding negative behavior by pouring your finite energy and resources in. Feeding black holes provides them additional credibility in front of their peers – their gravity trap grows ever-larger.

Lean values time… Eliminate waste! – Where are you wasting your energy?
If you removed the energy feeding a black hole would it eventually burn out?
In human change, detractors usually either get with the program or leave.

If you’ve read some of my prior articles you’ll know that whilst I appreciate good people; if your behavior and attitude isn’t up to scratch, all the technical prowess in the world is unlikely to make me want you on my team.

Some black holes may be an almost permanent rift in space. Work to minimize their impact and sphere of influence rather than offering more fuel. Consider using them as your “professional cynic” – your sounding board for the detractor response – but be aware this is a lot like playing dodgeball with a burning coal. It’s usually safer to move them away from the powder magazine instead.

Where could your wasted energy be better spent?
Simple! Use it to shift the center of gravity on your team away from the black hole.
Partner with your “design” members as a team and swing your population of defaulters toward your chosen direction. Some may be pulled toward or into the black hole but work on the overall gravity shift to bring the team around.

If you don’t have sufficient design weight to adjust the center of gravity right now, go digging for more – one person at a time if needed. At some point you will be able to tip the balance.

(Oh – a nod to Muse for inspiring the title of this post)

Building a Case for Change

Posted on by
Reply
Reading time ~ 3 minutes

I recently led a short evening session discussing strategies for collective code ownership. We opened with a set of patterns and practices but the team highlighted something painfully obvious that I’d overlooked…

What’s the business value and driver behind collective code ownership. What’s in it for your product owners and customers?

So often we focus on the people barriers and technical challenges to collective code ownership without recognizing that the barriers may be organizational or financial.

This challenge happens when you attach yourself to “the right thing to do” and seek to progress without recognizing that the population you’re likely to be working with will fall across a spectrum from complete support, through “don’t care” to disagreement and dissent.

If you want to pursue a strategy for collective code ownership, step back and work through the following questions (some of these are hard – consider starting by brainstorming with a small supportive team):

  • If we just got on did it, would we be successful?
    • Yes – Great, you’re working with a team and business that “gets” this or trusts you to do the right thing. You could stop reading here, but you might want to skim this to see what ideas & thoughts are triggered.

    • No – OK, you’re part of the more normal population (for now) read on for some ideas. You might not need to cover all of the following (and if you do, it might slow you down)

Still reading? – Good!

The following apply to pretty much any change or investment program but answering them is surprisingly hard. Your context will probably differ to mine so I’ve not given all the answers today.

  • What are the top 1-3 benefits of pursuing this?
  • What are the top 1-3 costs of pursuing this?
  • Are there people outside the team that I’m going to need to “sell” to?
  • Are there people inside the team that I’ll need to sell to?
  • What are the risks, pitfalls and political or personal agendas?
  • What do we sacrifice – what’s the opportunity cost?
  • Who are my supporters and how can they help me?
  • Who’s on the fence, do they need to be involved and how can they help/hinder?
  • Who will fight against this and how big a problem is that really?
  • Do I ask for permission and support or press ahead and ask for forgiveness later?
  • Who will this impact and in what ways (positive and negative)?  **detail below

**How about those stakeholders?

For the set of stakeholder questions I suggest you’ll achieve better flow and find natural breaks if you cover positive and negative aspects for each role by “switching hats” as you work through rather than batching up all the positives first.

  • What’s in it for you and what’s the down side?
  • What’s in it for your peers and what’s the down side?
  • What’s in it for your boss and what’s the down side?
  • What’s in it for your team and what’s the down side?
  • What’s in it for your business and what’s the down side?
  • What’s in it for your users and what’s the down side?
  • What’s in it for your customers and what’s the down side?
  • What’s in it for a product manager/owner and what’s the down side?
  • What’s in it for a project/program manager and what’s the down side?
  • What’s in it for an individual team member and what’s the down side?

Wow! that’s a lot of questions.

As I said – you might not need to answer all of these and you really don’t want to have to write them all down but it’s worth spending a few minutes or hours considering these if you’re planning to invest your time, effort and credibility in something you believe in.

Beyond everything here, I also recommend a read of Fearless Change to help you on your way.

Communicating in Patterns

Posted on by
Reply
Reading time ~ < 1 minute

I’m a huge fan of “patterns” or what I describe as “pattern thinking”. My main source of inspiration was not “design patterns” but rather Mary-Lynn Manns & Linda Rising’s book “Fearless Change“.

Whilst I’m no expert at developing my own patterns, the concept of planting a seed – a verbal cue or anchor – to encapsulate a powerful concept in a couple of words is incredibly valuable when coaching and leading teams and managers.

2 Great examples of this that aren’t mine are “Technical Debt” and “Code Smells”. Terms that people can latch onto quickly and use in conversation with generally little problem in being understood.

As a line manager a few years ago I required every member of my team to read Steve McConnell’s white paper on managing Technical Debt.  Whilst he wasn’t the inventor, his treatment of the subject was a detailed and resonant enough introduction for it to stick with the teams. The term technical debt is now heavily used (and usually properly understood) all the way up to exec level within the group.

I was recently privileged enough to have Naresh Jain visit my site to coach TDD & refactoring. In a week of training he effectively introduced our entire group to the very sticky term “Code Smells“.

I’ll be writing up and sharing some of my own verbal seeds shortly. I doubt they’re unique  but they’re how I choose to socialize specific thoughts, ideas & behaviors from my own experiences.