Interactive Human Spectrogram

It’s true – everybody has an opinion! Big ones, little ones, difficult ones, simple ones, lonely ones and herd ones. So how do you facilitate an agile team to share differing opinions, constructively discuss options, and gain insight into each others opinions? Agile Team Facilitators use real live human interactive experiences to facilitate discussion dives, build team repore and allow product decision making.

The Interactive Human Spectrogram is most definitely a long name for a group excercise that basically gets people to stand where there mouth is!

Prepare your Session!

You will need;

  • some space enough for your team,
  • masking tape for the spectrogram index,
  • markers to show the spectrum values
  • position statements for discussion
  • spectrum values

Optional support equipment;

  • statement crowdsourcing technique
  • discussion kanban
  • behaviour guide toys

Set your space up

  • place the tape along the floor; consider the number of people attending and number of values on the spectrum
  • mark down the values you wish to have people allign to; for example
    • strongly disagree – disagree – agree – strongly agree
    • 0 – 10
    • consider metaphor characters; olympic medals – gold, silver, bronze, or movie characters –  padawan (for newbie learner) to jedi knight (for experienced master)
      • creative metaphors help attendees to shift from their ‘stagnant mindset’ to a more creative responsive mindset – leverage these easy tools to help build the energy and collaboration you’d like

Run your session!

  1. Introduce the Session by framing the basics
    • This an interactive spectrum
    • We’ll choose the next statement & you will be asked to step to the value on the spectrum that best represents your position

A couple of free facilitation guides

And resources from the web…

Human Spectagram


Constellation Activity



Facilitation Workshops

Seeing a Balanced View Retrospective

This Retrospective technique is focused on visualising individual votes, opinions or feelings. By using a simple visual metaphor of a see-saw you can capture the essence of the teams position and quickly highlight weather things are out out of balance or weighted evenly.


I recommend creating your own labels for a couple of reasons. Firstly, it’s good to identify what problem you need solved, and use the most appropriate language to help that diagnosis. Secondly, it’s important to facilitate in your language, colloquial cultural style that matches the team you’re with. It’s authentic, and people respond better, open up more when you are authentically yourself.

Some examples of using the same retrospective visual for different purposes.

Capturing the mood Retrospective;
Often a team can get into a slump and stay there. Be transparent about feelings in the workplace is hard. So in a safe space doing a simple visualisation exercise can help them “get out of the feeling” and take a new perspective on what’s going on. The below excerise could include a step to write down why you feel the way you do but sometimes it’s good to just ‘air the feelings first’.


1. Ask the team to quietly consider how they feel about the past iteration (or event)
2. Place a stickie on the scale where it best represents their feeling
3. Acknowledge the distribution or weighting of the stickies
4. Go into discussion and diagnoses withe team
5. Facilitate them to come to a point of actionable agreement

Identify the distribution of performance retrospective.
The purpose of looking into performance is to discover what wrong or what could be improved.

1. Ask the team to quietly consider their recent work, and jot down their why
2. Place a stickie on the scale where it best represents their efforts
3. Acknowledge the distribution or weighting of the stickies
4. Go into discussion and diagnoses withe team
5. Facilitate them to come to a point of actionable agreement about what to do better next time

Facilitation questioning techniques

As part of a facilitation peer learning group the below probing questions and communication guides were past around. It’s a good summary to help an agile coach drive ‘smarter thinking’ among the team.

Recently a facilitation peer learning group shared a list of ‘probing questions’ and ‘communication guides to help provide effective facilitation. As a coach it’s good to have a variety of language techniques up your sleeve and below are a few that may help…


Probing Questions:

When seeking more detail, there are a number of types probes you can use, depending on what they are saying and what you want to discover.


When they use vague or unclear language, or when you just need more detail, seek to further understand them by asking for clarification.

  • What exactly did you mean by ‘XXX’?
  • What, specifically, will you do next week?
  • Could you tell me more about YY?



Sometimes they say things where the purpose of why they said it is not clear. Ask them to justify their statement or dig for underlying causes.

  • Why did you say that?
  • What were you thinking about when you said XX?


If they seem to be going off-topic, you can check whether what they are saying is relevant or salient to the main purpose of inquiry.

  • Is that relevant to the main question?
  • How is what you are saying related to what I asked?

Completeness and accuracy.

You can check that they are giving you a full and accurate account by probing for more detail and checking against other information you have. Sometimes people make genuine errors (and sometimes deliberate), which you may want to check.

  • Is that all? Is there anything you have missed out?
  • How do you know that is true?
  • How does that compare with what you said before?


One of the most effective ways of getting more detail is simply by asking the same question again. You can use the same words or you can rephrase the question (perhaps they did not fully understand it first time).

  • Where did you go?
  • What places did you visit?

You can also repeat what they have said (‘echo question’), perhaps with emphasis on the area where you want more detail.

  • He asked you to marry him??


When they talk about something vaguely, you may ask for specific examples. This is particularly useful in interviews, where you want to test both their truthfulness and the depth behind what they are claiming.

  • Sorry, I don’t understand. Could you help by giving an example?
  • Could you give me an example of when you did XXX?
  • Tell me about a time when you ___.


When they have not given you enough information about something, ask them to tell you more.

  • Could you tell me more about that, please?
  • And what happened after that?
  • Then…


To discover both how judgmental they are and how they evaluate, use question that seek evaluation:

  • How good would you say it is?
  • How do you know it is worthless?
  • What are the pros and cons of this situation?

Good Retro Guide

Continuous Improvement is only a retrospective away

Retrospectives are the art of the inspect and adapt cycles in iterative agile development. They can be done well or poorly just like any workshop but there is a simple approach checklist that will assist you to facilitate for greater team retrospection. Diana Larsen and Esther Darby have outlined a succinct and great top 5 methods for ensuring teams inspect well and adapt appropriately.

1. Set the stage   (social agreement the agreed purpose)

2. Gather some data   (before we decide what to change)

3. Generate Insights   (what does that mean for us?)

4. Decide what to do   (experiment to try…)

5. Close the perspective    (recap decision, review retro quickly)


Setting the stage is an important book end for the start of your session. It’s made up of two essential elements. The social frame & the focal point for this retrospective. Firstly the social frame is similar in purpose to creating a social agreement or team agreement but in this instance it is to help establish the context and recommended behaviour for creating a great retro. The Focus On / Focus Off exercise they talk about in the video is a great summary to establish expected behaviour.



The second component of setting the stage is agreeing on the focal point of the retrospective. Often teams become improvement bored, or reach a stage of ‘whatever’; particularly, if the same format for a retrospective is used each and every time. Setting a goal and focal helps to look at different areas at one time and to decrease the size of the improvement ‘wishlog’. Improvements need to be feasible, doable, and not stress full for teams.



Gather some data on the focal point to get the facts and sense from the teams perspective so as not to have the session dominated by anyone persons perspective. For example if your looking at coding practices have the team write up stats for # of failed tests, # of failed builds, # of successful recoveries PLUS underneath have them chart their energy for coding levels over the iteration.


This will give you a number of facts around what is happening and debunk any assumptions i.e. Geoff is always breaking the build and stuffing us up. The data shows (or not) that Geoff has low energy for coding focus because he’s also on incident management which constantly interrupts his work.


Generate insights from the data, the conversations,  and the anomalies in the data. This is where most coaches use the learning matrix of what went well, what didn’t go well etc have the team think, discuss, and write down. Ask the team if there are any emerging patterns? What’s the causes, is their a convergence point that’s leading to this. Play the what if game to help expand their thinking to get to the cause – what if you had skills, what would our day to day look like if we never had a failed build? (probably weird as it’s a normal part of TDD but it’s a nice simple example to use here) Ask what path from the past lead us to this point?



Decide what to do and be clear about how to achieve it as well. Often in a retro it seems obvious what needs to be done, and people ask why has this never been fixed before? Even though that person may be thinking it’s so obvious it often isn’t AND do answer why has this never been fixed before? It’s a quick way to know if blockers will pop up. What to do should never be so huge the team gets into a helpless rutt and preferably not just ownership of always one person. Teams get used one person always fixing so avoid this mentality as much as possible.

Close the retrospective quickly and decisively. It’s important that the team has final agreement what, how, when they will be doing the improvement action. have the team agree on when they’ll follow up to ensure ongoing support for achieving the improvement is in place. Lastly do a Return on Investment poll to understand how to improve the retrospective. Break even is great, and it’s very interesting after a number of iterations if teams start to see benefit from their iterations.



1. Google Tech Talks: 25th January 2007 Diane Larsen and Esther Darby Authors of Agile Retrospectives: Making Good Teams Great

♥♥♥♥♥♥♥ Every dog lover deserves a designer dog collar or designer dog lead this  Christmas from the Leroy Madison Online Pet Shop ♥♥♥♥♥♥♥


Good Retro Guide