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....


Tuesday, August 9, 2016

Decrease the time to learning

Consider that the goal is to Learn fast.. not fail fast. 

We do want tests to fail fast... 

...  to decrease time to learning.

Friday, August 5, 2016

Choice of wording in coaching conversations

A fascinating coaching discussion today....

The difference in perceived threat to a leader when sharing an insight and using the phrase "most organizations" or "many organizations".

Realize that the recipient might perceive or compare themselves to the comments. The choice of words can create two totally different feelings during the conversation.

Monday, July 11, 2016

Using SonarQube in a Shared Docker Image to simplify Java code quality testing for teams - Part 1

As teams work to increase their speed to production, a discussion about code quality will inevitably come up. 

In many cases, development team members (even with production level tools in place) have difficulty checking code quality before checking code into a shared repository and have to wait to see results. 

This article seeks to provide a method to allow code quality checks using SonarQube to happen on the development station before having to check to the code into a code repository while also providing a consistent base Plugin­ set for team members. 

Although the procedure below gives a base set to start with for Java developers, it is provided as a guide to allow you to use a similar approach and build something that is perfect for your unique environment.

This is the first of several posts.

Part 1 - A Quick-Start to using SonarQube and docker on a developer workstation with no long-term data retention 

Part 2 - An extension of this procedure to a cloud based server (such as Digital Ocean) 

Part 3 - Some notes about storing data long-term into a database.

Important Notes:​

The Quick-Start procedure in this document launches a container on a workstation that is disposable and will not retain any data if re­-created.  
An understanding of docker installation and execution is implied.

Please consider firewall implications as source code may become available at port 9000 at your workstation.

Technology used:

Article Sections 

  • Quick­-Start (development station) 
  • Sample launchable Dockerfile and image


Using the shared Droplet instance from your workstation

docker run -d --name sonarqube -p 9000:9000 mikecaspar/docker_sonarqube

You should see the latest image download .... 

You will be able to confirm the server is running with the command: 

docker ps

It should show you something like this ... 

Notice that the SonarQube server starts at tcp port 9000.  You may need to make firewall adjustments. 

To get the local server to see it’s current information, use the Url: 


The default SonarQube instance will look like this:  

* Notice the red warning that data stored in this instance will not stay in the server after it has been restarted. 

To add your Java project to the local instance for current code quality information, go to your Java project directory (where you POM file is) and type: 

mvn sonar:sonar

By  default , the Sonar plugin looks for a local Sonar Server to store data. 

The sonar plugin will download from your configured sources, analyse your code with the currently configured rules and then store the results in the current temporary instance. 

Now, you can see your progress without the need to check your code into a repository first!

Go back to your web instance at http://localhost:9000 and you will see how your code quality is. 

This sample has a few hours of technical debt shown for presentation purposes ... 

 A more detailed view.. 

Sample launchable Dockerfile and image 

A sample Dockerfile is available at this git repository:

This repository could be used as is to launch containers without the need to create your own if you are happy with the settings in the repository. 

If you to make your own changes, feel free to fork or clone the repo.

The Dockerfile is available at 

The default admin userid is ​admin​

The default admin password is ​admin​

Thursday, July 7, 2016

Self-driving vehicles and test code coverage

As many of us know, a world of self-driving vehicles is coming quickly. These vehicles do this with computer software.

I'd like to share a thought with others to start a discussion.

I generally hesitate to ask for rules and procedures, but in this case, I feel our lives may depend on it.

Should we ask auto-manufacturers to provide some kind of metric about source code test coverage as a percentage for the self-driving portion of the source code?

I acknowledge that 100% test code coverage does not guarantee reliable software. I also feel personally certain that I don't want a vehicle driving me around that has no Unit Tests or automated tests as part of the development, build and test process.

I have seen too much in my career to expect this to be safe.

Why do I bring this to people's attention now?

Many people do not know that there is an ongoing discourse in the software industry relating to the delivery of features versus appropriately testing software. I won't talk about this here. Do an internet search on "Extreme Programming" or "Test Automation" as a place to start. You'll see how important testing is to software.

It is not uncommon to hear comments in the software industry such as "Oh, it will be fine, it can go out with that bug", or "we'll fix it later", or my least favourite....

"We don't have time to write tests. 
We need to get the feature out."

Personally, I don't want to let a vehicle drive me where the developers have been pressured (or the developers have decided on their own) to write code without tests. Not all companies or developers are this way! I do not intend on painting them with a big brush.

I want to be clear.  I have zero knowledge of any vehicle manufacturer acting irresponsibly to-date. I am just thinking about my future and I don't want this topic to come up when it's far too late for myself, family or friends.

I have been in the software business long enough to know that I have a responsibility to society to bring this up now.

There's no perfect answer to appropriate code coverage with tests, Please don't get that impression. 

All I ask of you is that we find a way to not let this important conversation just disappear.
Letting auto manufacturers (new and old) know we care about code quality for self-driving vehicles will already go a long way.

If you are in the self-driving car business, please consider this as an important topic. Even if you disagree, I'll be happy because at least you thought about it.

I think about it this way.. I am saving my own life.