XP2016 – Katherine Kirk – Herding Cats: Coaching Techs and Execs

Standard

One of the best talks at XP2016 was from Katherine Kirk @kkirk. If you happen to be at a conference where she is speaking make sure you attend!! Katherine was one of the most engaging and entertaining speakers I’ve seen for a long time.

Insight Facilitation


In Katherine’s talk she introduced us to the concept of Insight Facilitation. Katherine talked about the importance of enabling people to figure out their own solutions in complex adaptive situations. Often “Agile Coaching” is about Process Education. This might appear to have some early success but once the big problems happen the teams are unable to adapt to the changing world around them. Through Insight Facilitation we want to empower people to handle these situations on their own.

It isn’t easy

As Coaches we can often fall into dysfunctions which can be damaging for the people within our organisations. Katherine talked about 3 common dysfunctions:

  1. Comforter“Trying to make people happy”
  2. Controller“Being the person who always knows best”
  3. Coercer “Leading the witness to your conclusions rather than their own”

These dysfunctions can lead to the following problems:

The Journey

Taking a Coaching approach can lead to interesting reactions from people. Katherine gave an example of an executive who joined a new company and during the early months people would come to his office asking for advice on how to solve problems, his response: “What do you think you need to do?” The simple act of asking this question was promoting empowerment of the individual and ownership.

This example made me think of a book I’ve been reading recently which is all about asking powerful questions; “The Coaching Habit: Say less , Ask More & Change the way you lead forever“. In particular the  book talks about the‘AWE’ question which is incredibly powerful to help explore other possibilities. AWE = And What Else?

Katherine also shared the different reactions she has seen and the journey people take through Coaching which I thought summed it nicely:

Excellent talk and great learning points about Coaching.

Thank You Katherine!


Some of my other posts from XP2016 are here:


 

Advertisements

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

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.