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? 🙂
Despite some inaccuracy in the numbers quite accurate how we use it.
To sort the numbers for you:
1) Roughly 30 Architects (bit more at the moment)
2) Roughly 500 People in IT (+ externals, so 500 Developers might be true, or not, we do not know exact)
3) 85% of all severity 1 defects recognize-to-fix < 2 hours
4) Daily Delivery to Production (that is not necessarily one day from Idea-to-Production
5) best case was 25 potential projects in 30 minutes. 🙂
The 3 ways to use the delivery darting (some are projects, but not all):
1) we use EPIC SCAN to understand why we are where we are. So very literally the EPIC of how we got where we are.
2) we use WISE SCAN to understand where we want to go. So very literally if it is WISE to go where we thing we should go.
3) we use PACE SCAN to understand at what speed we can change. So very literally what is the PACE to change.
The process is simple:
gather a group of clever people (Architects in our case) and let them play a variant of Planning Poker till there is agreement on one Architecture Item SCAN value (consensus on S, C, A or N) and then move to the next.
Tools we use for it: Whiteboard, Excel and SharePoint (in that order).
Many thanks for the update and corrections, Kai – really does help. (I’m glad to know I didn’t get it too badly wrong… 🙂 )
Likewise thanks for the links to your EPIC SCAN, WISE SCAN and PACE SCAN – all really useful extensions to the original idea. That kind of extension really helps, both in getting the ideas out there, and also in making them more usable for real-world practice.
And finally, thanks again for a great conversation! 🙂
Tom / Kai
If a simple and straightforward project is transforming a capability which is also being transformed as a result of an ambiguous project would you transpose the simple and straightforward project to not-known until clarity is received? or would you continue with the project and utilise the solution as input into the not-known classification.
Thank you both for an interesting perspective.