I’ve been practicing mindfulness for several months and it has made a good difference in my life.

Here is a good introductory video:

Meditation 101: A Beginner’s Guide from Gobblynne on Vimeo.

Active Listening

One of the agile games I play with my teams is meant to help encourage active listening. As the quote above states, most people are not listening to understand but to reply.

The game that I utilize to help people change to active listening is called “Fortunately/Unfortunately”. In this game, which I believe started in Improv, the team builds a story. The first person starts with a “fortunately”, such as “Fortunately my wife is pregnant”. The next person needs to be actively listening and then responds off of that statement with an “unfortunately”, like “unfortunately, it’s not with your baby.”. The story keeps building with alternating “fortunately/unfortunately” until it gets back to the originator, or goes around a few times.

This technique helps the team to have some fun and gets them into the habit of active listening.

I had a team that exhibited all the wrong ways of doing this exercise. After I started with “Fortunately my wife is pregnant” the next person stated “Unfortunately the Raptors are out of the playoffs”, and the following person said “Fortunately you like kids”. Both people were not listening to what the previous person said and had their own agenda or thought out reply already in mind.

A couple other positive outcomes come from this game. The first is embracing the silence. If you are truly engaged in active listening there will be a definite pause after the previous person finishes speaking. Silence is fine.

Another outcome is the unspoken agreement to let each team member complete the task on their own. Very rarely does a turn come to a member and have another member speak up and interrupt with their own idea. Each team member is able to come up with their own solution in their own time.

Try this game at your next team gathering. It will really help highlight why we need to be actively listening in our meetings, and in life in general.

What Happens if We Fail One or Two Sprints?

(First published on the Scrum Alliance Website)


I ran a Scrum Master Summit for my company recently where we invited the 42 Scrum Masters for a day of learning for them and for us. At the end of the planned session we had a “Lean Coffee” discussion where anyone could vote on the topics for discussion.


One of the more interesting topics that unfortunately didn’t get any votes, was “What happens if we fail 1 or 2 sprints?”.


I think you should be failing more often than 1 or 2 sprints.  As a team we need to be challenging ourselves more, trying new things, and experimenting. That will lead to failure, which will lead to learning which is great for it’s own sake.  I want the teams to fail, but I want them to fail fast. Try something new for a sprint, see if it works, how you can tweak it, what is un-usable, what can be taken away and then start again. Get into a pattern of trying and failing.


In talking to the Scrum Master who wrote this, their concern was around velocity. They are concerned that they should be hitting the exact number each and every sprint. It’s actually good that they are NOT hitting the number sprint after sprint.  They should be challenging themselves with a higher number every once in a while. It would be too easy to not challenge yourselves and keep the same number sprint over sprint, set the number 10 points lower than what you know your team can do and coast.  But that’s not good for the morale of the team, for the education of the people, for the project/sprint, really for anyone.


So they should set the sprint goal higher than what they have been, with the team’s agreement.  And not just gaming the system by making a 5 point story an 8 point story, but by taking on more than what you would normally and seeing if you can do it.


Or keep the same velocity target and trying pair programming. Anything that gets your team trying new things, learning and pushing their boundaries, either personal or team based.


The question however has some deeper undertones unfortunately.  Traditionally in the work world failure is punished and we have ingrained the fear of retribution into our people. I think the question is based on that, the “What will management do to us if we fail 1 or 2 sprints?”.  I think most companies that are working in an agile manner and have adopted the agile mindset will be open to experimentation and failing. Fortunately where I work we are encouraging this, we want our people to try, to strive for more, to learn and yes to fail. Management will do nothing if you fail, so keep trying.


Velocity and other metrics are meant to offer a team an opportunity to improve, to give them insight on how they are performing.  They are not to be used to measure teams against each other, to say that team “A” is better than team “B” simply because their velocity is 10 points higher. Management should be looking to the teams to see how they can help them become better, not to be using metrics as a punishment tool.


To answer the original question “What happens if we fail 1 or 2 sprints?”; you learn.

Something all Scrum or Agile practitioners need to know

Sharpies are cool!

Difference between a Scrum Master and an Agile Coach

I was fortunate enough to be the MC at the Happy Melly Exploration Day event in Waterloo recently and was asked this question that I think deserves some exploration.

I do have a question for you about transitioning from Scrum Master to Agile Coach. I heard opinions that say that it’s just a title, and that in fact Scrum Masters often do very similar things to coaches anyway. I agree that this can be the case in some companies, but my observation has been that Agile Coaches usually get a wider mandate and hence are able to better foster overall organizational growth. Also, Agile Coaches could potentially coach more than Scrum. And, here I have limited evidence, but I think there is usually a salary difference, too. So I’m curious about your take on it. What are the biggest differences between Scrum Master and Agile Coach?


It is true that Scrum Masters and Agile Coaches do similar things, however at different levels. It is also true, as you state, that Coaches to get a wider mandate, not only to coach the executives but SM and teams as well. You are seen as the overall expert, answering questions, reviewing sessions, providing feedback and guidance and helping to plan the journey. What are the next steps? What training is necessary? Who should be trained? What do you do about a SM that isn’t performing? About a team?

There is a salary difference, but that depends on the expertise of the Coach, the industry, and the mandate.  It can be a pretty wide range, and that again depends on the maturity of the organization that is hiring you as companies new to the agile process might not place as much value on the role as it deserves.
The biggest differences are what you are expected to do. A Scrum Master works with “A” team. An Agile Coach works with ALL teams, AND executives AND other teams/groups. A Scrum Master ensures that the team is following the Scrum process, doing the ceremonies and behaving the right way. An Agile Coach helps to define what is to be done, how, who does it, when, why, how it fits in with the organization, change management, people management and interactions between agile teams and other parts of the organization (like Dev Ops, Hosting, Build teams, Education, UX/UI, etc).

The main difference is the level that the two are operating, single team or enterprise.

Agile Metrics

Ugh. What are you supposed to do when the executives ask for an “X”% improvement in the performance of your agile teams?

I’ve been researching and reading a bunch of things to try and come up with a solution to this problem and so far it seem like there is no solution. Any way you try and measure a team’s performance can be ‘gamed’.

  • Velocity. Easy enough as the team tracks velocity each sprint. As soon as they become aware that they are being evaluated on velocity it is simple enough to make a 3 point story a 5 point story, or an 8 point into a 13 point. Boom! Instant productivity gain.
  • Stories completed. This is a better metric, however it sets the team up for some  bad practices. Product Owner needs a simple change? I need a Story for that.  We are being measured on stories? Okay, let’s break the stories out into Dev and QA tasks, also let’s add a CRT task and start putting in tasks for our Agile Ceremonies.

In addition to the bad practices for the stories the good practices that you may be trying to instil, like breaking large stories down to smaller stories, will again lead to a false result in productivity improvement.

All the articles I have read about Agile Metrics have not been any help either.

  • Five Agile Metrics you won’t hate list “Sprint Burndown”, “Epic & Release Burndown”, “Velocity”, “Control Chart” and “Cumulative Flow Diagram”
  • Measuring Team Performance states that you should use the ability to hit the Sprint Goal, with the caveat that if a team continually hits their sprint goal then they are under performing. This might be a good way to evaluate how the team is doing, but not for measuring any kind of improvement.

The overall goal is definitely to make the teams better, more productive. The issue comes in when the metrics are to be used to evaluate the teams against each other. This can not and should not be done. A team that has a velocity of 120 points per sprint is NOT better than a team that does 40 points.

Executives that are not as experienced in Agile are looking for ways to either judge teams against each other or measure success of improvements through the use of metrics.  In “Metrics you can bet on” Mike Cohn discusses how metrics can be misinterpreted and that as an organization you need to be very careful to measure at the correct level.

Great care must be taken when going down this path. Executives have investors and boards that they are accountable to and have to show value for the money they are spending on these activities.

I think better metrics are turnover rates, happiness factors and improvements made. Look at the teams’ retrospective action items, how many are they solving? How often are people leaving the organization?

No matter what metric is being gathered it is very difficult to use any of it to evaluate team against team or team performance over time.

Happy Melly Exploration Day!

Very happy to be involved with this program.  I will be co-MC’ing the event with Jeff Kosciejew!  We promise there will be MAGIC!




Get your tickets here: https://www.eventbrite.ca/e/happy-melly-exploration-day-tickets-26636167494


Agile from the eyes of a 20 year PMP veteran – No Project Plans

I admit, I used to love project plans. I was a master of MS Project, with a sub-specialty in GANTT charts. I could link and unlink, change durations and critical paths with the best of them. You need a project to end in November, bang! it ends in November (the 30th, but still November).

Now, I cringe when I see them. I realize how much wasted time and effort went into these. And the wasted bullshit. “Can you finish testing by the 15th?” “Abso-fucking-lutely” and they still aren’t finished to this day.

Douglas Adams summed up deadlines very nicely with this:

Deadlines - adams

Hours spent changing dates, futzing with dependencies, all to make something that wasn’t going to happen. Countless useless meetings, that had been scheduled and re-scheduled multiple times, which to be honest, should have been the first clue that the plan wasn’t going to work.

Under Agile the fixed project plan goes away in favour of getting work done.  However,  the Project Management Pyramid still holds in one aspect, flexible scope.

Project Managment Pyramid

Utilizing Agile you are able to get a better understanding of scope and, it seems, people are more willing to negotiate on scope, which helps bring in the cost and time elements as well. You only have 3 months until release? Fine, we are going to work on the items that have the highest value.

All this doesn’t mean you don’t need to have a plan (and saying this is going to make some of my friends in the Agile community get mad at me).  There are other parts of the organization that rely on the output of the development effort and need to have an awareness of when things are happening so they can coordinate items on their side.  Letting Load & Performance testing know that you are delivering, and when you are delivering, gives them the ability to plan for the work that is coming to them. Release management, sales, marketing, security, hosting, and support are all groups that need to have a forward notification that projects are coming their way.  The main difference between a ‘traditional project plan’ and the agile plan is the way in which it is communicated.  You don’t need to send a thousand line plan to all the stakeholders to get their approval and buy in.

project plan updated

You need to involve them in the Vision Sessions, the demos, and grooming sessions so they know when things are coming their way, can better plan for what is coming and put items on their own boards to handle the workload and timing. I’ve held hour long ‘planning’ sessions (they really were scrum of scrums but I couldn’t title them that) to make sure all the teams were aware of what was coming, and what changes were happening in schedule and scope.

No need to spend hours updating and sending out a project plan before a meeting, only to have the content of the plan change during the meeting, requiring a subsequent update that becomes out of date as soon as it was documented. Communication is the key.

Fun Communication skills game

I been working with Jason Little (@jasonlittle) on delivering Vision Collaboration Workshops for my company, PointClickCare. By ‘working with’ I mean he’s been doing all the presenting and I get to stand around, watch him and chip in my 2 cents whenever necessary.  I will be conducting this workshop on my own in the coming months and leaning on Jason’s experience to get me through them.

One of the great games that he has introduced me to is a communications game that highlights the benefits of doing things the agile way.

You break the group into two teams, “Product” and “Developers”.  Have the Developers leave the room while you give the instructions to the Product team.  The Product team is given a picture:



and 5 minutes to write a specification document describing how to draw this.  The Developers come back in and read the spec and draw what they have read.  They are not allowed to ask the Product any questions other than handwriting clarifications.

You get some very interesting diagrams:

Agile drawing

Agile Drawing 2

Bull Symbol Agile Drawing

The instructions said “draw the bull symbol from the stock exchange”, so I can see how this happened.

Ask the Product people if they would accept this version and the vast majority reject.  There are some exceptions, this drawing, for example was fantastic:

2016-08-17 16.01.52

The next round has a different drawing and a different set of rules.  This time, in 5 minutes, you have the Product and Developers sit together and the Product describes what they want while watching the Developers draw.  The only rules are they can not show the Developers the picture and they can not use their hands.

After the 5 minutes you get a very different result. Nearly everyone experiences a sharp increase in acceptability, a better drawing that closely matches what they were working from.

I’ve used this as a team building exercise for a couple teams outside of agile and had great success with it. When using it for communication techniques, I had the teams sit back to back for the first round instead of writing out the requirements. The second round I had them facing each other. It really highlights the benefit of proper communication.

Difficulty: Easy

« Older posts

© 2017 Lee News

Theme by Anders NorenUp ↑