There’s been loads of writing about how operating models vary from business to business. Since Agile was a thing (from 2001) it has grown to become a buzzword that many organisations see as a silver bullet. This is not a new phenomenon. We often see the existence of companies who are using some methods that have a foot in the Agile camp but in fact find that things are still not working at organisational level.
Let’s be clear, ‘Agile’ started as a philosophy to deliver software projects, not a way to run a business.
In large organisations
If an Agile way of working is efficient then why do organisations so often fail (slowly) to get something out in front of customers in a timely fashion? Or why do you end up with disparate teams pulling in different directions? Multi-million pound transformation projects see huge amounts of money being lost on talented teams that are discombobulated despite being empowered to do the right thing.
In ergonomics and human factors engineering, we study the relationship between work and the worker. Whilst this may not sound very friendly, ergonomics is in fact concerned with the wellbeing of the people doing the work. Happy healthy workers mean a happy healthy organisation. This can include everything from the desk and computer, to the chair, the work type itself right the way through to the larger social and psychosocial aspects such as the culture, leadership and operating model (approach to structure, planning and process).
It may be no surprise that being such a wide area of study that Ergonomics is also concerned with how structure can impact error rates in organisations and how organisational structure can respond and deal with such errors. There is a wealth of stuff out there on human error and resilience engineering which talks about how to create cultures that reduce impact of error but right now I am focussing on organisational structure and the requirements for the successful and error free running of a business.
Whilst the tech industry does not generally operate in life and death situations (unless you have a really angry boss) there is much we can learn from looking at complex organisations in which organisational structure impacts on the success or failure of the business.
Nuclear Power Plant
3 mile island and Chernobyl are among the most studied examples of organisational failure in history. The events that led to the tragedies are varied and unfolded despite numerous training exercises to test multiple points of failure, in the end each of the accidents generated such unpredictable knock on effects when the operators made mistakes that nothing could be done to prevent the tragedies. There was not enough slack, and due to the unpredictable nature the complex systems at work nothing could have been done to predict or address every contingency. (Wickens). The system was both tightly coupled and complex, not too dissimilar in terms of the factors governing the organisational interaction in large businesses seeking Agile transformation.
We know how teams using a ‘just in time’ approach for delivering technical solutions can work very well. The most well known just in time method is Kanban and we use it in all our projects. Our teams are self managing and empowered to make decisions about the direction of the project based various factors, user goals, business goals, feedback from testing etc…
A just in time approach is by definition a tightly coupled system. Academic thinking around tightly coupled systems says that these systems are most prone to failure ‘because organisational requirements for their control are conflicting’ (Wickens) We can see this in businesses where a product owner is at the mercy of multiple stakeholders and project sponsors who disagree on the direction of a product or, the presence of complex subsystems (or ‘fiefdoms’) all vying for control. Where you have a complex organisation a flexible and decentralised management structure makes sense because the people at the top will never be able to make a good decision due to the complete lack of visibility.
The teams are trusted to make the right decisions at the right times.
But when the ‘system’ is exposed to something out of the norm, when something goes wrong the tightly coupled nature of the teams means there is little room for recovery due to the fact that all resources are accounted for. In our industry this does not result in life threatening situations and is fairly simple to remedy. We simply start again. Change is welcomed in Agile, but unnecessary change due to complex messages coming from an organisation has ramifications on cost.
The result is waste and wasted effort, as we know, is the antithesis of Lean.
It is essential that organisations balance giving teams autonomy with the centralisation of control. In the effort to have a flat structure, with self managing teams we must not lose sight of the end goal and give someone the autonomy to own it.