Designing agile organisations
Organisations are increasingly seeking to re-deploy their people to higher priority work. They are looking for productivity improvements to get more from their organisation’s resources. They suspect they have resources locked up in their existing structures and that they are not organised optimally. Some teams are over-stretched while others have spare capacity or are working on lower priorities. Organisations also know that a restructure will just substitute one sub-optimal arrangement for another. So what can they do?
The hierarchical model adopted by almost all organisations was designed for different times. It is a great model for stable conditions. It brings order, control and certainty. But we live in a world that is increasingly interconnected, resulting in accelerated change in social, economic and physical environments. Every organisation is operating in a very dynamic context with different challenges each year.
Whether your organisation is about health, welfare, food, technology, products, services, regulation, water, energy, finance, insurance or resources, the context you are operating in today is very different from the past. It will be even more different five years from now. Artificial intelligence, blockchain, genomics, climate change, the internet of things, economic shifts and social change will bring disruption for every sector.
Whilst it might seem a simple task to invent a new structural model to replace the existing hierarchical model, it is not that easy. We have based a sophisticated architecture on the hierarchy. We use structure to describe accountabilities, develop business plans and allocate budgets. Plans and accountabilities determine Key Performance Indicators. The hierarchy defines governance, risk ownership and even accommodation. Discarding a hierarchical model is not a trivial exercise. And what would it be replaced with?
The replacement being proposed is inspired by the agile software development model. Agile software design takes work items and puts them in a backlog. It prioritises the backlog, and when capacity is available, the highest rated item is picked off and assigned to a cross disciplinary team. The cross disciplinary team, drawn from areas of expertise across the organisation, then moves into a sprint of 1-2 weeks around that item. In that time it understands the work item then designs, builds and evaluates a prototype solution. Based on the evaluation, either another 1-2 week sprint is triggered or the prototype moves into implementation and scale. The sprint team has a very clear start and very clear stop. The backlog is regularly re-prioritised.
So what would that look like if an agile model were applied more broadly to all the work of an organisation, not just IT projects?
First, an organisation would determine which parts of its work are about a repeatable static process and which are responding to dynamic change. The repeatable, unchanging work is probably best managed by the existing hierarchical model. But a surprising amount of the work of most organisations is not based on static processes. And it is to this work that an agile model applies.
Work suited to agile teams includes over the horizon strategic scanning, research, policy and strategy development, the design and implementation of anything new—services, products, IT systems, customer service models, channels, workforces, business processes—and more. Also suited to agile teams are responses to crises or issues, conducting audits and evaluations and developing measurement frameworks. Many forms of testing are also suited to agile teams – testing products, testing markets, testing controls and testing quality. This means there are different types of teams. Task forces anticipate responses to emerging issues. Tiger teams create and grow ideas. Design teams develop new capability. Red teams test controls. Incident teams respond to events.
So how can you move to such a model? There is no template for an agile organisation design. It is early days so there are not many examples to learn from, although several come from technology companies and a small number of larger organisations. In Australia, for example, the ANZ Bank has announced they are implementing scaled agile across their organisation, excluding branches. Acknowledging the changing environment facing banking institutions globally, ANZ Chief Executive Shayne Elliot decided to move away from a traditional hierarchical structure to an agile team based approach to organise and deliver work.
A large number of organisations are contemplating such a move but are wary of the magnitude of the change. They are right to be wary—although that is not a reason to avoid change—because they realise the implications. An agile approach means fundamental change to the way that power is devolved through an organisation. Changes to the structural model mean fundamental changes to the way accountabilities are assigned, delegations are framed, planning is conducted, budgets are allocated, people are managed, risks are managed, performance is measured, reports are prepared, decisions are made and accommodation is laid out. Moving to an agile approach means designing through each of these topics.
Lack of a template means change will need to be designed. It is not all bad news. Organisations already use a range of temporary teams. Task forces and incident response teams are two such examples. They work today because they are ad hoc and small in scale as a proportion of organisational effort therefore they don’t have a big impact on organisational governance.
But if agile models do become the predominant model, that will disrupt the normal way of doing things and will require a whole new design of those important organisational elements. Today, when a taskforce or incident response team is formed, every person on the team is the subject of a negotiation and often reluctance to give up that resource. In a crisis, leaders will generally rise to the challenge and release resources but in more mainstream work they may be less enthusiastic.
So where do you start? If there is sufficient interest to the change, the first step is to get a shared understanding of the leadership intention for the change – the drivers, the scope, the outcomes, the hypothesis, the constraints and the implementation plan. Then the leadership select and empower a design team to work across the organisation. The change can be designed and implemented in an agile way. Form a backlog of areas and issues to be considered. Take the first item from the backlog and get that working then move on to the next then the next. A co-design approach involving those affected by the change will be the most effective. It will take at least six months to work through the backlog and probably more depending on the size and complexity of the organisation. Consideration must be given to how current planning, resourcing and governance will take place as new ways are implemented over the top.
It sounds a lot of work. It is. But the dividend will be knowing that your organisation is striving to be ahead of the productivity curve, getting a strategic advantage in deploying a model that has been proven in the IT domain to get much better results from the same workforce. Those who have experienced more agile development suggest far greater productivity from the workforce, more satisfying work, much faster cycle times and importantly better results for customers and stakeholders.