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 of Stephen R Covey's friends and family members - he and his books have helped so many with so much. And me especially. I recommend the Seven Habits of Highly Successful People to nearly every one I coach or mentor.

Things will never be the same after this.

Stephen R Covey Helped So Many In So Many Ways

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) (or US) 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.

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 are able to facilitate it correctly to the intended benefits.

Always remain on the safe side - for your sake and for your participants' also!

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 post-its stuck to foreheads but this does not work in warm sweaty conditions, sometimes paper tape/medical tape but have the same problem with sweaty foreheads, sometimes name badges tied on short strings under people's chins).

- Labels should be written (or use symbols) 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 have observed.
- 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 "secret" (from them) 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 or infer their label based on how others were interacting with them.

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 "random" person from the "Old Lady" group what they see. Then ask 1 "random" person from the "Young Lady" group what they see.

Step 10:

Now ask the whole group to raise their hands those who see an Old Lady? And then ask those to raise their hands 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 then 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 of 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, Myers Briggs Type Indicator and Preferred Auditory, Visual or Kinaesthetic Communication Styles. For additional benefit, these sessions, run before coachees attempt their first feedback gathering from peers, also help to give people more self confidence in the collection, in the giving, and in the understanding of the content+emotion they receive from other people. We are all human, even if often it appears we are, or they, are not! ;-)

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 .

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 by using the retrospective timeline cartoon pictures is an incredibly powerful team building activity. The retrospective timeline often raises team awareness, very gently, with humour, of something some of the team members are experiencing - eg providing feedback about a particular behaviour of one of the team members.

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:

Retrospective Timeline Cartoon Drawing Exercise

As agile coach I've seen and heard about many funny cartoons, and seen or heard of fantastic individual or team insights conveyed by using them!

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 thus was actually detrimental to progress as the team had to keep bringing this "leader" up to speed and could not become truly empowered and self-organising.

Not really Scrum then! And this is a great awakening to help teams go through - many think they are agile or Scrum, but when they understand those 2 terms, and when they understand deeply the evidence in support of or opposition to, this can be quite shocking for some team members, whilst being the "I told you so!" moment for some other team members. You  have to be ready to coach for this situation and help each individual and hence the whole team successfully negotiate this awakening phase.

I suggest helping everyone with calm and focus in the current moment, and hope for the future to envision a future they all want to become the new current reality!

Thankyou for reading! I hope I convinced you to try with your team! It's really good stuff!