Agile Coach Camp Canada 2013 Snapshots from a far…

As much as I would love to travel the world only attending agile conferences and agile unconferences I simply can’t. Instead i’ll review the outputs and create learning snapshots to add to my coaching tool kit. These are some favourites from the Agile Coach Camp held in Canada June 2013.

Note: If you recognise any of your words in these snapshots please let me know so that I can assign you credt. Some of the videos don’t give presenter names.

How to teach anything;
1. The first lesson of teaching is to teach them where they are at
2. We need to discover what their hurdles are – emotional & knowledge
3. Understand what their motives – work with them to find that motivation
Motivation is where you will get the engagement
All learning is made through meaningful association

How many coaches does it take to change a light bulb?
1. Well, it depends
2. Why do you ask?
3. Who’s willing to pay, i’m tired of freebies
4. Who has the problem
5. Do you mind if I ask you 5 questions first
6. Lets visualise this
7. How do you know the light bulb is the problem
8. How do you know it’s fixed
9. We need to add some disciplines to this so we can scale
10. Do you know what your organisation culture is?

“Solve problems, real problems and don’t just focus on agile as the only solution…cause I just want to make the world suck a little less”

“What ever you are scared to do on stage – is exactly what you should do! Is there anything in your life, in this conference come up and do it. The more you get out of your comfort zone, the more you’ll get out of it.”

10 steps to proper motorcycleing cornering, and leaning into the corners of your life – using motorcycling as a metaphor

1. position yourself so you don’t catch your toe
2. prepare your body before the corner
3. use counter-force to lean into the corner
4. set your sites on the next horizon
5. and release into it

“As a coach we ask questions that allow the student to come up with the answer.” (Questions that lead to the insight needed for the student to learn.)

About Lean Agile Coaching Presentation

Join Agile coach Stephanie Bysouth in a conversation about Agile Coaching.What is it? Why does it help? Chris Collins also joins Stephanie to talk about what it’s like to be coached.

An Agile Coaches journey often starts long before one claims the title. Lean Agile Coaches come from a variety of backgrounds; including but not limited to, senior developers, architects, project managers, business analysts, designers, operations. Essentially Lean Agile Coaches come from many places. What start’s to set them apart is that they normally become a team leader, a team mentor as well as a master of lean agile skills.

Lean Agile Coaches will work through a sequence of stages with new teams. The first task for coaches is to observe and learn about the space the are moving into. It’s important to understand the territory, challenges, and natural flow of their current systems before taking a company, team or even managers on an organisational change.
This presentation delves into the why agile coaching, what agile coaches do, and show real profitable examples of how a coach can benefit a team, and companies bottom line.

Lean Agile Coaching Introduction Presentation

Agile Business Analysts Melbourne Meetup Agile Coach Introduction Presentation

Seeing a Balanced View Retrospective

This Retrospective technique is focused on visualising individual votes, opinions or feelings. By using a simple visual metaphor of a see-saw you can capture the essence of the teams position and quickly highlight weather things are out out of balance or weighted evenly.


I recommend creating your own labels for a couple of reasons. Firstly, it’s good to identify what problem you need solved, and use the most appropriate language to help that diagnosis. Secondly, it’s important to facilitate in your language, colloquial cultural style that matches the team you’re with. It’s authentic, and people respond better, open up more when you are authentically yourself.

Some examples of using the same retrospective visual for different purposes.

Capturing the mood Retrospective;
Often a team can get into a slump and stay there. Be transparent about feelings in the workplace is hard. So in a safe space doing a simple visualisation exercise can help them “get out of the feeling” and take a new perspective on what’s going on. The below excerise could include a step to write down why you feel the way you do but sometimes it’s good to just ‘air the feelings first’.


1. Ask the team to quietly consider how they feel about the past iteration (or event)
2. Place a stickie on the scale where it best represents their feeling
3. Acknowledge the distribution or weighting of the stickies
4. Go into discussion and diagnoses withe team
5. Facilitate them to come to a point of actionable agreement

Identify the distribution of performance retrospective.
The purpose of looking into performance is to discover what wrong or what could be improved.

1. Ask the team to quietly consider their recent work, and jot down their why
2. Place a stickie on the scale where it best represents their efforts
3. Acknowledge the distribution or weighting of the stickies
4. Go into discussion and diagnoses withe team
5. Facilitate them to come to a point of actionable agreement about what to do better next time

Good Retro Guide

Continuous Improvement is only a retrospective away

Retrospectives are the art of the inspect and adapt cycles in iterative agile development. They can be done well or poorly just like any workshop but there is a simple approach checklist that will assist you to facilitate for greater team retrospection. Diana Larsen and Esther Darby have outlined a succinct and great top 5 methods for ensuring teams inspect well and adapt appropriately.

1. Set the stage   (social agreement the agreed purpose)

2. Gather some data   (before we decide what to change)

3. Generate Insights   (what does that mean for us?)

4. Decide what to do   (experiment to try…)

5. Close the perspective    (recap decision, review retro quickly)


Setting the stage is an important book end for the start of your session. It’s made up of two essential elements. The social frame & the focal point for this retrospective. Firstly the social frame is similar in purpose to creating a social agreement or team agreement but in this instance it is to help establish the context and recommended behaviour for creating a great retro. The Focus On / Focus Off exercise they talk about in the video is a great summary to establish expected behaviour.



The second component of setting the stage is agreeing on the focal point of the retrospective. Often teams become improvement bored, or reach a stage of ‘whatever’; particularly, if the same format for a retrospective is used each and every time. Setting a goal and focal helps to look at different areas at one time and to decrease the size of the improvement ‘wishlog’. Improvements need to be feasible, doable, and not stress full for teams.



Gather some data on the focal point to get the facts and sense from the teams perspective so as not to have the session dominated by anyone persons perspective. For example if your looking at coding practices have the team write up stats for # of failed tests, # of failed builds, # of successful recoveries PLUS underneath have them chart their energy for coding levels over the iteration.


This will give you a number of facts around what is happening and debunk any assumptions i.e. Geoff is always breaking the build and stuffing us up. The data shows (or not) that Geoff has low energy for coding focus because he’s also on incident management which constantly interrupts his work.


Generate insights from the data, the conversations,  and the anomalies in the data. This is where most coaches use the learning matrix of what went well, what didn’t go well etc have the team think, discuss, and write down. Ask the team if there are any emerging patterns? What’s the causes, is their a convergence point that’s leading to this. Play the what if game to help expand their thinking to get to the cause – what if you had skills, what would our day to day look like if we never had a failed build? (probably weird as it’s a normal part of TDD but it’s a nice simple example to use here) Ask what path from the past lead us to this point?



Decide what to do and be clear about how to achieve it as well. Often in a retro it seems obvious what needs to be done, and people ask why has this never been fixed before? Even though that person may be thinking it’s so obvious it often isn’t AND do answer why has this never been fixed before? It’s a quick way to know if blockers will pop up. What to do should never be so huge the team gets into a helpless rutt and preferably not just ownership of always one person. Teams get used one person always fixing so avoid this mentality as much as possible.

Close the retrospective quickly and decisively. It’s important that the team has final agreement what, how, when they will be doing the improvement action. have the team agree on when they’ll follow up to ensure ongoing support for achieving the improvement is in place. Lastly do a Return on Investment poll to understand how to improve the retrospective. Break even is great, and it’s very interesting after a number of iterations if teams start to see benefit from their iterations.



1. Google Tech Talks: 25th January 2007 Diane Larsen and Esther Darby Authors of Agile Retrospectives: Making Good Teams Great

♥♥♥♥♥♥♥ Every dog lover deserves a designer dog collar or designer dog lead this  Christmas from the Leroy Madison Online Pet Shop ♥♥♥♥♥♥♥


Good Retro Guide

Knowledge Conventions

Knowledge Conventions should use practical short common sense


OK, so I say should quite simply because i’m still astounded that developers or operational staff still to this day use poor disorganised logic for directory or website structure. I’m not sure if they just aren’t trained, or whether the cause is that they create their own cryptic ryhthm but I so wish there was more people like J. Edger out there.

The below is a very simple multimedia and naming convention document I wrote in 2002. It certainly seems quite non remarkable in it’s instruction and format; however, making things stupidly simple does seem to be difficult for a lot of people.

In today’s plethora of information being swamped upon us it’s even more important to have clarity in how you search and filter information.

A few top things to think about are;

– Author in a 3 by 3 rythm

– Powerpoint 3 point per slide

– 3 childs per point (max)

– Only project managers think according to time, the rest of think in terms of components, objects and artefacts. Organise by the character not by the age

How do you organise your information?


2002 Naming Conventions Document

Ask your users how they search? What knowledge do they need vs. what document is a good starting point

Coaching Agile Teams – Lyssa Adkins Review and key lessons

Coaching Agile Teams Book CoverLyssa Adkins is a great command & control confessionaholic! Her experience on both sides of the delivery experience and the transformation she went through between the two is what sets her practical teachings apart from a number of coaches who have only ever experienced agile or green fields delivery. That experience and tuition she provides for coaches to ‘navigate their teams’ along the journey is a good reframe for any agilist thinking of becoming a coach.

I’ll endeavor to note some of the lessons and where I’ve tested out the recommendations as part of sharing my learnings.


The book covers two very important themes – the health of the coach and the health of the team – as stories and lessons are told. The fact that she looks at the health of the coach as a key stigma for the team is what makes this book a bit different from the others. In fact in many subjects the two are interdependent in much the same way organic and environment systems are co-dependent on each other. Even though coaching styles do differ I notice that the majority of coaches ‘forget’ to put their health first, and burn energy rather than be a source of energy.


A good example of the parrallels is the lessons Lyssa Adkins provides on Shu Ha Ri;

  • Shu: Follow the rule.
  • Ha: Break the rule.
  • Ri: Be the rule.


Coaches need to know the rules, when to break them and a coach needs to teach the team the same wisdom so that they aren’t blindly going where the blind have gone before, or as Lyssa Adkins says performs “empty rituals”.

" To surpass one’s master, one must first master the rules—fully. Then break
the rules safely. Then create new rules that allow a deeper expression of the
principles behind the rules. The progression rarely follows this three-step
straight path, however. As shown in Figure 4.1, it’s not a linear progression."

Translation = Often great practitioners start coaching with a zealot approach because they are great achievers, they know miracles are possible and forget to listen and learn from the environment and people around them 😉 Often it’s not just a matter of grandstanding. Humility is such an important part of authentic coaching, having the courage to show humility is a good step towards earning respect as a people leader.

Lyssa talks about the key styles of coaching – teaching, coaching, advising – modelling & reaching. She also mentions that those styles are essentially the stages of coaching a team. Interesting terms to use, I quite like her definitions of ‘modelling’ rather than just saying coaches ‘facilitate’. The language she uses to describe a coaches technique or behaviour adds an empathetic layer of accountability to the people we serve.

If you are a scrum master, tech lead, agile manager or an aspiring coach this books is a must read to create a more robust suite of coaching tools.

Using Outcome Driven Innovation with Agile Practices for breakthrough Customer Satisfaction

Most companies are responding to a market disruption rather than creating one, some innovate beyond expectation. The most popular of our time is obviously Apple and it’s amazing products. Why? Common opinion will have you think Steve Jobs is the cause. Well, yes he was the driving force behind the innovation equation but that equation is not his alone, it is actually a documented process polished by Tony Ulwick, originally a Harvard Business Review article and then fleshed out in his book What Customers Want: Using Outcome Driven Innovation to create breakthrough products and services.

Outcome Driven Innovation uses a few key practices to leverage the combination for a profitible outcome:

1. study the market at present to identify underserved customer demands (opportunity to solve probelems & serve needs)

2. study what the customer does, not what they say (behavioural observation)

I specifically say ‘profitable outcome’ not ‘drive revenue’ because unfortunately most companies think just polishing the way they serve customers will drive revenues – it does initially, but not in terms of being a sustainable market differentiator. Constant innovation is required, as market is constantly changing.

For example; most companies solely focus their customer driven organisation on service models. This is awesome – always serve beyond expectation to ensure advocacy. However, at what cost is that service? Why DISSOLVE the problem all together rather than having an amazing service to manage the problem.

The perfect example is the Strategyn Bosch Case Study. In summary












Product & Service Innovation is such an important part of the new business movement and unfortunately is missed change or restructures when agile consutltants serve companies that aren’t web 2.0 businesses. Product Innovation is assumed to be part of an R&D division alone and often Systems Thinking, Lean and Agile is (rightly so) busy looking inwards at the company on how they working RATHER THAN outwards at the market to drive what’s actually worth doing. Combining this sort of Customer Driven design at each stage of the agile delivery model is what was at the core of Internode successfully being the first to market with real time NBN services qualification tool in Australia, why they are an NPS leader in the market.

We looked at what the market really wants, where they are being underserved, and delivered quickly using Scrum, XP, and iterative feature releases.

This is my presentation that helped transform the paradigm of thinking and show how user stories can get us closer to customer satisfaction.