The ”Current Reality” DevOps movement with Logical Thinking Process
Nice to have you back, lets find out how our current reality looks like and what we need to change to meet the goal!
I know reality is scary, it’s a lot easier just to continue as we always has, but you must understand that the longer you wait with solving an issue the harder and more complex the change will be, adjusting as early as possible makes less disruption in your organization and might pass by almost unnoticed.
This article series is about how we identify what to change and what it shall be changed to, and how you can prove to others that this is what you need to do.
In last article ’The Goal” DevOps movement with Logical Thinking Process’
We talked about your goal, which shows you where you are heading, so lets find out where you are now in relation to your goal, and what is blocking us from being where we want to be, meeting the goal!
Before we begin; from now on I will refer to Logical Thinking Process as LTP as it is a lot easier to write 🙂
This picture shows the steps we will work on, and I will give you the tools of LTP to you to make this happen.
We are now in Step 3; we analyze the mismatch to the goal by creating a Current Reality Tree (a cause and effect tree, if this happens then this will happen and so on).
Our ”Current Reality Tree” gives us proof and a way to visually and verbally describe such evidence , where we show what our root causes are to our undesirable effects, the things we need to change to meet our goal.
Lets have a look at a simple example that happened to me when I was younger;
The Current Reality Tree is read from bottom to top and is a Cause and Effect tree, above example is read like this;
If I have spent all my money, Then I do not have money, If I do not have Money, Then I cannot go to the movie.
The logic is clear and cannot be disagreed with, however their might be solutions to our root cause, and we will look into how to solve them later on, an example of a solution for above could be that we borrow money for example.
Some of you might not have read the previous article so lets give you a very quick introduction.
Previous article described how you define your Goal, to do this you need to decide for what we are analyzing e.g. the system In previous article I used the IT Organization of your company as an example, but it can be anything like a sub department, or a service delivered by your department or it can be you as a person.
But as the topic is DevOps lets stick to that, so lets look into the Current Reality of your IT organization and what stops it from adopting DevOps.
Here is an example of where the root causes are, in below picture you see and example and the boxes with no predecessor is a root cause, and all of them needs to be fixed.
You also see that one root cause is impacting many of our blockers (Undisered Effects) and by solving them we will get closer to our goal.
A word about DevOps
I think it is the right time to talk about what DevOps is, and I bet that you have a different opinion than I have, it just indicates that we are talking about a hype that is not yet fully defined, and also that I have not described DevOps in it’s fully.
But I think we will agree on my description even if I have simplified it extremely much.
DevOps is about two things where the first is the main driver;
Time To Market, get new things out to the market as fast as possible to compete and meet customer demands
That Stability and quality is preserved even with high ratio of changes, by securing that the long years of Operations skills are protecting the business from failing due to instability and customers not being satisfied.
When I read what I wrote It can come over me, wow, DevOps is a paradigm shift, we will do something remarkable, so lets get on to it.
Finding our reality
Yes, I know the reality is not what you want, like me I like the fluffy pink cosy world, but we are not here to be cosy, we are her to make a difference!
So be with me!
Identifying our current reality is extremely difficult so I have made my best to describe a situation many of you will recognize which will make it easier for you to follow me.
So everything in this example is based on information I have got from interviewing IT people, and from good speakers at conferences etc.,I have picked stoppers that I believe will be recognized by most of you but not true for all of us.
But first lets update our self on the goal tree that we defined in last article, it shall be read from top to bottom and is read as it has already happened.
Read the tree from top to bottom so start with the goal and add in following phrase ”In order to” ”The goal” we need/must (provide) ”The CSF” followed by ”and” and next ”CSF” until all boxes with arrows pointed to it is read, then take one branch at a time.
So lets do it, read after me …..
In order to ”Provide competitive digitalization solutions now and in the future” we must provide ”High quality added value features as fast as possible (TTM)” and we must ”Minimize operational expense” and we must provide ”Stable operations”.
Read the first branch.
In order to provide ”High quality added value features as fast as possible (TTM)” we must ”Optimize development capacity” and we must provide ”Short lead time to production” and we must provide ”Architectural governance”
To show you what is not working in out reality we need to look back to our goal tree.
Our goal is to provide competitive digital solution now and int the future.
So what is stopping us from doing this?
In this process the first step is to identify the most important things preventing the Goal, the CSF and the NC to be meet.
Current Reality is intended to show you all the issues you have and build them down to the root causes so we can identify exactly what we have to change.
Some of the root cases is of the nature of a conflict, if we find one we have to try to solve it, so we will create a bunch of conflict clouds and we will add information on how to solve them later on.
Current Reality is the most difficult part to do, so do your absolute best as it is very important.
We have a goal, we have CSF and we have a bunch of NC so let start finding some UDEs.
Wow that was a lot of terms;
Goal the ultimate purpose of the system, in our case the IT Organization
CSF (Critical Success Factor), a clarification of the goal to help you understand what we need to accomplish before we are able to meet the goal.
NC (Necessary Condition); strategic objectives, that can change in time
UDE (Undesired Effect); things preventing the goal to be accomplished
Root Cause; the underlying problem that needs to be solved (the hidden cause)
Find our main blockers for success
We need to describe all the things preventing you from reaching the NC, CSF and the Goal.
I will describe two different methods doing this and you have to test on your own which one fits you best.
Method 1 UDE from CSFs
Start with the CSF and the Goal, how can we express them in one sentence with no ”and” and no ”or” the thing preventing the them to be fulfilled.
Lets try it out;
One of the CSF is ”Minimize operational expense”
One of our NC we have stated that we need to cut the cost with 10% with tells us that we are spending to much money.
Our blocker e.g. UDE (UnDesired Effect) for this CSF can be ”Our operational expenses is 10% higher than we can afford”.
Lets continue identifying more blockers, we shall try to find 3-5 of them to analyze, and which also will represent our current reality.
I have listed 4 blockers e.g. UnDesired Effects preventing us from meeting our goal.
From looking at this UDEs we can guess that DevOps will help improving TTM but most likely also our operational stability, and could also enable e.g. free up resources for digitalizing more areas.
In true Toyota way, lets ask why, and why again to get some more detailed to start with, so lets put this up on our whiteboard, create a post-it for each UDE and place them like the picture above.
We will start with one at a time and ask ”Why”;
Why is ”Our operational stability not meeting business demands”?
During last 12 month we had 4 production stops effecting our end users for more than 20 minutes.
Why did we have 4 production stops during last 12 month?
The downtime was in 3 out of 4 times caused of a planned change
In one case the downtime was caused of a power outage in one data center and the application failed to start in the second data center
Doing the same thing for each UDE, asking why two time will give you a good starting point, some time you will find two answers to a why.
We will end up with something like this.
Method 2 UDE’s from each CSF and NC in goal tree
This method is sometimes easier as you have a direct relation to the goal tree.
An alternative to above method is to use the Goal Tree and add in undesired effects directly into it.
And then move them out to its own paper and create dependency
It is also possible to put the UDEs directly on an own paper depending on how your goal tree looks like.
You can find 0-5 UDEs per box in your goal tree.
Remember that the UDE has to be a full sentence and should not contain ”and” or ”or”, if they do break them up to two UDEs.
Now move them out to it own paper.
And lets clean it up so only the top boxes are marked as UDEs and rest as cause and effect boxes.
I often get a better result with Method 2
Find our root causes of the UDE e.g. the blockers
We shall now try to find the root causes, if we are lucky we will see that one root cause is the source for more than one UDE.
It is important that each box has a full sentence and that it is clear and it is understandable by other people that will see and read this tree.
Ask ”why” for each box if there is more than one answer add in the boxes;
My suggestion is that you take a branch at a time and ask why until you found the root cause.
Here is how we have asked why ”Test systems is unique to each system but shared for all tests”
We ended up with two causes that has to be fulfilled to cause this, it takes time to set up a test system and that it is costly for service owners to have many test systems.
If we ask why a couple of time more we will find the root cause.
When you are finished, we shall map similar causes together to one cause, the tree will then get together and we will find at least on root cause that is effecting a lot of the tree.
It is now time to read the tree.
You read the tree from bottom to top with simple cause and effect logic, the cause and effect read by adding in ”if” the cause ”then” the effect.
So in above picture we can read the second column;
”If” Development and production setting is time consuming ”then” New functions takes 30 days to get into production.
”If” New functions takes 30 days to get into production ”then” We are not able to meet TTM requirements
When reading this, it looks like we have left some details out, this is called ”Long arrows” so we need to fill in the gap to make it clear.
It is important to add in all needed details to make your logic trustful, you need to convince people of that you are right and people will challenge you. Some times you only have one chance for convincing someone, so make sure you have a solid cause and effect tree with nothing important left out that you need for proving something.
The cool thing is that with a good tree the logic cannot be challenged as the cause and effect is clear.
The tree has to be based on facts, so do not invent things that do not exit just because they could happen, if it has not happened it is not part of your reality.
I have created an example of one reality for an IT Organization, I hope you recognize yourself in part of it, the tree is not fully broken down but is a good example.
Below we see most of the tree, and I have highlighted a cause and shows that it effects all our UDEs (blockers), so focusing on resolving this cause is good.
I have market the root causes so they stick out, they are the causes we will put most focus on.
Some words on the road
Be around 3 people in each work meeting, bring in the people with the overall knowledge, and call in other people on demand when you need help with detailed you do not have or an experts clarification.
An analyze like this fast grows in size so it is important that you have plenty of space to work on, a laptop or most projectors have not enough resolution to provide space enough to see the whole tree.
Use you Goal Tree to identify things not working and bring it into your CRT.
Make sure that you do not take long logical leaps, doing that will hit you back later.
Validate your tree by reading it loud, there is no better way, when you stumble on your words or rephrase your sentence you have to go back and update it and read it again.
LTP has tools helping you with validating each box and also the tree, here is some of the validations you shall do;
Is sentence clear and understandable by others (Language is the source of misunderstanding)
Is statement valid e.g. do it exist?
Is sentence clear when I read it load?
Is Cause and effect clear and cannot be challenged? if it can add in the missing steps to make it solid. The Cause most lead directly to its effect, no jumps.
Is there other causes not listed? Add them in.
Read it load with if cause then effect to verify it.
Ask someone else to read it, update based on readers comments.
Here is some examples;
”Architecture decisions are violated by developers and business” contains ”and”.
we split it up to separate boxes
if ”Architectural governance is not followed” then ”We are not able to meet TTM requirements”
This is a long arrow so missing intermediate steps has to be added.
We add in some missing steps to make logic of cause and effect work.
We are now reddy to find solutions, which are also called injections to find new ways and solving the root causes.
Some root causes will be a conflict, it can be different opinions between people and it can be a generic conflict.
In next article we will work on identifying solutions, below you see my favorite DevOps example of a conflict
Business needs new competitive solutions, so they want to change existing applications as well as adding in new applications.
Business needs production stability to secure that we are not hanged out in the press, customers is unsatisfied with our up times etc.
I have elaborated with a few assumptions on each side of the conflict, in reality we would add in more assumptions to make picture fully clear.
First thing is to validate our assumption, is they really correct?
When we have invalidated and removed assumptions that is not correct/valid we can start trying to find solutions.
We always start on the side where we have fewest assumptions as this side is the weakest and probably easiest to break, if we fail finding a solution we have to try the other side.
In my example you see that I defined 3 solutions that together breaks the conflict, so many times it is not one solution but a combination of solutions that together can break a conflict.
Working with conflicts is a mind twister, so you need to be open minded and think outside of the box.
So open your mind, to take in new things and ideas, suppress all your emotions, existing solution might have been created by you and you have emotional feelings about it, but you have to put it aside.
I love below picture as it really illustrates our dilemma.
So before you claim you are right, move to the other side and try to put yourself in the other sides needs and perspective, you will be surprised of how much you will learn.