Saturday, December 17, 2016

What is an API for non-technical people

During conversations over the last few weeks, I have been asked more than once by non-technical people... "What is an API ?"

As technology evolves to have more interconnected systems, many will find the term API becoming a larger part of their lives. This includes both business people and technical people alike.

I thought I would share an analogy to help those that are less technical understand some simple concepts to get you started on your own journey of learning, or just to help you feel better when talking with someone about the topic :->

If you are interested in incremental, multi-team delivery, you will find these concepts important to understand.  

There are other concepts and the following is definitely an over-simplification, but this should get you started.  My goal is not to make you an expert, but to get you ready to have some conversations about this in your environment.

  • Public interface
  • Keep the implementation private
  • Don't make something public unless you really have to

For the purpose of this post, consider an Interface to be .... 

The means by which you interact with something to send and/or receive information or change of state.

An API is an Application Program Interface.  To extend the definition, consider an API to be...  

The means by which you interact with a Program or System to send and/or receive information or change of state.

For the technical people out there.. Yes, I know this is an oversimplification.

The Automobile gas pedal.

Public Interface - To interface is simple. One moves the pedal forward to increase the flow of gas to the engine.  Decrease the distance forward and the opposite happens.

The results are known to us either a - vehicle going faster, or b - engine revving faster, c - vehicle going slower, d - engine revving slower.

It is important to understand, there is no interface through the gas pedal for speed, torque or anything else.  Those are other systems that have their own interfaces.

Keep the implementation private - Imaging for yourself that to know how to push the gas, you needed to know

- How many cyclinders the vehicle has
- Is it gas or electric
- What size engine
- What type of engine computer
- etc.

If you needed these to interact with the gas pedal, it would certainly be more difficult to drive.

Imagine that before you pressed the gas pedal, you had to calculate the force necessary based on engine size, the angle of the hill you were on, figure out which cylinders to turn on in what order to be able to press the gas.

Don't make something public unless you really have to.

These details are referred to as Implementation details. A good interface keeps this information private (not visible to the person or system using it).   

By using this approach, you could for instance, change your engine from one type to another, or get an updated engine computer.  You might have different results as you press the gas pedal with evidence from other interfaces (ie: speedometer), but you didn't need to change anything in the current interface or learn anything new to use it.

Don't make something public unless you really have to - This concept is extremely important for those that are growing systems incrementally or organically. Think about it this way... 

Once you make an interface public in a complex system, it may be almost impossible to remove that interface from future iterations.

This situation will be compounded in systems that take years or generations to change or where interaction from other systems may rely on these interfaces long into the future.

In the example of our car, let's assume that someone said "You know, we could make the gas pedal really awesome if we allowed the operator to press on the right or left of the pedal by angling their feet to give a different acceleration potential".  

This might make sense in your environment (let's say you have a specialised product for race car drivers and that would improve their lives significantly!). Innovation is cool that way.

My goal here is to have you consider this; Would a different interface be appropriate ( a hand control for instance). Could we have a separate control for Normal Acceleration or Faster Acceleration (think about this.. some vehicles have a Sport Mode).

There are two potential considerations should you decide to add this really cool interface Publicly (in your current application).

In a distributed application or system, something or someone will use a public interface! This means that you may need to have that ability in your system forever. You may never take it away (well, not easily at least).

If you realize later that you should have made a different interface (Sport Mode), it will be too late. You have made the interface public.  

  • People may have already created driving schools for the new accelerator system
  • Someone may have created a special shoe to use it
  • Control systems may have been built to control the pedal from a manual control that converts it to suitable pressures on the gas pedal 
  • And so on.
To complete the analogy to software or systems development, now anytime someone wants to use the interface they have to spend time and effort learning and understanding acceleration concepts when all they wanted to do was press the gas pedal.

I hope this helped the non-technical person to be able to have some knowledgeable conversations about Application Program Interfaces or APIs.

There are Interfaces at different levels in your vehicle. Examples include....

- Engine computer
- Fuel pump
- Light switch controller
- Engine itself (think electric)
- Speedometer
- Tachometer

Technically oriented people will be using this term often in the future. APIs and discussions will become more prevalent as technology becomes more pervasive. The Internet of Things (IoT) is mostly about APIs for starters.

Hopefully, I have given you a bit of a non-technical description that helps you out to start your learning journey about this topic.

Actually, even communication and conversation is a form of Interface between humans. That's a topic for another time :->


Tuesday, December 6, 2016

Techpost - The Test-Maintain Loop saved me during a Jenkins Server infrastructure upgrade

Technical Post (just a warning for the non-technical follower).

As some of you know, earlier this year I created a first version of an Ansible Playbook Test framework and put it on Ansible Galaxy.  

Yesterday, this tool saved me from creating a disaster on my Production Jenkins CI instance on AWS (Amazon Web Services). 

I'd like to share that story as an example for others of what is possible if you include testing as part of your Infrastructure as Code strategy.

How I was saved yesterday:

(some details removed for security and simplicity reasons).

Execute the Playbook...
ansible-playbook -i Inventory/CASPAR/staging/ CASPAR_setup_jenkinsservers.yml -u ubuntu --ask-vault-pass --ask-sudo-pass
The result is a new AWS instance server with Java 8 loaded,  appropriate users and groups setup and a base Jenkins Image loaded.  The key here is SETUP (the minimum needed to get a server into MAINTAIN status. The server is in "Staging".

Then, the repetitive playbook is executed (this one runs on a regular basis to keep servers up-to-date in all environments. In my case, I execute for Dev/Staging and Production ( the same playbook is used and applied to all 3 environments ).

ansible-playbook -i Inventory/CASPAR/staging/ CASPAR_maintain_jenkinsservers.yml -u ubuntu --ask-vault-pass --ask-sudo-pass

Note: The only difference in the name is the word "maintain". 

Note: To run the same playbook in Prod or Dev, I simply run the same playbook against /CASPAR/prod/  ( Ansible's dynamic Inventory auto-finds the appropriate machines based on tags )

Then, while the machine is still in Staging, the following test playbook is executed....
ansible-playbook -i Inventory/CASPAR/staging/ CASPAR_test_jenkinsservers.yml -u ubuntu --ask-vault-pass --ask-sudo-pass

The "test" playbook executes all predefined tests to ensure the server is in good shape. 
If there are no errors, all that needs to happen is for the machine to be re-tagged in AWS from Staging to Prod and then the next time the maintain playbook is executed, it will have any appropriate changes using the SAME playbook as before (different Gateway addresses, different database connection string, etc).

Then of course, the TEST playbook is executed again (one final test).. 

The Test playbook can now also serve as a Governance check playbook as well and could be executed by the same team or externally where needed. It provides a means for safer, more comfortable changes, while also providing a built-in governance component if needed.

Yesterday, when I ran the tests in Staging I received an error about missing packages.

ansible-playbook -i Inventory/CASPAR/staging/ CASPAR_test_jenkinsservers.yml -u ubuntu --ask-vault-pass --ask-sudo-pass > test.log
grep "TEST_PASSED" test.log
grep "TEST_FAILED" test.log

I received the message...

 "msg": "TEST_FAILED: package xxxxxx expected present "

(xxxxxx is a hidden package only for this post for security reasons).

If I had converted the host to Production, it would have caused big problems in my production environment.

After doing some research, If found that I had previously requested a newer version of an AMI ( an Amazon Machine Image ). 

Although the entire "setup" and "maintain" playbooks ran flawlessly (with no errors), what I did not know was the newer AMI was missing a critical Operating System package that my environment needed.

I modified the "maintain" playbook to include the missing package, re-ran the "maintain" playbook and then re-ran the Test Playbook.  Everything passed. Now, I know the Staging and Prod machines will always be up-to-date with this package when the "maintain" playbook runs it's continuous loop.

The new Jenkins Server was tagged as "Prod" and then the previous server deleted from AWS. The transition was painless.

By taking this approach and adding new checks to my server first as they become evident, I ensure that I will  not deploy something to production that has not already been determined to be a potential problem. 

I will no longer have this issue or one related to missing this package again.  If an image contains the missing image, no problem.. It will simply pass. Ansible does not re-install packages if they already exist (unless "latest" is specified in the version").

Brief History of the Test/Maintain/Govern Loop

The purpose of creating the Test/Maintain/Govern Loop for Playbooks was to show a Test-First approach to infrastructure delivery to make the transition to Infrastructure as code easier to get accustomed to.

The approach uses knowledge taken from years of insight from the software development world in delivery of complicated environments and applies it to the Infrastructure as Code domain.  

Technical Notes:

Jenkins CI server running in Production on AWS.  

Ansible Playbook uses to Setup/Maintain and Test server(s) in both Staging, and Production. ((how my environment works for build servers.. TODAY).

In AWS, tags are used to determine if a machine is "in production" or "in staging". They are both live in AWS in the same VPC (A VPC is like a private IP range within AWS for my hosts to reach each other).

Playbooks are formatted into YAML (a markup format) to have Dev/Staging/Prod in the same playbook.

A unique matching approach allows the same Playbook to run many times in Dev and Staging. This helps to ensure that when the Playbook runs on the Production machine, it has already executed many times already (and confirmed correct).

An often missing catch with playbooks is that "If" statements can be used to determine of parts of playbooks are executed.  A playbook command can be set to only run a certain instruction only IF a certain environment exists (an example).

When I want to upgrade my Jenkins server or reconfigure a new one, I take an approach of.. "Build a new one, run the setup/maintain and test on it, and IF everything is OK, move it into the Production Tag and then disable the older server. This allows me to ensure all is well before activating a new production change.  

Think of the saying ....  

"All Servers Are Temporary"

A link to the original presentation be found here..... 

If you are so inclined, here's a link to the root repository... 

A sample "test" (also used for governance) playbook is located here...

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


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"