Governance covers:
- what decisions are important,
- who makes those decisions, and
- how account is rendered
For each and every decision a governance structure either pre-exists (implicitly or explicitly) or has to be created (ad hoc). If you don't have any explicit governance structures, then you are bound to invent one for each decision. If you ignore a decision and it defaults, you have just used the "default" governance model.
Governance has a bad name because it is often associated with centralised, top-down organisational models and tends to be centralised in itself. Devolved and distributed organisations don't talk much about governance, although they also have governance structures in place. Centralised governance can help with achieving economies of scale, but on the other hand such governance structures tend to become outdated and inadequate for rapid decision making. This causes a lot of pain for people who need to get things done before it's too late — in the modern world this means pretty much everyone — and they blame the governance people and by implication, governance itself.
Agile governance does not mean "assuring the business's investment in IT generates business value", because that is called agile portfolio management. Neither does it mean "mitigating the risks that are commonly associated with Agile projects", which is better filed under project management and control.
- working from (and on) a common vision
- transparency and awareness
- clear and simple policies
- distributed consensus-based decision making
- professional judgement (within agreed limits)
- regular, rapid cadences
- learning from feedback
- etc.
Applying Scrum or some other agile method without changing the governance structures will simply result in organisational schizophrenia. People work at cross purposes, confounding each other and wasting time and energy. For example, management thinks that each project is a separate entity, and requires oversight through weekly reports and a monthly PMO meeting. The Scrum teams believe that projects are unnecessary, and work should instead flow on a company-wide product portfolio board. Put these two together, and there will be confusion and wasted work. If people know what governance is, they have a common vocabulary and can have meaningful conversations about the conflict. If they don't know what governance is, well, better enjoy the show from the outside.
As an aside, this is what Joseph Pelrine means when he talks about "organisational friction". A team starts using Scrum and increases their decision-making frequency while lowering the batch size to match. Other parts of the organisation do not understand the need for high frequency and small batches, and this conflict causes friction and waste heat. People get frustrated and one or more of the following happen: 1) people set up padding to protect themselves, 2) the Scrum teams slows down to a manageable frequency or stops altogether, 3) the organisation speeds up to match the Scrum team.
Some hints for the agile governance road:
- Don't make the mistake that governance equals central governance equals slow and inadequate decision making. Governance is ubiquitous — you can ignore it if you want, but governance will not ignore you.
- Avoid blindly copying institutionalised models such as the matrix organisation or the project organisation. How do you know those are the best for you? Best practice is always past practice, and by adopting an existing structure you are simply limiting yourself. Read Porter's seminal article "What is strategy?".
- Make organisational experiments, but make them safe-to-fail. Don't be afraid to try new things, but make sure they can be unrolled without further repercussions. Use the relevant theories and thinking models to design potential solutions.
