Traditional strategic planning is dying. In today’s dynamic world fewer and fewer organisations are practising the traditional process of ‘forecast ahead, prepare 3-year plan, then implement’.

This rigid, ‘top-down’ approach is in complete contrast to the approach used today by many large and international companies, particularly leading tech companies (e.g. Google). With this approach, using a ‘visionary framework’ they have defined for the medium-term ahead, goals and actions are decided and reviewed every few months for staff teams, and strategy emerges from their ongoing innovations and tactical decisions. In effect, strategy emerges with tactics.

This is ‘agile’ strategy. It echoes the now well-established agile approach to software development and now being used for wider IT, operational and organisational innovation and change projects. But what exactly does the agile strategy process involve? How is it different from traditional strategy ? And is it right for every organisation ?

Agile strategy avoids trying to pre-design and map out the future in detail – like traditional strategy tries to – and instead is very much a continuous, osmotic process that involves trying out different tactics and ideas all the time to serve customers/stakeholders better and ensuring the organisation responds fast and effectively. This is in contrast to traditional strategic planning which has typically been regarded as a periodic, ‘once every few years’ exercise involving more of an analytical and linear process with significant change, therefore, happening mostly in ‘fits and starts’ rather than on a continual basis.

However, agile strategy still needs to start with the established notions of (long-term) ‘purpose’ and (medium-term) ‘vision’ – in order to provide a fundamental ‘anchor’ to guide ongoing decisions and tactics. A purpose statement is needed to answer such questions as ‘how do we fit into the wider world?’, ‘how fundamentally do we make our customers’ lives better?’, and ‘what space in the market can we make uniquely ours?’ And having a specific aspirational vision/sense of direction for the next few years ahead is important too – ideally with a few definite ‘head-line’ goals or broad priorities – to inspire and guide people. Without carefully defined purpose and vision statements, agile strategy would result in chaos and totally un-co-ordinated decision-making!

Once purpose and vision have been defined, the crux of the agile process involves following a regular cycle of setting very short-term delivery goals (ideally 3 or 4 monthly, but at least 6-monthly) for every team in the organisation and then reviewing their implementation at the end of of the cycle period, making any adjustments or adding new goals to suit the latest performance results, match people’s latest ideas, or better suit the latest changes in the market.

This approach is the basis of the performance management system known as Objectives and Key Results (‘OKR’), practised by many of the leading high tech companies: senior leaders define every quarter a few broad (often qualitative) goals for each part of their organisation and then, in turn for each of those objectives, a small number of more focused, quantifiably-expressed sub-goals (‘key results’) to guide every team needed to work in pursuit of the higher-level objective.

With agile strategy, the traditional annual operating plan goes out of the window. However, there’s still a need for an annual, overall financial budget – to act as a framework for the short-period performance/action plans. From a governance point of view, just having a sequence of very short-term budgets with no attempt at thinking further ahead at all about future resourcing needed would, of course, not be prudent. However, with agile strategy, the annual budget does not act as the dominant yardstick and focus of control for senior managers: the conventional, overriding focus of ‘hitting’ a set of annual ‘figures’ does not apply so strongly. Rather, the budget becomes more of a guide simply for co-ordinating forward resoruce thinking.

The other key feature of the agile strategy process is a performance reporting system that matches the short-period goal-setting/review cycle of the organisation and includes a rounded and holistic set of success measures. The familiar concept of the ‘balanced scorecard’ is relevant here, but with less stress on sales or financial metrics and more on customer-centred metrics (particularly customer satisfaction e.g. Net Promoter Score) and people management metrics (e.g. employee retenton, employee satisfaction) and practices that foster good ‘organisational health’ (e.g. flexible job roles, internal communications, a learning culture, and wide use of coaching by managers).

Agile strategy involves a shift in approach in several aspects compared to traditional strategy. Here’s a summary of eleven key ways:

i) From reliance on long-term forecasting …. to … ongoing, wide market-scanning and widespread intelliegence/feedback; ii) From ‘wait and react’ to customer changes … to… deep customer understanding and close involvement of customers, allowing proactive creativity; iii) From annual analysis/planning exercise … to … a continuous process of experiment and change; iv) From developed at the top of the organisation …. to … open/full staff involvement i.e. both top-down and bottom-up); v) From innovation occurs irregulalry / in local pockets of the organisation ….to … continuous innovation across the whole organisation; vi) From short-term performance/results focus … to … both long-term and short-term thinking; vii) From gap between strategy making and execution … to … strategy making and execution being intertwined / happen together; viii) From focus on financial returns/shareholders … to … focus on customers and wider stakeholders; ix) From pursuit of long-term competitive advantage … to … pursuit of multiple, transient advantages; j) From employees and suppliers treated as resources … to … all treated as partners; k) From slow, linear approach to adopting changes … to … fast/flexible, agile mixed-team approach to development.

A matching (but not always fully suitable) part of the overall agile strategy process is to use an agile-type methodology for tackling and progressing individual projects and initiatives involved in or arising from the organisation’s strategy. In particular, for example, an agile method can be used to help the development of new or improved products, services, or operational processes, or to develop sales/marketing initiatives, or to solve problems or plan changes concerning internal management systems or policies. There are a few different versions of what is meant by an agile project (e.g. lean devlopment, which focusses on the continual elimination of waste, and kanban, which focuses on reducing lead times and the amount of work in process), but the most common variant goes by the name of ‘scrum’ which emphasizes the uses of adaptive teamwork to tackle challenges.

The typical, core features of a scrum-type project include appinting a dedicated and cross-functional team (of 3-9) individuals to work together full-time (or most full-time); setting an overall goal but not having any detailed or fixed overall (start-to-end) work plan; working towards the goal in incremental steps involving short ‘sprints‘ of work; daily short meetings of all team members to update each other and discuss ideas/solutions together; prompt testing/trialling of the outputs from each sprint with active input from customers; and the team itself deciding what outputs from each sprint should be taken as the starting basis of the next sprint to advance things further. A series of sprints adds up to an ‘iteration‘, at the end of which either a usable new/improved product or service or process is presented to the overall project customer (or sponsor), or a following major milestone is set if the project is part of a very large or complex development/initiative.

The key benefits/advantages of agile strategy – compared to traditional strategy – include: i) an organisation is able to respond faster to environmental change and achieve more rapid innovation; ii) avoidance of trying to predict/forecast the future and of the use of lengthly planning documents; iii) increased staff engagement and motivation and minimal silo-thinking, as agile strategy involves almost everyone in an organisation; and iv) more opportunity for staff to use intuition and creativity to contribute to innvovation, not just rely on the customer for ideas.

Further benefits brought by agile strategy are: v) the value and productivity of individuals’ work is higher as there is rapid testing and feedback of their outputs; vi) overall work is simplified and overall risk is reduced on account of the short, rapid bursts of work and the prompt feedback received; vii) relationships with customers and suppliers are closer and more dynamic, as they are treated as co-creators/partners in the development process; viii) higher customer satisfaction, thanks to the early and regular feedback on delivered outputs; ix) by the use of self-managed teams, senior management is freed of micro-managing projects and able to focus on higher-value duties (e.g. selecting strategic priorities and coaching staff); and x) the use of cross-functional teams broadens organisational experience for staff and builds mutual trust and cohesiveness.

However, an agile approach to strategic projects is not always appropriate. There are a number of key issues to consider. Perhaps most importantly, how suited is the organisation’s culture and management style to deal with decentralized decision-making and a ‘loose’ innovation and change process? If the culture is hierarchical and not very empowering (e.g. staff are not well trained or coached by managers), a classic strategic planning approach is likely to be more apt. Equally crucial, how suitably skilled, confident and experienced in acting as a self-managing team are the the people who will be working together on the project? The lower the level of skills, the more supervision will be required and a less agile approach will be necessary.

Other key factors to consider include: i) How stable and uniform/fixed are the organisation’s operating conditions or future customer requirements ? The less stable things are and the more opportunity there is to achieve some product/service differentiation in the marketplace, the more an agile approach will be useful; ii) How easy/ feasible will it be to gain prompt and specific feedback from customers after each sprint? If it’s not easy, an agile approach is unlikely to work well; iii) How large or complex is the overall project requirement? When things are more complicated, the discipline of a plan-driven approach is usually a more sensible choice; iv) How risky or time-crticial is the overall project ? If a very high level of assurance is needed, a traditional plan-based approach is likely to be best; v) How many people are needed to complete the project? A team of ten can be agile, but a team of a hundred cannot!

So, overall, agile strategy and traditional strategy both have circumstances when they are more suitable than the other. But the distinctions between the two approaches are likely to increasingly blur, as the new digital landscape and fast-changing competitive conditions increasingly characterise all markets and sectors everywhere.

For the next few years, though, except for markets that are extremely fast-moving like high-tech, I think agile is likely to be used more for handling individual strategic projects rather than totally transforming companies’ overall strategy proces: truly agile requires a very supportive and empowering organisational culture which mahy senior managers will simply find far too daunting and difficult! In the longer-term, though – say within five years – agile strategy is likely to have transformed the vast majority of organisations’ total approach to strategy development. The degree of adjustment needed will be huge and quite painfrul for many organisations, but the unstoppable pace of change around us will demand it!

As ever, if the team at Owen Morris can assist your organisation with any of the issues in this article, do get in touch.

Written by Mike Owen, CEO at The Owen Morris Partnership.

Copyright of Owen Morris Partnership