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.
WANT TO KNOW MORE ABOUT OUR WORK AND OUR IDEAS? JOIN CIPI!