I have been talking a lot about leadership and the part leadership plays in agility. A lot of the feedback I get on that are comments along the lines of "that's great but I can't talk to leaders". When I dig further, there are two separate problems here. One is an access problem. Some organisations make it difficult to talk to leaders, and sometimes someone will be in an engagement at a level where access is extremely difficult to arrange. Team coaches can often find it hard to get access to senior leaders because they are engaged at the team level. There isn't much I can do about that problem. The other class of people are ones who basically respond "because I don't know how".

The facetious answer is "well you engage your brain, open your mouth and words come out". But so many people have said it that it got me wondering why. Why do so many people have this in their heads? Why do so many people say to me that " you can't just walk up to leaders and talk to them, you need to handle them differently". Why do I keep getting told that "only specialist leadership coaches can talk to leaders"? Apart from specialist leadership coaches trying to secure their future work pipeline, that is all absolute crap. Leaders are people just like the rest of us, with the same concerns and pressures as the rest of us. They are not some alien species that needs to be handled in a special way. I think the main problem is a language one. People start talking to leaders in the same way they talk to teams and it just doesn't connect. Then they get discouraged and leaders become this remote species that you can't talk to. So I'm going to give you my 7 point cheat sheet for leadership communication to help get those conversations started.

There has been a lot of talk at work about increasing empowerment and employee engagement. The common complaint I get from management is that "we have empowered our people but they just won't make use of it". It's a common story. Management gives empowerment but nothing at all happens. Things go on as they did before - everyone looks to management for direction. No one takes initiative. No one takes ownership. No one is empowered.

Empowerment takes more than a few words from management. You can't just tell people they are empowered and lo and behold, they are empowered. Empowerment is something people can't be given. They need to take it, it isn't something you can give. It is something people need to become. Management can't give empowerment. What they need to do is create an environment that allows people to become empowered.

Last time we started looking at my holiday workshop experience and seeing how it related to agility and infrastructure agility in particular. We looked at why the two are similar (long lead times for materials, limited rollback options for mistakes and so on). We then started to step through the process of building something out of timber and discovered a few useful rules for infrastructure agility along the way. We looked at the planning and material buying stages and discovered the first two rules for infrastructure agility -

• Have just enough information to get started. The detail will follow.

• When buying materials, give yourself a little slack. A little upfront cost leads to a lot of downstream flexibility.

Today we are going to cover some more of the process and see if we can discover some more useful rules.

Happy new year folks! Welcome back to the blog for another year. I hope you all had a great holiday break. I certainly did. I spent a large part of my break productively engaged in my workshop building things. I have mentioned this before but for those who have missed my previous workshop updates, I build things out of timber. Furniture, using traditional joinery so no nails, no screws, no fancy fasteners, just mechanical fit and glue to hold it all together. No cheap timber either. No pine. No MDF. No chipboard. Australian hardwoods all the way. To describe the process of working with expensive timber, let me put it into terms that more of my audience will understand (given that I suspect there are more software people than timber-workers who read this) - imagine working on a software project where every action you make is non-reversible. There is no source control, no revert, no undo, no control-z. Everything you do is straight to production. If you make a mistake you have to throw the whole part (and anything it is permanently glued to) away and start again with new materials, which involves a 3 hour round trip to the specialist timber yard, a lot of expense as you have buy a whole length not the little piece you need, and a long delay if they don't have what you want in stock.

So while I was building, I was thinking about just how anti-agile the whole process is. You need detailed up front plans. Once you start you really can't make changes, you are basically locked in. Materials are in limited supply, have long lead times and are expensive. There are limited options for any sort of teamwork. You can't have a team standing around a table saw. That's unsafe. In fact any more than two (one feeding, one catching and even then only if it's a big piece) and it's just not possible. You can't even have multiple people working on different pieces simultaneously (not in my workshop anyway) - there isn't the space and more than one machine at a time would start to blow fuses. So it really is a solo activity (until it gets to glue time where 7 or 8 extra pairs of hands are really handy for manipulating clamps). In a lot of ways it's a lot like infrastructure projects - expensive materials with long lead times. Detailed up front planning. Limited ability to roll back changes without massive rework. Lots of solo work doing configuration then brief bursts of activity at deploy time when it's all hands on deck. No wonder people say that infrastructure can't be done agile. But then I really looked at what I was doing and realised that most of those things describe the way I used to do woodworking a few years ago when I was starting out. What I was actually doing now, while it looked similar on the surface, was actually quite different. And quite agile.

When a team in an organisation decides to do something a bit different (like adopting agile), the rest of the organisation tends to push back and force the team to conform to the normal way of doing things. A team, isolated and on their own, can only resist that pressure for so long until they have to give in. It's like standing outside in a thunderstorm - sooner or later you will get so uncomfortable that you will have to retreat to shelter.

But what if you could take some shelter with you? Something like an umbrella perhaps? It's not exactly comfortable standing under an umbrella in a raging storm but it will let you withstand the elements for longer than you could if you didn't have one. This is what we do in organisations when we start to engage leaders. When the team's leader gets engaged with the change, they can provide some shelter to the team. They become the team's umbrella. But as anyone who has stood outside with an umbrella in a storm will know, the protection they provide is limited at best. We need something better.

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.