Last time I looked at one of the common traps an organisation can fall into - the solution trap. Going straight for a solution rather than stopping and thinking about the problem first. Today I'd like to explore another common trap - the productivity trap. Productivity is usually seen as a good thing. The more productive we are, the more we get done with the same level of investment, so we are better off. The more time we spend on productive tasks (and the less we spend on unproductive tasks) the better.

Generally that is the case. The difficulty comes in the definition of what is a productive task. Working directly on something that is valuable to customers and will make money for the organisation is clearly a productive task. But what about things like maintenance? Upgrades? Training? Process improvement? Exploration of new ideas? Where do you draw the line between a productive task and a non productive task? And why does it matter?

"Don't come to me with problems", says the boss, "Come to me with solutions". We've all heard it before. It's supposed to be terrifically empowering - giving people the agency to fix their own roles instead of expecting the boss to do it for them. It's become a kind of mantra for modern management. Empower your people. Ask them for solutions. And it can be empowering. Sometimes.

Quite often though, I find myself talking to a leader in an organisation who says something like "I don't like having problem discussions with my people. They always just whinge at me. They never come to me with solutions. I have empowered them to come up with solutions but they don't, they just whinge all the time". When we look a bit deeper at the reasons for that (usually by asking the leader what they would do about the problem if they had to solve it), it's usually because the problem is actually quite hard to solve. There may not be a clear solution. The symptoms are usually apparent but the causes may not be. The data to understand and solve the problem may not exist. Jumping straight to a solution in this case is not a good idea. I call it the solution trap.

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.