Efficient Teams Are Not the Answer You’re Looking For

DZone 's Guide to

Efficient Teams Are Not the Answer You’re Looking For

Teams often inspect their processes and find better ways of working more efficiently. But what if efficient systems are more prone to collapse and fragility?

· Agile Zone ·
Free Resource

You know how you can be triggered into thinking in a different way? Sometimes this is known as the shower effect; when your mind, free momentarily of the usual routes to solutions, comes up with an idea from the left field, a humdinger, an idea that seems to steal the foundations away and replace them with straw. That happened to me the other morning as I was reviewing, again, the agile manifesto.

While reading the bit about self-organising teams, I remarked to a passer-by how I wanted my team to take responsibility for the interface layer instead of handing it off to others for implementation. It was a classic, non-thinking, agile comment, and I was dumbfounded when he replied, “Hand-off is a good thing. The more we share the solution, the more cover there is when things go wrong.”

His comment immediately reminded me of the 2000 petrol crisis in the UK. A few convoys of slow moving haulage traffic protesting about fuel prices led to a run on petrol at the pumps and a national shortage. It turned out, there was not enough slack in the supply chain to deal with a sudden increase in demand. Worried drivers tried to fill up earlier and keep their tanks fuller. High demand led to shortages which in turn led to more worry and higher demand; a vicious cycle of unintended consequences.

In The Five Stages of Collapse, Dmitry Orlov argues that “Efficient systems tend to be more highly optimized for a given set of uses or conditions, making them more fragile and less resilient.” It turned out that the petrol distribution network of the UK was highly efficient. And therefore prone to shock.

But efficiency is exactly what are striving for with agile teams. We do the minimum to get the value and no more, we pursue efficiency at regular retrospectives, we immediately adapt to changing requirements, we conduct minimal risk-based testing and build super-efficient routes to the production environment and we communicate face-to-face – which is the most efficient and effective method.

As a consequence, are we less able to cope with unexpected events than in the hey-day of waterfall nirvana? A highly strung, responsive machine is far more likely to break than a jalopy running on dirty fuel. Robert Colvile, in The Great Acceleration, states that “lean, efficient systems are always vulnerable to being knocked off course by sudden shocks,” and my colleague had been alluding to resource shocks when he said it was a good thing to hand work over.

He meant that we were sharing the knowledge and the solution, that we were widening our support and making our business less fragile. If one of the teams happened to leave – or worse, walked under the proverbial bus – we would happily cope because of the inbuilt robustness of an inefficient system. I reflected on if I had been pursuing the false god of efficiency for years.

So when we consider our agile drive to efficiency, it’s also vital we take the entire context of our organisation into account, and we build in slack. Your team may be lean and mean on web development, but if it can’t function the moment the DevOps guy catches flu, you know you have stumbled into fragility.

But a sudden shock should not presage a collapse of service, because that would negate the very first agile principle of satisfying the customer. And that means that agile principles have built in the need for us to create less-than-perfect efficiency. We should not strive to always improve even though the regular retrospectives (principle 12) suggest we should! A balance is required.

Managing likely, unlikely, risky and threatening events was something the old siloed waterfall teams and management were good at. Solutions were over-documented, risks were over-managed and programs controlled by financial diktat. They weren’t efficient, but they were resilient. Ask anyone who tries to change them to agility!

agile, agile application delivery, devops, efficiency, lean, systems thinking, team development

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}