Friday, December 21, 2018

Adding a process. Think about how it gets removed.

Are you adding a process to your system?  

Consider deciding and possibly defining under what circumstances it can be removed. 

Otherwise, you may just be stuck with it when it's no longer needed.

I once received a phone call from a mainframe operator who had been running an obsolete procedure for years without knowing it. When an automated procedure aborted, he went through his list of contacts (my guess would be that I was the 20th person in order of priority as the previous people were no longer reachable). 

I asked when the last time the procedure produced paper output was (part of it's procedure was to print invoices). His response; "2 or 3 years ago".

I respected the professionalism of the operator for following his checklists (his system) and asked that he find out if that type of business activity still exists before we proceeded. As suspected, I never heard back from him.  

I later found out that the business need for the procedure stopped 3 years earlier. The error was caused by the back-end server being powered off.

I will always remember this story when someone talks to me about adding a process.  

I always wonder to myself.....  

How will they know if and when this process can be removed?

How many people are executing processes that no longer serve their intended purpose?

Wednesday, November 21, 2018

A phrase for your future. Test Driven Development for Infrastructure as Code

Consider spending some time researching the following terms...
  • Test Driven Development
  • Infrastructure
  • Infrastructure as Code
You will find an abundance of information on any of them. There is some, but very little combining the various concepts into one.

Consider that some day the phrase "Test Driven Development for Infrastructure as Code" will become widely used.

As technology gets deployed automatically (think Electricity Grids, Gas or Oil Pipelines, Autonomous Vehicles, Trading Systems, Health Care systems, etc.) the time required to test new features will become harder and harder to execute in a reasonable time-frame. 

This will become evident as you research and learn more about the term "Infrastructure as Code".

Testing in this realm will become increasingly burdensome as IF statements are added to deployment scripts to accommodate different versions of hardware, operating system or environments. 

To help yourself, remember this one question....

How do we know all the security patches and updates are actually there after the deployment script says it is complete?". 

Manually will take too long and might already be too late.

Note: For the novice. It is possible for the script to be complete and indicate completion. However, critical updates have not in fact been executed. If you are not sure how this is possible, ask someone you trust to explain how this is possible. Ask about increasingly complex IF statements.

An answer to this question will ultimately become...

"Test Driven Development for Infrastructure as Code"

As a bonus, this approach will help to bridge the gap between infrastructure, software and testing. This excites me as I enjoy it when people with various backgrounds have the ability to come together to solve or work on a problem.

If you want to learn more, I encourage people in these different groups to spend a bit of time participating in events or conferences put on by the "other" groups. The future synergies might surprise you!  

Enjoy what you learn :->

Mike Caspar

Wednesday, June 27, 2018

You are the Product Owner of Your Life

For my agile aware friends and colleagues that are struggling to make big changes in your lives because of their complexity:

Consider that You are the Product Owner of your Life.

Use some of the tools you already know to remove complexity. It may help.

Monday, April 23, 2018

Be curious

What is being said is valuable. 

What is not being said
can sometimes be more valuable. 

Next time you are trying to assess a situation, consider specifically asking yourself...

"What is one thing that was not said that I missed?"

It just takes a moment to determine how well you were listening.

Friday, March 9, 2018

TDD for Infrastructure as Code. Collaboration with security and governance.

One of the benefits of using a Test Driven Development (TDD) approach to Incremental Infrastructure as Code is that the same tests that were used to build out the system can later be used to monitor the system for security or state.

This can be a great way to help collaboration between development and security or governance folks.

Consider reaching out to an experienced technical coach on TDD or BDD to learn more.

A link to a potential illustration of how this might work is in the references below. 


Friday, March 2, 2018

Getting started with Test Automation for Incremental Infrastructure as Code

Today, I was reminded about a simple approach that has worked well for me in the past.  

When you do something manually for the 3rd time...Automated it.

Perhaps it can work for you.

Thursday, March 1, 2018

"Give them the environment and support"

The Agile Manifesto includes the principle:
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Specifically, consider "Give them the environment and support they need"

Do you believe the meaning of this statement would be the same for people identifying themselves as...

(sorted in alphabetical order)

  • Agile Coach
  • C.E.O.
  • Developer
  • HR Manager
  • Lean Consultant
  • Operations Manager
  • Product Owner
  • QA Manager
  • Scrum Master
  • Team Lead
  • Vice President
  • (insert any other title or group that makes sense in your context. A small subset chosen for my sanity) 

It might help you to find out if others have the same understanding as you do.


Friday, February 23, 2018

"The only way you can (insert topic) is to (insert method)"

"The only way you can (insert topic) is to (insert method)"

We have all seen these types of posts.

I know from experience....

There is rarely only one way to achieve a goal.

Consider using ....

- for many people, 
- for many organizations,
- effective approaches include 
- I have used 
- I have seen (x) used 
- (x) might work
- (x) might be appropriate to the situation
- generally
- often
- experience shows

(none of these are definite and fixed)

Add your own to your own personal list.


Note: I was careful not to say "There is only one way to achieve a goal".

Friday, February 9, 2018

The many who help

There are many, many people involved day-to-day in changes to improve their work environments, teams or companies. This can be challenging work and cause many sleepless nights.

Although I greatly appreciate bloggers, authors and conference speakers, it would be awesome if more time was spent thanking the quiet people.

To all of you....

You are appreciated. Thanks for what you do.

Saturday, February 3, 2018

A Discovery Approach to learning about leadership

Hoodoos - Mike Caspar, 2017

Ask someone you consider to be a leader how they might answer this. What you discover might surprise you.   (will bring you to a popular social media site).

Thursday, January 18, 2018

Could you stop development?

In your environment... 

If you wanted to stop development of a product or feature... Could you?

A few potential questions to consider about your context...

Does the system you have in place, provide a mechanism to stop non-valuable work for the benefit of the company without fear or recrimination? 

Do teams know what to do to stop non-valuable product development?

Is it considered Failure or Success to stop development of a product that will not deliver value?


Thursday, January 4, 2018

Sponsors and Users and Sustainable Pace

In reference to the Principles behind the Agile Manifesto, (

Consider this principle:

Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

During workshops and sessions in software development groups there is almost always discussion about sustainability for development team members. 

However, there is rarely discussion about the sponsors and users being able to continue at a sustainable pace.

Written a different way, the principle could read....
  • The sponsors should be able to maintain a constant pace indefinitely.
  • The developers should be able to maintain a constant pace indefinitely.
  • The users should be able to maintain a constant pace indefinitely.

Ask yourself... In your discussions about the Agile Manifesto, is any time spent getting feedback to determining if what you are doing allows Sponsors and Users to be able to maintain and constant pace indefinitely?

Ask yourself... What does this mean in my context?

Have fun.