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

Advertisements

XP2016 – Day 1 – XP at Scale – Elisabeth Hendrickson

Standard

Some notes from the opening Keynote at XP2016 from Elisabeth Hendrickson.

Some Principles at Pivotal:

  • Separate what & how
  • Sustainable Pace
  • Automate
  • Ensure fast feedback
  • Team Own Quality
  • Reflect, Adapt, Experiment

Pairing is really important. Do it as part of your recruitment.

Scaling problems are highlighted in the analogy “Tragedy of the Commons”

“Without intervention work rolls down hill!” Sometimes teams need to help and guidance.

Why isn’t XP practiced widely?

Some more Pivotal Principles…..

  • Use Conyway’s law to your advantage
  • Teams own things
  • Team that owns that thing tests that thing
  • Relentless feedback cycles
  • Increase Empathy
  • Collaborate, reduce Hand Offs

Empathy is our advantage….

“Don’t do it for me, do it WITH me”

If Field engineers encounter problems they are encouraged to pair with the team to get it resolved. Pair all the time with everyone!

Some new techniques Pivotal have applied……

  • Big team standup
  • Cross team retros
  • Allocations/Rotations
  • Cross Team Pairing
  • Regular Exploratory Testing

Some new roles at Pivotal…

  • Engineering Director / Leadership Liaison
  • Product Director
  • Product Manager

Closing comment…

Excellent Keynote!

I will be blogging throughout the conference. You can check out my previous post about Dan North’s workshop here

XP 2016 – Dan North – Software Faster

Standard



Today I attended Dan North’s @tastapod Workshop “Software Faster” at XP2016.

Here are a few things I learnt:

Learning #1

What is the goal of agile? Predictability

Learning #2

5 Steps in an Organisatonal Change journey:

  1. People Break
  2. Tools Break
  3. Governance Breaks
  4. Money Breaks
  5. Organisation Breaks


Typically alot of Agile Transformations focus on stages 1 and 2. They struggle to move to stages 3, 4 & 5. Often there is a conflict between people at each stage. In many cases stages 3, 4 & 5 are controlled by the “Frozen Middle”; Middle Management. Real breakthroughs only occur once issues are tackled at the later stages. Dans tip to change these stages is to “Use the system to change the system”

More: https://www.amazon.co.uk/Agile-Adoption-Patterns-Roadmap-Organizational/dp/0321514521

Learning #3

Marginal Gains will focus on optimising the existing system. For example if we focus on a 10% improvement we won’t rip up the rule book. For example, people might just starting working longer hours or doing over time. However if we focus on a 50% or higher improvement it will often make us think more fundamentally about our currently processes.

Learning #4

The point of Agile is not to create Software, it is a tool to deliver business capability.

Learning #5

The Goal of software is to:

“Minimise lead time to Business Impact.”

Lead time defined as:

“Having a need to having a need met”

It is easy to improve Lead time once or twice in isolation but it’s really hard to increase lead time “Sustainably”

When does the lead time clock start? As soon as you make a commitment to the person who requested it.

Can you measure lead time if you cannot measure business impact? No.

The big challenge is that measuring business impact is hard! Often teams use proxies such as Story Points rather than genuine impact: Number of users, Profit etc.

If you just focus on Lead Time it will lead to local optimisations.

More: https://dannorth.net/2013/07/05/are-we-nearly-there-yet/

Learning #6

Definition of a stakeholder: “People who’s lives you touch”

Learning #7

A good facilitation technique is to use the analogy of travelling between islands to explain the days agenda.

“Today we will start on Organisation Island, the swim across to Legacy Land, then drive to Core City and finish at the Planning Plateau.”

Learning #8

Three Ages Model can be used to explore where an organisation is:

Age 1 = Explore

Age 2 = Stabalise

Age 3 = Commoditisation


Often Organizations will misuse the ages. For example: try to commoditise testing by offshoring when it is an inherently exploratory activity.

More: https://www.slideshare.net/mobile/AdrianTreacy/dan-north-embracinguncertaintyv3

Leaning #9

PARC Model


More: https://www.amazon.co.uk/Modern-Firm-Organizational-Performance-Management/dp/0198293755

Learning #10

Apply “training from the back of the room” Encourage the attendees to teach each other. Example: In the next 3 minutes put together a pitch to explain what the PARC model is. At the end you will present this to another group”

Here is a group teaching each other:


More: https://www.amazon.co.uk/dp/0787996629/ref=cm_sw_r_cp_api_rshrxbDSR808Y

Learning #11

Value Stream Mapping Tips:

  • It’s easy
  • Get the real people who do the process involved
  • Don’t worry about rounding numbers
  • Make it viable

“Become less efficient to improve flow. Introduce sub optimisation.”

More: https://www.amazon.co.uk/dp/1935401009/ref=cm_sw_r_cp_api_6HhrxbNF4G6C6

Learning #12

Focus on reduction of Value at Risk(VAR) by working incrementally.

More: https://en.m.wikipedia.org/wiki/Value_at_risk

Learning #13

Dan finished the session playing a game called Taboo. Each person had to create a taboo card and then we played the game in groups.

This was an excellent way to reinforce the learning. Also another great example of “Training from the back of the room”

More: https://en.m.wikipedia.org/wiki/Taboo_(game)

Thanks Dan for a great day. Now onto post workshop drinks!

When to Coach and When to Mentor

Standard

Until recently i hadn’t thought much about the differences between Coaching and Mentoring. I’ve come to learn there are big differences and most recently started thinking about: When to Coach and When to Mentor?

What is Coaching?

The definition i’ve been using most recently is from Timothy Gallway:

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

What is Mentoring?

In my research for a sound definition i came across a good collection of definitions on the Coaching Network

One that stood out to me was:

“Mentoring involves primarily listening with empathy, sharing experience (usually mutually), professional friendship, developing insight through reflection, being a sounding board, encouraging” – David Clutterbuck

So what are the differences?

This is not an uncommon question. Look through google and you’ll find many people who have asked the same question. One of the top results i came across is from Brefi Group

Mentoring Coaching
Ongoing relationship that can last for a long period of time Relationship generally has a set duration
Can be more informal and meetings can take place as and when the mentee needs some advice, guidance or support Generally more structured in nature and meetings are scheduled on a regular basis
More long-term and takes a broader view of the person Short-term (sometimes time-bounded) and focused on specific development areas/issues
Mentor is usually more experienced and qualified than the ‘mentee’. Often a senior person in the organisation who can pass on knowledge, experience and open doors to otherwise out-of-reach opportunities Coaching is generally not performed on the basis that the coach needs to have direct experience of their client’s formal occupational role, unless the coaching is specific and skills-focused
Focus is on career and personal development Focus is generally on development/issues at work
Agenda is set by the mentee, with the mentor providing support and guidance to prepare them for future roles The agenda is focused on achieving specific, immediate goals
Mentoring resolves more around developing the mentee professional Coaching revolves more around specific development areas/issues

There are a number of things that stand out for me here. In particular:

  • Mentoring is generally long term whilst Coaching usually has a set duration focused around a specific goal
  • Mentoring involves  the mentor offering advice, usually from a more experienced stand point. Coaching is the opposite, the Coach will avoid offering advice and enable the Coachee to reach their own understanding through powerful questions.

The Agile Coach as Mentor and Coach

Part of the Agile Coach role is to Mentoring and Coaching. I recently attended an Adventures with Agile meet up where Lyssa Adkins and Michael Spayd spoke about the Agile Coaching Competency Framework:

Agile-Coach-Competency-Framework-for-website.0011

You can see Mentoring and Coaching are two elements of the framework. As an Agile coach this creates an interesting challenge: When to Coach and When to Mentor? 

When to Coach and When to Mentor?

My initial thoughts are that everyone can probably benefit from both. However at various times maybe the person might need more of one than the other.

Recently i’ve been coaching many people across my organisation. As part of any coaching engagement i’ll start by establishing what the individual knows about Coaching. Often it will become apparent that they are explaining a Mentoring relationship (Long term, advice based, sharing experience). That’s a good opportunity to explain the differences. In this situation it’s good to talk through the differences and assess the needs of the individual. In most cases there is room for both coaching and mentoring.

This creates another dilemma for the Agile Coach; can you coach and mentor the same individual? My view is that the coach should help the individual find a suitable mentor outside the coaching relationship. This enables clearer boundaries for the coaching sessions. A good example would be finding an experienced developer to pair with someone more junior.

I’d love to hear if anyone else has encountered this question of When to Coach and When to Mentor.

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.

Testing a RESTful API using Supertest

Standard

This post explains how to test a RESTful API using Supertest.

There are many great blog posts that explain how to test NodeJS Express API’s using Supertest. For example:

This post explains how Supertest can be used to test any RESTful API even those that don’t run through express.

Setup

You will need a couple of node packages to get going including:

  • 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.”

Once installed your package.json should look something like this:

Testing API

To try out Supertest i tested http://postcodes.io/ – Postcode & Geolocation API for the UK

Searching for a single Post Code (GET Method)

APIhttp://api.postcodes.io/postcodes/SW1A1AA

In this method the user can query the Post Code data for a single post code. If valid, the API returns further detail.

In the tests below you can see a basic example that calls the API with a given Post Code and then performs assertions on the response. You can see in all three cases i’m checking the Status Code of the response and also inspecting the JSON response to ensure the correct data has been returned.

Searching for multiple Post Codes (POST Method)

To search for multiple Post Codes we need to POST an array of Post Codes to the API. To do this we pass in a JSON object to the service, in this example three post codes.

You can see we are again checking the status code of the response. In addition as multiple post codes are returned we iterate through the response to ensure the results match our search.

Summary

Supertest is really easy to use. You can very quickly write a series of tests for your API. Posting data and inspecting responses is very easy.

At this point i haven’t tried with a secure API that requires authentication but the documentation suggests that this shouldn’t be a problem.

Present Moment Coaching

Standard

On Thursday 21st April I attended a “Life Coaching” Meet Up called “Present Moment Coaching” hosted above The Engineer Pub in Primrose Hill, London. I wasn’t really sure what to expect but it was an interesting evening.

What happened?

There were around 12 attendees at the Meet Up. A mixture of Professional Coaches, Students studying Coaching and even a fellow Software Tester.

To kick off we went around the group to share “What is coaching to you?”

In my previous blog posts i’ve explained that i’m exploring deeper into my understanding of Coaching so it was good to hear thoughts from a varied group of people. Answers included “Helping unlock an individuals potential”, “Thinking from the heart not mind”, “Not giving advice or your opinion”. During the early discussion we also explored the difference between counselling and coaching which we talked as; Coaching = Looking at the future vs Counselling = Looking at the past.

Present Moment Coaching

Following introductions we did the first exercise.

“In this Meet Up we will learn the art of Present Moment Coaching.  Present Moment Coaching is a a very simple method to help clients  to take back possession of their life as well as being a remarkable and effective way to  self coach.”

In the exercise we all practiced being “Present” for a few minutes. Dan, the meet up organiser talked us though some techniques. Once time was up we shared experiences amongst the group. These included:

  • Became more comfortable with surroundings
  • Focus on your breathing helped
  • Became more aware of body
  • Let things be – e.g Noise in the room. Acceptance.
  • More aware of tiredness
  • Noise of the pub reminded some of their childhood
  • Overhwleming sense of joy and happiness

Coaching in Pairs

Following this exercise we moved onto the second part of the Meet Up where in pairs we had the opportunity to practice coaching and being coached.
This exercise was really valuable. It was good to be able to practice coaching in a safe environment.
My key take aways:
  • My questioning skills in a coaching situation can be improved. I felt i was missing “Powerful Questions”
  • My listening skill has improved recently. I’ve been studying the work of Nancy Kline and this has helped massively.
  • I wasn’t sure when to offer solutions and ideas. Through the discussion after the coaching session we talked that as a coach we should avoid offering solutions.

My first experience of a “Life Coaching” Meet Up was pretty interesting. The opportunity to practice coaching and get other perspectives with other Coaches was really good.

See you at the next Meet Up?

Present Moment Coaching

Thursday, May 26, 2016, 7:00 PM

The Engineer Pub
65, Gloucester Ave, Camden London, NW1 8JH, GB

18 Coaches Attending

The Coaching Exchange is a place to meet and exchange coaching with others.Present Moment Coaching is exploring with your client what is happening for them in the present moment. Often we seek to ignore what is happening now because it means being with our discomfort.Our normal reaction is to judge our discomfort or do something so as we do not fe…

Check out this Meetup →