We've all been there. We know that there is a better way to do what we are doing. There has to be. The universe isn't cruel enough for this to be the only way. If only you had a few minutes to think about the problem you are sure you could come up with something much better. Problem is, you don't have a few minutes. You are flat out trying to get whatever it is you are doing, done. And because the way you are doing it is inefficient, it's taking ages and you are already at risk of missing your deadline. You just have to keep going and hope you have some time once it's finished to work out a better way for next time. Of course that never happens because the next task is also inefficient and so that time to improve never materialises.

As AA Milne said in Winnie The Pooh -

“Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back of his head, behind Christopher Robin. It is, as far as he knows, the only way of coming downstairs, but sometimes he feels that there really is another way, if only he could stop bumping for a moment and think of it."

Welcome to the improvement paradox.

A few months ago I saw a meme floating around contrasting a good agile team with a group of cowboy coders. Their chosen metaphor was a nautical one. The good agile team was the navy (age of sail style) - disciplined, focused, effective, working together for a common purpose. The bad team was, of course, pirates - rough, undisciplined, attacking stuff at random, scary but ultimately ineffective.

I looked at that, and knowing a little something about pirates (real ones, not the Long John Silver/Jack Sparrow/Captain Hook type Hollywood ones) it didn't quite ring true. In fact, if you look a little deeper, the age of sail navy is actually quite a good metaphor for traditional organisations and pirates actually make a great agile team. Since this is International Talk Like A Pirate Day, heave to for a moment ye scurvy dogs and let me explain.

Last time we looked at some of the challenges around organisational change and the need to flip the system from one attractor to another. But where does that leave us? We know organisational change is hard. We know that we need to change the state of the system. We know that traditional approaches run out of steam and the system settles back to where it was before (often after thrashing wildly). We know we still want to change organisations. But how? How should we be doing organisational change?

Traditional approaches fail for a few reasons - they try to do a massive change all at once but don't add enough energy to push the system into a new state, or they add so much energy that the system breaks completely and descends into chaos, or they go the other way and try to do a low energy change but they can't sustain for long enough and they don't manage to shift the system. So what do we do?

Organisational change is hard. I don't think there are many people who will disagree with that statement. But let's look a little closer at it. What about organisational change is the hard bit? It's not getting change started. Generally organisations know they need to change constantly and are quite accepting of the fact that change happens. They have change teams and change champions and change consultants to help their many change programs succeed. But often, at the end of the day, despite all the effort that goes into these change programs, nothing actually changes. Once the dust settles, the organisation is left essentially the way it was.

It doesn't matter what kind of change it is, agile adoption, cultural change, new processes. They all tend to end up with the organisation reverting over time to its old behaviour. Why? Is it just the universe trying to be awful to people who do change for a living? No. The reason change doesn't stick comes from the study of the behaviour of complex adaptive systems. In particular from something called attractors.

It's bonus time here at work right now so everyone (well, all the permies anyway) is excited about finances all of a sudden. The corridors are abuzz with talk about last year's performance, our EBIT, EBITDA, ROI, earnings, operating costs and of course the most important question of all - "what does all this mean for my bonus this year?". Anticipation builds as finance gets ready to release the all-important set of yearly numbers.

The company's financial results are really important and everyone should engage with them. After all, that's really why we are all here (even us contractors) - to make the company successful. Engaging with the financials is great. The problem here is that people engage for about a week around bonus time, then once that's done and dusted, they go back to focusing on their own individual KPIs and ignore the financials for the rest of the year. That's not what we want. We want people to focus on the financials all the time. So how do we do that?

In previous posts (here, here and here) I have called out the need for really solid agile leadership to enable change. Without great leadership, change falters. We know what bad leadership looks like - directive, dis-empowering, disconnect between what they say and what they do. We all know the symptoms of bad management. But what does good management look like?

We can do the obvious and just say that good leadership looks like the reverse of bad leadership - non directive, empowering, behaves in accordance with what they are saying and so on. All that is true, but I have seen really empowering, non directive leaders who were still bad leaders at driving change. I think there is something fundamental that all leaders need to make them effective at delivering lasting change. That thing is the ability (and desire) to change themselves.

We talk about value a lot in agile. The whole point of agile is often given as "the ability to deliver value quickly". Lean looks at value streams and flows of value. But when we say value, what do we really mean? What is value? The dictionary tells us that value is "the regard that something is held to deserve; the importance, worth, or usefulness of something."

So value describes something that is important to someone. But who? When we ask ourselves this question, we usually come up with and answer of - "the customer". This isn't a wrong answer, customer value has to be our of our key drivers. Make the customer happy by giving them what they want. That's the key to business success. But note that I said "one of our key drivers", not "our key driver". There are other "someones" out there who are also important, and often get forgotten. What about the organisation itself? Its employees?

We have all seen the press releases come out. The CTO of some big organisation proudly announces that with this new agility thing they are now able to release to market every three months instead of yearly. Great news isn't it? Great endorsement of agile techniques, isn't it? Have you ever worked in one of those organisations? What is it like working in the delivery teams for one of those organisations? Is it, as the press release seems to indicate, some sort of IT workers' paradise where features flow easily into production and there are smiles and profits for all?

Or does it feel like an endless treadmill where releasing every three months just means jumping through all the hoops you had to jump through for the yearly releases but now instead of doing it once a year you are doing it all the time? Where the nightmare month you used to have once a year to push the release kicking and screaming out the door is now your normal workload? Chances are, it's not the first one. Feeling burned out? Are we achieving our results by throwing away one of our key principles - the principle of sustainable pace?

How do things get funded in the organisation you work for? If you work for most organisations, a business case will be prepared and submitted to management for approval. The conversation around approval will invariably be based around cost and benefit - how much will this cost and how much will this make? This leads to some pretty well known problems. I have written about these problems before (The Problem with Projects and Outcome Based Funding) and they are pretty well known. Ask anyone involved in funding approvals and they will tell you that the process is pretty bad and things need to be done to improve it.

Organisations have tried many things - fast track funding for small initiatives, streamlined approvals processes, delegated approvals, all sorts of things, but the process remains inflexible, flawed and generally broken. I think this comes not from a flawed process but from a flawed starting assumption - that cost vs benefit is the correct way to allocate money. I think we are asking entirely the wrong question. No amount of tweaking the process will help if the process is answering the wrong question. So what is the right question? I think we should stop asking "how much will it cost" and start asking "how much should we invest".