The Three Ways of DevOps — Part 1 of 3
The first time I heard about the three ways of DevOps was on The DevOps Handbook, by Gene Kim. And suddenly, everything makes sense.
The three ways, or also called principles, focus on different levels of actions and helps to guide on a DevOps transformation. They are defined as:
The First Way — The principles of flow
The Second Way — The principles of feedback
The Third Way — The principles of continuous improvement
The First Way — The Principles of Flow
The principles of flow are about having the work flowing from left to right on the value stream, in the fastest way possible, from the conception of the feature to the deployment in production.
The work starts on the business requirements, passing through development, handled to operations, reaching the customer. Note that for internal projects the customer is also the business, that defines the requirements needed to operate the business.
The focus here is to go from Business to Customer in the shortest time as possible. This will give us a metric called Lead Time, which is the total time between the request from the business to the functionality deployed and available in production to the customer.
In order to pursue this metric it is needed to have a pipeline that is lean and consistent, allowing us to continuously integrate new code, keeping the environment consistent and having a deployable state of the application.
Some key actions for success on having this principle effective working are:
Small Batches
Huge batches, as we used to do on waterfall projects, lead us to discover problems late on the development process. And when issues arise, the amount of work to fix what was already done is often impossible to handle on the required time. If forces us to find workarounds creating technical debt, which will cost much more in the future.
Limit WIP (Work in Progress)
Stop starting, start finishing. With fewer tasks, you can give focus and not fall into the multitasking and prioritization traps. And when our current task is depending on others, we tend to start another task, after all, it’s better than do nothing. But instead of starting another task, ideally, we should put effort into finding out why the delay is happening and how to improve the process.
Give Visibility
Giving visibility of the work on the value stream is important as limiting WIP. And let’s face it: the work on a development stream is invisible, with no physical processes. Furthermore, it is easy to transfer the work or reassign a ticket to another team by clicking a button.
By giving visibility to the work using a Kanban board or sprint planning, for instance, help us to visualize the current WIP in each phase and validate if the work is flowing as it should, from left to right.
Hunt Constraint
The constraint, or bottleneck, is the phase of the process where the work gets stuck and delays the whole value stream. Any process where the work flow in one direction, from left to right, there is one and only constraint in the process that must be addressed and improved. If we make improvements before the constraint, we will continue pilling up work on the constraint step. And any improvements after the constraint will have no effect on the total lead time, causing even more idleness.
After addressing the current constraint, we must hunt where on the stream the next constraint is and repeat the process, making the flow leaner on every iteration.
Fewer Handoffs
The need to move the work throughout the phases on the value stream often requires the handoff of work through different teams with different responsibilities, requiring clear communication, coordination, creation of tickets, scheduling, prioritization, testing and so on, potentially creating queues and delaying work, preventing it to flow to the next phase on the chain.
By automating processes and reorganizing teams we can reduce the number of handoffs throughout the value stream phases.
Identify and Eliminate Waste
Waste, on the software development perspective, can be defined as any task, step or work that will not bring value to the development stream and will cause a delay in the workflow. Those must be identified and eliminated from the value stream, making the process leaner.
Examples of waste include manual work, documentation that is not used downstream, defects, unclear information, handoffs, delays, task switching, extra process and features that are not needed by the customer.
In summary, having a consistent and lean pipeline with a clear value stream will allow you to have small and faster deliveries, with a consistent measurement, and preparing you processes for the second way, the way of feedback, which I will cover in the next article.
As usual, don’t forget to follow, comment, clap, and check the other articles of DevOps, Cloud & IT Career Publication!
Marcello Marrocos is a DevOps and Cloud advocate, passionate about technology and software development. He is an Azure certified professional in DevOps, Developer, and Architecture. In his spare time, he writes for DevOps, Cloud and IT Career publication on Medium. You can find him on Twitter and LinkedIn.
