Introduction

Governance seems to be on everyone’s lips these days. The first thing the new CIO of one of my clients demanded when she arrived was “more governance”. I have also heard ScrumMasters requesting “better governance”, and a big organization that I consult for has stated that projects start only after a clear governance structure has been defined.

But what is governance and does it differ in traditionally run projects vs. agile product development? I have been arguing with myself for quite some time now on this topic. Lately I believe to have gotten some clarity on it, which is what I want to share here with you.

Thanks to Robert Love, Bianca Legorreta, Steffen Foldager, Jesper Boeg, Linda Stougaard Nielsen, and my brother Dirk Bucka-Lassen for both proof reading and providing me with valuable feedback.

Traffic Jams

Have you ever been stuck in traffic on a highway and wondered what kind of accident must have happened further ahead to cause the jam? Isn’t it kind of weird when all of a sudden traffic flows nicely again with no explanation, no visual clue as to why you and a lot of other people just wasted half an hour?

In congested traffic it actually doesn’t take much to cause such a jam. Just one driver hitting the brakes – even lightly – is enough to bring traffic further down the line to a halt. Because cars are so close to each other and because there is a reaction time, the next car has to brake a little harder, the next one even harder, and soon after that they have to slam on the brakes – eventually coming to a complete standstill.

In summary, there are the two factors that in combination cause jams:

  • a high utilization of the road (congestion)
  • somebody hitting the brakes (interrupting the flow)

In this article I want to talk about the latter, interrupting the flow. The utilization I will deal with in more detail in a separate blog post.

Assumptions and Decisions

During a normal working day, a developer makes a lot of assumptions. I couldn’t find any scientific research on this, but from my own experience I’m sure we are talking big numbers here. Most of these assumptions are made unconsciously, some consciously, and some are outright decisions.

Each assumption carries a risk that it is not optimal. What I mean is that if we always made the best possible assumptions, we would end up with the best possible product (in the shortest time). Whenever we do not end up with this best possible product, it must be because we made some non-optimal assumptions along the way.

Steering wheel No matter how well we specify the product to be built, we know there will be questions to be answered and decisions to be made during the development, so we set up governing processes to ensure the best possible decisions are being made, by setting up steering committees for instance. The term governance stems from the Greek verb κυβερνάω, which means "I steer". So this makes perfect sense, doesn't it?

Agile Governance

While I agree that proper governance will increase the chance of success, I believe that a lot of people get governance wrong. For a manager it is not about taking the steering wheel in your own hands: it is about letting the team drive and only taking corrective action yourself when necessary.

Governance is about steering when necessary, but only then. It is like Google’s driverless car. It still has a steering wheel and brake pedals. You let it do the driving, but you (for the time being) supervise and check that everything is moving in the direction you expect. If something goes wrong, then you intervene.

The traditional decision-making process creates stop and go waves, just like in traffic. This leads to jams (if we also have congestion – which I will assume for now and promise to talk about in a future blog post), and jams mean we are moving unbelievably slowly (very stressful to most people). The flow is ruined. It doesn’t really matter how frequently the change review board meets or how available the project manager is: if a developer goes and asks a question and doesn’t get an immediate answer, he will have to park the task at hand and start on something else.

Even Scrum teams are not immune. I see a lot of inexperienced teams that struggle. They do everything by the book but still don’t see the beginning of something that looks like the promised land of hyper-productivity. The reason is often a lack of flow. They continue with the habit of asking a superior – a senior developer, an architect, the product owner, or some stakeholder – to make decisions whenever there is the slightest uncertainty.

Delivering often into production opens new possibilities

What many people fail to understand is that when we develop products in an agile fashion and thus deliver often and early into production, we can get away with being less sure about our assumptions. We don’t need all the facts on the table to be able to make the best possible decision.

Agile Governance is guiding, not deciding _“Will the users want it this or that way? I don’t know and I could go and ask them, but I could also just make a decision here and now and continue with my work without interruption. I’ll find out in a few days, when the users see the product, whether I was right or wrong and even if I was wrong, I’ll have it fixed quickly.”_

The shorter the timebox until you find out whether the stakeholders like the direction of the product development, the more practical it is for the developers to make decisions, the more flow you will have, and the higher the productivity will be.

What do you prefer: six out of six newly developed features accepted at the end of a sprint, or eight out of ten?

When I see teams that get 100% acceptance of all implemented user stories at the end of their sprints, I often provoke them by asking them to try and lower that number. Getting everything right every time could (certainly doesn’t have to) be an indication that the team is doing (or requiring) either too much up front work and/or asking too many questions during the sprint in order to be sure everything is correct.

Transparency is Key

Transparency is one of the cornerstones of Scrum. It enables the governing bodies to stay on top of things. The product backlog, the reviews and the involvement of stakeholders in general, the shippable product increments – this all promotes transparency and enables us to maintain a good understanding of whether the product is developing in the right direction.

Transparency is Key In the beginning management will be quite alert, requiring an ultra-high level of transparency and invoking it often – just as you probably would on your first drive in Google’s car. You wouldn’t be reading the newspaper, would you? After a while however, you will start feeling more and more comfortable with doing other small things, and soon after that you might well be doing stuff that requires your full attention – only checking occasionally what the car is doing and where it is going.

That is agile governance! The team gets the authority to develop the product to the best of their understanding, and you as governing body keep an eye on things.

Governing doesn’t mean making decisions, it means making sure the right decisions are being made.

If you manage to get this right, you just got one step closer to hyper-productivity land.