"We need to harden this process...make it more robust. Too many things are slipping through the cracks". How many times have you heard statements like that? Things that don't fit the process take extra time to resolve, so we make sure that the process covers as much as possible. As issues arise, we tighten the process still further. Spell out the entry criteria. Map the process steps in great detail. The problem is, of course, that no matter how much detail we have in the process, things still don't always fit so we document and harden even more.

We create processes and because we are humans working with incomplete information, there are gaps. Our natural instinct then is to fill in the gaps. Tighten the process. Specify, document, enforce. The problem is that this simply doesn't work. The real world conspires against us. Customers don't always want the standard product. You may have a carefully documented 30 day SLA but that doesn't help a bit when a key customer rings up and says "We know it's usually 30 days but we really need it in 10, can you please help? If not, your competitor has said they can do it in 10 days." You may only sell in lots of 100 but what happens if a good customer rings up and asks for an extra 35 because they have had a spike in sales but don't have the space to store another full hundred? The more rigid we make our processes the more often they break down.

Time to close out our series on common traps with a look at probably the most common trap organisations fall into. I don't think I have ever worked for an organisation that wasn't caught to some extent in this trap. What I'm talking about today is the cost trap. You get into this trap by having the wrong sort of conversations - conversations about cost. "How much will this cost?" That question has lead most organisations astray. Why is that? Surely how much it costs is an important question. And indeed it is. The problem occurs when that's the only question you ask. Cost is important, but there is something else you need in order to make a good decision. There is half the information missing. That other half is value. "What will I get in return?"

Let me put it this way, if I were to ask you "would you rather I took $10 from you or $50?" I suspect most of you would chose $10 (and for those who wouldn't, you are very generous, please leave your name in the comments below...). If, on the other hand, I asked "Would you rather I took $10 and gave you back $50 or took $50 and gave you back $500?" I'm guessing most of you would pick the $50. Just focusing on the cost would drastically lower your return. But this is what most organisations do. To be fair, most organisations do consider value, particularly at the top levels of the organisation. Every idea starts with a cost/value decision. ROI is a key consideration. But as work moves down the organisation, the discussion starts to become less and less about value and more and more about cost. The point at which the organisation falls into the cost trap is the point where the value part of the discussion vanishes and the discussion becomes entirely about cost. Often, this is where an idea becomes a project and is handed over for delivery.

Continuing on with our series on common traps that organisations can fall into, it's time to look at the Urgency Trap. What's that? It's a particularly common trap and unlike most of the other traps where agile techniques tend to help avoid them, the urgency trap is one that agile teams can fall into even more easily than traditional teams. It's also a particularly dangerous trap because it can lead otherwise great teams into other traps, like the rebuild trap we looked at last time.

But what is it? Take a look at your current backlog. Now take a look at your team's long term goal. How much stuff at the top of the backlog is stuff that is strategic and aligned to your long term goal. How much is stuff that's short term, tactical and is at the top of the backlog, not because it gets you closer to your goal but because it's urgent? That bug fix. That urgent tweak to a feature that someone demanded. That urgent update to the terms and conditions because someone in legal found a problem. What's the ratio? More than 50% long term and strategic? Trend is steady? You are probably OK. Less than 50%? Percentage of urgent work is creeping up and displacing more and more strategic work? Welcome to the urgency trap.

Another post in my series about common traps that organisations can get themselves into. This week we will look at a really common one. I think I have seen this in one form or another at every organisation I have ever worked for. It's really easy to get into. Once you are in it, it's really hard to get out of. But fortunately, once you know what you are looking for it is really easy to avoid. It's the rebuild trap.

It works this way - the product or process you are working in is becoming old and inefficient. The code base is old and riddled with tech debt. Technologies have gone out of date. It's becoming slower and slower (and more and more expensive) to add new features or other changes. Finally the organisation throws up its hands and announces that the system will be re-built. Everyone cheers. Out with the old, in with the new. A team is stood up. Everyone fights to be on the sexy new rebuild team rather than the boring old legacy maintenance team. Work begins and...never ends. The new system never gets delivered. The old one never gets replaced. Large amounts of money are spent with no result. The other possible outcome is that the new system eventually gets delivered, very late and with vastly less functionality than the one it replaces. What went wrong?

I have been looking recently at some of the common traps organisations can get into. Today it's time for the efficiency trap. "Hang on", I hear you say. "What's wrong with efficiency? Efficiency is a good thing...right?" Well, yes, but exactly what are you efficient at? Are you efficient at delivering things or efficient at achieving business goals? "But wait?" you say. "Aren't they the same thing? Don't we achieve business goals by delivering things?"

The answer there is "not always". It's really easy to deliver things that don't actually deliver business outcomes. Features that no one uses. Products that don't sell. Or at a smaller scale, designs that never get implemented. Business cases that never get funded, and so on. This is where the efficiency trap gets us. We fall into the trap of thinking that the more stuff we produce, the better. We mistake efficiency at producing outputs with efficiency at producing outcomes.

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.