See also Workshop techniques and Agile Techniques and Consulting Principles.


All types of workshop

  • Five whys
  • Futurespective
  • Value Stream Mapping
  • Lean Value Tree
  • Empathy mapping
  • Stakeholder empathy mapping
  • Event storming
  • Service mapping
  • Wardley mapping:
  • User journey / story mapping
  • The Cynefin Framework
  • Elevator pitch
  • Trade-off sliders
  • Hypothesis Workshops - see notes below
  • Inverse Conway Manoeuvre - see notes below
  • CRC cards
    • blank ("naked") CRC cards
  • Value proposition map / value proposition design
    • Real example here (Clare only)
    • Blank example here
    • Over on the far right you list the things you want to achieve ("jobs to be done")
    • In the same section, you list gains that users might get
    • Under that list things that are currently painful for users
    • On the far left, list features / services in your solution
    • Also list ways in which gains might be achieved ("gain creators)
    • Also list ways in which pains might be alleviated ("pain relievers")
    • Now you want to cross-reference
      • (? I'm not 100% sure I'#ve got this bit right - need to check)
      • for each job, check that it has an associated service / feature
      • for each gain, check that it has an associated gain creator
      • for each pain, check that it has an associated pain reliever
      • for each feature / service, check that it has an associated gain creator or pain reliever
  • Data mapping
    • Real example here(clare only)
    • get people to start by adding postits for sources and destinations of data
    • then add lines to indicate how data moves from one place to another
  • As-is and to-be user journey mapping
    • Real examples here and here (clare only)
    • As-is:
    • put the ultimate goal over on the right
    • add post-its to represent steps along the way
    • have a line underneath that represents whether each step makes happier or sadder
    • Pink post-its underneath document pain points
    • Blue post-its above document possible quick wins that will improve things for the user
    • To-be:
    • Now do the same again but for the suggested improvement journey (or to represent a brand new journey)
  • Storyboarding
    • Real example in this repo
    • Fold paper to create 8 panels, then use them to create a ocmic strip that describes a blue-sky imagined new or improved user journey.
  • Action Learning
  • Lots of consultancy examples
    • (available to Clare only): Until I've processed them, just need to look in this folder and trawl through the presentations: OneDrive\TW-Stuff\Clients\Pitches

Specific types of workshop in more detail

Hypothesis workshops

Notes from Tito's Made Tech talk August 2020 (see also screenshots below):

  • in the context of replacing legacy - the point is that you are revisiting the things your system already does, and asking how probable is it that users will even need some of that stuff
  • The whole team should be involved
  • What is the point of the thing that you are building
  • Put goals on the right - ideally 1 - no more than three - if more split into separate workshops
  • put features on the left
  • write postits between left and right that will lead from the thing on the left to the thing on the right - see image
  • add numbers saying how likely it is that this will happen - see image
  • add colours to show priority - see image.
  • you have to take risks and this enables you to visualise / understand the risk of investment vs return
  • in the context of replacing legacy - the point is that you are revisiting the things your system already does, and asking how probable is it that users will even need some of that stuff
  • every event assumes that every event to the left of it is true
  • you can then prioritise what to focus on based on how likely it is that all the events will happen that you need in order to reach your goal
    • for instance, MHCLG energy certificates, finding a certificate provider, it's unlikely people won't find one by just using google,
    • so there's little point putting tons of effort into improving or reimplementing this legacy product
  • then your hypothesis is that nobody will use this product so don't implement it
    • or it's highly likely that you'll reach your goal by improving / reimplementing this thing, therefore go for it

hypothesis-workshops.png hypothesis-workshops-2.png hypothesis-workshops-3.png

Inverse Conway Manoeuvre

Notes from Tito's Made Tech talk August 2020 (see also screenshots below):

  • Your software systems / components will likely match your org structure
  • Don't fight conway's law - don't reoganise your products in a way that won't match your teans
  • the new structure becomes an emergent pattern of your architecture
  • but don't expect it to work like magic
  • you need strong leaders to manage the fact that there will be a temp velocity slowdown and a bit of chaos

inverse-conway-manoeuvre.png inverse-conway-manoeuvre-2.png

Measures of Success

Measures of success workshop agenda

Role Definition

  • Claire W ran one of these for me and a resident tech lead at Samba. The outcome postits are available (to Clare only) at OneDrive\TW-Stuff\Clients[Samba]]\ClaireW-TechLeadPics-small
  • The structure included the following:
    • Does/Doesn't: Use post-its to define what is and isn't part of the role
    • Value/Effort quadrants: Use quadrants to prioritise the does/doesn't
    • Looking forward (this was done when looking at a role that was already being done, so may not all be needed at the start of a role):
      • Identify key deliverables / objectives and vote on them to decide a priority
      • Identify what support and resources you are already receiving
      • Identify what support and resources you are NOT receiving but do need
      • Identify what support and resources you are currently receiving but do NOT need
    • As you go, identify Actions (and as ever, use a parking lot for things you don't have time to address now)


Office Hours

  • This is a great article suggesting the idea of an "office hours" meetup. The description of a dysfunctional meetup is unfair to most meetups I've ever attended, because they allow time for discussion after each talk and they often use a workshop style rather than a lecture format. But still I like the office-hours idea. For those that haven't come across the concept (I hadn't before I worked with a US-based company), it seems to be something commonly used in US universities, where lecturers will make themselves available at certain times of the day for students to knock on their door and get some one-to-one time.