Why Agile is no more (or less) than a Skunkworks
Agile as skunkworks. This simile struck me quite forcefully the other day, and I have already tweeted to this effect. But the more my subconscious works on it, the more the analogy seems apt. (My apologies if anyone else has already drawn these parallels.)
For those unfamiliar with the term, "skunkworks" is widely used in business, engineering, and technical fields to describe a group within an organisation given a high degree of autonomy and unhampered by bureaucracy, tasked with working on critical, advanced or secret projects.
The correspondences with Agile, and in particular with those Agile Pilot projects so beloved of organisations dipping their toes in agile waters, seem manifest:
So, if you accept these parallels, what's the relevance of the analogy? I believe the relevance lies in the history of skunkworks. Even though some have produced amazing products, like the U-2 spyplane and the later SR-71 Blackbird, few skunkworks have succeeded in exporting their highly-effective ways of working back into their corporate host organisations.
Agile exponents by and large still cling to the forlorn hope that Agile will go mainstream, leach into traditional organisation by osmosis - and the benefits of the Agile approach will be realised by all.
I use the phrase "forlorn hope" advisedly, because if skunkworks have been unable to shift the mindsets of their hosts for fifty years and more, why should we expect Agile to be any different in this regard?
As ever, your comments and conversations will be most welcome.
- Bob
For those unfamiliar with the term, "skunkworks" is widely used in business, engineering, and technical fields to describe a group within an organisation given a high degree of autonomy and unhampered by bureaucracy, tasked with working on critical, advanced or secret projects.
The correspondences with Agile, and in particular with those Agile Pilot projects so beloved of organisations dipping their toes in agile waters, seem manifest:
- Agile projects generally receive dispensations to forego "normal" standards of documentation, project reporting, etc.
- Traditional processes - aka ways of working - cease to be mandatory.
- Agile projects often get to work on something critical to the business.
- Agile projects can freely(?) adopt a different world-view than their parent organisations with respect to hiring practices, treatment of staff, incentives, working hours, dress code, job titles, roles & responsibility, and so on.
- Parent organisations look-on in bewilderment, and sometimes outrage or fright, at the corners that the agile project teams seem to cut, and maybe at their general alien demeanour, too.
So, if you accept these parallels, what's the relevance of the analogy? I believe the relevance lies in the history of skunkworks. Even though some have produced amazing products, like the U-2 spyplane and the later SR-71 Blackbird, few skunkworks have succeeded in exporting their highly-effective ways of working back into their corporate host organisations.
Agile exponents by and large still cling to the forlorn hope that Agile will go mainstream, leach into traditional organisation by osmosis - and the benefits of the Agile approach will be realised by all.
I use the phrase "forlorn hope" advisedly, because if skunkworks have been unable to shift the mindsets of their hosts for fifty years and more, why should we expect Agile to be any different in this regard?
As ever, your comments and conversations will be most welcome.
- Bob
9 Comments
The missing part from your description of the Skunkworks, and the bit that people most often leave out, is the fact that they’re original intention was to act as if competing with the parent organisation.
Most of us claim to welcome criticism, but few of us actually do.
Ta for pitching-in. I share your view that a skunkworks is often an allergic reaction to alien thinking. This is the core proposition of Rightshifting after all: to become significantly more effective, an organisation must change its entire world-view. No surprise then that most organisations can’t bring themselves to do this, yet needing a critical new product or in the face of some other dramatic event, feel driven to setting up a bubble within which weird and wonderful things can happen without infecting their cosy(?) status quo.
I’m not sure that competing with the host organisation is a necessary aspect of a skunkworks. Do you have any references w.r.t. that, that you could post here?
BTW Whence your closing comment about criticism? (i.e. What is your context for that remark?)
- Bob
However, I do think there’s a good deal of literature on intra-firm competition - and there will be inevitable ‘competition’ between skunkworks and the host, if only for attention and resources.
An error on my part. Sorry.
My context for the ‘criticism’ part is from being part of skunkworks-analogues where discoveries and potential innovations were met with hostility, often by the people who had commissioned them. The more one fulfils the brief to break the box, the greater the reactance.
I remember one presentation in particular where I co-presented with a bigwig whose name was on a paper (through droit de seigneur as he hadn’t actually done any of the work). The bigwig, after, talking everybody through the results as if it were his own work then spent the rest of the meeting haranguing me and pulling it apart.
That wasn’t at all clear in my reply.
This post (and comment thread) set me off thinking and I blogged something here:
Sexier Skunkworks - yep, definitely a me-ish title.
It’s long, so here’s the summary:
Those un-agile peckerheads who ruin everything? We need them, but not because they’re right (they’re not).
It’s another piece in my ongoing battle against consistency
Further, I understood The Skunk Works was a deliberate move by Lockheed, at the behest of the US Air Tactical Service Command (ATSC), to respond to the urgent need to counter the threat of the Luftwaffe at the height of WWII. There was an urgent need, potentially critical to survival; a clear vision of the desired outcome (though not of the details of the deliverable product); the vision was shared by the customer, supply-side management, and the developers; responsibility resided jointly in the ATSC & Lockheed senior management, but authority was delegated to the visionary leaders of The Skunk Works; there was a critical deadline (when ‘dead’ meant people would die)… or rather, it was a case of ‘deliver as fast as possible’ because any delay could result in casualties in the field (hence squaddies on the frontlines were in many ways, stakeholders); the developers took responsibility for planning, and were empowered to investigate all solution options, collecting evidence through experimentation and basing decisions on facts. Importantly, the ‘leading coalition’ formed by the ATSC and Lockheed senior management were prepared to remove impediments to foster the success of the critical project.
In many ways, some agile projects do bear some of the hallmarks exhibited by The Sunk Works. But some agile projects don’t.
What I call the ‘agile random walk’ through the user... more
Further, I understood The Skunk Works was a deliberate move by Lockheed, at the behest of the US Air Tactical Service Command (ATSC), to respond to the urgent need to counter the threat of the Luftwaffe at the height of WWII. There was an urgent need, potentially critical to survival; a clear vision of the desired outcome (though not of the details of the deliverable product); the vision was shared by the customer, supply-side management, and the developers; responsibility resided jointly in the ATSC & Lockheed senior management, but authority was delegated to the visionary leaders of The Skunk Works; there was a critical deadline (when ‘dead’ meant people would die)… or rather, it was a case of ‘deliver as fast as possible’ because any delay could result in casualties in the field (hence squaddies on the frontlines were in many ways, stakeholders); the developers took responsibility for planning, and were empowered to investigate all solution options, collecting evidence through experimentation and basing decisions on facts. Importantly, the ‘leading coalition’ formed by the ATSC and Lockheed senior management were prepared to remove impediments to foster the success of the critical project.
In many ways, some agile projects do bear some of the hallmarks exhibited by The Sunk Works. But some agile projects don’t.
What I call the ‘agile random walk’ through the user requirements, picking on some half-formed requirement, delivering something (essentially a partial prototype), learning from the customer via a demo that it doesn’t really fill the bill, then making changes and trying again, through a number of iterations. That’s ‘fix on fail’ …and a far cry from the search for engineering excellence employed at The Skunk Works.
Regarding the ability of a skunk works (or agile project) to permanently change the behaviour and mindset of the host organisation.
I don’t think that was ever the intent of those that established The Skunk Works (although in the long term I think various lessons learned have filtered across from ‘guest’ to ‘host’). The host organisation was much larger and had responsibility for more than one entire end-to-end value stream, turning raw materials, info & effort into flyable, fighting planes (and sustaining the war-fighting machine by providing spare parts). The Skunk Works was pure product development (albeit responding to considerations of manufacturability). I don’t believe The Skunk Works had any ambition or agreed responsibility to ‘convert’ its ‘host’. So I don’t think it tried.
So, I guess I’m agreeing with Bob (and Simon). It is unlikely that ‘just’ running one project, be it critical to survival or not, will be sufficient to start a host organisation on a Rightshifting Journey. The necessary change of mindset and behaviours takes more than the example of a relatively small, segregated, ’secret’, group that is following a different vision, and employing behaviours that are not understood (or even visible to) the majority of managers, employees and customers. Organisational transformation to a more effective future requires a systematic & sustained Rightshifting Journey. Which is not to say that piloting candidate solutions to collect information & experience will not be part of such a journey.
Executives that believe otherwise really are setting up a Forlorn Hope to failure.
Strictly speaking, a Forlorn Hope is the first wave of soldiers attacking a breach in defences during a siege, where the risk of casualties is high. Like that formed by men of the British & Portuguese army led by Generals Craufurd & Picton at the Siege of Badajoz during the Peninsula War. Apparently, it is derived from the Dutch: ‘hope’ equates to ‘hoop’, a heap, not the English word ‘hope’.
The senior commanders, Wellington in the example, expected most members of the forlorn hope to be killed or wounded. The hope was that some would survive long enough to seize a foothold to give a second wave better prospects.
It’s interesting to note that “a forlorn hope was typically led by a junior officer with hopes of personal advancement. If he survived, and performed courageously, he was almost guaranteed both a promotion and a long-term boost to his career prospects” (ref: Wikipedia). So perhaps some advocates of agile methods believe they will be recognised by the organisation that hosts them, and will reward them according to their successes.
However, given the above discussion re: The Skunk Works… IMO it is unlikely that executive management in a traditional hierarchically structured organisation, where command & control and belief in T
However, given the above discussion re: The Skunk Works… IMO it is unlikely that executive management in a traditional hierarchically structured organisation, where command & control and belief in Taylorist principles hold sway, will be likely to recognise the worth of lean/agile practices. Results notwithstanding.
Consider how the senior management of the British Peninsula Army treated the 'jumped-up' from the ranks, Sharpe of the 95th Rifles in the fictional series written by Bernard Cornwell.
So, in conclusion. Organisational transformation of a host firm is unlikely to occur by 'osmosis' of ideas from an 'agile project', whether or not that project is judged to be 'successful'. Such a transformation must take a considerably more systematic and holistic approach.
- Bob
Of course, there is a risk, in talking within a group of like-minded people, of a failure to engage with folk who don’t share our viewpoint or who look at the evidence and reach different conclusions.
Closer to home, I’ve just received an invite from BCS PROMS-G North to attend their “Project & Programme Management Risks School”. You can find details at:
http://www.proms-g.bcs.org/eventbooking/showschool.php?eventid=psg1020
Unfortunately, the introduction starts off thusly:
“Risk is the key difference between Change and Operational Management. Projects have maintained a monotonous ≈70% failure rate for at least four decades, despite improvements in management approaches, largely because the projects have become more ambitious over that period. The school is intended to help practitioners from most change management professional backgrounds learn more about increasing effectiveness in each part of the process, as well as the current and developing standards that apply.”
Now, I don’t know about you, but IMHO, the “monotonous ≈70% failure rate for at least four decades” is not “largely because the projects have become more ambitious” but exactly because of the BDUF, command & control, mass production-oriented, approach adopted by those responsible (and by those advising them). To wit:
“The near-continuous common factor arising from analysis of both failing mission-critical projects or programmes and several contract-dispute expert witness assignments was the lack of realistic control and documen... more
Of course, there is a risk, in talking within a group of like-minded people, of a failure to engage with folk who don’t share our viewpoint or who look at the evidence and reach different conclusions.
Closer to home, I’ve just received an invite from BCS PROMS-G North to attend their “Project & Programme Management Risks School”. You can find details at:
http://www.proms-g.bcs.org/eventbooking/showschool.php?eventid=psg1020
Unfortunately, the introduction starts off thusly:
“Risk is the key difference between Change and Operational Management. Projects have maintained a monotonous ≈70% failure rate for at least four decades, despite improvements in management approaches, largely because the projects have become more ambitious over that period. The school is intended to help practitioners from most change management professional backgrounds learn more about increasing effectiveness in each part of the process, as well as the current and developing standards that apply.”
Now, I don’t know about you, but IMHO, the “monotonous ≈70% failure rate for at least four decades” is not “largely because the projects have become more ambitious” but exactly because of the BDUF, command & control, mass production-oriented, approach adopted by those responsible (and by those advising them). To wit:
“The near-continuous common factor arising from analysis of both failing mission-critical projects or programmes and several contract-dispute expert witness assignments was the lack of realistic control and documentation systems for risks and issues.” Ian Thornton-Bryar (he’s got a super wizzy spreadsheet tool).
“Faced with this uncertainty, we can attempt to predict the factors that can impact on a project. Once we can identify these factors and their possible impacts we can call them risks and attempt to analyse and respond to them. …One common weakness… is the failure to identify the sources of project risk early enough, before the organisation commits resources to the project (appraisal stage).” Professor Elaine Harris (she’s promoting a method called Pragmatix®).
“The central premise will be to set out a very practical and engaging approach on how the risk management process may and should deliver value and stakeholder engagement through effective facilitation.” Dr Penny Pullan (I’m not arguing with the need for facilitation & coaching to engage stakeholders… but she is “a Prince2™ and MSP™ Practitioner and PMP, is Director of Making Projects Work Ltd.”).
“…the speaker will show how [ISO 31000, BS 31100 & IEC/ISO 31010 all titled ‘Risk Management’] may be used in practice to help an organization embrace risk management into the organization’s business management system and provide a framework for taking advantage of opportunities as well as treating negative risks.” David A Smith (He is a much-published author ‘currently co-authoring a book for BSI on the implementation of IS 31000′).
I guess we should regard BCS PROMS-G, its members and all its works, much as a evangelic Darwinist would view the congregation of a Creationist church. “These people truly believe the world operates to a different set of rules than those supported by the facts. They make decisions based on faith, rather than upon the evidence. They do not apply the scientific method, preferring opinion. BUT… they run the town. If we’re going to get anything done, we have to convert them, subvert them, join them, or remove them.”
Actually, that’s part of the problem in Rightshifting Effectiveness. It requires people and organisations to change their mindset. And that is not easy.
Leave a comment