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