If you are on the technical side of any software development organization, you might have heard about the concept called “The Three Ways” for sure. It is nothing but a set of business principles that motivates organizations to give the value it deserves for a corporate culture with short feedback loops. When this culture is followed, everyone will be in a position to understand how different parts of the business correlate to each other. Also, in this culture, all employees are motivated to seek knowledge that helps organizations to achieve their business goals.

The Birth of Three Ways:

The concept of The Three Ways was introduced first in one of the most familiar information technology/business books named the Phoenix Project. The narrative storyline of this book shows the readers through the eyes of the characters the ill effects when the security team, quality assurance team, IT operations, software development team and product owners in an organization do not work as a cohesive unit.

The 3 ways concept was introduced by a mysterious character in the book called Erik Reid. The good thing about this book is that it offers the other characters a framework for DevOps implementation. It takes the readers through the development of a culture, where technology, process and people are aligned properly and work towards the achievement of the same goal of providing value to customers.

The Phoenix Project, which is a book published by IT Resolution has an associated reference work named the DevOps Handbook. You can gain an in-depth explanation of the three ways of DevOps and how the principles can be used for creating the best practices in your organization.

Three Ways – A Brief:

When talking about the three ways of DevOps, here is a brief of the three ways:

• The First Way: It explains that the work always flows in the same direction. The direction is from top to bottom or downstream.

• The Second Way: It involves the creation, shortening and amplifying of the feedback loops.

• The Third Way: It denotes ongoing experimentation so that it will be possible to learn from mistakes. In turn, mastering will become easier.

In short, the first way talks about the principles of flow, the second way discusses the principles of feedback and the third way involves the principles of continuous learning. Let us gain a better understanding of each of these three ways of DevOps below:

1. The First Way:

In simple terms, the first way is all about system/flow thinking. It gives importance to the performance of the system as a whole as against the performance of a particular department or silo of work. This can either be as large as a division or as small as an individual contributor. An example of the former is the development or IT operations department, while the examples for the latter are a system administrator or a developer.

The focus of the first way will be on all business value streams that are enabled by information technology. In other words, it starts when the IT department or the business as a whole has identified the requirements. The not only identification of requirements but begins when the solutions that can meet the requirements are built-in development and then transitions into information technology operations. The value is then taken to the customers as a form of service.

Of course, before putting this first way into practice, you will be interested in knowing the outcomes you can expect. It includes never passing an already spotted defect to work centers downstream. It also involves not permitting local optimization for the creation of degradation at the organizational level. The outcome involves seeking an increase in the flow and seeking to achieve a profound understanding of the system as a whole.

Key Principles of the First Way:

When you intend to follow the first way among the three ways of DevOps, it is better to understand the principles of this way.

Making work more visible:

When it comes to industries involved in the production of any product, it will be easy to observe the processes involved on a plant floor. But, when it comes to software development, the flow through its development lifecycle cannot be seen with ease. So, activities that happen behind the scenes can be brought to light with methods like Kanban boards. In turn, it will be possible to see the left-to-right movement of a user story via the development phases.

Restricting Work in Progress:

When the work-in-progress is restricted, it will be possible to quicken the flow of work. The reason is that it reduces context-switching and multi-tasking in the workforce.

Bringing Down Sizes of Batches:

Breaking the work into smaller pieces like a sprint for two weeks can help with delivering bug fixes and features to the customers at a faster pace. When this is done, issues can be spotted with ease when those additions and updates are released quickly,

Apart from these principles, the first way includes other principles like spotting and removal of waste and constraints and bringing down hand-offs between teams.

2. The Second Way:

The second way will pay attention to increasing the feedback loops from the right to the left. In this method, the attention will be on increasing both the quickness of getting the feedback and the number of feedback loops that you have in your flow. The idea here is that the flow should stop immediately on spotting an error. Also, the idea here is to transmit the feedback coming from errors as swiftly as possible to the source so that it can be corrected.

How to Achieve The Second Way?

When you wish to follow the second way, you should have continuous integration, deployment and build processes that work in association with each other with a quick and automated combination of tests. When this is done, it will be possible to provide feedback quickly to the development team in your organization.

Bring Down the Number of Work-in-Progress:

Similar to the first way above, even in the second way, it will be possible to improve the quickness of the feedback loop by bringing down the amount of work-in-progress. When the number of work in progress is lower, it will be possible to quickly move through the pipeline. In turn, it can be tested quickly in the upcoming node in the flow. As a result, feedback generation will happen quickly.

3. The Third Way:

The third way involves the culture of experimentation. It encompasses the following practices:

Continuous Experimentation:

The first practice and idea of the third way among the three ways of DevOps is the culture of continual experimentation. In other words, the teams should first be provided with the time to experiment. When they get time for experimentation, they can get new technologies or ideas so that they can quicken their job.

Learning To Fail:

The second idea of the third method is to learn from failure. Your team members will be ready to take risks only when they know that they will not be punished for their mistakes. The third way of DevOps insists on taking risks. Only people, who tend to take risks at times become great leaders in history. This idea recommends that teams should never fear away from failure. But, they should be brave enough to take risks. When they fail, still they can learn from the mistakes and can avoid them in the future.

Repetition:

According to the third idea of the third way, repetition is the pre-qualification for mastery. When certain tasks are done repetitively, it will be possible to get trained. This way of DevOps involves introducing flaws to the system. When correcting these flaws is introduced as a practice, it will help with improving resilience. Even repetition will help with bringing down MTTR or mean time to recovery. An excellent example of this concept is the Game Days followed by Google. The idea is to introduce failure into the system. When the employees of Google engage in repetitions, it will ensure that the teams stay well-prepared to deal with the type of situation, particularly concerning tools and training. 

Injecting Results into the System:

When the outcomes from the repetition are injected into the system, the teams can make the system more dependable and resilient. The idea here is that all failures will happen one day. How is it possible to claim that they will not happen? In case, it happens in a crucial situation, how to repair them when your team does not have prior experience handling such a situation?

In short, the third way, of course, assumes an efficient instrumentation system such that we can use the feedback and improve the system. Even, this way presumes that these experiments can be quickly implemented. If done, it will be possible to do system restoration quickly.

With these three ways of DevOps, you might have understood that DevOps is not just automation. It is not just tools. But, it is much more. It encompasses efficient feedback loops, it follows a culture of ongoing experimentation, feedback, and much more. Together, they will make your software development process complete right from the beginning to the end. 

Simpliaxis is one of the leading professional certification training providers in the world offering multiple courses related to DevOps. We offer numerous DevOps related courses such as DevOps Foundation® Certification Training, Docker and Kubernetes Certification Training, Continuous Testing Foundation (CTF)SM Course Description, Continuous Delivery Ecosystem Foundation (CDEF)SM Course Description, DevSecOps Foundation DSOF℠ Course Description  and much more. Simpliaxis delivers training to both individuals and corporate groups through instructor-led classroom and online virtual sessions.