In the agile community, we tend to focus a lot on teams. This is a natural thing to do as building high performing delivery teams is where agile started. We tend to see management as an impediment to good team functioning. We talk about "the frozen middle" and "lack of executive support". We teach scrum masters and product owners how to shield their teams from management.

If we are going to stay in delivery team land, this is fine. We can build high performing teams and shield them from management as we always have, but if we want to take agile further - build truly agile organisations rather than just agile delivery teams - we need to take a different approach to management. We need to start engaging them as allies rather than treating them as the enemy.

Got a team that isn't performing? Won't raise issues in the retrospective? Acting like group of individuals rather than a team? Product owners constantly changing priorities mid-sprint? Scrum masters not protecting the team from interference? Team communicating via email instead of talking? That's quite a laundry list of dysfunction, isn't it? You would think you have a whole bunch of problems to solve, but if you are seeing all of these at once in a team that has been together for more than a sprint or two, chances are you only have one. It's a big one though. There is one really common dysfunction that can cause a whole range of problems. Usually, it's not a problem with the team, it's a problem with the wider organisation. What could well be to blame for your team's problems is...blame.

A corporate culture based on assigning blame for failure can manifest in a wide range of bad behaviours. The first casualty of a blame culture is trust. If everyone is frightened of being blamed for something, they will tend to start deflecting blame to others - "it's not my fault... Fred didn't get his part done in time...blame him!" Naturally, teamwork suffers as people retreat into self-protective shells and start communicating via documents and emails so they have evidence to back up their side of the story when blame time comes round. Naturally, this sort of thing makes teamwork pretty difficult. As soon as blame starts getting handed around, trust evaporates and with it goes teamwork.

So last time I talked about large companies and some of the reasons why they make sub-optimal decisions. Not bad decisions, but ones that aren't as good as they could be. The main reason for sub-optimisation was centralisation of decision making and the main reason for centralisation was the need for control. In particular the control on spending money. With no central control of funding, anyone could spend a bunch of company money and the company would soon be broke.

If decentralised decisions are more optimal because the person making them has more information than someone further from the coal face, but centralisation is required for spend control, what are large companies to do? Are they doomed to make sub-optimal decisions forever? Fortunately, no. There are ways of maintaining centralised control of spend while allowing decentralised decision making about where to spend money. There are, in fact, many ways to do this and we will look at one of them now. I'm calling it outcome based funding; I'm sure the financial folks have a fancy, official name for it, but outcome based funding will do for now.

Everyone who has ever worked for a large company knows that they make really silly decisions. Completely illogical decisions. Decisions so monumentally ridiculous that you wonder how the company actually manages to survive as a going concern, let alone turn a profit. It's seemingly obvious to everyone in the organisation, except the senior executives who are making the decisions. Good projects aren't funded, bad ones are. Good teams or departments are restructured but poorly performing ones aren't. Opportunities are lost. How do they continue to make money with all these bad decisions? And why do smart executives continue to make them?

The answer of course is that big companies very seldom make truly bad decisions. What they make are a lot of very sub-optimal decisions. Decisions made are seldom illogical, there is a lot of reasoning that goes into them. Unfortunately, that logic and reasoning is based on very poor information. The decisions they make are good enough to stay in business and continue to make significant amounts of money. They just aren't the best decisions possible. The real question isn't "how can companies still make money while making poor decisions" but "how much more money could they make if they made better decisions". Looking at the reasons why companies make sub-optimal decisions can point us to ways to make better ones.

The responsibility trap is a very easy one to fall into. The symptoms are easy to spot - it's 11pm, you are sitting in an empty office, buried in work up to your eyeballs. Everyone else went home hours ago. Weekends are a myth. You haven't seen your family for days. The agile principle of sustainable pace applies to everyone on the team... except you. How did it happen? The trap is a really easy one to stumble into because it's insidious. You can wander in without realising you are inside, you won't notice until you are deep inside and by then it's too late. Try to leave and the trap will snap shut around you. While anyone can fall into the trap, it's particularly easy for people in expert, leadership or coaching roles to get stuck in it.

The trap is really simple, it works like this - the team needs something done. You, as "the expert" in the area, take it on and do it. The next time it needs doing, you do it again. Now, everyone just expects you to do it. Then something else comes up and, as "the expert", you step up and do it. And so on, until you are buried in a pile of work. Your intentions were good - the team needed something done, they were busy, it was urgent, you did it. What's wrong with that?

Some agile teams do well. Many don't. In my experience, there is one consistent thing that separates the teams that succeed from those that fail and that is sound engineering practices. Foremost among those sound practices is Test First (or Test Driven) design.

Having a solid test suite that runs frequently is a key to agility. By frequently I mean every night at least. Without frequent regression testing, teams become risk averse and unwilling to make changes in case something breaks. In an agile environment where change is encouraged, this can be a death sentence for an agile project.