Agile strategy: What the CSO can learn from the CIO

Grant Crow Jan 2016

The birth of Agile

Perhaps it should be no surprise that agile as a philosophy and practice has arisen in IT. As Marketing is arguably the most dynamic business function today, IT has been in that position in the past 30 years. IT functions have had to cope with continuous, often disruptive change over this period. When change is so in your face, you either wither away or become adept at it.

The traditional way of developing software solutions is typically termed waterfall and there are a number of parallels with traditional approaches to strategy. In the waterfall way, projects tend to be seen as big, chunky things to be tackled by an army of developers, QA’s and project managers over a long period of time. Essentially, big was good. Big often correlates to big budget, big profile and therefore political importance. The downfall of this approach was that when the new/enhanced product was released to customers, everyone braced themselves for the avalanche of anger, insults and defect queries from customers. Waterfall has no real feedback loop, so the only time reality entered the process was right at the end – when it was too late. One can only imagine how costly and ineffective this was.

This ritual end of project beating delivered by customers led to the birth of agile. It took a few people to reflect on these beatings and to realize that:

• An incremental way of working is better suited to environments of rapid change. There may be a long-term plan or theme in place, however, it’s all about what’s being delivered in the next two weeks
• Customer feedback needs to be procured regularly to avoid divergence
• This feedback can quickly influence the incremental plan
• The team members themselves feedback to one another daily
• Provided the right capabilities are in place, self organizing teams work well

The result has been a complete shift in IT practice and process with substantial benefits for all involved. IT professionals can now work in autonomous, largely self-governing teams and influence their own working environment. Customers get much faster delivery of what they really need, albeit in smaller chunks. The quality of what they receive is also much higher. Employers get motivated developers and happy customers. What’s not to like?

Parallels for strategy

Until very recently, strategy has not been viewed as one integrated process. The process of designing the plan has been where the big money (consultants) and intellect have migrated, whereas the execution of that plan has been viewed as largely separate and something done by someone else in the business.

Strategy has also been viewed as a long-term process. Often, practitioners have taken pride in the fact that they have facilitated a ten-year strategy, whereas the guys next door only have a three-year strategy. People have viewed the twenty-year planning horizon of certain organizations with awe. Long term thinking with the use of scenarios is useful, however, long term planning much less so. The disruptive change constantly surrounding us has made these perspectives largely redundant.

In my view, one of the reasons why strategy practice has not evolved as quickly as agile in IT, is that the feedback loop is not that clear. With IT, irritated customers besieged the help desk within minutes of the new product being released. So, feedback was typically instant and direct. With strategy, feedback is required in two areas – whether it actually got done and the “quality” of the strategy i.e. was it effective? In most cases, there tends to be a minimum of a one year gap between the strategy being decided and “implemented” and any feedback. Additionally, the greater complexity of strategy means that a far larger range of factors influences the result. If we add the fact that many organizations don’t have a feedback loop or reporting process designed for determining the effectiveness of their strategy, the extent of the problem becomes clearer. The paucity of feedback and delay in that feedback has resulted in a lack of innovation in the strategy community.

In fairness, it is much easier to achieve agility in a discrete business function such as IT, or increasingly Product Development, even if the employee numbers in these areas might be large than it is to achieve agility for strategy.

Justin McMurray from Made by Many defines agile strategy as: “The ability for companies to stay competitive in their business by adjusting and adapting to new innovative ideas and using these ideas to create new products and services as well as business models.”

If we accept this view as roughly accurate, it’s clear that an agile approach to strategy cannot be achieved without massive changes to most organizations’ current ways of working. Agility is not something that will be achieved within a year – it will be a journey of 5 to 10 years in many cases.

I suggest that rather than setting out on this long-term journey with agile as the endpoint (remember we want to be agile about this), start with the first incremental point. That necessitates an assessment of where your organization is in its Strategy Maturity. This will provide the starting point of the roadmap. Many organizations will find that implementing the basic disciplines around project management and daily problem resolution will be their starting point. Others, further along in their journey, will be looking to implement a formal execution methodology with associated processes and governance. A handful will be looking at how to integrate strategy and execution into a holistic and agile business system.