Heuristics for Building the Right Thing

On Monday I had the privilege of spending the day with some really smart people. Organised by Gojko Adjic, other attendees included Chris Matts, Henrik Kniberg, Mary and Tom Poppendieck, Gabby Benefield, Jeff Patton, Aaron Sanders and Olaf Lewitz.

The theme of the day was exploring how we can help organisations not just build the “thing right”, but build the “right thing”. We spent the morning sharing and exploring the various techniques we used, such as Story Mapping, Impact Mapping, Effect Mapping, Feature Injection, Real Options and Lean Canvas. We then moved onto more general discussion on the problem we are trying solve, before focussing back in on putting something together to try and articulate the commonalities we had found and create a platform to continue the conversation and try and make an impact ourselves.

Henrik has already blogged one statement summarising our conclusions.

Great results happen when:

  • People know why they are doing the work
  • Organisations focus on outcomes and impacts rather than features
  • Teams decide what to do next based on immediate and dircet feedback from the use of their work
  • Everyone cares

Another output was what I called “Heuristics for Building the Right Thing”. I mentioned heuristics in relation to Kanban Thinking, and again, the goal was to provide enough guidance for people to learn, without constraining to specific solutions or techniques. We started by brainstorming ideas and then grouped those into 5 themes, before putting some action-focussed words describe the themes. We noticed that there was a general feedback loop that the heuristics formed, and that there was a missing heuristic that was central to everything. Thus we ended up with:

  • Understand your customer
  • Be Comfortable with Ambiguity
  • Co-Create
  • Learn Fast
  • Make an Impact
  • Make it Visible

IMG_1222 IMG_1221

5 Comments

  1. […] Karl Scotland – Heuristics for building the Right Thing […]

  2. Hi Karl,

    Sounds like you guys had a great day on Monday – I would have liked to be a fly on the wall!

    I am sold on the idea of the focus shifting from building the thing right to building the right thing & have been for a few years (this is not to say we stop trying to build the thing right)

    I have a question regarding the “be comfortable with ambiguity” heuristic.

    I am familiar with the concept of heuristics & I am comfortable with ambiguity up to a certain point in relation to limited up front analysis, but doesn’t the ambiguity need to be eventually driven out to try & ensure we build the right thing (right)?

    For me, this driving out the ambiguity happens when the Programmer, Tester & Business Stakeholder (the closest I can get to a Customer) pick up a (smallish) piece of work to develop it.

    Also during development further ambiguity is driven out as we demo the work to the Business Stakeholder to ensure it is what they are expecting (this appears to be similar to “focusing to much on features” from your diagram…)

    I’d really appreciate your feedback on this.

    Thanks in advance,

    Duncan

    1. Hi Duncan,

      Yes, I agree. I probably need to spend more time explaining this in more detail!

      The feedback loop emerged because we realised that we deal with the ambiguity by getting together to “co-create” something, in order to “learn fast” about whether we did “make an impact”. That will inevitably lead us back to further “understand the customer” and more “ambiguity”. However, each time round the loop with will probably reduce the overall ambiguity slightly as we hone in on the “right thing”.

      Does that help?

      Karl

  3. Thanks for that Karl, greatly appreciated.

    It appears that driving out ambiguity isn’t a phase in itself, more that it is ongoing throughout the cycle.

    Also, I guess that whilst you are creating you are questioning what you are creating as well – this will help ensure building the right thing.

    I’m looking forward to seeing how this develops – thanks again Karl.

    Duncan

Comments are closed.