Does DevOps Confuse You?
Doug Schiano
Global Corporate Leadership | Customer Success | Strategic Planning | DevOps & Lean Enthusiast | Quality Software Development Management
Has someone, maybe your boss, friend or co-worker, mentioned the word DevOps to you recently? Did they try to explain what DevOps is all about? Maybe they mentioned something about merging operations into the dev team? Perhaps they spoke about automating as much of the development and delivery process as possible. They may have suggested the need to hire a DevOps team which have superhuman skillsets. Did they say the testing will be done by the development team? Most likely continuous integration and continuous delivery were involved in those conversations. DevOps is under debate in every conversation involving software development and it can be very confusing.
During any of those conversations, did value streams, the 3 ways, feedback loops, metrics, business alignment, learning culture, safe to fail or fail often and fail fast come up? Great news if this came up, DevOps is being discussed at the fundamental level. You may still be confused but luckily the correct conversations are occurring. Unfortunately, when these fundamentals are not covered, DevOps quickly becomes confusing and often becomes a deliberation of roles and responsibilities and people become defensive over a perceived threat to their job, knowledge, team or territory.
A few weeks ago, I wrote about the transformation software development is undergoing. The article, Quality Matters: The DevOps Tipping Point, covers three high level reasons companies are moving to DevOps, speed, quality and testing. It’s a quick read, I would be honored if you checked it out.
Every day I read a new article or discussion about what is DevOps, how to implement DevOps, mistakes with implementing DevOps, etc. Every piece I read usually has some useful tidbit within its words but most often the article or discussion is rehashing common misconceptions or missing key points behind whichever nugget of enlightenment they had. I will do my best to forgo you that experience in this article.
So, most people want a definition of DevOps. We’re not really going to give you a definition of DevOps, because there is no one canonical definition of DevOps. – John Willis, co-creator of the DevOps movement
Overwhelmed with conversations of DevOps and a little embarrassed with how confused I was in understanding DevOps, I set out on a journey to finally understand this thing called DevOps. I have spent the last few months reading everything I could find about DevOps. I am even working through the Linux Foundation’s certificate program for DevOps taught by none other than John Willis, one of the creators of the DevOps movement. The more I have learned, the more of an advocate I am becoming for DevOps. However, I hold no specific certifications in any of the specific areas I am about to discuss. If this is a deal breaker for you, now is the time to find another interesting article. I have a few links at the bottom of I found interesting as well as links to great resources for understanding the fundamentals of DevOps. Once upon a time I obtained my MBA and surprisingly, DevOps, under a different name was covered.
DevOps by any other name is lean manufacturing. The principles of DevOps stem from the methods developed by Toyota over 50 years ago. Gene Kim, another co-creator of the DevOps movement, applied the principles of lean product manufacturing to software development and gave Lean a voice in his book The Phoenix Project. When you read articles that talk about DevOps being about automation, people, culture, a process of learning, they are all correct. DevOps does encompass all those aspects but it is much more.
A little bit about what DevOps is not. It is not a single person with a bunch of the latest and greatest skills. It is not a team of developers. It is not Continuous Integration and Continuous Delivery. It is not a rebranding of Operations Teams or bringing Operations team into the Agile team, although this last one is critical. DevOps is not a role or a set of responsibilities for an employee.
There are very good books about DevOps and lean manufacturing and there is no way for me to cover every aspect of DevOps in a single article. To do so would just add to the confusion. My goal here is to help clear up the confusion by painting you, what I hope to be, a simple picture.
This picture depicts a 6-step process to create a product. The different workstations’ size indicates relative capacity of that step in the process. As you can see, workstation 1 has the largest capacity and workstation 4 has the smallest. For our purposes, define capacity as a measurement of quantity or size of work, time or a combination of the two. As it is depicted above, workstation 4 is a potential bottleneck to the entire system as work cannot move through the system faster than workstation 4 can complete. Here is an example:
As you can see, no more 5 total products can be completed after 5 units of time due to workstation 4’s limitation of 1 work item per unit of time. Workstations 1, 2 and 3 are over producing and workstation 5 under producing. This system is very inefficient. Remember the goal here is a simple picture of how lean manufacturing is used to optimize the system. To optimize this system there are several methods which can be implemented depending on their cost benefit analysis. One potential way is to cross train members of WS 1 to perform WS 2 work and have them assist WS 2 once WS 1 work output is more than the processing ability of WS 2. Same thing with WS 2 members to WS 3 and so forth. However, it may not always be possible to fully cross train team members, think specialty skills like electricians and plumbers. In this case it may be useful for team members to provide any support which would reduce the constraint; prepare the worksite, clean the site, organize materials, etc. The issue may not be a personnel constraint. The constraint may be a physical limitation or a time constraint, think a build takes X hours to perform. In these situations, adding more resources may be cost prohibitive but adding any additional resources here increases the overall throughput of the system. The main idea is to optimize the system where feasible to streamline the process and increasing the value of the system to produce greater customer value. Single points of failure should be eliminated when possible. In the event they cannot their work in progress needs to be tightly monitored and controlled as to not prevent a blockage to downstream workstations (Workstations that come after the restrained workstation. Workstation 5 is downstream from workstation 4). Monitoring systems need to be put in place to inform upstream systems (Workstreams occurring early in the system) of potential blockages so those workstations may adjust work to prevent exacerbating the blockage. Hopefully this crude explanation of lean manufacturing provides a basis of understanding to build upon.
Let’s apply this simple model to software development. Here is an example of how a typical software development organization may look:
Your teams may look something like the above. The lists are not all inclusive but should provide an example for comparison. WS 1 are your customers and your business team that generate the ideas. It should be noted that this should not be the main source of the ideas which are developed, the internal team should be generating their own ideas as well. It is important to listen to the needs of your customers and the business but innovation comes from experimentation and failing and the team should experiment with all ideas. KEY POINT!
Imagine if WS1 was in a building by itself and rarely communicated with the rest of the downstream systems in clear communication method but sent communication by index cards. Imagine if all upstream communication to WS1 was done by smoke signals.
WS 2 is the Product Management team who turns ideas into concepts which can be incorporated into the software by the technical team. WS3 is the Technical team and so on forth with the Operations and Support Teams.
Agile is generally used to tie WS 2 and WS 3 or Product Management and the Technical Team closer together. In some organizations, these teams form 1 workstation. However, decreasing the number of workstations does not necessarily result in an increase in throughput of the entire system. Constraints in downstream or upstream workstations may still exist. DevOps goal is to evaluate the value of each workstation of the development process, eliminate the waste, and reduce the time of work between workstations by forming one team that has all the necessary skills to handle the work for all the workstations. That may look something like:
DevOps teams are made up of every part of the organization so that waste is eliminated. These teams are independent and self-contained. KEY POINT!
Think back to the assembly line picture. Imagine if WS1 was in a building by itself and rarely communicated with the rest of the downstream systems in clear communication but sent communication by index cards. Imagine if all upstream communication to WS1 was done by smoke signals. No matter how effective the remaining downstream workstations are in the system WS1 will always be an inefficient workstation and constraint. It is hard to imagine that WS1 is in line with the other workstations and vice versa. Value is not being optimized in this example.
Keep in mind this is not DevOps:
https://partsolutions.com/engineering-the-worlds-largest-swiss-army-knife-the-1300-wenger-giant/
IT is easy to get excited with the number of functions it can perform but how well does it accomplish each function? How many functions can it execute at once? Having the right tools in the right place and having the right people who know how to use them properly, that is critical in DevOps. Take this for an example:
https://tpslean.com/images/5s6.jpg
All the correct tools are in a well-defined space, laid out for easy access. There is no confusion as to a tool’s proper location. It is clearly visible when a tool is in use or missing. Each tool is designed for a specific function.
DevOps does not necessarily eliminate roles, or combine them. DevOps optimizes the transition between them, works to eliminate errors, automate processes which are routine and easily automatable. KEY POINT!
My mission at the beginning was to clear up some of the confusion of what DevOps means. There is much more to DevOps then I covered here, honestly, I barely scratched the surface but hopefully I have provided enough clarity that you can begin to understand what DevOps truly is about. It is a process of delivering value to the customer by eliminating waste and time inefficiencies. It evaluates the business’ current processes and identifies the value creating processes and eliminates those process which do not add value. KEY POINT! When people write about culture change, they are correct, a business must change to understand how to optimize the business processes to maximize value to the customer. When authors write about tools, yes tools are important if they add value, reduce errors or reduce time. When articles speak about applying agile processes to operations teams, they are correct, this is an important part of DevOps.
When in doubt determining what is or is not part of DevOps, refer to the first example in this article which depicts 5 workstations and their capacities. Ask yourself how would you go about optimizing the entire system and not just a single workstation to obtain the most product after X number of runs. Apply that to your software development process in your company and hopefully you will see the potential DevOps has to transform your business.
Found this article interesting and want to find out more about Lean Manufacturing, Lean Software Development and DevOps? Here are some sources I find useful.
Lean_manufacturing
The Lean StartUp Methodology
Toyota Motor Manufacturing, USA, Inc. - Harvard Business Review
The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
DevOps: Myths, half-truths, and whole lies
Misunderstanding DevOps – Adam Barreiro – Medium