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


Tuesday, August 30, 2016

Teacher and Principal step back to let student team self-organize after a rough day

A message from the Principal of Hope High School in Arizona regarding a student team that was having some personal challenges getting organized around a fairly large community event they decided to take on as a team....
Things worked out great! 
Moses really had a handle on the forming, storming, and norming speech and the biggest impact was Mr. Cook and myself leaving the room so they could hash things out. 
They have added items to their team agreement and even came up with their own incentive reward plan when the team meets certain goals. 
They also realized a key lever in their team stress was that their scrum board was not in a location that was functional with their meeting space. So, without asking us...they moved it...AS A TEAM!! 
They were so proud of their progress today and everyone left on cloud 9. I couldn't have asked for a better turn out. 
P.S. they are shifting to 1 week sprints. 

Notes about this message...

A student Scrum team had been organizing a very large community event. They were using two week Sprints to deliver their work and had selected a large number of activities to do in each Sprint to meet a perceived goal of 16 events (self-created).

There were some conflicts arising as students who recently started this school year worked to organize themselves to share work.  

The Principal called me for some guidance. We discussed ways to empower the students to solve this rather than teacher or principal involvement (something important to the Blueprint Education folks and their culture). We would share the Tuckmann team formation model of Forming, Storming, Norming, Performing to let the students know that what the were going through is normal and there is nothing wrong with them.

Moses (Scrum Master)
Hope High School
(c)Copyright Blueprint Education, 2016

Krissyn Sumare (the Principal) sat in the room for support while Moses (a Scrum Master on the student team) learned about the concepts, why it was important, while intently taking notes and asking questions. He was sure this would help the team feel better about things and was anxious to give it a try with his team-mates.

Moses went so far as to consider how to get involvement from other Scrum Masters in the resolution.

Moses' involvement in the ultimate solution to this problem is awesome to me. Let me explain.....

I met Moses last year at this event. He was a shy, reserved person, who looked down at the ground and often avoided eye contact. 

The Moses I was now talking to intently took notes, asked direct questions, stood tall and was proud and determined to help his team. Moses has become a person who's primary passion is helping the people on his team and ensuring they are all heard. In their environment, this can be challenging.

He seems to have taken on the persona of team "healer". I heard about Moses taking students out to other rooms to talk with them until they feel better. I heard about how he gathered everyone to make sure they would all be there as he was worried that everyone might not be there the next day to listen to what he had learned.  Before our conversation, people were pretty down.

All I can say to Moses (who I hope reads this).. WOW! I am so happy for you. Your outgoing, caring nature and ability to facilitate for people to solve problems will be a great benefit to all those you come across. I am glad you found something to really excel at and am more glad to have met you. 

Other topics to notice from this message....

  • teachers stepping out of the classroom
  • students coming up with their own process and goals
  • team self-organizing without permission to move their board
  • leadership not getting in the way of self-organization
  • a realization that shorter sprints may remove some stress

I hope you can agree that this team is well on their way to being a very successful student Scrum team with much to offer the world and a great future! They are all such awesome, brave people.

If you would like to learn more about what is going on at Blueprint Education and/or Hope High School, reach out to them at

I know they would be happy to start a conversation with you.

Monday, August 22, 2016

The Always Do It Differently Approach

Over the last few years, I have found myself working with organizations, coaches and consultants who use variations of a theme as follows;
  • Standard Team Startup Checklist
  • Team Kickoff Procedure
  • Standardized Reporting Template
  • Standardized KPI scheme
  • Proper Percentage of Developers to QA

These conversations often seem to revolve around the concept of "scaling agile" and "efficiency" for the coaching team.

I will submit that perhaps a different approach might be possible.

I see each team and each situation differently. I prefer to put my complete self and energy into doing the best for those that I work for based on their specific needs.

I don't actually feel comfortable with "following the standard checklist". That made sense for flying an aircraft (and necessary). I find that when coaching, it hinders my ability to be the my best for the team, organization or group I am working for.  Yes, it is more work for me. However, I find the client gets better results if I meet their needs rather than the needs of standardization (or effeciency).

Some will claim checklists for startup are about "quality"... OK.  I concede, in some cases that might make sense in a Training context. 

We are not trying to create "standard work" or "same piece size" when we start a team. We are working with a living system of people who have invited us into their lives. They deserve our respect. 

I find that by embedding myself completely into a situation and having an approach of "Always Do It Differently" keeps me fresh, engaged, doesn't let me slack off, and helps me to love my career.

I understand that Innovation does not come from following scripts and the same procedures every time. I know as a professional that I too must be Innovative and always learning. 

What is strange to me about following predetermined team startup processes is that we are so often asking our clients to question procedures and standard approaches. We want them to value change, get used to it, embrace it! 
Killbot Assembly Line - Courtesy of Pascal

I enjoy the challenge of having the best session I can come up with for the people I am working for. It keeps me alive, keeps my professionalism up, and gives my clients the best possible help for their situation.

It stands to reason that every coach will have some common tools they know work for different situations and that they are comfortable with. We don't need to re-invent the wheel. That would not make sense. However, by stretching ourselves to always come up with a different approach or idea for the next engagement or team keeps us learning and exploring!

I personally enjoy the reaction from teams when they received a session that I invented when I woke up that morning, perfectly matching their situation, or knowing that I have the skill to take an existing technique or tool and modify it for improvement while I am flying to their city.

Agile coaches should be embracing, innovating, changing, and experimenting along with their clients. I need to be clear here. There is a difference between training and coaching. This message is more about coaching. That being said, I know some amazing Teachers who pride themselves in always changing and improving and would be very unhappy to hear about a standardized, designated way to start a new class for the school year. 

For the next few months, consider trying ....

"The Always Do It Differently Approach"

  • Start every team differently based on their needs
  • Talk to the team and then consider where it makes sense to start
  • Take existing coaching tools and techniques and see if you can improve them for the current situation
  • Try and push yourself to learn something different from another coach or leader
  • Build some methods to share new ideas between coaches
  • Feel the joy of pushing yourself to a new level to serve others
  • See if you end up being a better coach for this

If after several months, you want to go back to procedures and processes, you always have that choice..  Agility is after all about what's right for people, and you as a coach are also a person. 

If you would to talk about me providing my services for yourself personally, for your team or your organization, feel free to reach out to me. I enjoy new challenges :->

More importantly...

For the next few months.....


 "The Always Do It Differently Approach"

Monday, August 15, 2016

Changing your approach.. Let them know.

I recently found myself hunting around for a post about a topic that has been come up a few times lately.

After some digging, I discovered a post I was looking for at a previous employer's web site. I'm happy to send you over there.. They are good people.

I believe the message to be important enough to not ignore.

One line from the article.....
Consider letting people know you are changing your approach.  It might not work for everyone, but some might appreciate knowing that you intend on doing so.

Here is the link...


Friday, August 12, 2016

AnsibleFest 2016 Presentation on Test Driven Development for Infrastructure

I recently had the pleasure of meeting some amazing people at AnsibleFest 2016 in San Francisco.

I was presenting a session for beginners on a pattern to introduce Test Driven Development to Infrastructure.

The Test/Maintain Loop for Infrastructure

Actually, it wasn't just beginners... which makes me really happy. :->

To truly do Incremental Infrastructure delivery, we must have an automated way to know that we haven’t broken something else in the system when we make changes.
The key is finding a method to allow constant evolution of our code base (infrastructure).
We do not need to reinvent an approach. Test Driven Development concepts have proven effective in incremental software delivery and can be re-used effectively for infrastructure as code.
Mike Caspar, 2016 

Slideshare of the presentation

Source code of files for the presentaiton

Audio of the session provided by Ansible.

Github source repository for project in the works....