Nov 062013

Local staffing firm and winner of the Most Non-Ironically Orwellian-Sounding Twitter Handle Award tweeted this the other day:

All successful change initiatives start here


That’s a pretty bold statement for a company that’s never done a change initiative.  All successful change initiatives start at the top.

This idea is actually not unheard of.  You hear it other places, mostly as the result of disillusionment.  You can’t be an agile consultant very long without having the surreal experience of a company hiring you to help them change, then deciding they don’t really want to change all that much.  As agility begins to cascade upward and outward threatening all extant presuppositions and practices, they stand, Gandalf-like, bellowing that YOU SHALL NOT PASS and breaking the bridge before all that hubbub you’re creating in their developer teams gets to accounting or whatever.  There was one organization in particular where I felt they were paying me a very good amount of money for the privilege of ignoring me altogether.  Like I said, it’s a very surreal feeling, especially when people can and do ignore me for free.

However, the truth is that change that begins at the worker level can and does work.  In fact, my most successful “agile transformation” started with a development team, and once people saw the points being put on the scoreboard, the changes cascaded throughout the organization, changing their culture, levels of trust, rate of delivery – all kinds of good stuff.  I’ve also seen change initiatives start at the top and fail miserably because, even though management was behind it, none of the workers were.  It was something forced down on them, and they could get with the program or get out.  People were resentful at worst and apathetic at best, confident in the knowledge that this was management’s new fad, and next year it would be something different.  Change initiatives that start at the top without the full buy-in and participation of the ground up have a high risk for failure, and I speak from experience.

So, is it the case that all successful change initiatives start from the ground up?  That’s also incorrect.  Nobody can destroy a company’s agility like their leadership, and I’m going to go along with Deming here and say that the vast, vast majority of a company’s performance problems rest with leadership (ironically, vast amounts of time and money are spent on structures trying to pinpoint failures in the work force – “We need to hold our people accountable” is usually followed by an unspoken “because the problem sure isn’t me”).  Your pilot project can outperform everything in company history, and management can still shut you down.  It would be nice if good results were the final word in these kinds of decisions, but anyone who thinks data is the final word in an argument has never been in a long-term relationship.  So, change initiatives that begin at the roots level without the full buy-in and participation of management also carry a high risk of failure.

If change initiatives that start at the top are prone to failure, and change initiatives that start at the bottom are prone to failure, then what are you supposed to do?  Start in the middle?

The first part of the solution is, as Deming says, “The transformation is everyone’s job.”  You have to be willing to address the organization as a whole.  Agility has ramifications for everyone, and can actually be harmful if you only optimize a particular segment.  Can you imagine what would happen if you could make the front driver-side tire on your car go 50mph faster than the other wheels?  A similar thing happens to organizations where agility is only increasing in one place.  If you want to transform an organization, everybody has to know that what you are doing is going to affect everyone from the CEO to the night janitor.  Naturally, this can cause concern, and this leads me to my second part of the solution.

The second part of the solution is that organizations are resistant to change because of the way we try to make them change.  When we blame an organization’s agile adoption difficulties on their industry, culture, or people, we haven’t gotten to the root cause.  The root cause is that your way of changing the organization is setting it off the way a cold virus sets off your body.  “What the hell is this thing?” says your body, and the fever goes up to try to boil it out of you, the snot spigots unload to try to flush it out of you, and sometimes other unpleasant things that tend to happen at inopportune moments.  This is what organizations do to alien matter introduced into their system.  And believe me, brothers and sisters, I am preaching to myself as much as anyone on this point, as I can cite instances in my career when I was happy to blame the transformational difficulties on the company instead of the way I was going about things.

Yosemite Sam

Yosemite Sam (Photo credit: Wikipedia)

Change initiatives have to be done with a respect for people and in a manner that drives out all fear of losing their job (Deming, again).  This is the genius of Kanban: the changes are incremental, evolutionary, and the ideas and decisions come from the people doing the work instead of something imposed on them from the outside.  You can’t just go in like Yosemite Sam hootin’ and hollerin’ with pistols blazing.  When people start responding with resentment or fear, that’s your cue that you have done something wrong; it is not a cue that something is wrong with them.  What kind of misanthrope would you have to be to start thinking about getting rid of people who are actually doing you a huge favor by reacting negatively to what you’re doing?

When you start with where workers are at, and you give them the tools to visualize their work, and you help them define what they’re doing, and you help them measure how efficiently that work is being done, and you ask them, “So, what do you think we should do?” you are on the road to people being valued, giving you buy-in, and coming up with better solutions than you could.  Do you sometimes need to bring in ideas from the outside to get people started?  Sure, sometimes – but even then, it’s something you want them to own, not something they have to comply with.

Change initiatives from the top can work; change initiatives from the bottom can work, but both are risky.  Successful change initiatives start with everyone, and they are done by listening and building up your people instead of forcing it on them or getting rid of them.

Enhanced by Zemanta
Oct 032013

Think (Photo credits:

Back in August, Bob Maksimchuk wrote a brief article on what he calls “agile scorpions.”  The basic idea is that companies have these people who have no intention of changing, and it is intrinsically in their nature to… well, murder you, according to the story, but I think he was trying to get across the idea that there are people who are by nature a certain way (i.e. not agile and resistant to change), and these people will end up torpedoing your attempts to create organizational change.  His recommendation is to try and discover these scorpions as early as possible and get them off your team.

Some of us discussed this article over on LinkedIn.  LinkedIn discussions are valuable, because you usually end up with 90% of the masses on one side of an issue and 10% on the other side.  The 90% are usually the well-intentioned-but-inexperienced, the parrots, the inflated frauds, and a very small margin of thoughtful, experienced people who just happen to have that view.  The 10% tend to be the people who have been around the block a few times and have a very deep understanding of how agile efforts do and don’t work in organizations.  Needless to say, the 90% was firmly on the side of getting rid of the scorpions, which makes sense, considering 90% of Salem was on the side of the witch trials.

I mean, how is that not appealing?  The reason your team is struggling isn’t because of trying to apply a prepackaged solution that doesn’t fit, lack of systems thinking, militant adherence to a methodology, or overpaid consultants who don’t know their ass from a hole in the ground; it’s because somewhere, someone on your team doesn’t have agile DNA, and they must be rooted out before they doom you all.

As attractive and simple as the theory might sound, that if you just get rid of the heretic everything will magically fall into place, I am here to tell you this is complete hogwash.

People are complex.

The personality test industry is a multi-billion dollar business right now.  Organizations like buying pre-packaged solutions.  They like the idea that they can pay someone, run everything through some tests, and come out the other side of the machine with a complete analysis.  It’s one of the reasons you can be a bad Scrum / SAFe consultant and still do so well in the market.  Here’s your company.  Here’s my solution.  Just execute it.  ???  Profit.

The idea that these tests are rigorously accurate has been scientifically debunked many times over, but that hasn’t stopped the money train.  Are these tests completely bogus?  Of course not, but at best they reveal generalities.  You can use them for general ideas about communicating together and whatnot, but the simple fact is that personality is complex.  It can’t be quantified the way people wish it could be.  Saying, “We need to hire an INFP, but this guy didn’t score as an INFP” is similar to saying, “We need to hire a Republican, but this guy drives a hybrid.”

You can’t put people in a box, formally or informally.  Sociological data, especially data that comes from the subjects themselves, is just not accurate or reliable enough to make concrete decisions on.  Why does someone seem like a “scorpion” to you?  How could you possibly determine that?  Is it because they argue with you?  Is it because they think your ideas are stupid?  Is it because they like the way things are now?  Is it because they got an 80% on your Scorpion Detection Test?  None of those things tell you that a team member is actually a saboteur.

Getting rid of someone is a last resort.

If someones first response to a “scorpion” is to get rid of them, they probably need to learn a few things about management, people, organizational health, and courage.

About ten years ago, I was leading up an agile team at a worldwide bank, and there was a guy on my team who just fought me on every little thing.  I swear, if I said that the sky were blue in a meeting, he’d spend half an hour explaining how it was actually maroon.  Every new thing I tried to introduce, every point of view expressed, this guy was right there to explain why the old way was better and this new way was more complicated and pointless.  He showed all the Grade A signs of being a “scorpion,” and he wasn’t secret or subtle about it at all.

According to the 90%, I should have started looking for a way to get this guy off my team.

About eight months of this went by, and after some conversations with the bank, we determined we needed to make a shift in the application architecture to accomplish some new needs they were having.  I dreaded bringing this news to the team, because I knew I’d have a fight on my hands.  I especially dreaded having this guy in the meeting.  I decided to call him in advance – not out of some deep insight into his personality I’m sorry to say, but because I just wanted to get it over with.

So, I called this guy the day before, and I said, “Listen, I’m calling you because I got out of some meetings where the bank is going to need some things our architecture won’t support.  We’re going to need to change how we access our third party data, and I just know this is going to be a big disruption to the team.  I was wondering if you could help me figure out a way to explain it so that everyone will understand and see why it’s needed and not just get upset about it up front.”

It was like I flipped a switch.  This guy was suddenly full of ideas.  He wanted me to explain the change to him, and he told me that we could do this, and maybe roll this out incrementally, and maybe I could work through the infrastructure bits, and this and that.

I asked him if he thought this new way would be more complicated than the simple architecture we were currently using.  Oh, no, not at all.  It would be easy.  We’d just have to make sure this, that, and the other thing.

I asked him if he’d be willing to introduce this idea to the team and walk them through it.  Of course he would; he’d set something up for Thursday.  Three months later, and this guy would still pipe up in retrospectives about this change, talking about how much easier it made everything.

This guy didn’t hate change.  He didn’t hate me.  He hated not being a participant.  He hated not having a voice.  Rightly or wrongly, he felt he was not part of the effort, and he resisted this in the way he knew how.  What if I’d gotten rid of that guy?  I would have lost an ardent supporter and dedicated employee because I wasn’t willing to try and find what made this guy tick.

Sometimes, the heretic is right.

The quickest way a species goes extinct is to have something valuable humans want.  The second quickest way a species goes extinct is to weed out all variation.  Mutation is survivability.  In a world where species compete for resources and live in harsh environments, differences are inherently beneficial to survival.

The same goes for an organization.  The second quickest way to wipe yourself off the economic map is to eliminate everyone in your company who thinks differently than you want them to.  Why?  Because sometimes the heretics are right, and you have no heretics, you’ll never see it coming.

Sometimes, people resist your agile initiative because your initiative is stupid.  Sometimes, people resist it because you are trying to impose things that don’t organically fit.  Sometimes, people resist it because you are jettisoning or overlooking important, valued things that you may not value as much.  In my experience, people actually very rarely resist change simply because they are intrinsically change resistors, and frankly, I don’t even know how you’d go about proving something like that.

Even insane people have reasons for the things that they do.  When someone presents themselves as an obstacle, you have a fork in the road.  You can get rid of them (90%), or you can learn from their viewpoint (10%).  They probably have some very legitimate concerns.  Maybe for that specific organization, you have to approach things differently.  Maybe the nature of the business means you have to sacrifice some agility temporarily for longer term gains.  Maybe you just made the guy who’s been that team’s manager for 15 years look like an idiot in front of them.  Maybe someone else just has a better idea than you, even if it’s not in the textbook.

Your resistors and complainers are very often mirrors we don’t want to look into. They’re the people who take our pie in the sky ideas and say things like, “You know, pie can’t actually hang in the sky unsupported.”  You know what?  Kid’s got a point.  Listening to your heretics and using them to help give you new insights and modify and improve your course is healthy and wise.  Sure, they may be expressing their resistance inappropriately (a common thing when people feel they have no appropriate avenues open to them), but that’s hardly the main point.  When someone points out the hole in your armor, you can repair the hole and say thanks, or you can fire them for not being a team player and enjoy feeling like Donald Trump all the way up to the point some Norman shoves a lance up your nose.

Managing people, helping them improve, channeling their strengths and weaknesses, learning and growing as an organization of people – these things are hard work.  It’s in the trenches work.  You can’t print out the spreadsheet that tells you who to keep and who to let go.  You can’t manage by the numbers, here.  You can’t let the Bobs talk to all your employees and tell you who to keep.

I’m not saying no one should ever be fired, because that’s not true.  But I am saying that people are not born with or without the agile gene.  If you are willing to get to know your people and think about the organizational system with them in it instead of just getting rid of everyone who doesn’t fit your idea of the “right person,” you might find that the “wrong people” will surprise you, and not in a stingy-tail way.

Enhanced by Zemanta
Mar 082013
2012 Behaviour Matrix copy

2012 Behaviour Matrix copy (Photo credit: Robin Hutton)

An organization’s culture rightly gets a lot of attention when talking about how to improve the organization. It’s the culture that makes certain changes easier or more difficult to accept. Even the amenability to any change at all is heavily influenced by the culture. When you look at various surveys on why agile projects and initiatives fail, “culture” usually tops the list. Culture is the primordial soup of a host of workplace ills and the mother of all dysfunctions.

In light of this, it may be tempting to put process improvement on the back burner to “work on” culture, but here’s the problem: You can’t change culture. At least, you can’t change it directly.

Think about it like this.

You’ve decided to make a personal culture change. You want to be a happier, more optimistic person instead of the roiling squall of negativity that you have become. Ok, great. How are you going to do that?

You can’t just become a happier, more positive person just by wanting to or just by visualizing yourself as being more positive. You have to identify the behaviors you want to change and start changing your personal culture that way. You might budget time to read inspiring biographies. You might snap a rubber band on your wrist every time you cut down a co-worker’s ideas. You might stop watching Fox News. You might start watching the YouTube video of that Japanese 4 year old playing the xylophone. You’re going to identify behaviors that contribute to being negative and unhappy and replace those with behaviors that enhance your happiness and positivity.

If you want to start eating healthier, you don’t just magically start eating healthier by identifying the problem and wanting to do better. You’re going to dismantle the pneumatic tube that connects your desk with Krispy Kreme. You’re going to order salads at burger joints. You’re going to pick the changes you want to make in your processes to create the culture you desire.

Organizations are no different. It’s insanity to say, “Let’s not work on your processes until we improve your culture,” because working on processes is the only way to improve culture. How else are you going to do it? Long speeches on how much your culture sucks? Exhortations to be different? “You guys really have a problem with trust. So, start trusting each other. Everybody done, yet?”

If your organization suffers from a lack of trust, then create processes that demand trust (collaboration, lack of unnecessary rules) rather than processes that shield you from the need to trust (heavily governed silos). You don’t say that collaboration won’t work here because we have a trust problem; you fix trust problems by making collaboration easy, valuable, and essential. How else would you possibly fix that? Make everyone fall backwards and have the person behind them catch them every day for a month?

Although it’s kind of a fad right now to disdain process improvement in favor of culture improvement, it is a deeply misguided one. You can’t work on one apart from the other. The relationship is too reciprocal, too tightly-coupled, too systemic to be able to deal with organizations that way.

When you spend time engineering your processes, then you’re engineering your culture as well. Culture isn’t an abstraction or an ideal; it’s what you actually do.

Enhanced by Zemanta