May 11, 2006

...Learn TDD with Codemanship

What Is Agile Governance?

The IT industry has a nasty habit of taking words we all thought we knew the meaning of, and mangling them until they either don't mean the same thing any more, or until nobody has any idea what they mean.

One such word is governance. A quick search on Google for a definition of the word suggests that the worst has already happened. There's now no longer an accepted definition. The definitions I could find were mushy and overblown. Some definitions seem to have been created for the benefit of marketing, too. When someone defines "governance" in relation to Service-oriented Architecture, or Six Sigma, then I'm afraid I think they may have lost the plot. Still, we've all got to make a living, eh?

I'm a little simplistic, and I like simplistic definitions that contain as few words of as few syllables as possible. I like this definition of "governance":

Governance - the governing of some thing or things.

What is "governing"? Well, that definition - thankfully - hasn't been co-opted by the brand wizards yet.

Governing - exercising authority.

And, digging a little deeper, and hopefully to the core of the matter:

Authority - The power or right to give orders and/or make decisions.

So governance is about exercising the power or right to make decisions about some thing or things. When I talk about project or program governance, I'm talking about the power or right to give orders or make decisions about that project. Ethical governance suggests that this power or right must be used in the best interests of the project or program - and not necessarily in the best interests of those that govern.

The governance of the United Kingdom has a particular model, just as the governance of an IT project has a model. The UK is what some people called a pseudo (or semi) democracy. In a true democracy, all key decisions are put to the vote and every stakeholder gets an equal say in how things are run. What we have in the UK is - 90% of the time - an elected autocracy. That is, every so often we get to elect the people who can then make key decisions without putting it to the vote of the UK's stakeholders. Theoretically, MPs votes are supposed to represent the will of their constituents - the people who voted them into office in their particular part of the country. In reality, MPs votes can be sharply in contrast with the views of their constituents - and ambitious MPs tend to vote for what their party tells them to vote for, regardless of what their constituents want. You don't get to be a cabinet minister by opposing the Prime Minister!

The governance of IT projects and programs can be equally dysfunctional. Most organisations - especially in business - are true autocracies. Appointments are made from above, and authority devolves from the top down by favour, not by right. In most projects, the bulk of the people involved - e.g., programmers, testers, analysts, and so on - have very limited authority. Interestingly, authority and responsibility devolve seperately. It's not uncommon to find programmers with a heavy burden to carry in terms of workload and deadlines, but with no commensurate authority to make decisions about how they do that work.

Centralised decision making is not a scalable model for governance. The UK government's continuing drive to centralise the management of many local public services, like hospitals and schools, has had a disastrous effect on the quality of service and the cost of providing those reduced services. We now have the worst of all worlds - poor quality public services with high taxes.

The IT project equivalent is very expensive systems that are of a very low quality. Unsurprisingly, this effect is most prominent in the public sector. It seems the same organisations that couldn't source a pencil for less than $100 also has severe trouble delivering a line of code for less than $1,000.

And when things are going wrong, the UK governments instinctive reaction is to centralise more power and exercise even more decision-making control from Whitehall - which is exactly the wrong thing to do. Like a kid with severe eczema, they just can't stop scratching and they're making it worse.

The desire to centralise power seems to have infected many other walks of life. Time was when I could arrange to speak with my bank manager, and he or she had the power to make decisions about loans and so on. Now I have to learn a special trick on my phone to get to speak to a real person at all, and he or she can only tell me what decision the computer has made ("The computer says 'no' "). The quality of service we all seem to be getting from banks has deteriorated significantly over the last two decades. Many other service industries seem to be similarly afflicted. The high street banks may be raking in the profits now, but when service is that lacklustre, they will find that we're prepared to bank anywhere - even with our local supermarket. The price the banks have paid for centralisation and automation is brand loyalty, and that will almost certainly come back to haunt them in the longer term.

IT projects often suffer a similar fate. When things aren't going to plan, the management's instinctive reaction is to take more control and to micromanage from above. This is exactly the wrong thing to do. Like hiring more developers, or cutting corners on quality assurance, the real impact of increased centralisation of authority is more delays and even higher costs. More management requires more managers, and managers tend to cost more. Whether 100 managers can make better decisions than 2 managers is highly questionable. And we cannot manage software into existence. Someone still has to write the code, just as we need police officers on the street to catch criminals. More people at the Home Office != less crime on the streets! More managers in the NHS != better healthcare.

There is, of course, the politics to contend with. And I fully appreciate just how hard it is for managers to do the right thing when they're expected by their superiors to be seen to be doing the wrong thing. With the best will in the world, sometimes even the best teams don't deliver. And if a project fails, who wants to be seen as the boss who got "more hands-off" when the schedule was slipping? Who wants to be known as the boss who didn't hire more developers? Or who didn't cut out a few luxuries, like testing, to make up time?

Agile Governance takes real guts. Letting go and trusting in the team(s) is a tall order in the centralised, autocratic business cultures of many organisations. It's the right thing to do, but it's also the hardest nut to crack. Which is why most managers don't bother. When I explain how it works, there can be genuine hostility to the core ideas. A de-centralised model for decision making spells anarchy for a lot of managers. And anarchy has gotten something a bum rap over the years. Anarchy does not mean chaos. Anarchies are self-organising decision-making systems. They are not ruled from above. And they are not "design by committee" democracies, either.

The problem with democracy is that it translates into mob rule, and - just as effectively as any autocracy - can stamp out diversity by enforcing the will of the majority. Democracy, as we have seen, can be a dangerous thing for anyone who belongs to a minority. Lynch mobs are an extreme example of democracy at work.

Anarchy - meaning "self-organising" - allows for diversity, has none of the constraints of centralised decision making and, most importantly, comes with a lower price tag. Self-organising things don't need organisers, and organisers can be expensive. This is probably why people who are deeply embedded in a management heirarchy can feel threatened by this new management paradigm.

Agile Governance is a bounded anarchy. They have firm limits and clear goals that constrain the forms they can self-organise into. In the Agile Governance seminar on August 24th in London, we will explore self-organising models of governance, and see how they can be steered through the application of adaptive tension - forces that influence the evolution of organisations and the solutions they create.
Posted 15 years, 4 months ago on May 11, 2006