I also believe that many of the techniques used in software design and strategy formation can be successfully applied to both domains. Both domains can learn from the other.
And, to top it all, because so much business strategy is implemented through software I see software execution as a continuation of the strategy process.
Consequently I’m always on the look out for evidence to support this theory. This month I thought I had found some more evidence. An article in this months issue of the MIT Sloan Management Review entitled Closing the Gap Between Strategy and Execution by Donald Sull seems to support my case. In fact it seems the article has discovered many of the practices of Agile software development in the strategy formation and execution process, e.g.
- Use of iterations: plan some, do some, assess and re-plan;
- Use of commitment, or promises, over estimation
- A reflection process that sounds a lot like the Retrospectives we practice in software development.
So was this the missing link?
Unfortunately not, in this case it is hard to disentangle cause and effect. First of all you have to go back to the roots of the Agile software movement...
Agile development has its root in the Lean manufacturing movement, and in the “Quality if Free” ethos, and in business strategy itself.
The term Agile itself comes from the business domain, tracing backwards – and I haven’t tried very hard – the first reference I know about comes from Alistair Cockburn (Agile Software Development, 2002) who cites Goldman (Agile Competitors and Virtual Organizations, 1995).
Sometime in the 1990’s the idea of ‘Business Agility’ arose. This raises its head from time to time in business literature but only in software development does – as far as I know – it seem to have taken off. (I have a theory or two here and I’ll explore them in a future blog if I get the time.)
So this article builds on research into software development processes which are themselves in partly the result of reading the business literature. You see why I say cause and effect are hard to untangle?
In writing this blog I’ve looked up the Donald Sull’s web site and discovered a lots of mentions of “Strategic agility” and it seems he teaches a course on this at LBS. Which goes to prove that business Agility is alive and well and prospering in at least one business school.
Unfortunately the business agility community and the agile software community do not seem to have much cross over. This is where Sull’s article in the Sloan Review is interesting because he does mention software development. However he doesn’t mention Agile software development, neither does he fully reference the agile software development literature.
Sull cites Scrum as an example of how strategy formation might work, and how the “new rules” of strategy formation might be used. However, given that Scrum is Agile, and Agile has its roots in business is this reference circular?
To be honest, I think Sull has missed some points. As I just said I think he could have referenced the software development literature he cites, for an academic that strikes me as a little sloppy.
Secondly he proposes a strategy formation cycle of four steps: Make sense, Make choices, Make things happen and Make revisions. To me that looks a lot like Deming’s Plan, Do, Check, Act (PDCA) cycle.
I’m probably being picky here. The MIT Sloan Review is towards the popularist end of academic journals. It tries to contain articles that managers might actually read. Had Sull given us the full academic treatment (and he may well have done so elsewhere) the thing would be read a lot less.
So, where does all this leave us?
Well I take it as good news. Someone else is finding links between software development and business strategy, specifically in the Agile field of both subjects. This can only be good news if it brings the two domains a little closer. And personally I think this further validates my theory.
This may also show that the software development community are at the cutting edge of understanding how you actually go about doing agile anything. It is one thing to talk about an Agile strategy but how do you execute one? What do you actually do?