Doing the Rounds

(This is an old draft article that I rediscovered.)

A while ago, while obtaining my regular fix of Ben Goldacre's pronouncements over at the Bad Science blog, something Ben had had cause briefly to explain lodged into my mind. In a mere couple of sentences, Ben explained what a "grand round" is in the world of medicine. After learning this, I began to be intrigued by the possibility of this idea being appropriated by software development.

So what is a grand round, and what would it be in the context of software development? It is described, in the realm of medicine, by Ben Goldacre as:

"a major event, where the whole hospital comes together to watch one team of doctors present a difficult case, and very frequently, one they haven’t been able to treat, while their colleagues criticise their actions."

It is a regular event, usually held once per week, with a multiple goals: to educate, to inform, and to critique. In doing so, other doctors both learn and keep themselves up-to-date with the latest developments in the wider environment, and the "presenting" doctors gain the benefit of insights from other doctors.

"But obviously it’s squamous cell!"

"Why didn’t you do an MRI?"

The seeking of other people's perspectives has a value in software development already known, but is not often institutionalised. Stuart Wray's article on Pair Programming argues well on how gathering other perspectives while performing your work is a valuable exercise.

It got me to thinking: would a "grand round" be a useful or desirable thing to do in software development organisation? Nerds sitting in a big conference room or auditorium listening to another who has been tortured or intrigued by some problem, just like doctors, except wearing sandals and T-shirts instead of white coats and ties. A good software organisation institutes some kind of regular gathering of developers to discuss problems (daily stand-ups are a good example), but what if banging together several heads doesn't still doesn't solve a problem? The danger is you convince yourself that some hack or sub-optimal solution will have to suffice, but what if there's someone else down the corridor who has a better solution? Presumably, doctors in a similar situation start by asking a small number of colleagues. I guess there's less wiggle room for doctors to be able to just patch up a patient if they find that the answers are unsatisfactory and so they proceed to seek more and more opinions until a grand round is called for.

This also raises for me an interesting question: could such a practice be considered agile? It certainly seems an Extreme idea. After all, if getting a small handful of devs together to chinwag over a problem is good, then regularly getting a whole department together to listen to an important problem is the extreme end on this scale of wisdom. It does seem like an agile idea to me, emphasising the interaction of people, and could also circumvent the inconvenience that agile teams are often small (and thus provide a limited source of ideas) by regularly bringing multiple teams together.

I am not aware of an organisation that does such a thing institutionally (and maybe there's a good reason for that), but I'd be very interested to know if there does exist one.




One thought on “Doing the Rounds

  1. This very much reminds me of some of the organizational knowledge management things I’ve seen at IBM. You were able to poll everyone(!) world-wide logged into an IM tool and ask them a question. Each question would be compared to possible previous Q&A from the pool to make sure you didn’t ask the same thing twice. This attempts to solve the same problem with less cost of a physical presence I think.

    I like the idea of escalating and pulling in more brainpower but I suspect that for many, doing this face to face is not an option. Also, I think this is what many devs use forums for. Sounds to me like Saros should team up with a knowledge management & survey/global poll module that also crawls forums…

Leave a Reply

Your email address will not be published. Required fields are marked *