"Zühlke Blogs" via Stefan in Google Reader

My favourite coaching tools: Peter Drucker's "manager's letter"

2012-05-31T21:52:00Z

Caveats:
This tool has some similarity to my previous tool posting Record, Typeup and Playback. I also feel this can be used for everyone, including yourself. I might use this tool instead of Record, Typeup and Playback or I might use it with. Depends on the coachee, and the manager and if there is a particular aspect that has been highlighted and needs a little more information

I discovered this tool in the book Essential Drucker (Classic Drucker Collection) which contains 26 chapters by THE management guru Peter Drucker. I cannot highly recommend this book enough to anyone studying management or anyone wanting to become a better manager. It's the only book out of the hundreds I own and have read that I actually underlined, drew pictures in and made comments in the margins. I love my books but Peter's ideas and writing style inspired me to break my own rules.

Required:
Text editor
Sufficient time

Step 1: The coachee writes a 1 page letter to their superior. In this letter the coachee identifies the superior's job's objectives, and the objectives of their own job as they see them.

This is not a copy-and-paste out of an intranet web page or HR tool. It is in their own language, and from memory/current understanding of these 2 areas.

Step 2: Next the coachee sets out the performance standards that they understand and being applied to them

Again, not a copy-and-paste, and again brutally honest, own language, own experience, own understanding.

Step 3: Then the coachee lists the things they must do themselves to attain the goals, and also lists the major obstacles to attaining the goals.

Often organisations are adept at creating vague, abstract and almost meaningless goals, actions to achieve the goals and obstacles in order to not offend anyone and to ensure some HR or governance checklist is all ticked off. Here again, it is important to get total honesty from the coachee and list real items.

Step 4: Next on the letter is the list of things the superior and company do that help, and the list of things the superior and the company do that hinder.

This is basically one of the most powerful and simple 1-1 solicited feedback tools I ever learned, used, still use and now teach.

Step 5: The final piece of the letter is the coachee's proposal of what he/she wants to do over the next year to reach his goals.

This tool can be deployed twice a year according to Peter's research with managers he was working with. I've not yet had the pleasure of seeing a second letter but I hope my coachees who wrote it once with my guidance, at least write it for themselves, if not for their newly inspired managers.

Used by managers and their reports, this rolling system of staying relevant and updating of goals and understanding in both directions is much better than forced systems which only uncover almost nonsense by only touching on 1 of the above 5 sections. Peter also advises that when used correctly, the manager can accept the letter which then becomes the agreed charter between manager and subordinate.

Of course, if there are surprises in the letter, the chance to have a clearing up conversation now exists and good managers will have a good conversation to ensure everyone is on the same page before going further...and accepting the charter.

Though, as coach, reviewing the surprises in the letters I have seen, and asking questions sometimes of the coachee, sometimes of the manager, I have helped highlight how important every manager interaction and comment is. Subordinates constantly form incorrect impressions and hence behave in non-beneficial ways but once the correct intention is illuminated, things get better and easier - alignment is a really powerful, commonsense thing to achieve to achieve goals together!

These letters can be used either as collection of data for reinterpretation, as well as to form a coaching plan. And if taken all the way to include the update with the manager, things are well primed for "Results-Based Coaching"

My favourite coaching tools: Free online Visual-Auditory-Kinaesthetic (VAK) communication style preference assessment

2012-05-28T15:46:00Z

Caveats
Some people really just don't get this, either. And, VAK confusingly can be applied to preferred/natural communication style, as well as to preferred learning style. This tool is for preferred COMMUNICATING style. (for VAK learning style assessment see my previous post: Free Online VAK Learning Style Assessment)

Again, this is a scaling assessment, and there are several around that you can download for free as well. I liked this for an online free tool as it is consistent with my previous more detailed ones in a proper psychometric test centre. Some tests actually highlight how strongly preferred the style is as compared to the others - this is useful to know as well, but I have not found it very useful for coaching purposes.

It does ask you for personal details at the end, but I managed to proceed to my results without completing the fields or providing real information.

Required:
Internet access
Quiet space
10-15 minutes

Step 1:
Give this link to the coachee: http://www.new-oceans.co.uk/new/lsdi.htm. Again I think the best time to do the assessment is in the morning, before work really starts.

Step 2:
When the assessment is complete, you will have the 3 in preferred sequence for communicating.

You now have material you can use to support the coaching goals and plans where guiding communication is required (100% of the time?). Once you are aware of your own preferred communication style, and your coachee's learning style, you can tailor what you say to be much more effective. And vice-versa, once you know your preferred learning style and your coachee's preferred communication style, instead of "shielding out" inadvertently some information you are sent by your coachee, you can be more aware to receiving, albeit in your non-favourite style! I find coaching relationships where we both know each other's preferred learning and communication styles much more fun as it allows us to safely practice new approaches on each other, to prepare us both for using these tools with others that we are having "problems" with. Really useful stuff!

My favourite coaching tools: Free online Visual-Auditory-Kinaesthetic (VAK) learning styles assessment

2012-05-24T13:05:00Z

Caveats
Some people really just don't get this. And, VAK confusingly can be applied to preferred learning style, as well as to natural communication style. This tool is for preferred LEARNING style. (for VAK communication style assessment see my other post: Free Online VAK Communication Style Preference Assessment)

For this test you do have to give an email and some personal data which I do not like doing, and I got away with giving fictional.

Required:
Internet access
Quiet space
5-10 minutes

Step 1:
Give this link to the coachee: http://www.vak.solida.net/. Again I think the best time to do the assessment is in the morning, before work really starts.

Step 2:
When the assessment is complete, you will have the 3 in preferred sequence.

You now have material you can use to support the coaching goals and plans where learning is required. You also have the approach you need when explaining concepts to the coachee - a real time saver and much more enjoyable experience for you and the coachee as compared to approaching from the worst angle. And even more enjoyable if you're going to have to explain in your non-usual communication style. Personally, once I realised what my preferred/natural learning approach was, I realised why I was bored out of my skull and kept falling asleep in school and university lectures. Really useful stuff!

My favourite coaching tools: 1-1 meetings

2012-05-16T07:00:00Z

Caveats:

1-1 meetings can be intimidating, especially for those who have had none or very few, or they've been used by managers purely for reprimands instead of growth opportunities.

I've learned what I know through experience and reading - especially I think Johanna Rothman and Esther Derby's Behind Closed Doors: Secrets of Great Management is a must read for running successful 1-1's.

Requirements:

Safe quiet space - sometimes hiding in plain sight eg in canteens is also a good place so long as you can still hear and see each other perfectly.

Notepad and pen - I advise using low-fi as much as possible as they are less intrusive and always work. Easy to update later, and refer back to before your next meeting.

Optional:
Highly recommend scheduling 1 hour sessions every 2 weeks way in advance at a time in the diary of the coachee that is a good time - preferably not straight after their hard meetings and preferably not when they are most needed by their team members or managers for important things. Change takes concentration, focus and commitment - as coach you can't control these but you can be skilful in making them more possible.

Step 1:

The trick is to have an open discussion, full of open questions. At the beginning, it seems a bit strange for people who have never done this before to know what to say, what to ask, so it is important to build up a relationship by taking an active interest in discovery about what is common to both. To discover the opportunities where you can offer some advice or shortcuts, to discover other areas where you may need more tools or data from others to truly help the coachee.

I generally give my 1-3 minute intro, and ask the coachee to do the same, picking up on common career moments, or outside interests, or phrases or - whatever catches my attention. And then start to ask questions around those things, ensuring as I do that the coachee relaxes. If the coachee does not relax, there is always a next time to try again. While coaching is not counselling, deep relationships are still established and must be done sensitively and sensibly.

I take notes especially of things I can do outside the meeting to help - for instance referals to other people, books or websites. Towards the end of the meeting I setup a working agreement/plan about what I will do for the next meeting, and what the coachee will do eg meet someone, read a web site. In the early days the "homework" I give is usually short and used as basis for conversation in the followup 1-1 meeting.

Step 2:
I like to summarise the meeting in an email, especially what I have to do and by when, and what the coachee has to do and by when. For some coachees, this might be the opportunity to complete an Myers-Briggs for me/them (see Free online Myers-Briggs Type Indicator).

The way I create these summaries is important and simple. After every meeting, I summarise in email by forwarding the previous emailed summary. This creates a rolling log that is extremely easy to manage, always backed up by email servers, and a simple format to check progress - dates, timeline sequence, agreements, what was done, what was not done, etc very easy, and I've successfully used weekly rolling logs in this way for over a year. But this does not replace my low-fi notepad and pen for during the meeting - I sometimes also end up drawing things!

Step 3:
I do my "homework" (or actions if you prefer such speak). This begins to form the basis of trust for someone who does not know me - I do what I say, repeat, repeat. And I hope that the coachee is also doing their "homework". Sometimes I drop-in and check if I can help to ensure that the actions are being done - especially in cases where progress is slow or non-existent. I like to discover what in the workplace could be blocking the coachee - in order to strategise to unblock progress.

Step 4:
The 2nd 1-1 about 2 weeks later. It usually goes a lot smoother as the ice is broken and there is progress to report on both sides, and some homework to specifically discuss and put effort into. Or, there is no progress and this too is something to specifically discuss and decide to put further effort into or not. In opt-in engagements, people opt-in by doing, and they opt-out by not doing. There is no right or wrong as it is all about what can be done with the time and effort allowed.

I like to hear about what work problems were encountered since the previous 1-1. What they thought about the homework, what questions they have now for me. Then I like to clarify and rephrase my understanding. If there is homework output/outcomes then we discuss that for a bit (helps to know a lot more about the homework you've given in order to have a fruitful and enlightening discussion!).

During all this talking, again I am making notes like in the first meeting. And I am checking each item on the agreement list of what the coachee achieved, and what I achieved. Usually this cycle results in a couple more actions for both of us, and then I request the next piece of homework....

And this essentially is how I use 1-1's. They're status meetings, repeated, to enable shared understanding and for me to offer help as well as point in the direction of useful things as homework for the coachee. This inevitably creates more work for both of us - just enough for us to do in the 2 weeks inbetween.

Some tips:
If the homework is too much, then it is not completed - for either of us.
If the meeting is too long, then summarising it is too hard - try to always leave wanting more!
If there is no progress, and it seems like there won't be before the next session, decide together to stop sessions until there is enough slack time again for the coachee to continue their growth plan

For extra depth in getting 1-1's right, I also highly recommend Stephen R Covey's The 7 Habits of Highly Effective People.

Interesting ways to turn things around: If 1 person tells you...

2012-05-15T14:14:00Z

There is an old story that goes something like:

"If 1 person tells you are drunk, then they're probably drunk.
If another person tells you are drunk, then you're probably drunk!"

Let that sink in for a moment. There seems to be some truth in there, that applies not only to intoxication but to all our human behaviours!

A friend of mine added something like:

"And hence all the excuse and motivation you need to stay out and dance it all away before closing time/midnight/dawn!"

Perhaps dancing is one of your strengths if drinking is not!

My favourite coaching tools: Clustering

2012-05-11T07:30:00Z

Caveats:

No caveats - so far over the years I have been using this, sceptics and even those who know the technique and have a feeling about what will be revealed, all use it willingly and correctly.

I first experienced clustering during a software project retrospective facilitated by 1 of my seniors in 2007. Since then I've read up on Esther Derby and Diana Larson's Agile Retrospectives: Making Good Teams Great (Pragmatic Programmers) must have book, as well as Luke Hohmann's Innovation Games: Creating Breakthrough Products and Services, and seen just what gold clustering produces!

Requirements

Either a clean wall or large clean table surface

1 or more participants

Cards, Post-Its, or similar small, low fidelity things that are easy to pick up, have some information on them, and place somewhere else (for brevity, I will refer to these as just cards)

Step 1:

Each card contains either some writing (eg data collected from team members during a retrospective, news articles) or some graphic (eg pictures, photos, Archetypes, etc). Spread all the cards out and get the group to have a look/read through them in a timebox.

Depending on the size of the group, the number of data cards, 5-10-15 minutes should be sufficient for each timebox. It is the pressure of the timebox that drives the right outcomes in a group setting, but for 1-1 sometimes a little less pressure is more beneficial - be guided by your coachee!

Step 2:
Again setting the timebox, ask everyone to cluster: everyone has to find cards, attempt to keep them on the surface or near, 1-at-a-time, and move that card closer to one or more others that the card is related to in some way either obvious or not. Essentially we're facilitating the creation of categories without names (so far) that are important to this group, in this data, in a consensus building way.

Step 3:
Often the wall or table is too small for the group and/or number of cards, and often some members of the group like to stand back and watch, rather than participate. Your job as facilitator is to make sure every person moves several of the cards, and participates/contributes to the creation and destruction of the clusters. I often just use a "line up" method and request people to move back as I think they've had enough time, and request people to move forward as I think they have not had enough time.

A major team-building side-effect/benefit of a small room/surface at this time, is that people actually have to talk to each other and negotiate with verbal or non-verbal cues as they try to move past each other - which all adds up to better team understanding and cohesion! Of course this adds to Health and Safety concerns, so be sensible.

Step 4:
Once the clusters are settled, as facilitator you need to quality check them. Are all the bugs in the bugs cluster? Are all the specification problems in the specification problems cluster? And all the risks are in the risk cluster? And all those others we're unsure what to do with, they're in the miscellaneous cluster? Right?

WRONG! However, to extricate from the above incorrectness, a useful way is to take each miscellaneous card and recluster as much as possible from the unuseful clusters around that.

Alternatively, request the group to try again, this time finding other relationships such as timing, specific people, specific technology failures, specific bug etc etc ... and see what cluster data then appear. And then ask them to try again, and again, until really, there are some real and new themes that have emerged!

Step 5:
Now ask the group to collaboratively name the clusters according to the following rules:
1. Short concise descriptive sentences are better than
2. Short descriptive phrases are better than
3. A list of words are better than
4. A single word

And rotate the writer of the cluster name for each cluster. The group has reach consensus - again a great team building activity to practice in low-risk non-crisis moments! The name of the cluster is written typically on a different colour card, or with a different colour pen, or font, and is usually underlined to distinguish it clearly from "data cards".

If a good name can not be agreed on by consensus, often it means the cluster should be broken down again, and this is a good thing! People, especially in fast changing environments, learn more from retrying than just getting on with old themes, old behaviours, old attitudes. This is a high energy, exciting, engaging, positive, great thing to do, not boring, unless you're letting the person or group members do it wrong. A little uncertainty, discomfort goes a long way to really getting to the heart of [hidden] matters.

At this stage, for the coaching technique of clustering, we're done. We have allowed underlying themes hidden in data cards, to emerge into categories that are somehow, and some why, important to the individual you're coaching or the team you're facilitating, who have been making consensus after consensus, and not really trying to out-think the future consequence of the enjoyment they're getting from this physical exercise. And if you then "litmus test" the discovered themes, generally the coachee or group members agree they would never have suggested those as areas where there is some weakness or strength to be explored further with goal setting and plan creation to achieve.

Clustering can be used for so many purposes where there is data, and you're trying to let hidden themes emerge.

(*tip, if you ever need to use post-its, experiment with them to find the best ones for your purpose. Usually you would want "super stickies" in bright neon colours. Also, these days post-its also come in A3 size even - perfect for walls where tictac or bluetac has been banned, and much cheaper than the really cool Magic Whiteboard which I also use and think is great for complex ad hoc charts!)

My latest saying!

2012-05-11T02:05:00Z

Oil and water don't mix, without a lot of shaking!

My favourite coaching tools: Positivity ratio

2012-05-10T09:00:00Z

Caveats:

Dr. Barbara Fredrickson, author of the book Positivity: Groundbreaking Research to Release Your Inner Optimist and Thrive provides an online and free lab-tested tool to assess an individual's positive emotions versus negative emotions. According to her research a 3-to-1 positive ratio leads people to the tipping point where they become resilient to any adversity and effortlessly achieve their dreams/private thoughts/musings.

A coachee who does not achieve such a high and healthy ratio has a lot of scope for seeing things differently, if they acquire the right skillsets and knowledge - with support from the coach and others of course. This tool can be quite emotionally challenging for people, so use it wisely, only with those who can cope well enough beforehand as you might not the right person to help take them from where they are now, to where they should be...a lot of the negativity might be outside work context, and if it is in the work context, you certainly have a lot of work to do.

Again this is a scaling test, so mood and environment are big - HUGE - influences on the results.

Requirements:
Internet access
Quiet space and 5 minutes

Step 1:
Provide Barbara's Positivity Test to the coachee. I suggest doing the assessment at the beginning of the day, before work really begins.

Step 2:
Discuss the results with the coachee. If the coachee wants to improve their positivity ratio, keeping an effective diary, other tools available on Barbara's website, and books like Stephen R Covey's The 7 Habits of Highly Effective People are good places to start, as well as of course whatever tools you as coach already have. You can once again set some goals and assist creating a coaching plan to achieve them!

My favourite coaching tools: Free strength finders test

2012-05-09T08:00:00Z

Caveats
Some people like to identify natural weaknesses and then work really, REALLY hard to try to overcome or diminish the effects of those weaknesses. Some people like to identify natural strengths and then work to improve those - basing the argument that there is a higher Return On Investment (ROI) on the time invested to take a good skill/behaviour to great. It is also far more enjoyable, and hence becomes a self-fulfilling cycle of improvement, and naturally diminishes the amount of time spent on doing weaker strength things. Success breeds success, and failure breeds something else.

This is another scaling assessment so I believe mood and environment affect the results. I learned from doing the Myers-Briggs Type Indicator assessment every 3 years or so, that my type shifts around. And this is sensible in my opinion as by knowing yourself better, setting some goals and working on different behaviours and attitudes, it is good to have the long-term confirmation that you are changing!

Possibly this free online test is similar to a more comprehensive test which comes with a workbook - Strengthsfinder 2.0: A New and Upgraded Edition of the Online Test from Gallup's Now Discover Your Strengths which sounds great. I have not looked into it.

Required:
Internet access
Quiet space
10-15 minutes

Step 1:
Give this link to the coachee: RichardStep Strengths and Weaknesses Aptitude Test (RSWAT). Again I think the best time to do the assessment is in the morning, before work really starts.

Step 2:
When the assessment is complete, you will have the "top 5" strengths (again, statistician George EP Box's "all models are wrong, some are useful" applies!). And a list in strength order of the other 29 the test apparently covers. There is some alignment between the MBTI and this RSWAT. And with this test you get a ranking order of 28 small types/aspects of the personality, so useful, in my opinion

You now have material again to either focus coaching goals and plans on making more use of the top 5, or making less use of the bottom 1, or improving skillsets around the bottom. All up to the coachee and your understanding and guidance!

My favourite coaching tools: The free online Myers-Briggs [personality] Type Indicator [assessment]

2012-05-06T10:00:00Z

Caveats:
I feel you can use this tool with anyone, and definitely yourself too. There's enough useful information about Myers-Briggs on wikipedia here: Myers-Briggs Type Indicator. I received a professional evaluation a couple of years ago and as far as I remember there were a few more questions asked, and there was also confirmation of type strength after the assessment with the professional. All of my favourite coaching tools attract George EP Box's "all models are wrong, some are useful", and this 1 especially receives this treatment before I request coachees to undertake it. One of the issues with the MB test is that its results vary depending on the mood and environment of the person completing the assessment.

Required:
Internet access
Quiet room and time - I usually suggest the morning, before the work day really begins

Step 1:
Coachee completes the questionnaire at: http://www.teamtechnology.co.uk/mmdi/questionnaire/
It is possible to only collect the free report - which requires either screenshots or saving the individual pages as PDFs, or to pay for the full the report. Usually the free is enlightening enough and to have a good conversation around.

Step 2:
Provide the coachee with the MBT detailed page, found off the high-level page here: http://www.personalitypage.com/html/high-level.html

Step 3:
Discuss the accuracy of the type and preferred leadership style with the coachee and see what insights are generated by discussion alone.

Step 4:
To develop more self-awareness, ask the coachee to think about the type of their spouse, family members, friends, favourite managers. I like to use the phrase my mother taught me: "birds of a feather, flock together" and another that Robert Cialdini's insightful book taught me "we like those who are like us" at about this point.

Step 5:
To develop even more self-awareness, ask the coachee to think about the type of people they've had problems with in the past, their least favourite colleagues, least favourite managers. I like to use the phrase "oil and water don't mix, without effort".

Step 6:
At this point, it is possible to identify either a strong or weaker area and thus supporting skillset and behaviours that can be even further explored and/or improved on with confidence - especially if the coachee is for instance in different kind of organisational culture that is in opposition to their natural style.

* Interesting - or for more confirmation in my own experience - for certain roles in some organisations I have deployed this in, it was possible to collect several results from a number of people and begin to see similarities that must stem from the hiring decisions and career path management. Great insight! And really, not bad for a few minutes of a free tool!

My favourite coaching tools: Archetype cards

2012-05-04T11:00:00Z

Caveats:
With a deep enough commitment and explanation, even sceptics will allow a sensible coach to do this exercise with them. In certain situations though, the cards may look a little dodgy so, be sensitive and sensible when using them - and more discretion is often beneficial

Background:
Over the years I've attempted to define my value system, my principles, my motivations, my behaviours etc.

It started off with being given a blank piece of paper and told to "think hard", and "now write down your most important, or top 5-10, values" which left me with "writers' block" pretty much every time. Eventually as time ran out, I would scribble down things that sounded "good".

Then the tools got more sophisticated, and I was given a sheet of "values" and told to circle the top 10. Again, as time ran out, I would circle the ones that sounded "good".

The tools got even more sophisticated and suddenly I had 60 odd cards in my hand and I had to sort them, halve the pile, halve it again and again, until I had just 10 or 5. And inevitably I would reach a pile of 30, and really struggle to bring that down to 29, let alone 10.

Every time, I felt I had just managed to pick some [semi-]random words that sounded good. Every time it was deeply unsatisfying to me. Over the years of working, I noticed a similar thing happening to my career - I do not fit into a box! (certainly not a small, typical org-chart box anyway)

So whilst pondering what this all meant in the background, another coach showed me Caroline Myss' Archetype Cards.

Required:
Quiet room
Big enough clean table
Archetype cards (Archetype Cards: An 80-card Deck with instruction booklet)
Pen and paper

Optional but not required:
Read the instruction booklet that come with the cards
Read the book behind the cards: Sacred Contracts: Awakening Your Divine Potential (hey, coaches read a lot of different things! The wise ones anyway...)
Type all the card names, light attributes and shadow attributes into 3 columns in a spreadsheet

Step 0: Shuffle the deck and make sure all cards are pointing the same way.

Step 1: Spread the cards out, face down and let the coachee pick a random 1. Make a note of the card name.

Step 2: Put the random card back and shuffle the deck again. Give the deck to the coachee to look through so that they get an understanding of what is really in it. Explain light attributes are typically considered "good" and shadow "not good". Explain this is just a model, and that the model is not 100% right, but it is valuable nevertheless at providing some valid insights.

Step 3: Depending on how self-aware the coachee is, you need to do this part of the exercise in different ways and it takes longer/shorter. You're aiming for about 10-24 cards, but this is determined really by the coachee, not the coach or some rulebook. It is a sliding scale that will become visible only once begun.

Ask the coachee to now go through the entire deck, look at each card's name especially, and briefly on the light attribute.

Very self-aware: ask for the coachee to pull out any card that resonates with the person

Not self-aware:
1. Ask the coachee to pull out all the cards they like, as fast as possible
2. Ask them to check the discard pile again and pull out cards they overlooked, as fast as possible
3. Now ask them to go through the "like" pile and discard any that are definitely not some aspect of "them" that they play/show at least once per day

Step 4: Ask the coachee to "cluster" the cards that they see are related to each other as quickly as possible. To ensure they're doing it correctly ask them to explain the relationship/theme they're thinking of when 1 cluster is 3 cards big.

Step 5: Once the clustering is complete - looking for 4-8 clusters approximately, again depends on the coachee. Ask the coachee to come up with a short sentence / a descriptive phrase for each of the clusters. Sometimes they might only choose 1 word, sometimes that is enough. It is their journey...so balance carefully what you know, what you think you know, what you think the coachee knows.

Step 6: Ask the coachee to write their own Light Attributes and Shadow Attributes for the clusters - using concise sentences or phrases. AVOID single words, comma separated.

Step 7: Record all the information - cluster names and card name members, all the Light Attributes, all the Shadow Attributes

* Tip copy the card names, Light Attributes and Shadow Attributes from a spreadsheet, into a spreadsheet just for this coachee.

Step 8: Now take a copy of the card names and their attributes. Ask the coachee to edit the attributes to better reflect themselves. It could mean deleting the entire attributes, or changing from multiple to single or from single to multiple. Changing from external to internal focus or vice-versa. Essentially change it to themselves.

DONE!

This information is now in 4 categories:
1. Random
2. The "like" pile
3. The clusters, cluster members, and cluster attributes
4. The edited for self

You now have 3 categories (2-4) that can be used as reflections of the values and principles of the coachee!

Either or all of the 4 categories, or specific members of these categories, can be used to ground coaching goals and plans around. The Random card can be used as a magnet to learn new skills, or as a mirror to compare against, or as a single card to represent the coachee.

My favourite coaching tools: The record, typeup and playback

2012-05-03T10:57:00Z

Caveats:
I feel you can use this tool with anyone - no matter how open/closed you/they are. You can use it for yourself even. However I do realise that it is possible some thing(s) might come up/be mentioned that require a much more safe environment and a much more experienced+educated counsellor to really deal with appropriately. Try to avoid those things.

Required:
Quiet room
Pen and paper
Knowledge of Johari Window (http://en.wikipedia.org/wiki/Johari_window)

Optional, but HIGHLY desirable:
A sensible/sensitive enough recording device (that you have previously tested) is preferable but this exercise can still be extremely fruitful without

Step 0: Record the date, start time and coachee name on the paper - remember to record the end time as well. Make sure your own mind and body are comfortable and restful - you too will be fully engaged in this session for it to go well!

Step 1: Make sure your coachee is focussed and engaged and happy to be recorded. If the coachee is happy, start the recorder, else put the recorder away. Prepare for much note taking.

Step 2: Ask the coachee to pick the start date. Usually in a work environment I ask for the date to be when they met for interviews or their first day at work. Take brief note of the date and try to understand the coachee's body language.

Step 3: Ask them to try to cover as much ground as they can in 15-20 minutes - their timelined biography of what they did, what they learned, what they felt, how their career progressed. Usually the coachee is really good at timeboxing the story they're telling, not that it matters too much. What's important is capturing what is remembered and very important - how it is remembered. Make notes, and make notes of questions that you might want to raise to get more of the story and emotion surfaced.

Step 4: Ask the questions and record the answers - look especially for areas which you believe might be important in the person's work life that were not mentioned (obviously this depends on how well you know the person by this stage). Avoid questions that are beyond the scope of the relationship you have with the coachee at this stage

Step 5: Wrap up and explain what happens next, make sure the coachee is comfortable and thinks enough was said (you can paraphrase the timeline). Turn off the recorder and take a note of the time! End the session.

Step 6: Get some headphones, play the recording back to yourself slightly slower speed, and type everything that was said. You don't have to analyse it, but you need to make sure it is an accurate type-up of exactly what the coachee said - beware of the shortcuts you would and DID take mentally during the interview. Type what the coachee said, and how they said it - if they giggled, or hummmed, or errrrrrred, or paused... make sure to catch their words, not your translations. Initially you think this will take a long time, and it does, but you do get better at it, and your typing does improve a great deal! This is because your WIP memory expands a great deal it is exercised more thoroughly and intensively.

* As an aside it is interesting and educational for you/yourself to also take a note of what you thought you heard, and what was actually said!

Step 7: Read through the type-up and make notes for yourself about what you see that the coachee does not - this feeds into the Johari Window rooms. I've found spiritual and leadership potential, I've found root causes of huge levels of frustration and anxiety at work, trust issues and lots lots more.

Step 8: Have another session with the coachee. Ensure they are safe and engaged. Provide the type-up document, and the audio file back to the coachee. Ask the coachee to read through the document and if there is anything missing, add to it.

Step 9: Now you can give the coachee some work to do and this is where you need to be a little creative sometimes. You've now uncovered some things - either content, emotion or personality - in this person's [life] story at work over this period, that they're not aware of - and it might be good to educate the coachee about Johari Window at this stage.

Often there is enough in the type-up for the person to really think about, and together you can plan some coaching goals and work to achieve them to improve an aspect even at this stage.

Often there is more, deeper work that can be undertaken by the coachee on their journey if they become more aware of it. However you, as coach, in this session, are not allowed to give direction. You are allowed to design 1-2 "filters" though to help the coachee sort and categorise things, which might make them more aware of things about themselves they are currently blind to.

I used different filters for coachees to apply successfully in the past:
- Mad / Sad / Glad
- What Went Well (WWW) / What Did Not Go Well (~~WWW~~) / What I Learned (WIL) / What Puzzles Me (???)
- I lead / I followed
- Drop / Keep / Improve
- Motivations: Health / Mental / Spiritual
- Recognised for / not recognised for

And I am sure there are many more. With the categorisation done, allow the coachee to reflect back to you what it means. Sometimes they have many questions, sometimes they don't understand what they have just done, sometimes they do not profess to having learned anything new or worthwhile from the time invested.

But often they do, sometimes they even see the things you see. Sometimes they see things you did not (the rose-tinted spectacles take a long time and much practice and reflection to become clear!).

Whatever they outcome is though, the coachee now has material and some idea(s) about what coaching goals to prioritise and work towards with your help.

Step 10: Make some notes for yourself about how the session went, the type-up, what you learned at the various stages, and what the outcomes were. How did the coachee's body language reflect different things as they were saying them, and did this concur when you asked the questions? This is also about continuous self improvement, in order to help others on their journeys much more effectively.

Waltzing With Bears by Tom DeMarco and Timothy Lister

2012-05-03T10:08:00Z

Why I recommend Waltzing With Bears:
Reason 1: It is a very fast read covering many topics concisely and accurately
Reason 2: It is the best book I've read about risk and managing risk
Reason 3: And the shortest best book on estimating

It has been 3-4 years since I read this book and I still recommend it to every PM and PMO and any other team member who is interested in the topics in it.

Moving Mail to a New Laptop

2012-04-30T10:17:00Z

My wife was getting fed up with her eMac running slower and slower, plus incompatibility between her MS Office X and the MS Office 2010 in use at her company, so for her birthday she got a Windows 7 laptop. Until the weekend just gone, however, she didn't make much use of it because it was beyond her ability to move her mail account from Entourage to Outlook and to move all her files across. The address book was a particular problem.

Eventually we found ways to achieve almost all these migrations. The document files were the easiest part - local area network connection, turn on Windows sharing on the Mac, just drag the files over (we had to retry a few times because the connection reset while copying long files).

To migrate the mail messages, we decided to use Thunderbird instead of Outlook (this PC doesn't connect to a corporate Exchange server). Drag each folder from Entourage to a Finder folder or the desktop. This exports the messages in the form of a .mbox file. Rename to remove the extension and copy them to Thunderbird's Mail folder in the current profile.

The mail addresses turned out to be rather a tougher proposition. You can export each address card to a .vcf file, but Thunderbird found no useful information in them. It dawned on me later that this might be a line-ending issue - we could have run mac2unix and then unix2dos before importing. But by then we had solved the problem in a different way.

Entourage allows you to drag address cards to the Mac's native address book application. This was synchronized with Plaxo using my wife's account. Plaxo supports export of the address book in LDIF format, which Thunderbird was able to import without problems. If you can't use this route, you can also export the entire Mac address book in a single operation to .vcf (or possibly even to LDIF). I suggest adjusting the line endings to Windows conventions before attempting to import to Thunderbird.

Then it turned out that the vast majority of e-mail addresses that she needed were not in either address book. Entourage just maintains a cache of recently used addresses and we could find no way to export all of these into any sort of useful file format. To the rescue came Adam Haeder with a simple shell script to extract plausible e-mail addresses from mbox files. I was able to adapt it for use under Cygwin and enhance it a bit to cope with non-US addresses and escaped newlines and spaces. The resulting tab-delimited file was suitable for import to Thunderbird.

 #!/bin/bash  
   
 # This script will parse an mbox file, displaying all of the From: email addresses, removing ones that  
 # are from postmaster, mail admins, etc  
   
 FILE=$1  
   
 if [ ! -r $FILE ]; then  
  if [ -r /var/spool/mail/$FILE ]; then  
  FILE="/var/spool/mail/$FILE"  
  else  
  echo "Sorry! Neither $FILE nor /var/spool/mail/$FILE exists, or I can't read them"  
  exit  
  fi  
 fi  
   
 # Using cat to read the input means you can run this over many mbox files simultaneously  
 # dos2unix and mac2unix standardise line endings to LF only  
 # First sed script joins lines that have been split with a "=" at line end  
 # grep isolates lines starting with "From:" and egrep -vi rejects all non-human addresses  
 # Next grep discards any lines that contain no email address (@)  
 # The next sed script turns =20 into spaces and discards trailing spaces and "From:"  
 # The next converts [mailto:x@y.z] to <x@y.z> form  
 # Any bare SMTP addresses are converted to "x@y.z <x@y.z>"  
 # Any SMTP addresses with no friendly name but in "<>" delimiters are converted similarly  
 # Finally the "<>" delimiters are removed and replaced with a tab separator  
 # Result is sorted uniquely (ignore case & leading blanks) and converted to DOS line endings  
 cat $FILE | dos2unix.exe | mac2unix.exe |\  
 sed '/=$/{N;s/=\n//}' |\  
 grep "^From:" | egrep -vi \  
 "(postoffice|\  
 postman|\  
 administrator|\  
 bounce|\  
 MAILER-DAEMON|\  
 postmaster|\  
 Mail Administrator|\  
 Auto-reply|\  
 out of office|\  
 Mail Delivery System|\  
 Email Engine|\  
 Mail Delivery Subsystem|\  
 Mail.Administrator|\  
 non.deliverable)" |\  
 grep '@' |\  
 sed 's/=20/ /g;s/\s*$//;s/^From:\s*//' |\  
 sed 's/\[mailto:\(.*\)\]/<\1>/g;s/"//g' |\  
 sed '/^[^<]*$/s/^\(.*\)$/\1 <\1>/' |\  
 sed 's/^<\(.*\)>$/\1 <\1>/' |\  
 sed 's/^\(.*\S\)\s*<\(.*\)>/\1\t\2/' |\  
 sort -ubf | unix2dos.exe

New responsable developer for UML2Exporter wanted

2012-04-25T03:58:00Z

Since a couple of years I'm not working as a developer any more. My position is currently in the upper management. My time for this project get lower and lower.

Now I'm looking for someone else, who will take over the responsability and the work to improve and develop this export utility for EA.

Code is easy to understand and extensions could be made quite easy.

Don't hesitate to contact me.

Lessons learned from building a successful social media app – a series

2012-04-23T16:22:00Z

I gave a WebCast on this topic for SAP last week. You can see the slides here on Slideshare.

Afterwards I thought it would be wise, to formulate some of my thoughts in my blog. Here we go…

Disclaimer: Most of my observations come from building an application (XING by Zühlke) for the Windows Phone platform. Nevertheless I think many of them can be transformed 1:1 for other mobile platforms like iOS or Android.

I divided the lessons learned into several sub-topics and will try to argue from an architect’s and/or product owner’s point of view.

If you need more technical developer-centric information, the blog of my colleague Stephan Gerbling might be good for you…

Lessons learned from building a successful social media app: Performance

2012-04-23T16:26:00Z

This is the first part of (hopefully many) blog entries to describe my and my teams’ experiences in mobile development. In this part I’ll try to point out some observations regarding app performance…

See this intro to get the context.

LL Perf1: The emulator is not your target!

We did a lot of work on our application before we used target devices for real-world tests. This was a big mistake, because we encountered performance issues quite late. We should have known better from the many embedded projects we did in the past – but the phones seemed to be so much faster than other embedded target devices. But they still are devices with limited processing power and limited memory!

At the same time, the Windows Phone emulator runs lightening fast (compared to real phones). One example: One of our cryptographic methods took 20ms in the emulator, but 2 seconds on some phones, 200ms on others.

Bottom line:

Test on the target!
As early as possible!
On as many device types as possible!

LL Perf2: Don’t guess performance!

Many developers tend to judge performance on an emotional level – “feels” good or bad. And this is good! If your performance feels good on important target devices then you’re safe, because your users will judge on performance in the same way.

If your performance doesn’t feel “right”, you need to change your tactics dramatically!

In order to prepare well for this situation, I would like to recommend:

Measure and trace as much as you can (in v1 of your app)!
Be aware of privacy when tracing!
Identify frequently used areas of your app (in order to optimize for v2)
Optimize these areas for optimal performance (in v2)

LL Perf3: Control loading and tell your users what currently happens!

We started our app development with a lazy loading tactic, because our XING app offers many different areas with loads of data (social network activities, private messages, birthday list, visitors, contact requests, contact list with profiles…). It is nearly impossible to load all this data within an acceptable time frame.

Our next mistake was to implement paging algorithms, that worked “automatically” and weren’t controllable by the users.

Both ides were bad, here’s why:

App performance in our experience is judged in 3 main areas:

App startup
Scrolling performance
Page transition performance

If your app is considered bad in one of those areas, it will get extremely hard to earn 5 stars. It is really hard to optimize all of them and feature-rich apps will always have a problem with fast startup, but you need to keep startup time in a certain acceptable boundary.

That means you need to control exactly, when which data is loaded. “Unmanaged” lazy loading isn’t an option. You must trigger data fetching tasks in a reasonable moment and put the user in control of that (show progress, enable cancellation, etc.). The users will need detailed feedback, what the app tries to do. Your users will understand a bad loading performance, if they have a bad connectivity – but your app needs to explain at any time what it tries to accomplish…

For us, these aspects resulted in several architectural decisions:

Offline-mode is default!
Cache most of the loaded data to avoid unreasonable re-fetching of data
Collect a lot of metadata to implement intelligent caching strategies
Fetch important data up front (eager loading of basic information)
Show the user always what the app is trying to do (especially important if connectivity problems occur)
Implement self-healing mechanisms, if something goes wrong with caching (and we all know this can and will happen…)

Also remember: your mobile app is just one client to the server system – typically there are others – you need to consider “background activities” – the server state might have changed without the app noticing. Some of your users might change constantly, so “continuous client” ideas should be followed, see kellabyte’s blog for inspiration....

Rethinking Automated Testing

2012-04-15T21:32:00Z

While you’ve been worrying about your BDD adverbs the iFart dev just made $40,000.

- Iain Hunter

Can you give 140 char synopsis of "opportunity cost of TDD?"

Is #TDD always a "Best Practice"? Is there even any such thing? When shouldn't you use it? What could you do instead?

- Conversation on Twitter

Testing implementation is terrible terrible terrible.

- Matt Rogish

The pendulum is swinging back and forth in the TDD and developer-testing world...
I blogged over two years ago about Testing Backlash and then again one year ago Are you too agile for TDD/BDD?

It seems the time has come for the pendulum to swing by once again. In an almost mystical conjunction a lot of alpha geeks are voicing current "new" insights about automated testing and TDD.

Maybe this is the developer community climbing the ladder to another stage of competence or to another stage of grief (the viewpoint is probably depending of the pains in your current project)… but maybe it is just that alpha-geeks like any other intelligent beings are getting bored after a while and turn to new topics.

Anyways, here is a list of the recent tide of "let's rethink automated testing":

Michael Feathers: Taking Automated Tests Off The Pedestal
DHH: Testing like the TSA
Scott Bellware: The Inflection Point - How Long can you Safely Avoid Automated Testing
Alberto Gutierrez: The evil unit test.
Hopefully soon Dan North: The opportunity cost of TDD

Just for completion I am reenumerating older reflections on the topic:

The Dark Side Beckons? by Obie Fernandez
Test-Driven Development and Embracing Failure by Steve Freeman
Problems with TDD an Essay by Andrew Dalke. Heavily discussed on his blog and on Hacker News.
Ayende's posts: Even tests has got to justify themselves and re: Are you smart enough to do without TDD
And finally Luce Francis brilliant presentation: Testing is Overrated (matching blog post, slides)

Update:
Tudor Girba: When testing does not cut it

If you like this, follow me on twitter ...

ipod shuffle and Ubuntu (11.10)

2012-04-15T18:34:19Z

Sports make a lot more fun with some good music. So I decided to buy one of this ipod shuffle.

In the store the clerk ask me if I have a mac or pc. So I told im I have a pc. The next question was which windows I use and I told him linux. He replied that he is not sure if this will work.

For the rest out there it will work, probably not as good when you have itunes, but you can upload your music and thats all I care about.

First install the gnupod, which is a command line tool for managing your ipod. Ubuntu has already a package for gnupod.

sudo apt-get install gnupod-tools

Plug in the ipod shuffle and it should be automatically mounted at
/media/IPOD/.

After that we have to initialize the ipod file system.

gnupod_INIT -m /media/IPOD/

All you need now is a tool to sync your music with the ipod shuffle. I use gtkpod and it works fine for me.

Tutorial – BDD and Dependency Injection in .Net (1)

2012-04-12T17:33:21Z

This tutorial focuses on Behaviour Driven Development, Dependency Injection and application design in general. The primary technologies being used will be SpecFlow and MS Test. While we are targeting the .Net platform the content is applicable to most object oriented languages.

A Brief Introduction to Behaviour Driven Development

Behaviour Driven Development (BDD) is an ‘outside in’ or ‘top down’ development approach. Development starts from the user interface downwards as opposed to starting with the database design. When there is no user interface (as in the beginning of this tutorial) we work from the highest level possible.

BDD encourages thin slices of work. Where we break features down into very small ‘end-to-end’ pieces of work. This work is expressed in the form of examples. This is known as specification by example and we will see this in the tutorial.

In SpecFlow speak, each example is known as a scenario. We need to implement a number of scenarios before the feature is considered complete. We will flesh out the design as we implement each scenario.

The following diagram from The RSpec Book shows the BDD cycle:

As depicted, there are two levels of testing – high level system or integration tests and lower level unit testing. The high level tests often drive a user interface and may be referred to as automated acceptance tests.

Not only will we be following the BDD cycle, but we will only implement the code we need to make the existing tests pass – and no more. We will be very strict with this. This may seem tedious to some however this approach is good to practice. You can always fall back to this approach should you become stuck when writing production code.

Interestingly TDD was always meant to have multiple levels of testing. In Extreme Programming Explained, Kent Beck and Cynthia Andres have the following to say about architects: “Architects on an XP team look for and execute large-scale refactorings, write system-level tests that stress the architecture, and implement stories”. This is similar to what we are trying to achieve in BDD. In fact Dan North introduced the term BDD to help him explain TDD to developers. This is why I say that BDD is TDD done properly.

These days it is common to hear teams say they are doing “TDD but not BDD”. By this they sometimes mean that they are writing system tests and unit tets, but they are not using a “BDD testing framework” like Cucumber or FitNesse. There is nothing wrong with this approach. Sometimes “we do TDD but not BDD’ means that the team members are not writing system level integration tests. This is better than no tests at all, however it is not true TDD and they are missing a trick.

A Brief Introduction to Dependency Injection

James Shaw does a great job of explaining Dependency Injection (DI). He points out that “Dependency Injection means giving an object its instance variables”. The instance variables are typically reference types which provide a layer of abstraction. We can give an object it’s instance variables through a number of different ways namely constructor injection, property injection, method injection.

There are many reasons for using Dependency Injection. The most obvious reason is that it makes the code more testable. It makes it easy to use mock objects in place of the real dependencies during testing. Testability is not the only reason, when done properly code which uses dependency injection tends to support the SOLID design principles, most notably the Single responsibility principle and Open/closed principle. This will be shown in the tutorial.

Dependency Injection is a simple concept, the confusion seems arise when Dependency Injection containers enter the discussion. For this reason I will not use DI Containers for the first few parts of this tutorial. All I will say is that DI Containers may help when composing objects, however they are not required to implement the dependency injection pattern.

The Tutorial – Part 1

When I began playing cricket at school, the coach instructed me to change the way I gripped the bat. At first the new grip seemed strange and uncomfortable. After many practice sessions I began hitting the ball further with more accuracy while using less effort. When I adopted TDD I went through a similar experience. I first felt discomfort and frustration but after practising the technique I found I was achieving better results with less effort.

In this tutorial we will build a Rock Paper Scissors game. We will focus on building a library that can be used with any front end e.g. a console application, WPF etc.

Part 1 covers the solution set up and the basics of SpecFlow. In this first section we are cover the set up and we get used to the BDD cycle. There is no dependency injection in this part, we will move onto that and more interesting topics in part 2. I will not spend much time explaining SpecFlow, we will get the hang of it as we go.

Solution Setup

Firstly download and install TechTalk.SpeckFlow. We will also need the latest version of Moq.

We begin by creating a new project in Visual Studio. Select a Class Library (C#) template. Name it RockPaperScissors. Class1 can be deleted.

Add a new project to the solution. This should be a Test Project (C#), call it RockPaperScissorsTest. UnitTest1 can be deleted. Add the two new folders called Tests and Specs. Then add a ‘Steps’ folder under the ‘Specs’ folder, see image below.

The Tests folder will contain the unit tests, the Specs and Steps folders are used for SpecFlow tests.

Add a reference to the latest version of Moq, TechTalk.SpeckFlow and the RockPaperScissors class library.

SpecFlow uses NUnit by default. In order to use SpecFlow with MS Test we need to add an App.config file to the test project. Modify the App.config file to look as follows:

App.config

<!--?xml version="1.0" encoding="utf-8" ?-->

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <section
       name="specFlow"
       type="TechTalk.SpecFlow.Configuration.ConfigurationSectionHandler, TechTalk.SpecFlow"/>
  </configSections>
  <specFlow>
    <unitTestProvider name="MsTest" />
  </specFlow>
</configuration>

Enter SpecFlow

Add a new a SpecFlow Feature file, with the following:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

This contains a Feature and a single Scenario. The Feature is the user story. The Scenario forms a part of the specification, see specification by example.

Next we map the feature file onto code. This is done by adding a SpecFlow step definition file. Add a step definition file to the steps folder and call it ‘PlayRoundSteps.cs’. Delete all the sample steps.

No we need to define steps in the step definition file that match the lines within the feature file. The SpecFlow plugin makes this easy for us. In the feature file, right click on the line “Given the computer makes a secret code of rock”, then choose ‘go to step definition’. This will give you an option to copy the generated code to the clipboard. Select copy and then past this step into the ‘PlayRoundSteps.cs’ file. Repeat this for other three lines in the feature file. At this stage the PlayRoundSteps.cs file should look as follows:

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            ScenarioContext.Current.Pending();
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"the result shoussld be ""Player Wins!""")]
        public void ThenTheResultShoussldBePlayerWins()
        {
            ScenarioContext.Current.Pending();
        }

It is possible to run the SpecFlow tests by right clicking on the feature file and selecting ‘Run SpecFlow Scenarios’.

When using Cucumber, the steps are generated with a comment similar to “Now enter the code you wish you had” – and that is exactly what we need to do.

To start we remove ‘ScenarioContext.Current.Pending();’ from all steps and then implement the following code (which will not compile at this stage):

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add("Game", game);
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {

        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get("Game");
            Assert.AreEqual("Player Wins!", game.Result());
        }

The ScenarioContext is used to share objects between steps. At this stage the code cannot compile as we don’t have a Game class. Next we create this class in the RockPaperScissors assembly. Next we add the required method.

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string Result()
        {
            throw new NotImplementedException();
        }
    }
}

Now the code should compile and running the tests will throw a NotImplementedException. To fix this we drop down into unit testing.

Adding Unit Tests

In the Tests folder, create a unit test called GameTest.Add the following test:

GameTest.cs

        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            Assert.AreEqual("Player Wins!", game.Result());
        }

At this stage we are duplicating the SpecFlow test in the unit test.There is little benefit at this stage. We are simply following the BDD cycle. Experience has taught me that it is better to introduce unit testing sooner rather than later. It is easier to remove redundant tests than to introduce unit testing late in development.

We are only adding what we really need. You are welcome to go faster if you wish, however I would like to show very small steps in this tutorial. Be patient, we are changing our grip…

The unit test should fail. Then we make it pass by adding the simplest bit of code we can in the Game class.

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string Result()
        {
            return "Player Wins!";
        }
    }
}

That should make the unit test pass. We then run the SpecFlow test, and that should also turn green.

At this stage I am not that interested in a complete implementation of the games’ rules, I am trying to flesh out the architecture. We know we are nowhere near a complete solution, but we do have our first scenario passing – progress!

Test Driven

We want to use tests to drive out the logic. We should write a test that exposes our hard coded “Player Wins!” line in the Game class. The easiest way to do that is to write a test that expects the computer to win. We move back up to high level testing and append another Scenario to the SpecFlow feature file:

PlayRoundFeature.feature

Feature: Play a single round of Rock Paper Scissors
	As a player
	I want to play a round
	So that I can test my luck

Scenario: Computer chooses Rock and the player chooses Paper
	Given the computer makes a secret choice of Rock
	When I choose Paper
	Then the result should be "Player Wins!"

Scenario: Computer chooses Rock and the player chooses Scissors
	Given the computer makes a secret choice of Rock
	When I choose Scissors
	Then the result should be "Computer Wins!"

We then add the two new step definitions:

PlayRoundSteps.cs

        [Given(@"the computer makes a secret choice of Rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose Paper")]
        public void WhenIChoosePaper()
        {

        }

        // Added
        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {

        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        // Added
        [Then(@"the result should be ""Computer Wins!""")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

The new test should fail with an appropriate error message e.g. Expected “Computer Wins!” actual “Player Wins!”. Now we drop back down into unit testing and replicate the test:

GameTest.cs


        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            Assert.AreEqual("Computer Wins!", game.Result());
        }

This unit test should fail, similarly to the integration test we wrote using SpecFlow.

With the intention of taking small steps, we look for ways of doing the least amount of work to get the unit tests to pass. The computer chooses Rock in both tests, it is only the player choice that changes. Therefore we use that in our logic. First we alter the unit tests as follows:

GameTest.cs


        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

Then we do the least amount of code in the Game class to make the tests pass. After refactoring, I ended up with:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        public string PlayerMove { private get; set; }

        public string Result()
        {
            return PlayerMove == "Paper" ? "Player Wins!" : "Computer Wins!";
        }
    }
}

Later we will add more tests to drive out this rudimentary logic. At this stage we have the unit tests passing. We we still need to use the new PlayerMove property in the SpecFlow tests to get them passing. Before doing that it is a good idea to throw an exception if the PlayerMove property is used before it has been set. We drive this functionality out through tests:

GameTest.cs


        [TestMethod]
        public void ComputerRock_PlayerPaper_PlayerWins()
        {
            var game = new Game();
            game.PlayerMove = "Paper";
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [TestMethod]
        public void ComputerRock_PlayerScissors_ComputerWins()
        {
            var game = new Game();
            game.PlayerMove = "Scissors";
            Assert.AreEqual("Computer Wins!", game.Result());
        }

        [TestMethod]
        [ExpectedException(typeof(ArgumentNullException))]
        public void ThrowsErrorIfPlayerMoveIsNotSet()
        {
            var game = new Game(new DescissionEngine());
            game.Result();
        }

With the implementation being as follows:

Game.cs

namespace RockPaperScissors
{
    public class Game
    {
        private string _playerMove;
        public string PlayerMove
        {
            private get
            {
                if (String.IsNullOrEmpty(_playerMove))
                    throw new ArgumentNullException("PlayerMove");
                return _playerMove;
            }
            set
            {
                _playerMove = value;
            }
        }

        public string Result()
        {
            return PlayerMove == "Paper" ? "Player Wins!" : "Computer Wins!";
        }
    }
}

We then move onto the failing integration tests, they need to use the new property:

PlayRoundSteps.cs

namespace RockPaperScissorsTest.Specs.Steps
{
    [Binding]
    public class PlayRoundSteps
    {
        private const string GameKey = "Game";

        [Given(@"the computer makes a secret choice of rock")]
        public void GivenTheComputerMakesASecretChoiceOfRock()
        {
            var game = new Game();
            ScenarioContext.Current.Add(GameKey, game);
        }

        [When(@"I choose paper")]
        public void WhenIChoosePaper()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Paper";
        }

        [When(@"I choose scissors")]
        public void WhenIChooseScissors()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            game.PlayerMove = "Scissors";
        }

        [Then(@"the result should be ""Player Wins!""")]
        public void ThenTheResultShouldBePlayerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Player Wins!", game.Result());
        }

        [Then(@"the result should be ""Computer Wins!""")]
        public void ThenTheResultShouldBeComputerWins()
        {
            var game = ScenarioContext.Current.Get(GameKey);
            Assert.AreEqual("Computer Wins!", game.Result());
        }

    }
}

We now have a total of 5 tests passing, three unit tests and two SpecFlow integration tests. There is still a lot more to be done, including refactoring the SpecFlow tests to use the table feature. In upcoming posts we will see more of SpecFlow and we will use dependency injection.

Please let me know of any mistakes I have made, and any topics you would like to have covered in the follow up posts.

Filed under: BDD, C#, Extreme Programming, TDD, Tutorials, XP Tagged: BDD, csharp, dependency injection, specflow, unit tests, XP