Playing To Win
Playing to Win & Agile
How to Make the Most of the Combination
I am frequently asked a consistent genre of question: How, if at all, does concept x or framework y fit with Playing to Win. For instance, how about Integrative Thinking, Design Thinking, Pay for Performance or Agile? I have already written on the first three in the Playing to Win/Practitioner Insights (PTW/PI) series. So, I have decided to make my 38th PTW/PI on Playing to Win & Agile. (Links for the rest of the PTW/PI series can be found here.)
What is Agile?
For the those who aren’t already aficionados, Agile is software development doctrine that dates from the release of The Agile Manifesto in 2001. The Manifesto espouses four values:
1) Individuals and interactions > processes and tools
2) Working software > comprehensive documentation
3) Customer collaboration > contract negotiation
4) Responding to change > following a plan
These in turn are reflected in the 12 Principles of Agile pictured above.
Agile was a reaction to the standard ‘waterfall’ approach to software development at the time. The Agile founders saw waterfall as an unhelpfully linear, inflexible, and internally centered way to develop software, and in response developed an iterative, flexible and user centered alternative.
As is evident from the wording of the Principles, Agile was an approach targeted specifically at software development (i.e., #1, #3 and #7 all mention software specifically). However, in large part through the work of the Scrum Alliance, the Agile approach has been applied more generally to project management of all sorts.
Sometimes Frosty
Sometimes Agile enthusiasts can be quite frosty about strategy. To some Agile/Scrum folks, strategy is representative of the great enemy, waterfall, which Agile seeks to slay. I must say, their concerns are not entirely misplaced. They focus on software development’s analog, which is strategic plan development. Their criticism is consistent with my criticism of most strategic planning as too linear, too process focused, too internally oriented, and too impervious to adjustments as learning occurs along the way. So, I understand the frostiness: it is largely deserved by the standard approach to strategic plan development. I argue for a very different approach to strategy across this Playing to Win/Practitioner Insights series. But it is not the normal practice, so the Agile frostiness is understandable.
My Frostiness
But I have my own frostiness when it comes to Agile and strategy. The Agile aficionados who see Scrum/Agile as a broadly applicable project management tool can wander into the territory of viewing Agile as a de facto strategy development process. That is, great strategy will emerge naturally if you simply listen to customers, expose them frequently to iterations of the offering, adjust repeatedly to take account of new learning from the client, and work in well-functioning, face-to-face teams.
That is where I part company, as I also do with many of the Design Thinking folks. No amount of listening to customers, short cycle iteration, self-organization/emergence, face-to-face working teams, and reflectiveness is, on its own, going to produce a robust strategy. That is despite my belief that strategy does have to start with customers, and that I am a fan of iterative prototyping and flexible processes that change with new information. But even with those things, you ignore the principles of strategy at your peril.
All those features are positive contributors to a better rather than worse strategy. But strategy requires understanding of the economic viability of your choice and the sustainability of advantage relative to current and potential competitors. I have seen far too many of both user-centered Design Thinking processes and Agile processes that have no concept of economic viability or sustainability relative to competitors, despite producing products/services or software that users like. Good strategies are always a subset of the range of possibilities that would make users happy. The ones you want are those that make users deliriously happy in a way by which you can deliver distinctively.
The fundamental strategy limitation of Agile is that the opposites of its basic premises are stupid on their face. (And the same holds as well for Design Thinking.) The core rule of strategy is that if the opposite of your choice is stupid on its face, it isn’t a strategic choice. Not listening to customers is stupid on its face. Not changing when change is required is stupid in its face.
If the opposite is stupid on its face, in due course everyone will do the smart thing. Reputedly, 90% of the Fortune 500 uses an SAP Enterprise Resource Planning (ERP) system. It has come to the point whereby not having an ERP system is stupid on its face. Having one is not a competitive advantage — since 90% of your competitors are likely to have one. It is just dumb not to do it. That is the trouble with winning. When a choice becomes obvious and it is doable for everyone, everyone does it. In contrast, strategy is the act of making choices whereby the opposite is not stupid on its face. That is what can lead to distinctive advantage.
I assume that in some industries, no competitor is doing Agile and by being Agile, you will have obvious advantage because everyone else is inflexibly ignoring the customer. So, do it while it lasts. But that is not the long-term answer.
The Long-Term Answer
The long-term answer is to combine the principles of Agile and Playing to Win. It is to do strategy in an Agile way. Start with the customer. But don’t just aim to serve the customer. Aim to do so in a way that enables you to be distinctive. Iterate with different ideas and approaches as you learn new things from the customer’s experiences with your prototypes. Keep working and working to build a unique solution that creates economics that work for your model and is difficult for competitors (existing or potential) to follow. If it is an idea that customers love — ordering pet food online — great, but you have to be able to make a case for why twenty other sites won’t pop up to sell pet food online (and they did!) in order for your customer insights to generate a useful economic model. Don’t assume that being Agile (or using Design Thinking) alone will provide you a competitive advantage that is worth having because it most likely won’t!
Practitioner Insights
If you are an Agile (and/or Scrum) aficionado, I encourage you to use the Agile Principles to enhance the customer-centric, iterative, and flexible nature of your strategy development. By doing so, you can make strategy development much more effective. However, be very careful to avoid getting seduced by the idea that meeting a newly discovered customer need will provide you with competitive advantage. It only will if you can build Must-Have Capabilities and Enabling Management Systems that competitors either can’t or won’t replicate. A strategy that doesn’t pass the can’t/won’t test isn’t really a strategy at all.
If you are a Playing to Win aficionado, pay attention to how to integrate the most valuable aspects of Agile into your strategy development process. Agile features including customer focus, responsiveness to changing findings and needs, iteration, business and technology people working together in a collaborative and sustainable manner, all contribute to better strategy development. Any strategy aficionado would be remiss in not taking advantage of applying these insights from the world of Agile to strategy development.
In the end it is a classic situation in which the right choice is to get the best of both rather than accepting a false choice of either being Agile or doing strategy. The answer is to integrate both for a superior outcome.
