There is an interesting piece in the latest issue of the MIT Sloan Review entitled: Should you build strategy like you build software?
I can imagine some managers initial reaction: What? IT is such a total disaster why would we want to make strategy the same way?
After all, we are regularly told that 70% of IT projects fail, and a few months ago the same journal ran a piece damning software development and specifically ERP systems: The Trouble with Enterprise Software
So why would anyone want to copy what IT does?
Well, believe it or not there is something interesting what the author, Keith R. McFarland is arguing is: many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.
To some degree I think he’s a little behind the curve. The myth about long range / strategic planning in companies was exploded a long time ago. Sure some companies still do it but that doesn’t mean it works. Henry Minztberg’s Rise and Fall of Strategic Planning explains why it just doesn’t work and why its a myth.
It is not only software development were managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.
Big strategic planning has been out of fashion for a while but its far from clear what should replace it. McFarland seems to be suggesting the answer is Agile Strategy.
There is an irony in McFarland’s work – and that of Donald Sull at LBS - is that while businesses thinkers, and some businesses, are looking to Agile Software Development for a paradigm of devising strategy too many businesses are still resisting Agile development or finding it impossible to implement.
Agile development is still largely a bottom-up change exercise. Not enough senior managers are embracing and backing Agile, they cling to the illusion of control. Too many people still say ‘Agile is unproven’. The fact that McFarland and Sull are prepared to embrace these ideas for strategy formation shows that Agile ideas are valid.
Regular readers will know that I have been arguing that there are close parallels between business strategy and software development for some years now. This argument is embedded throughout Changing Software Development. It is most clearly seen in the early chapters were I discuss the knowledge and learning aspects of development work. (The argument is also embedded in my MBA Dissertation “Software Development as Organizational Learning” if you want a less polished - more academic - version.)
And I have written in Overload about it – An Alternative view of design (and planning).
Most directly I’ve blogged about it on and off, specifically last August
Agile software and strategy and Thoughts on strategy and software development.
But this is more than just a parallel: for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes image software code as liquid strategy.
There are two forces at work here. Firstly, as much IT - including software - becomes commoditised (Nicholas Carrs argument) what remains is strategic. Your Word Processor is a commodity, but your inventory management system is strategic. if you inventory management system is a commodity then your customer management system is strategic, and so on. Because IT is so varied, and software so capable - limited by your imagination - it is used to embed our knowledge.
Which is our second force: what we know. We embed our knowledge in our code so our organisations can operate: whether it is the Galileo booking system, Google’s Adwords or Unilever’s ERP system the capabilities and limitations of our IT systems are also the capabilities and limitations of our organizations.
As Cynthia Rettig argued in her Sloan Review piece, the limitations imposed by an ERP system impose costs on organization and limits on what they can do. That in turn limits on strategy options.
At the same time software systems open up opportunities and create strategy options for companies. We see this most directly with companies like Microsoft and Amazon but it is also true of companies we might not expect. Companies like FedEx depend on software in order to be able to execute strategies like delivering packages on time.
Banks are on the cutting edge of this convergence, unfortunately that doesn’t mean they do it well, but they are converging. Go to the financial centre of London or New York and you’ll probably find more software developers than investment bankers. Trading derivatives, managing risk and countless other banking activities would be impossible today without the sofwtare.
So where does this leave us?
Companies which embrace Agile in software development can learn a new way of working which will help them elsewhere – specifically in strategy formation
Companies which embrace Agile will be better positioned to as software and strategy converge
No company has to embrace Agile, you can do it the old fashioned – see IT as a cost outsource it, run it like a train timetable. But those companies who embrace Agile will win. The more you embrace it the more you win.
I can imagine some managers initial reaction: What? IT is such a total disaster why would we want to make strategy the same way?
After all, we are regularly told that 70% of IT projects fail, and a few months ago the same journal ran a piece damning software development and specifically ERP systems: The Trouble with Enterprise Software
So why would anyone want to copy what IT does?
Well, believe it or not there is something interesting what the author, Keith R. McFarland is arguing is: many of the practices and techniques used in Agile software development can be applied to strategy formation and execution. McFarland focus on techniques such as small iterations, collective ownership, overlapping phases, direction changes (i.e. refactoring), organising around people not tools and abolishing big up front design.
To some degree I think he’s a little behind the curve. The myth about long range / strategic planning in companies was exploded a long time ago. Sure some companies still do it but that doesn’t mean it works. Henry Minztberg’s Rise and Fall of Strategic Planning explains why it just doesn’t work and why its a myth.
It is not only software development were managers and companies have suffered from the Illusion of Control it occurs in strategy formation and planning. Strategy formation is an emergent process, in the same way that software design is emergent.
Big strategic planning has been out of fashion for a while but its far from clear what should replace it. McFarland seems to be suggesting the answer is Agile Strategy.
There is an irony in McFarland’s work – and that of Donald Sull at LBS - is that while businesses thinkers, and some businesses, are looking to Agile Software Development for a paradigm of devising strategy too many businesses are still resisting Agile development or finding it impossible to implement.
Agile development is still largely a bottom-up change exercise. Not enough senior managers are embracing and backing Agile, they cling to the illusion of control. Too many people still say ‘Agile is unproven’. The fact that McFarland and Sull are prepared to embrace these ideas for strategy formation shows that Agile ideas are valid.
Regular readers will know that I have been arguing that there are close parallels between business strategy and software development for some years now. This argument is embedded throughout Changing Software Development. It is most clearly seen in the early chapters were I discuss the knowledge and learning aspects of development work. (The argument is also embedded in my MBA Dissertation “Software Development as Organizational Learning” if you want a less polished - more academic - version.)
And I have written in Overload about it – An Alternative view of design (and planning).
Most directly I’ve blogged about it on and off, specifically last August
Agile software and strategy and Thoughts on strategy and software development.
But this is more than just a parallel: for companies which use a lot of technology software and strategy are increasingly converging. Ultimately your software is your strategy – so much so that I sometimes image software code as liquid strategy.
There are two forces at work here. Firstly, as much IT - including software - becomes commoditised (Nicholas Carrs argument) what remains is strategic. Your Word Processor is a commodity, but your inventory management system is strategic. if you inventory management system is a commodity then your customer management system is strategic, and so on. Because IT is so varied, and software so capable - limited by your imagination - it is used to embed our knowledge.
Which is our second force: what we know. We embed our knowledge in our code so our organisations can operate: whether it is the Galileo booking system, Google’s Adwords or Unilever’s ERP system the capabilities and limitations of our IT systems are also the capabilities and limitations of our organizations.
As Cynthia Rettig argued in her Sloan Review piece, the limitations imposed by an ERP system impose costs on organization and limits on what they can do. That in turn limits on strategy options.
At the same time software systems open up opportunities and create strategy options for companies. We see this most directly with companies like Microsoft and Amazon but it is also true of companies we might not expect. Companies like FedEx depend on software in order to be able to execute strategies like delivering packages on time.
Banks are on the cutting edge of this convergence, unfortunately that doesn’t mean they do it well, but they are converging. Go to the financial centre of London or New York and you’ll probably find more software developers than investment bankers. Trading derivatives, managing risk and countless other banking activities would be impossible today without the sofwtare.
So where does this leave us?
Companies which embrace Agile in software development can learn a new way of working which will help them elsewhere – specifically in strategy formation
Companies which embrace Agile will be better positioned to as software and strategy converge
No company has to embrace Agile, you can do it the old fashioned – see IT as a cost outsource it, run it like a train timetable. But those companies who embrace Agile will win. The more you embrace it the more you win.
Allan, while I agree with your post on many points, I strongly disagree with its conclusion because you're essentially not answering your own question. Start with the premise that (a) agile = good (b) control = bad. In their pure form, both are useless. There is just about as much bad to say about overzealous XP as about overzealous CMM. It is obviously the balance that makes things helpful.
ReplyDeleteFor example, TDD is a form of control, but nobody in the agile world would bicker about it. Yet, planning for some reason carries a foul stench, even though aimless hacking doesn't really quite help anybody. I have not yet seen a serious debate in the developer world about what the role of management should be, other than getting out of the way and covering their backs. When it comes to accountability, it's all the customer's fault because they gave them the user stories. Nice. Handy. What ever became of professional responsibility?
I think agile people are fooling themselves if they think they can ignore organization at will. Alistair Cockburn understands that. Everyone who tells you different is trying to sell you something. What would be required is a serious attempt of the developer world to try to understand what managers really do. Many were once developers (like myself), but only a tiny fraction of developers were once managers. Who's better equipped to lecture the other side?
I can't prove this, but I have a theory: developers don't "get" management.