Agile as… Surgery

I think it’s safe to say that I’ve had a few unusual experiences in my life. I’ve never hiked to Machu Pichu or surfed down the Congo, skydived onto Mount Everest or prepared and eaten my own puffer fish. But I did have a job once where it was quite normal for someone to turn to you, hand you a human leg, and say ‘Get rid of that’.

No, I wasn’t working as an extra in Looper or spending my gap year with one of the more painstaking mafia families. I was a technician in an operating theatre. My job was to keep the place totally aseptic, look after the equipment (including some pretty weird stuff), keep drugs and gases in stock and, occasionally, assist in surgery. So half-a-dozen times in the three years I was doing the job I’d find myself walking around with a detached human limb in my hands and thinking ‘Surely that’s not right?’


All my jobs after that were pretty mundane. I picked oranges for a while, and once fell right through a lemon tree. Did you know lemon trees have extremely sharp, 4 cm-long spines? No, me neither till that moment. But after that it was just office office office. That was when I started work in IT – in the good old days of waterfall.

Did I just say ‘good old days of waterfall’? In a blog about Agile? Perhaps not. Though I suspect I’ve always had more sympathy for waterfall than the average Agilist – if there was ever a tool that suffered from not being used properly, it was waterfall. But even if it had been used well, it really wouldn’t have been able to compete.

But what has surgery got to do with Agile? Quite a lot actually. Why is an operating theatre different from an office? Both are supposed to work smoothly, which means good organisation, staff, tools, process, leadership – all the usual things that make up good practice at work. But what makes an operating theatre different is that, while an office needs to get things right in time for the next meeting, the next milestone, the report, an operating theatre needs to be right now. At almost any moment in an operating theatre, something could happen that will have serious, perhaps even catastrophic effects. Reputations, careers and business plans die in badly run offices. People die in badly run operating theatres.

In that respect, of course, it’s wildly over-dramatic to compare Agile with surgery. No one ever died because a webpage wasn’t updated correctly or a new app missed its deadline. The operating theatre is a world controlled by standards such as ‘The team will recognize and effectively prepare for life-threatening loss of airway or respiratory function’, ‘The team will recognize and effectively prepare for risk of high blood loss’ and even ‘The team will prevent inadvertent retention of instruments and sponges in surgical wounds’ (WHO Guidelines for Safe Surgery 2009). And yes, I have seen the consequences of such standards not being applied – it’s not quite the sort of thing you get over by having a bit of a rant during the next Retrospective. But Agile does share the same commitment to being always right, all the time. That’s Agile’s trademark: not just an astonishing intensity and pace but also the way everything that might hinder delivery of exactly what the user needs in the shortest possible time is eliminated as quickly as possible.

For example, several of the standard Agile ceremonies include an element of continuous improvement. Daily Stand-Up Meetings are constantly probing for obstacles to the day’s work; Backlog Refinements reviews are constantly trying to optimise the delivery of value; Retrospectives specifically prompt the team for opportunities to remove problems, learn lessons and build always-better methods, tools and techniques. Only Showcases aren’t quite so focused on perfecting the team, and even then relevant feedback will be scrutinised and acted upon.

It’s not just the ceremonies either. Key Agile techniques such as refactoring and actively managing technical debt do a very similar job, but focused on the product and software themselves. But most of all, the entire culture of Agile aims at constantly seeking out opportunities to always have exactly the right methods, tools and techniques in action. It’s everyone’s job to:

  • Identify problems with and ways of building on the team’s ways of working.
  • Suggest fixes and opportunities to overcome these problems.
  • Make them work.

In other words, practically everything about Agile is designed to keep the scalpels, forceps and proctoscopes (don’t ask) in a state not only of optimal readiness but also of constantly enhanced design.

Which is just as well, because Agile delivery, like surgery, relies absolutely on the smooth running and exact performance of dozens of well-oiled parts. If the scalpel blade is contaminated or a clamp fails, if the surgeon’s assistant misses their count and a single swab is left inside, the results can be dire. If, on the other hand, surgery proceeds as planned, the results can be life-changing – or life-saving.

Again, nothing an Agile team delivers is likely to be anywhere near as valuable (on a human scale) as even quite minor surgery. If you doubt that, I suggest you try a few days with a grumbling appendix. But from the organisation’s point of view, its impact can still be pretty startling.

Compare this with waterfall and an ordinary office that carries out some sort of BAU admin process. I’ve worked in a few of those too, and professionally evaluated many more. Days pass, stuff gets done, but there’s little sense of movement or achievement. Because the next real test of most office work – and of waterfall programmes too – is so far off (right up to the moment when suddenly – gulp – it isn’t) that everything tends to dissolve into a rather grey atmosphere of routine, with nothing like the urgency and drive Agile engenders.

Sounds grim. And the very opposite of Agile. And, in my experience, it’s both.

And to make things just that bit worse, no matter how you may feel about all this mundane routine, as often as not there’s nothing you can do to change it. You don’t own the process. Maybe in a corporate environment, neither does your boss, or your boss’s boss, and neither you nor they have any idea who does.

Even if you do find out who owns a given process or system, quite often the answer turns out to be ‘no one’. Or if it’s a real person, you probably can’t get much (or anything) done about it, because:

  • ‘Ownership’ turns out to be a pure formality. The ‘owner’ doesn’t have any actual responsibilities for the process’s on-going value or performance.
  • Or maybe there’s no regular management cycle that checks how well they’re doing, or drives improvement if the answer is ‘Not well enough’. And without that, no change request you raise is ever going to rise above #29 on the nominal owner’s to-do list.
  • And even if there is such a management cycle, often they don’t have the skill, budget or resources to make the change.

So which do you prefer? A day at the bureaucratic coalface or a day in the operating theatre? For a sense of achievement or effectiveness or professionalism and just plain fun, I can tell you which I preferred.

I used to work in an operating theatre. Now I work in an Agile environment. So once more I know that delivery really is down to me, and I really need to get on with it right now. So in a peculiar way, Agile has brought me back around to the beginning again.

Not that Agile was ever going to get me to where I really wanted to be. For reasons that escape me, I never quite made it as a Rock God, and, even more importantly, I never played for Liverpool Football Club. Which I can only attribute to a) blind prejudice, b) dark forces, or c) not being very good at football.


About the Author:

Chief Architect,

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.