Tuesday, 17 July 2012

Stephen Covey

Just saw this via linkedin: http://www.usatoday.com/money/books/story/2012-07-16/stephen-covey-obituary/56251996/1

My condolences to all his friends and family members - he and his books have helped so many with so much.

Thursday, 12 July 2012

Test Driven Development solutions to same problem

!WARNING - THIS POST IS WRITTEN FOR SOFTWARE FOLKS!

I discovered Test Driven Development / TDD in about 2005/6 thanks to Gunjan Doshi's TDD Rhythm and 1-2 old articles on JavaWorld.

Years later I read Kent Beck's book Test Driven Development (The Addison-Wesley Signature Series) and was glad I had not missed anything fundamental from my non-standard "foundations" on the subject. These days there is a fairly good intro on Test Driven Development wikipedia entry. This post is aimed at software craftsmen and journeymen and perhaps even masters - to inspire a bit of thought along the following dimensions that impact the solutions that evolve:
- the understanding of the functional requirement
- the understanding of the non-functional requirement
- approaching the solution in primarily an iterative approach (managing complexity, perhaps)
- approaching the solution in primarily an incremental approach (managing complication, perhaps)
- the understanding of the required test strategy to ensure required quality level is achieved

Dimensions that, in TDD, result in the tests selected AND the order in which to approach the tests, which result in the emerging of different solutions.

I've spent a great deal of time leading/mentoring/coaching Test Driven Development (TDD) sessions, working with teams and individuals on a particular problem which they had no experience in beforehand. These sessions were the correct environment for us both to learn TDD, or for them to learn TDD, or even as part of a recruitment selection process where the team was practising TDD and we had to ensure candidates could practice TDD as we did.

I selected a problem that was documented on wikipedia on the page describing Numerology. I like discovering interesting coding problems on wikipedia as the descriptions there are [theoretically] internationally acceptable and understandable - which helps enormously to "level the playing field" for English first language speakers as well as non-English first language speakers.

The specific problem I wanted to pair up on is described very well under "Methods" in terse language (another "pro" as time is always pressured, and I wanted a problem understood, solved and discussed in 30-45 minutes).
In essence for this challenge, I wanted solutions to be developed that would convert a word, a phrase, and ultimately a person's full name, into a number, using simple rules that had to be analysed on the wikipedia page and extracted, without my help, to establish the even playing-field going into the solution development phase and discussion phase thereafer.

The first part of the rules were simply how to encode letters to numbers according to Numerology:

1 = a, j, s;
2 = b, k, t;
3 = c, l, u;
4 = d, m, v;
5 = e, n, w;
6 = f, o, x;
7 = g, p, y;
8 = h, q, z;
9 = i, r

The second part of the rules would usually give the candidate 2 strategies depending on how detail-oriented the person was.

For those who rushed through understanding the requirements, the rules were simply summing individual numbers repeatedly until the total < 10, eg using the wikipedia examples:

3489 ? 3 + 4 + 8 + 9 = 24        ? 2 + 4 = 6
Hello ? 8 + 5 + 3 + 3 + 6 = 25  ? 2 + 5 = 7

For those who paid a bit more attention, the rules were simply:

  value modulo 9, if 0, then 9

It is *always* interesting to see who picks up the shorter modulo 9 strategy, and who does not. (feeding into a lightweight Belbin assessment - see my Coaching with Belbin)

The various solutions below highlight [clearly] how the right problem tackled in the right way creates a much more readable, maintainable, extensible and flexible solution using TDD. Although even the less TDD-correct approach still produces an acceptable result. For me though, the best solution was actually produced largely without using TDD. Can you spot it?

/***************************************/
// TESTS
/***************************************/

I have removed name identifications and some "interesting" tests from the typical TestClasses that were all similar to either:

// Simple
import Calculator;
import org.junit.Test;
import static org.junit.Assert.*;
public class CalculatorTest {
    Calculator calculator = new Calculator();
    /*
     * Test Cases:     *    
     * 3,489 => 3 + 4 + 8 + 9 = 24 => 2 + 4 = 6     *          
     * Hello => 8 + 5 + 3 + 3 + 6 = 25 => 2 + 5 = 7  *
     */
    @Test public void testCalculateImportantChars() {        assertEquals(2, calculator.convertCharToNumeric('k'));        assertEquals(1, calculator.convertCharToNumeric('a'));        assertEquals(9, calculator.convertCharToNumeric('r'));        assertEquals(5, calculator.convertCharToNumeric('n'));        assertEquals(8, calculator.convertCharToNumeric('h'));        assertEquals(5, calculator.convertCharToNumeric('e'));        assertEquals(3, calculator.convertCharToNumeric('l'));        assertEquals(6, calculator.convertCharToNumeric('o'));        assertEquals(9, calculator.convertCharToNumeric('i'));        assertEquals(8, calculator.convertCharToNumeric('z'));    }

   @Test public void testCalculateHello() {        assertEquals(7, calculator.calculate("Hello"));    }
}

OR:

// More along Kent Beck's final example approach


import Calculator;
import org.junit.Test;
import static org.junit.Assert.*;


public class CalculatorTest {


   Calculator calculator = new Calculator();


   /*
    * A = 1
    * B = 2
    * C = 3
    * a = 1
    * b = 2
    * j = 1;
    * k = 2
    * i = 9;
    * 0 = 0
    * 1 = 1
    * 11 =  2
    *
    * AA = 2
    * AB = 3
    *
    * 1B2a =6
    */


   @Test
   public void testCalculate1() {


       String[] inputs = {"A", "a", "B", "b", "C", "k", "j", "i", "AA", "AB", "ABc", "0", "1", "11", ",", " ", "1B2a", "-1", "hello", "3,489"};
       int[] outputs = {1,1,2,2,3,2,1,9, 2, 3, 6, 0, 1, 2, 0, 0, 6, 1, 7, 6};


       for(int testcase=0; testcase < inputs.length; testcase++) {
           assertEquals(outputs[testcase], calculator.iWantToBelieve(inputs[testcase]));
       }


       assertEquals(-1, calculator.iWantToBelieve(null));
   }


}

/***************************************/
// SOLUTIONS, all checks and Exceptions removed for brevity
/***************************************/



/* Common Solution 1 */


public class Calculator {


   public int iWantToBelieve(String string) {
       if(null==string) {
           return(-1);
       }
       int result = 0;
       for(int pos = 0; pos < string.length(); pos++) {
           int valueToAdd;
           char currentChar = string.charAt(pos);
           if(Character.isDigit(currentChar)) {
               valueToAdd = Integer.valueOf(String.valueOf(currentChar));
           }
           else if(Character.isLetter(currentChar)){
                int tmpValue = Character.toUpperCase(currentChar) - 64;
               int valueOfCharacter = tmpValue % 9;
               valueToAdd = valueOfCharacter == 0 ? 9 : valueOfCharacter;
           }
           else {
               valueToAdd = 0;
           }
           result+=valueToAdd;
       }


       if(result>9) {
           result = iWantToBelieve(String.valueOf(result));
       }
       return(result);


   }


}


/* Common Solution 2 */


import java.util.HashMap;
import java.util.Map;


public class Calculator
{
 private static Map numericCodes = new HashMap();
  
  static 
  {
   numericCodes = initialiseNumerologyMap();
 }


 public Calculator(){
 }
  
 public int calculate(String word) {
   char[] chars = word.toLowerCase().toCharArray();
   int[] digits = new int[chars.length];
    
   for (int i = 0; i < chars.length; i++)
   {
       char characterValue = chars[i];
       Integer numeric = numericCodes.get(characterValue);
       if (numeric == null)
       {
         digits[i] = 0;
       } else {
         digits[i] = numeric;
       }
   }
   int sum = 0;
   for (int i = 0; i < digits.length; i++)
   {
     sum += digits[i];
   }
   if (sum > 9)
     return calculate(""+sum);
    
   return sum;
 }


 /* 
  * 1= a, j, s; 2= b, k, t; 3= c, l, u; 4= d, m, v; 5= e, n, w;
  * 6= f, o, x; 7= g, p, y; 8= h, q, z; 9= i, r  
  */
 private static Map initialiseNumerologyMap()
 {
   // a to z mappings
   for (int i=97; i<123; i++) {
     int alphabetValue = i%96;
     int modulatedValue = alphabetValue%9;
     if (modulatedValue == 0) {
       modulatedValue = 9;
     }
     numericCodes.put((char)i, modulatedValue);
   }
   // 0 to 9 mappings
   int j=0;
   for (int i=48; i<57; i++) {
     numericCodes.put((char)i, j);
     j++;
   }
   return numericCodes;
 }


}

/* Common Solution 3 */

public class Calculator {


   public int calculate(int n) {
       if (n == 0) {
           return 0;
       }


       int result = n % 9;
       if (result == 0){
           return 9;
       }
       return result;
   }


   private String a2n = "abcdefghijklmnopqrstuvwxyz";


   public int convertCharacter(char ch) {
       return calculate(a2n.indexOf(Character.toLowerCase(ch))+1);
   }


   public int convertWord(String word) {
       int sum = 0;
       for(char c : word.toCharArray()) {
           sum += convertCharacter(c);
       }


       return calculate(sum);
   }


}

/* Common Solution 4 */

public class Calculator {


   public int convertCharToNumeric(char c) {
       int intValue = (int)c;
       if ((intValue >95) && (intValue < 129)) {
           int numericFate = (intValue - 96) % 9;
           return convertForNumerology(numericFate);
       } else {
           return 0;
       }
   }


   private int convertForNumerology(int yourFate) {
       if (yourFate == 0) {
           return 9;
       }
       return yourFate;
   }


   public int calculate(String word) {
       int total = 0;
       for (char c : word.toLowerCase().toCharArray()) {
           total += convertCharToNumeric(c);
       }
       return convertForNumerology(total%9);
   }


}

/* Common Solution 5 */

public class Calculator {


   public int calculate(int n) {
       int result = n % 9;
       if (result == 0) {
           result = 9;
       }
       return result;
   }


   public int convert(String word) {
       String workingWord = word.trim().toLowerCase();


       int total = 0;
       for (char ch : workingWord.toCharArray()) {
           int intValue = (int)ch;
           if ((intValue > 96) && (intValue < 123)) {
               total += (intValue % 96);
           }
       }


       if (total > 0) {
           return calculate(total);
       }


       return 0;
   }


}


/* UnCommon Solution 6 */

public class Calculator {


   public int calculate(long n) {
       if(n%9==0)
           return 9;
       return (int)(n % 9);
   }


   public long convertStringToNumber(String string) {
       String tmpString = string;
       tmpString = tmpString.toLowerCase().replaceAll("[^abcdefghijklmnopqrstuvwxyz]", "");
       tmpString = tmpString.replaceAll("[a,j,s]", "1");
       tmpString = tmpString.replaceAll("[b,k,t]", "2");
       tmpString = tmpString.replaceAll("[c,l,u]", "3");
       tmpString = tmpString.replaceAll("[d,m,v]", "4");
       tmpString = tmpString.replaceAll("[e,n,w]", "5");
       tmpString = tmpString.replaceAll("[f,o,x]", "6");
       tmpString = tmpString.replaceAll("[g,p,y]", "7");
       tmpString = tmpString.replaceAll("[h,q,z]", "8");
       tmpString = tmpString.replaceAll("[i,r]", "9");
        return Long.parseLong(tmpString);
   }
  
}

/**************************/

It seems to me that TDD represents some interesting mental/psychological challenges for people who try:
- For software newbies, it is almost effortless, but they struggle to see the value in what they're creating as their solution emerges - I think due to a lack of experience looking at mountains of badly written and poorly designed legacy systems
- For software oldies, it is darn painful, and they struggle to see the value in the extra steps they're taking, constantly battling the urge to do more error checking and handling, to make the solution more complicated, and generally reach a point of suspended disbelief needing to see more examples and try it again in their work environments
- For some, and it is so far impossible for me to recognise them, they reach almost immediate "ah ha!" realisations of the power of TDD. They're flexible and open enough to suspend their not-as-entrenched over-thinking thought processes that the "oldies" display yet they have experience of maintaining some old production systems and dealing with some of their more novice mistakes that have come back to haunt them again, and sometimes again and again.
Keith Braithwaite and I once discussed that people applying TDD properly ("coincidentally" those who love doing so) experience Csikszentmihalyi's "Flow" - and hence even more benefits for those who successfully embrace, as well as the organisations that setup them up to succeed/embrace.


I look forward to hearing other points of view on the above 6 solutions for the "same problem" over the next few years.

Thursday, 5 July 2012

My favourite coaching tools: Labels and Believing Is Seeing!

Caveats:
This is a group exercise and great for team building. At certain times during the session some people's emotions might rise due to frustration at being misunderstood. As coach you MUST manage the level of frustration (a little is good, too much is bad) in order to allow the group to fully experience and gain from the steps below. Most participants however are quick to see the simulation for what it is and self-control themselves accordingly. If you feel unsure, practice with a smaller group of friends, for instance, who can safely give you feedback throughout to ensure you get it right for real. Always remain on the safe side - for your sake and your participants'.

Required:
- Enough labels to get people into groups of 6 - preferably the labels are on little hats so that the people who are labelled do not know their own label (sometimes I use postits stuck to foreheads which does not work in warm sweaty conditions, sometimes paper tape/medical tape but same problem with sweaty foreheads, sometimes name badges tied on short strings under people's chins). Labels should be big enough so that other people can read them from 2-3 feet away.
- Labels suggested in Quick Team-Building Activities for Busy Managers: 50 Exercises That Get Results in Just 15 Minutes by Brian Cole Miller include "laugh at me", "disagree with me", "leader", "brown noser", and many more - *BUY THE BOOK*. I've also used Belbin's team roles for labels, as well as Belbin team role opposites (see Coaching with Belbin for details). Sometimes I just make them up based on the group and behaviours I noticed.
- Printouts for half the group of Stephen R Covey's The 7 Habits of Highly Effective People (*BUY THE BOOK AND READ FOR FULL DETAILS*) Young Lady:

- Printouts for half the group of Stephen R Covey's The 7 Habits of Highly Effective People (*BUY THE BOOK*) Old Lady:


- A digital projector and computer in order to show the group Stephen R Covey's The 7 Habits of Highly Effective People (*BUY THE BOOK*) Both Ladies picture:




- 15 minutes for the first "Label Game" session
- 15 minutes for the second "Believing is Seeing" session
- 15-30 minutes for open group discussion to ensure lesson properly understood and people back to normal

Step 1:
Explain the basics of the "Label Game" to the participants:
- Everyone will receive a label that they should not see before the end of the exercise
- No one should tell someone else what their label is
- The groups will be given 7 minutes to plan something (department party, a new fun game, who to choose to evacuate a doomed earth, survive for 24 hours in a desert/artic, etc)
- As the group discusses, the participants must proact/react to the label of the person
- By the end of 7 minutes, people will be asked what they think their label is, before being allowed to look

Step 2:
Break the group into sub-groups of 6, distribute and place the labels on each member so that they are unable to see their own label.

Step 3:
Start the timer! Remind the participants about good timebox strategies to ensure they succeed with their discussion. Help with time keeping.

Step 4:
Time up! Let the groups discuss amongst themselves and get an indication of how many people realised within 7 minutes of simple discussion, what label they were wearing! Usually >75% correctly ?guess? their label.

Step 5:
Open the discussion up to the whole group. Good questions like "How did it feel to be treating people according to their label?", "How did it feel to be treated according to a label that was not visible to you?", "What about the labels we're treating each other with continuously in the day to day work?", "What are the dangers of labels?", "What are the pros of having labels?", "How do our labels affect us?", "Labels versus Job Title?" and see what thoughts and feelings are provoked by the group.

Be strict with your own time management as there is still the second session to run!

Step 6:
Get people to become 1 group again, this time split them down the middle.

Step 7:
Without making it obvious that there are 2 different pictures being given out, distribute the "Young Lady" above facedown to half the group, and distribute the "Old Lady" above facedown to the other half of the group.

Ask the participants to turn over the picture and stare at it for 30 seconds, and then to put it away. Help them with timekeeping and ensuring they're focussing on their own picture only.

Step 8:
With the pictures away, turn on the projector and show the group the "Both Ladies" picture.

Step 9:
Ask the participants to stick their hands up if they recognise the picture. Now ask 1 person from the "Old Lady" group what they see. Then ask 1 person from the "Young Lady" group what they see.

Step 10:
Now ask the group who sees an Old Lady? And then ask who sees a Young Lady? Act confused and ask how is it possible - surely they're looking at exactly the same, unmoving picture on the screen - how could it be that people are seeing different things? And ask who sees both an Old Lady and a Young Lady?

The groups are usually quite fun and energised by this time so allow them to discuss and try to resolve the different perceptions they have. People will come up to the screen and start tracing out the different curves, arguing, getting frustrated, getting amused and slowly all or most of the group will eventually see both pictures. (as an aside, what does it mean if someone is unable, even after a lot of help, to see both ladies?)

Step 11:
Now explain it the way Stephen R Covey does: "It's not logical, it is psychological!"..."the way we see the problem IS the problem!" 

Step 12:
And now ask similar questions to the Label Game session. Ask how this kind of knowledge, this insight might have changed how they approached problems in the past, and how they will approach problems in the future? Are the problems restricted to work problems, or are "people problems" also now more approachable? And so on.

Before running this session, I strongly recommend buying both books linked above and reading them properly for more many more details than I've summarised here. 

I find the 2 exercises even more beneficial for individuals I am coaching who attend, especially if they have already covered Belbin's Team Role Inventory Theory (see Coaching with Belbin), Myers Briggs Type Indicator (see Coaching with Myers Briggs) and Preferred Communication Style (see Coaching with Preferred Visual Audio Kinaesthetic Communication Style). And for additional benefit, these sessions, run before coachees attempt their first feedback collection from peers (see Coaching What do I do?) also help to give people more confidence in the collection, in the giving, and in the understanding of the content+emotion they receive.


Tuesday, 3 July 2012

My favourite coaching tools: Motivational direction discovery and visualisation to achieve

Caveats:
Some people reject/debunk NLP (Neural Linguistic Programming) in its entirety. I find some of it useful to know and to teach to others. I do this by skipping the whole NLP thing and just honing in on the particular tools where relevant - for example below.

Required:
A bit of time to chat through various situations

Step 1:
According to NLP: the New Technology of Achievement humans are motivated in 2 ways:
- TOWARD what we want
- AWAY from what we don't want

For instance:
- Going to pat the friendly happy dog
- Keeping distance/getting away from the angry aggressive dog growling and barking madly

Another way to think about these motivational directions:
- Toward oriented people are goal-directed (outcome focussed)
- Away oriented people are more interested in identifying and solving problems (journey focussed)

Step 2:
Of course, as is clear in the example, humans use both motivation directions depending on a variety of factors - eg environmental, experience, etc.

However, we also, due to the wiring of our brains according to the NLP model, tend to specialise in 1 direction of motivation more than the other, and hence use it in situations where really the other motivation direction is better. And this is where I find many people in coaching situations trying to make changes happen for themselves or for their teams, but just not succeeding.

Step 3:
Armed with the knowledge of motivation direction, we take a look at the goals and rethink what motivation direction is more in play. We do the usual things of listing the pros and cons of making the change...but it is still not enough.

Step 4:
Making use of another tool from NLP, I ask the coachee to describe the image of achieving each of the goals.

Goals that are not so important to the coachee, or are "away from" motivationally oriented are usually described in 2 dimensions, little or no movement, little or no colour, with some distance between the goal description and the coachee describing it - the coachee is an observer.

Goals that are important to the coachee, or are "towards" motivationally oriented are usually described in great deal more richly: 3 dimensions, sound, colour, movement, passion, excitement - it is clear the coachee is engaged in achieving the change. The coachee is part of the scenario.

Step 5:
Now that the list of goals, and the motivational orientation of each has been analysed, there is 1 more tool that NLP provides that helps people perform a change they do not really want to: The New Behaviour Generator.

New Behaviour Step 1: Preparation
Ask the coachee to focus on themselves, to settle in, find quietness and relax. Ask them to imagine another "them" who they are observing.

New Behaviour Step 2: Choose the goal / task required to fulfil the goal
Ask the coachee to select the task which is currently blocking the fulfilment of the goal.

New Behaviour Step 3: Imagine the benefits
Ask the coachee to imagine their imaginary clone reaping the rewards of performing the task.

New Behaviour Step 4: Imagine the clone performing the task, completing the task, and achieving the benefits

Ask the coachee to imagine their imaginary clone performing the task - going through the troubles, the problems, the challenges, and overcoming each one, all the while becoming more confident and beginning to enjoy the benefits of fulfilling the task / goal. And finally when the goal is achieved, observing how the imaginary clone is enjoying all the benefits and sense of satisfaction that is evident.


New Behaviour Step 5: Integration
Ask the coachee to imagine that the imaginary clone now merges with themself in the observer position. Some people hug to initiate the merging. Some people feel a surge of energy or tingling when this integration occurs.

New Behaviour Step 6: Planning
Now ask the coachee when they will perform the task for real, and followup!

Step 6:
Repeat for each of "away from" goals. I prefer to do this exercise only once per session as the amount of energy required from the coachee can in some instances be great.

These NLP tools do sometimes take a bit of practice to master. The key is "baby steps" and checkpoints full of feedback along the way. The key metric is the quantity and the richness of the description of the description the coachee provides. As coach you can suggest adding music to the scenario if it is missing, to enhance the colours or the movement etc etc to really help manifest the future desirable state. Some of my coachees have also benefited themselves by reading Rhonda Byrne's The Secret .

Monday, 2 July 2012

Update on SEM

For those that are interested:
- Through May traffic (New AND Returning Visitors) to this blogsite tripled
- Through June traffic (New AND Returning Visitors) to this blogsite doubled
- Google impressions through June (when I started tracking those as well) have more than doubled
- Early days in July, but already looking on track to double again :-)

Thank you all readers and supporters!!

At the same time, my research with Twitter has come to an end for now - the Twitter disconnect from linkedin announcement on Friday seems like an opportune time to deactivate. In reality this site attracts far more new+real visitors (hang around and read for 4-6 minutes) via google. :-)

My favourite coaching tools: Retrospective timeline cartoon

Caveats:
None. Getting a group to draw together, to make and convey meaning in story format in pictures is incredibly powerful team building activity. And the cartoons can often raise awareness, very gently/with humour, of something some of the group are experiencing - eg providing feedback about particular behaviour of someone.

Required:
Large paper and markers.
20-30 minutes to draw
10 minutes to present and explain

Optional:
For distributed team members, the easiest is a way to scan/photograph cartoon contributions and email/upload to a shared space.

Step 1:
Simply give the materials and the instruction to the group. Part of this experience is to allow the group to figure it out for themselves - ie, less is more. A typical instruction is simply:

"Spend the next 20 minutes drawing a cartoon of a couple of frames that capture the key things that occurred during this past sprint/iteration/month/week/year/day"

As facilitator, you can suggest strategies for dealing with the 20/25/30 minute timebox (breadth first, depth second, breaking the timebox into smaller timeboxes, breaking the team into sub-teams after consensus is reached in the initial timebox, good-enough-is-good-enough, etc) 

Step 2:
Sometimes someone will attempt to dominate the effort - as facilitator try to ensure everyone is equally being heard and equally participating in the effort to decide what things to include, and how to depict them. Monitor the work effort and help the group meet the final outcome: a cartoon strip that tells a consistent story!

Step 3:
Something like the below will emerge when all goes well:


As agile coach I've seen and heard about many funny cartoons, and such great insights conveyed. One of my  favourites that I heard about had a character showing up in 2-3 of the frames and asking "What's going on?". When the Scrum team was asked who this character was, it turned out it was the technical team leader who was also committed to 3 other projects and not really available to the team, and actually detrimental to progress as the team had to keep bringing this "leader" up to speed. Not really Scrum then...

Friday, 29 June 2012

My favourite coaching tools: Visual Individual - Squiggle Completion

Caveats:
None. You can do this for group work as well, and I have used it quite successfully for Agile Retrospectives.

Required:
5 minutes to draw
5-10 minutes to explain (per coachee/group member)
Paper
Pens/pencils/colours or not
Quiet space

Step 1:

Take the paper and draw a quick random squiggle on it. In a group everyone can draw a squiggle on a piece of paper.

Eg:





Step 2:
Pass the paper to the coachee, or in a group ask the members to pass to the left/right. Ask the recipient to look silently at the squiggle. Depending on the context, you can choose to ask a question for instance "How has this past week/month/year been for you?" or "How would you like the future to look?" or "What does success look like?"

Step 3:
Ask the coachee or group members to now complete the squiggle they have received as appropriately as possible to reflect their context or their answer to the question raised. Timebox this to 5 minutes - the results are more useful if cognitive thinking has been reduced and instead subconscious knowledge is accessed.

Eg







Step 4:
Now ask the coachee to explain their picture to you and/or the group. The insights from this exercise are extremely varied. Remember to make no judgements, nor allow any in the group to make judgements. Visualising knowledge is extremely subjective and it's up to the drawer to interpret along with guided questions eg: "What does that represent for you?", "That seems far away from this?", "Did you choose red on purpose?", "Who is that big figure?", "The waves seem to grow?" etc

The data gained from this coaching tool is useful for individual coaching plans - sometimes there is the discovery of a motivational factor or an anti-motivational factor. And the insights for a group who use this have a team building effect - especially when people take their masterpieces back to their office spaces with them and leave them on display. Especially if, over time, you use the tool a few more times for different or the same question.