Monday, November 28, 2016

Change can be fun or exciting

Over the last few weeks, I have seen a repeating theme in my social media feeds.

That theme... "Change is Hard" 

In my lifetime, I have been part of change, both positive and negative. 

Some of that change was imposed on me from above, and some from market forces. In some cases, personal interactions create change. My reaction to these different situations is very different for sure.

If you are a person who helps others to embrace or live through change (whatever your interpretation of change is)....

... consider the damage you are causing by inspiring fear where it simply may not be appropriate or necessary.

I can say from both personal and professional experience...

Change does not have to be hard.

It can be fun or exciting!

Please stop giving the impression that hard change is mandatory.

Sunday, November 13, 2016

Follow Rachel Perry as she learns to use Scrum to deliver a product to improve her community

Today I want to share an inspiring story about a person who is learning to apply agile values and principles through experimentation in both personal and business aspects of her life.

My first sign of this was from a post Rachel Perry made about trying to deliver a newsletter for the company she works for with her team. 

She took her understanding of Scrum to experiment with an approach to delivering a weekly newsletter using "Sprints" and a focus on learning. She blogs about it here at

For those of you that are interested in using Scrum in non-IT environments, it's worth following some of Rachel's learning as she progresses in her journey.

She is also developing social service product
to help communities. Read about it here.

If you would like to learn more, I'm sure she'd appreciate you reaching out to her to learn more (or help in your community).

Good luck Rachel as you progress on your journey.

Wednesday, November 2, 2016

An agile approach helps educators see better financial results to support their students

Someone pointed out today that forgot to post a reference to an article for my usual blog followers... 

Image (c) Blueprint Education, 2016
These two excerpt are from an article published on the Scrum Alliance Member articles section on Aug 24, 2016. It talks a bit about how a new approach can help the business side of charter schools. 
"Central to this turnaround effort was the creation of an Agile culture."

"The discipline of focus produced great results. Relationships also grew deeper from working together through the discouraging times. The result is that the team has developed new competencies, along with an increased confidence." 

If you have an interest in some other posts from this blog about this topic, here are two searches that will give you some more reading material.

link - Agile in Education

Sunday, October 30, 2016

Workshop notes Co-located vs. Distributed Teams and the Agile Manifesto

I recently had the pleasure of presenting a new workshop about co-located versus distributed teams for the Halton Agile-Lean Network in Oakville in collaboration with Nick Norbeck.

We ended up doing this session as a result of a question about some of the principles of the agile manifesto seeming to be in contrast to what people see happening in companies today.

The session involved myself acting as a business person who had a specific market segment and a ton of money to bring it to market (with limited patience ;->).

The attendees spent time working as co-located teams and then an engineered situation where teams would be asked to work on the same product but from different locations and time zones.

When we were done, we asked everyone to note Differences between the first and second round (co-located versus distributed).

As is my style, the question was rather vague. This allows people to bring their own interpretations as to what was important for them. 

Here are the resulting comments from the workshop (in no particular order). I used the exact same Case (capitals and smalls) to keep as close as possible to the originals.  

According to our two teams there were differences between co-located and distributed in the following ways....


  • Anxious
  • Energy Dropped with Distributed Team
  • Positive
  • Positive Energy
  • Increasingly Positive
  • Focus
  • R1: calm, R2: anxious
  • Smaller group -> more energy per person required


  • Communication
  • 1 - more relaxed, 2 less relaxed
  • distributed. uncertainty about integration -> communication
  • more personal
  • collaboration
  • First round felt safer - ALL IN
  • Communication
  • Collaboration
  • more pressure from PO when group is smaller


  • A Stronger Sense of Urgency in the 2nd Round
  • Dedication
  • Strengths & Skills
  • Less connection
  • Frantic/rushed when we got together
  • missing info/stuff
  • :-( other team mates didn't care about other team
  • Teams are much harder to collaborate
  • Skill Matrix is important


  • Clarity
  • Communication Breakdown
  • Quality focused
  • Better definition
  • Webex or Video to Run through sprints
  • just get on with it
  • pre-agreed process or agreement
  • a bit less thinking and or planning in 2nd round

Thank you to the awesome participants of this experiment. It was fun to see the excitement in the room.

Also, thank you Nick. It was great to work with you on this.

References and links

Agile Manifesto Principles

Halton Agile-Lean Network

Join the Halton Agile-Lean Network (anyone in the Halton region with interest is welcome)

Nick Norbeck

Workshop - Co-located vs Distributed Teams

If you think you might benefit from a customized workshop for teams, organizational change or technical practices, feel free to reach out at

Thursday, October 13, 2016

Impossible versus Improbable .. and trust.

A situation I observed recently reminded me of the power of words in building (or destroying) trust. 

- or -

Some examples...

It is impossible for the database to be hacked because It is improbable that the database can be hacked because
It is impossible to sell (x) to (population) because It is improbably that we will sell (x) to (population) because
It is impossible to help because It is improbable they will accept our help because
It is impossible that no one will like this feature because It is improbable that this feature will fail because
It is not possible to make this work because It is improbable that we will get this to work because

Ask yourself...

Which version of these comments might build or destroy trust?

On a somewhat related thought path...

Which version of these comments might encourage or discourage...
  • dialogue
  • collaboration
  • teamwork
  • an open mind
  • a project schedule
  • excellence

Consider your own experiences and conversations lately, and ask yourself.. Did I use the correct word to describe the situation?

Mike Caspar

Tuesday, October 11, 2016

The We versus Them Assessment

A friend asked me to re-post this article here. It was originally posted on linkedIN on June 20, 2016. Here goes...

. . . . . . . . . . .

This weekend I had a remarkable experience that really got me thinking..

I was talking with a fellow member of the agile community (we'll call her Alice).

Alice was telling me about why she liked the company she works for.

What truly stuck out for me was the fact that she continually referred to the company's groups as "We".  For whatever reason, I don't see this word used often when agile coaches, Scrum Masters or change agents talk about the companies where they are engaged (or work at). 

This got me thinking..

I wonder if you could assess the health of a company's teams or culture by simply listening to conversation and keeping track of the number of times people use the word We versus the word Them?

There is a possibility that this approach would also allow a coach to quickly notice where the language changes to Them to relate to other internal departments to discover where there might be room to help with interactions.

The simplicity of this seems like it may a totally bogus idea but an idea isn't worth having unless it's shared (and possibly criticised).

Of course, I hope someone doesn't try and use this idea in some horrible, inappropriate way. You never know though... Could the approach remove countless survey questions and senseless sessions?  The question jumps directly to People and Interactions.

This whole topic encouraged me to ask that you run a personal experiment (for yourself).

If while you were reading this, you have been wondering about you and other departments in the company you work at..

Have you considered...

"Are your customers....  We or Them ?" 

Just a thought.

To Alice (you know who you are)...

Thanks for the inspirational chat. <smile>

Monday, October 3, 2016

The Sprint as a Guide Visual Coaching Tool

In 2011, I created a coaching/visualization tool to help a team at a large organization to understand the timing of the various Sprint Ceremonies in Scrum.

I have been using this tool for various situations and decided it's time to share with the community in order to help others out.

It is called Sprint as a Guide.

Sprint as a Guide - Mike Caspar
Sprint As a Guide - Mike Caspar

It has served purpose for many situations, but three have been the most useful.
  • Understanding of the timing of ceremonies in a format that easily relates to people's current mental model of time.
  • Understanding how and when Backlog Refinement can work.
  • How the Scrum Framework can help to show where too much time is being spent on activities and why.

To see this document as part of a Slideshare, you can follow this link.

By using Scrum's ceremony timings as a guide, it can help to show where perhaps you are spending too much time on one ceremony versus another (as a guide).

I have facilitated many surprising sessions where new uses have been found.. Find your own!

Two examples (based on different views of Sprint Planning).

1 - Sprint Planning is almost impossible to get through and make a commitment as there is an insufficient understanding of the User Stories available to the team.

A quick glance at the diagram helps one to realize that perhaps if time was spent for Backlog Refinement, planning might be easier to get through. The key here is to realize that Backlog Refinement is part of the framework itself and may help. 

2 - An opposite (and often surprising realization) is for the team that makes it through planning in 15 minutes rather than the timing suggested in the Scrum Guide.

At first glance, this may appear to be a good thing.  However, consider that the reason for this extra time. You may be going too far ahead with requirements (or various other issues). I have seen this as evidenced by looking at stories that are 10 Sprints out (an extreme example for demonstration). 

The Scrum guide suggests ....

"Refinement usually consumes no more than 10% of the capacity of the Development Team".

This implies two things..

1 - Backlog refinement is necessary to be effective with the Scrum Framework.

2 - There is a recommended limit on the amount of time spent doing backlog refinement to avoid getting into a situation of excessive planning.

I cannot stress enough.. Think GUIDE...  Please don't use this as a tool to do anything other than have open dialogue and discussion. It is not an enforcement diagram.

If you would like some help with either backlog refinement or how the Scrum framework can help you, or simply to improve your situation, feel free to reach out on me. I offer 1/2 day or 1 day sessions for people, teams or organizations.

An image of the original diagram...

Sprint As a Guide - Mike Caspar