SCAN as ‘decision-dartboard’

How to use SCAN as a ‘decision-dartboard’ in work-planning? That was probably the highlight in a great conversation outside the IRM-EAC conference in London earlier this week with Kai Schlüter, enterprise-architect at Danish engineering conglomerate Danfoss.

Kai heads up a team of about 30 architects who support some 500 software-developers worldwide. As I mentioned in the summary of his talk at the UnicomEA 2013 conference, he takes agile-development almost to extremes: turnround for most fixups in two hours or less, turnround for business-changes often less than a day. By intent, they don’t use a ‘proper’ repository-based EA toolset: instead, their most important EA tools are the whiteboards in every room.

In short, fast.

But not always – because it can’t always work that way.

Which means that they have to decide – fast – what they can do fast, and what they can’t.

And that’s where SCAN comes into the picture.

In its standard form, SCAN denotes ways of interpreting and deciding within an overall context-space:

We view the context in terms of two dynamic dimensions – sameness versus difference, and time-distance from the moment of action – which in effect gives us four quadrants: Simple, Complicated, Ambiguous, Not-known. Yes, it looks much like the all-too-typical two-axis frame so beloved by so many consultants, but as you’ll see if you work your way back through some of the various posts here on the SCAN framework, there are a whole lot of subtleties and nuances and overlays and suchlike that, in principle, really ought to be taken into account whenever we use the framework.

Me being me, of course, I worry away at all of that detail, finding new layers, new correspondences, new applications. I worry away at getting it right, making it as versatile as possible.

Kai being Kai, of course, he doesn’t waste time on worrying. Instead, he instead strips it right back to the core: “How can I use it for this need, right here, right now? Most of all, how can I use it fast?”

(I’ll have to paraphrase Kai’s description a bit at this point – please correct me if I get it wrong, Kai?)

In his work-planning sessions, he doesn’t use SCAN as a context-space map: instead, he uses it as a kind of ‘decision-dartboard’. He’s partitioned his team’s work-methods in terms of the SCAN quadrants:

• Simple: it’s routine, we know how to do this, just do it
• Complicated: we’ll need to do some analysis first, but it’s within known space, and we can give an exact time-estimate
• Ambiguous: some parts of it aren’t clear, we’ll need to do some experiments, but we’ll deliver something usable within a known-time-box – though it might need another update later
• Not-known: some of it is novel, new, in unknown territory, we can’t guarantee usable results but we’ll see what we can come up with within the set time-frame

And then, as Kai put it, “We throw projects at it, and see where they stick. Thirty projects, and in twenty-five minutes that’s the whole project-plan done.”

Wow! In a word, brilliant. 🙂

Was SCAN designed to work this way, as a simple (some would even say simplistic) categorisation-framework? Definitely not.

Is it appropriate for SCAN to be used in this way? Definitely yes. (Though preferably with a solid understanding of how SCAN ‘should’ be used – which Kai certainly has.)

That’s actually the difference between ‘design-intent’ versus ‘affordance‘: SCAN wasn’t designed to be used in this way, but it affords the possibility of using it that way, in a way that really does work well. So if you know what you’re doing with it, just do it. Kinda simple, really.

I love seeing new stories about how the tools and techniques I’d developed are being used to deliver real results in real-world practice – especially if they’re being used in ways that I didn’t expect. So keep those stories coming, y’hear? 🙂