Metaphor isn’t a new thing in the world of software development. As I’ve been increasingly working with Agile coaches in the last couple of years, I’ve been hearing about Agile’s precursor, XP – Extreme Programming, and how “it used to use metaphor, but people didn’t understand it so they dropped it”.

Agilists love Clean Language.

They like that it provides a specific “how to” system for developing understanding. It can help people to understand themselves more deeply, to understand other people more clearly, and (perhaps most importantly) to feel that you understand them, quite profoundly. That’s useful within teams, and beyond teams – for example, in scoping a project, developing user requirements, or convincing management to fund a project.

They like how it helps them to maintain a “coaching stance” when they are tempted to get drawn into the detail.

They love Caitlin Walker’s Clean Feedback Model, and the insights it adds to their existing tools such as Non-Violent Communication.

But the metaphor part of Clean Language? Mostly, Agilists can take it or leave it. And since I think metaphor is one of the highest-value parts of the Clean toolkit, and what makes it unique, that made me curious. What was going on? What happened with XP and metaphor? And could Clean Language help to reintroduce the power of metaphor to this influential community?

The idea in XP, as I understand it, was that every software development project should have a “System Metaphor” to provide a means of communicating about the project in terms that both developers and customers will understand. The system metaphor would guide the mental models that project members have of the system, and shape a logical architecture for the system. But people didn’t get it. Specifically, they didn’t understand where a system metaphor should come from.

They knew a “good metaphor” when they heard one. When they were told that the system was like an assembly line or a bee hive they got the idea. It encapsulated how different elements of the system related to each other, it provided names for the various parts, it provided developers with an overarching “theory” about the system, and it helped people to explain what they were working on to their mothers.  But they didn’t know how to generate a system metaphor.

Now, I don’t know much about software development, but from years of using Clean Language, I do know how to help someone to generate a metaphor for something.

Here’s the drill:

  1. Start by getting the person thinking about the thing, noticing and talking about its features. Encourage them not to judge, just to notice.
  2. Probe a bit deeper, getting them to notice the things they didn’t know they knew about the thing.
  3. Once they are “treating their imaginary friend as real”, and perhaps starting to gesture vigorously, notice the metaphors they are already using to talk about the thing. The chances are that it’s already like… something.
  4. If they are using a metaphor at this point, play it back to them in your Clean Language questions so that they start to notice it, validate it and expand on it.
  5. If they don’t seem to be using metaphorical words, ask for a metaphor, using the features of what they’ve been talking about. “And that’s <feature> and <feature> and <feature> like… what?”
  6. Once you have a metaphor, stick with your non-judgemental attitude and help them to develop it using Clean Language questions.
  7. Before closing the conversation, invite them to draw a picture or diagram of what they know now.

Thinking this through, it strikes me that there are a few common patterns of behaviour that will have been making this harder than it needs to be.

  • Judging suggested metaphors against an impossibly high standard. All metaphors are imperfect representations: that’s their nature.
  • Trying to get universal agreement. Metaphors are deeply personal, because they represent a person’s unconscious thoughts. So we won’t all agree.
  • Seeking “right first time”. Metaphors don’t spring off the tongue fully-formed: that’s why we use Clean Language questions to develop them.
  • Missing the obvious. Metaphors are so common in our language – six per minute – that it’s easy to miss them when they arise spontaneously.

So, bearing all this in mind, could you develop a system metaphor for something you’re working on? I’d love to hear what happens next! Please comment below.




    2 replies to "How To Use Clean Language To Develop A System Metaphor"

    • Andrea Chiou

      Hi Judy,

      Spot on. What I would add to this is the ‘effect’ that doing such exercises has – not just from doing it for ‘systems’ as was somewhat the scope of XP, but for just about anything.

      Even for systems, given that the ‘mission’ or ‘vision’ of a project is usually handed to a team, having the team take ownership of the internal design vision and communicate it out would give them so much 1.) creativity 2.) internal team understanding 3.) clarity about where they are headed and 4.) a vehicle for communicating outward. The vision for example of the internal structures, interfaces, the ‘ilities’ of the system – now represented in metaphor(s) would be a great way to communicate across the cultural chasms (business-developer, developer-ops, product-owner-developer, manager-developer, UX-developer, sales-stakeholders and so on). And there is one company that does just this to great effect – granted a small company.

      Here is a link to a video that will bring this home a bit for those who are still curious..

    • Ray Whiting

      Wow, I never knew that XP used metaphor like that! I’ve only read about the coding techniques that it advocated! Loved seeing that old video of Caitlin too, thanks for posting Judy and Andrea.

Leave a Reply

Your email address will not be published.