With measurement comes control

In my last post on Why your organisation won’t be Agile I made the following assertion.

If your organisation is based on the traditional command and control management model and you cherry pick a set of project management techniques from one of the flavours of agile you will get visibility but not much else.

I promised to look at some of the root causes of the golf-course-agile movement and so here is the first.

Firms design for efficiency

John Roberts in his 2004 book The Modern Firm defines two main types of activities that make up an organisation. The first type are around the value chain – the set of routines and processes that are executed in order to fulfil an organisation’s strategy. The second are the supporting activities without which a firm wouldn’t function. Think HR, payroll and finance etc.

The optimal design of your value chain activites should enable you to execute your strategy as effectively as possible. Many large traditional organisations are designed around the idea of cost-control and efficiency. Make your processes as efficient and as cost-effective as possible as a mechanism for sustaining and, hopefully growing, your profitability.

In this world, decision making responsibility typically lies with middle managers whose direct reports are the people responsible for the value adding activities and who themselves report to either C-level executives or more senior managers. Decision making at this level brings some benefits from coordination of activities across different business units or groups within an organisation. An example would be a massive conglomerate where a middle manager is responsible for all the Software Engineering groups and who is accountable for results across those groups.

Strong incentives require measurement

The key word in that last paragraph is accountable. It is reasonable to expect that this accountability is tied in some way to increased rewards or incentives for generating better results and in order to qualify for those increased rewards the Manager must be able to demonstrate these better results.

Thus, the adoption of Agile project management practices makes complete sense in this context. Especially if it is linked to toolsets that offer Management Dashboards or other automated ways to interrogate the progress of the work in your business unit/division. Indeed, not only will your Manager’s Manager have access to the information she needs to demonstrate progress against her key metrics, she can use the new knowledge to increase performance further by concentrating on the (for a given value of) under-performing teams in the business unit. This gives the manager increased information on which to base their decisions presumably allowing them to make better ones.

Innovation retardation

This centralisation of decision-making comes at a cost. The information produced for individual teams must be standardised to a common format that enables the sort of aggregated and comparative reporting required by this model. This means standardisation of processes across teams within the business unit. And that standardisation comes at the cost of effectiveness. Designing or adopting a process, then locking it down and requiring all teams to implement it may be efficient, but it will ensure that each of the teams operate at a level of effectiveness below their optimal. Mandating the adoption of process is a guaranteed way to stop your teams innovating and changing their process as they find better ways of working.

Remember this?

The best architectures, requirements and designs emerge from self-organising teams

It’s from the Agile Manifesto and effectively states you get more maintainable, robust software if you delegate the responsibility of decision making to your teams. In my opinion you can add processes to that list .

What about this one:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Deliberately reflect on how you can deliver more effectively. The assumption is that you will change your processes over time as new information becomes available to you; as you learn. If you don’t do this, then you are an idiot.

Woah there dude! Are you saying that visibility is a bad thing?!? Surely you *do* get visibility with Agile?

Of course. And there in lies the rub. You do get tremendous visibility. Having hard data on whether you are going to hit your release date 1/3 of the way through a project enables you to have far more productive conversations with your business sponsors and even pull the plug if necessary. Code coverage metrics let the team feel safe enough to refactor the codebase, fix broken windows and deploy automatically on a regular basis. Big Visible Build Monitors allow the team to be confident that their software is always deployable and that they are a revert away from working code. The point of surfacing all this information is to allow the team to make decisions based on the feedback loops that provide it.

The first candidate cause of golf-course-agile is…

Here’s the problem then. The idea of a centrally mandated process designed by middle management or process mavens for the purposes of increasing visibility reinforces centralised decision making. If adoption is driven by a need to measure or increase visibility of the work being done because strong incentives require strong measures, you will end up missing a key part of the very thing that drives the huge increase in effectiveness you get by trusting your teams.

Without the devolution of decision making to the teams that are delivering the software; without the ability to make changes to the processes they use as they find new and better ways of working; you will get visibility but little of the increases in effectiveness that come from the ability to influence your own environment, to reflect and to adapt. In my opinion you won’t be agile. Whatever it means.

Next up, Ivory Tower Process Mavens, and the systemic reasons they fail