Moving over to a new address…..

Standard

I have moved to a new wordpress address.

You can find it here: https://tobysinclairblog.wordpress.com/

if-you-do-not-change__quotes-by-lao-tzu-60

Advertisements

Are you really Coaching?

Standard

I recently read “Brilliant Coaching” by Julie Starr. The book explores practical ways you can apply Coaching in the workplace. She provides great examples how you can apply a Coaching style moving from Directive leadership to empowering others(Self Directed)

In the book Julie presents a model; the Scale of Influence. This can be used as a model to build self-awareness in your Coaching conversations.

Snip20160813_2

Scale of Influence: Brilliant Coaching, Julie Starr

In a Coaching conversation we may use different levels of influence but we want a good coaching conversation to be more self-directed (left of hand side of the model). In particular Julie recommends that new coaches should try to avoid giving advice or instruction at all.

I’ve recently started using this model to reflect upon the conversations I have with people around me. It has helped to identify times where I could have taken a less directive approach.

As many of my blog readers are Testers I’ve translated what the model might look like in Testing context. For example a conversation between a Tester and a Developer on deciding how to test a particular User Story.

Snip20160814_5

This is a good way to reflect upon the conversations you have with people and understand “Are you really Coaching?”

Next time you are engaging in a Coaching conversation use this model and reflect:

  • How often do you tell someone else what to do?
  • How do you feel listening to someone share an idea when you think there is a better approach? How often do you follow with an opinion rather than asking further questions?
  • When you feel you are the expert, how often do you refrain from sharing advice and ask a question instead?
  • How does silence make you feel?

5 Books about Coaching

Standard

A common question i get asked is “What Coaching books do you recommend?”

Here is a short list of some Coaching Books i’ve read and some that are on my reading backlog.

1. Coaching for Performance: Growing People, Performance and Purpose

images_coaching_for_perform-245x300

What i liked?

  • This book explores the popular GROW Model
  • There are some great chapters about crafting good goals
  • Explains well what Coaching actually is
  • For many this is the go-to book about modern coaching techniques. A best seller thats been around for many years.

Recommended for: Anyone new to Coaching

 

2. The Coach’s Casebook: Mastering the Twelve Traits that Trap Us

41+I4lOgqEL._AC_UL320_SR216,320_What i liked?

  • Very practical examples of coaching conversations
  • Real Life Case Studies from high profile and famous figures
  • Easy to relate to (I often found personal examples in each of the traits)
  • Promotes Coaching Supervision which was a concept that was new to me until i read this book

Recommended for: Scrum Masters (Co-Author Geoff Watts also Authored Scrum Mastery)

 

3. Time to Think: Listening to ignite the human mind

1020273 (1)

What i liked?

  • This book has had a dramatic impact of my coaching approach
  • It will fundamentally challenge you
  • Excellent examples and well written
  • Case Studies towards the end of the book of how to apply the Thinking Environment are very interesting.

Recommended for: People involved in organisational change

 

 

4. Coaching Habit: Say less, Ask more & Change the way you lead

Coaching-HabitWhat i liked?

  • Simple and accessible introduction to Coaching
  • Suggests some power Coaching questions such as the AWE question
  • Techniques can be applied straight away
  • Does not promote a rigid process but looks at how coaching can be built as a habit in everything you do

Recommended for: Managers

 

 

5. Art of Coaching

art-of-coaching

What i liked?

  • Visual!
  • Covers many core coaching concepts but using visual aids
  • Provides great inspiration of how to apply visual techniques to coaching.
  • Techqniues for both individuals and the team

Recommended for: Experienced Coaches looking for new ways to engage clients

 

 

Some more books on the backlog:

XP2016 – Does the Test Automation Pyramid matter and who really cares? – Panel Discussion

Standard

At XP2016 there was a panel discussion focused around the “Test Automation Pyramid”

Testpyramid

The discussion was facilitated using the “Fish Bowl” technique. The starting panel was:


Left to Right: Elisabeth Hendrickson, John Fergusson Smart, David Evans, Simon Brown, Steve Freeman

The discussion kicked off with the following are questions:

So what did we talk about?

The 90 minute discussion covered the following:

  • All models are wrong, some are useful
  • Does it matter? Maybe
  • Who cares? Not sure
  • It sucks because it ignores other types of automation that support testing. Automation can extend beyond Units, Integration and UI. I thought of Richard Bradshaws comments about “Automation in Testing”
  • The Exploratory Testing bubble that is sometimes placed on the top is stupid
  • What is the definition of a unit? No real clarification here
  • What is the the definition of an Integration Test? Tumble weeds……
  • People treat items higher up the pyramid as second class citizens. Tests at the top still add value although the feedback is traditionally slower
  • Pyramid can sometimes be used to assign responsibility. Testers focus on the top(E2E), developers do the bottom(Unit), someone somewhere does tests at the middle (Assuming they know what an Integration Test is)
  • The pyramid is based upon an old “3 tier architecture” model where the Front End was difficult to test and could only be done using “In Browser” tools such as WebDriver. In todays world, this is not the case. With front end frameworks such as AngularJS the front end can be broken down into Unit Tests.
  • What is Testing? Talked about the difference about Testing v Checking. Most of the discussion was about Checking but we should also think about Testing which is not currently part of the Test Automation Pyramid. The Pyramid is not about testing.

  • Uncle Bob Martin talked about how the Test Pyramid is commonly inverted, with most of the business rule tests implemented through the Front End.
  • There was talk about “Plumbing” and the Test Automation. I forget what we discussed exactly.
  • Did the Test Automation pyramid come from the “Food Pyramid“?

food_pyramid

  • The focus of the discussion towards the end of the panel discussion moved into documentation
  • Uncle Bob Martin compared a well written code based to an “Encyclopedia”; It contains a robust collection of state transitions but its hard to search.
  • The Test Automation Pyramid exists because we like to talk in Metaphors.
  • Final comment;
    • Horizontal axis = Amount of Tests
    • Vertical axis = Amount of Pain

Thats me ^

So….what do you think? Leave a comment below.

 

How to do Example Mapping

Standard

A few months ago i came across Matt Wynne’s post about Example Mapping on the cucumber blog. During XP2016  I attended Matt’s Example Mapping workshop. I’ve been using the technique with teams for a few months now. This post will share what Example Mapping is and some of the experiences i’ve had using it.

FullSizeRender

What is Example Mapping?

Here is the process taken from the Cucumber blog:

Example Mapping uses a pack of 4-coloured index cards and some pens to capture these different types of information as the conversation unfolds. As we talk, we capture them on index cards, and arrange them in a map:

We start by writing the story under discussion on a yellow card and placing it at the top of the table.

Next we write each of the acceptance criteria, or rules that we already know, on a blue card and placing those across the table beneath the yellow story card.

For each rule, we may need one or more examples to illustrate it. We write those on a green card and place them under the relevant rule.

As we discuss these examples, we may uncover questions that nobody in the room can answer. We capture those on a red card and move on with the conversation.

We keep going until the group is satisfied that the scope of the story is clear, or we run out of time.

And that’s it. I told you it was simple!

How I’ve used it?

Teams I work with follow a simple principle called “Three Amigos”

three-amigos-main

We apply this to our story conversations ensuring that in each conversation we have:

  1. Someone who knows the problem domain (Usually a Product Owner)
  2. Someone who can technically implement (Usually a Developer)
  3. Someone who can critique the product/solution and think laterally (Usually a Tester)

Usually that results in 3 people but it could be more. We want enough people to have a good conversation.

Our Three Amigo conversations happen in two ways:

  1. Formal – A scheduled session run three times a week. In the calendar at a set time. Voluntary session where the team self-organise and decide who should attend. These sessions last maximum of 30mins.
  2. Informal – Conversations at someone’s desk where a small group gather to discuss a particular feature/story.

It is during these Three Amigo Comversations  that we use Example Mapping.

Benefits I’ve seen with Example Mapping

Benefit #1 – Getting past the first Question

Often during Three Amigo conversations i’ve found that teams struggle to get past the first question. When a difficult question arises the team get stuck on that one question. To overcome this we use the Diverge/Merge/Converge technique with Example Mapping. This allows us to get all our current understanding on the table first. We structure the conversation as follows:

  • 0 – 5 Minutes – PO/BA presents the story and potentially a handful of rules. Just enough information to start a conversation.
  • 5 – 10 Minutes – Individual Brainstorming of Rules(Acceptance Criteria), Questions and Examples.
  • 10 – 30 Minutes –  Discuss

Benefit #2 – Colour Heuristics

As the different elements are colour coded it is very easy to use this as a heuristic for the readiness of the story. For example:

  • Lots of Blue (Rules) story is too big
  • Lots of Green (Examples) might mean our rules are not specific
  • Lots of Red (Questions) might mean we don’t have clarity or there are too many unknowns

Benefit #3 – Knowledge Capture

Often in less structured Three Amigo sessions you can have really good conversations but there is a risk that the knowledge is not captured. In this process you have those great questions and examples captured.

Benefit #4 – Rules not Specifications

I’ve often seen teams write their acceptance criteria as designs or technical specifications. Example Mapping reinforces Acceptance Criteria as Rules. This leads to better examples and ultimately better stories. I’ve seen this be a particular challenge for some teams. If the Acceptance Criteria is written as Specifications its much harder to find good examples which aren’t tied to the technical implementation. Ultimately this process helps you get much better Acceptance Criteria.

Benefit #5 – It’s fast!

Prior to implementing Example Mapping for our Three Amigo conversations our sessions used to be an Hour long. We have now reduced the sessions to 30minutes but run them more frequently. The team finds short, frequent sessions better than longer less frequent discussions.

Benefit #6 – It supports remote teams

We have run the example mapping session digitally. Sometimes we have team members who are out of the office so we use a virtual post it note board.

Benefit #7 – Example format

Sometimes people get lost in the syntax of Examples. Given/When/Then can force people into a certain thought process. This approach allows people to declare their examples in a simple way.

Share and Visualise

It is also important to socialise your conversations. As Three Amigos is a subset of the team it’s important to share any key findings with the rest of the group. A good way to do this is to post your example Mapping sessions on the wall next to the Scrum Board. This way the team can keep track of the conversations. If you have a remote time simply sharing the link to the virtual whiteboard is a good way.

What happens next?

Typically we want to make the decision – Is this story ready? The main driver we’ve found is Questions. Do we have outstanding questions that mean we cannot proceed. It’s fine to have  some questions open if you are confident they won’t impact your ability to proceed in the Sprint. To aid this process a simple Roman vote can help the group decide if the story is ready.

For more about Example Mapping head to the Cucumber blog here

Mocking a RESTful API using Nock, Supertest, Mocha and Chai

Standard

In my previous blog i explored “Testing a RESTful API using Supertest”

In this post i will look at how an API can be mocked using a node package called nock.

Mocking API’s can be incredibly useful for a number of scenarios:

  1. You want to test different responses easily
  2. You want to mock a third party system which you don’t control
  3. You want to simulate some negative scenarios such as a system being unavailable or responding unexpectedly.

Setup

In this example we’ll be using the following:

  • nock – “Nock is an HTTP mocking and expectations library for Node.js. Nock can be used to test modules that perform HTTP requests in isolation.”
  • Supertest – “High-level abstraction module for testing HTTP”
  • Mocha – “Mocha is a simple, flexible, fun JavaScript test framework for node.js and the browser”
  • chai – “Chai is a BDD / TDD assertion library for node and the browser that can be delightfully paired with any javascript testing framework.”

Mocking an API

nock allows you to intercept an API call and respond with a programmed response. The documentation on npm is excellent. It provides many examples of how it can be used from simple responses through to the more complex.

I will be mocking the following API http://postcodes.io/ – Post Code & Geolocation API for the UK.

Mocking a simple response

Here is a simple example that returns a 200 OK and a simple JSON response

Simulating a Time Out

A good example where Mocking API’s can be useful is simulating a Time Out. Good for us is that nock provides this capability out of the box.

In the below example I’m simulating a 10 second delay.

NOTE: Mocha has a default timeout of 2000ms so you also need to increase the mocha timeout otherwise it will kick in before your mocked response completes.

Mocking from a JSON file

To keep your mock responses organized you may want to store them in JSON files to enable reuse and reduce maintenance effort.

According to the nock documentation support should come this with the function .replyWithFile. I tried to use this but found that the body property was not populated in the response.

As a workaround i used node to read in the file and assign it to a variable i could then specify in my mock response.

The JSON file containing the mocked response:

Summary

The examples i have included are pretty simple but can be incredibly useful when testing an API. The nock documentation has a whole host of other examples including:

  • Setting and Reading Headers
  • Reading request body
  • Using regular expressions
  • Replying with errors
  • Filtering

I will definitely be exploring these features further.

What is coaching?

Standard

At the start of this year my job title changed to “Agile Coach”. I’d always thought I had a pretty good idea of what “Coaching” is and that i’d been doing it to some degree in my previous testing and agile roles. Now I was officially a “Coach” i wanted to explore it further. It’s been an eye opening journey.

Firstly lets look at Agile Coaching which Lyssa Adkins defines as:

“Agile coaching is really important because we have a bunch of crappy Agile happening in the world right now. Even when it’s happening fairly well, I just know that pumping up mediocre results faster was not really the main intention behind this way of working.

I think coaches are an integral part to helping teams get to astonishing results because it’s all in the interactions of human beings where that happens. There is no piece of it in the Agile framework that’s going to help you with that. Having Agile framework there and working well, it’s certainly going to provide the structure and the container within which that can happen, the boundaries. But there are so much more to do within those boundaries, so many more things to bring to the team, so many more ideas and things from different disciplines – things from conflict management and facilitation and teaching and mentoring and professional coaching and a few more.” [1]

If we look at this definition Lyssa clearly highlights the benefit a coach can bring to the Agile context. In particular helping teams apply Agile principles and practices more effectively.

Things get interesting though in the second paragraph – “interactions of human beings”. This opens up a whole new dimension to the “Agile Coach”.

Timothy Gallway author of the Inner Game defines “Coaching” as:

“Coaching is unlocking a person’s potential to maximise their own performance. It is helping them to learn rather than teaching them.” [2]

This was an eye opening perspective. When I reflect much of my prior experience has been around teaching. 

In my quest to get a deeper understanding of “interactions of human beings” i’ve been reading Geoff Watts excellent book: 

The Coach’s Casebook: Mastering the twelve traits that trap us.

In the book Geoff explores common traits within individuals that can often trap us such as Imposter Syndrome, Going to Excess and Cynicism. Geoff explains that with the right techniques individuals can harness these traits to become highly successful people.

Geoffs book has provided me with a valuable inisight to coaching and with each trait he provides Tools and Techniques to help harness the traits for good.

 I’m enjoying exploring “Coaching” at a deeper level even though I’m a little overwhelmed by the the small stack of books next to my desk.

[1] – http://www.infoq.com/news/2012/12/agile-coaching

[2] – http://theinnergame.com/noel-posus-overview-of-life-coaching-quotes-tim-gallwey/