Businesses are adopting the DevOps value stream because it increases profitability, builds customer satisfaction, and creates more reliable production environments. Of course, extolling the benefits of DevOps is simple; building a successful roadmap to DevOps, on the other hand, is far more difficult.
DevOps can mean a number of different things depending on who you ask. That’s why it’s so easy to start off on the wrong foot. Another common misconception is that DevOps comprises just a different set of technical practices. But adopting this approach is much more than that. DevOps is a perspective that unites team members and drives technical practices.
Part one in this series begins with an overview of ways other organizations have failed to achieve DevOps. This sets the stage for the required cultural and technical practices as well as finding the best people to implement them.
Avoid These DevOps Transition Pitfalls
Transitioning to DevOps requires first adopting a new mindset and only then the technical practices required. Some organizations fail at building DevOps greatness from the outset, not due to any lack of modern technologies such as containers, but because of poor organizational structures or misaligned leadership.
Pitfall #1: Imitating Technology but Not Culture
Enterprise organizations adopt DevOps to improve their business. They may be fearful (or envious) of smaller or younger tech-native companies like AirBnB or Netflix, both well known in the DevOps space. Many companies model their internal DevOps initiatives after Netflix and assume that what works for them will work for their organization.
But this is a dangerous assumption. Netflix does export open source technologies, but they cannot export their culture or mindset. Every organization is different, each with its own set of internal departments, work force, existing technologies, preferences, and much more. Do not assume that simply imitating choices in technology will help you achieve DevOps greatness. In fact, it’s more likely to harm you.
Pitfall #2: Building Additional Silos
This is another common way organizations shoot themselves in the foot. A core DevOps idea is sharing responsibility by breaking down silos. It does not help to cordon off DevOps concerns into a separate department, as this effectively recreates the development vs. operations silo with even more blurred lines. A DevOps department is aimless by design, since the ideals and practices involved cannot work across departments.
The idea of a DevOps department is well intended but misses the mark. Organizations will have more success starting small by giving teams complete autonomy in achieving their goals while providing organizational support. Target uses an internal DevOps Dojo where new teams come in for weeks at a time with a specific problem and collaborate with existing DevOps leaders in the organization to resolve their issues and learn new ways to work. The new team is then ready to lead other teams in the Dojo afterwards. The Dojo idea hits the mark because it focuses on teamwork, goal-oriented problem solving, and shared learning.
Pitfall #3: Tackling the Lowest Hanging Fruits (Only)
DevOps greatness means incorporating all practices, not just cherry picking the lowest hanging fruit. For instance, organizations stumble when it comes to automated testing, but passing on this is a short-sighted decision. It is common to think that spending time on automated testing is not worth the effort or to not want to sacrifice feature development work for time spent improving testing. But there is absolutely no good reason to forgo automated testing as it has proven time and again to increase quality and velocity. DevOps is not akin to a buffet. It is better to take it all, or a company will surely stumble.
Pitfall #4: Maintaining Team Structure
This pitfall is similar to Pitfall #2 but misses the mark in a different way. DevOps requires smaller, more autonomous teams. Enterprises may try to shoehorn DevOps workflows into their existing organization structure, but this doesn’t work. You must be prepared for and have leadership backing to remix and re-cut the org structure.
ING hit a roadblock when their DevOps transformation was deemed successful, but business results didn’t materialize. They realized they’d fallen into this pitfall and acted accordingly. Peter Jacobs, ING Netherlands CIO, explained:
“ING reorganized into 350 nine-person teams called squads comprised of marketing specialists, product and commercial specialists, user-experience designers, data analysts, and IT engineers. ING’s squads aren’t just self-sufficient from a software development and delivery standpoint; they are also self-sufficient from a business and management standpoint.”
Pitfall #5: Not Accepting the New Reality
Modern companies are increasingly becoming IT companies—weather they like it not. Companies rely on IT to develop and deliver their products or services even if these products or services themselves are not technical. Peter Jacobs and the DevOps handbook touch on this, and Jacobs sums it up perfectly here:
“We came to the realization that, ultimately, we are a technology company operating in the financial-services business. So, we asked ourselves where we could learn about being a best-in-class technology company. The answer was not other banks, but real tech firms.”
The answer does not lie in the existing approach and will only be found elsewhere via teams that are doing things better than you are. And these teams are likely not in the same industry.
Pitfall #6: Missing KPIs
Building DevOps success is all about improving two KPIs: lead time and quality. Lead time is how long it takes to go from idea to production. Quality measures things like bugs, defects, and customer satisfaction.
You cannot have DevOps greatness without measuring these KPIs, and that’s where many organizations fail at the outset. They don’t track these KPIs or don’t orient their DevOps initiatives towards moving these KPIs in the right direction. Or, even worse, they have no actionable plan on how to do so.
Mitigate Pitfalls With these Three Principles
This is where DevOps ideas move from theory to practice. The DevOps Handbook documents three different principles and their associated technical practices required for a successful transition. It’s likely that your organization is already doing a bit of each one, but that’s not enough. DevOps greatness comes only when all three principles come together and build off of each other.
DevOps practices focus on establishing fast feedback loops, and, since shipping is the heartbeat of software companies, it’s only natural that their first priority is to speed up flow from the left (business hypothesis) to the right (customer value). This is the principle of flow.
Principle #1: Lower Lead Times via CD
As mentioned above, shipping and maintaining the production environment act as the pulse of all software companies. The goal of DevOps is to speed up this pulse while preserving product quality, and continuous delivery allows organizations to maintain a fast flow through the pipeline without chaos or disruption to the production environment.
Continuous delivery requires automating the deployment pipeline using automated tests to verify all code is constantly deployable, integrating code with trunk daily, and architecting the environment and codes for frequent low-risk releases. All theses practices come together in order to speed up the flow from left to right through the value stream.
The fact that continuous delivery depends on continuous integration is another cause for confusion. The term CI colloquially refers to the act of running automated tests against code changes or pull requests before merging them. But this is only half of it, and, truthfully, the easier half. The second part is all about trunk-based development.
Trunk-based development is the hardest sell because it means removing long-running feature branches and focusing on a single branch (commonly referred to as trunk, master, or mainline). This is particularly challenging given all engineers must rethink how they write, work with, and release code. However, the benefits of reinventing themselves are definitely worth their efforts.
So, with CD you speed up flow from left to right. Now, the second principle focuses on establishing the feedback loop from production to development, so teams can quickly adjust to changing conditions. This is the principle of feedback.
Principle #2: Drive Decisions with Telemetry
Continuous delivery pushes code through to production more quickly, but a code’s lifetime does not end in production. If that were the case, there would be no one to call when things go wrong, and the team must be able to identify and resolve issues before they become catastrophic. This isn’t just about bugs or operational issues. The DevOps value stream delivers a business hypothesis, which must be validated with experiments, to the customer. And proper telemetry enables the necessary insights to validate the hypothesis and understand what’s happening in production.
Telemetry is any form of data, preferably real-time, that provides insights into the organization’s technical and business state. Telemetry allows teams to quickly create improvements and learnings, whether it’s from a production issue, a deployment issue, early indicators of problems, or customer usage patterns. High-quality telemetry data makes teams see and solve problems as they occur, allowing them to develop safe ways of working. This in turn allows for changes to be made in confidence and product experiments to be run while knowing that failures will be detected and remedied.
The first two principles discussed create a fast-moving organization capable of understanding what’s happening in its pipeline at any time. The next step in achieving DevOps comes by leveraging these first two for continuous improvement. This is the principle of continuous learning.
Principle #3: Validate Your Learning Culture
Successful DevOps teams don’t only ship faster and better; they also learn faster and better. They understand that there are always opportunities to improve the process, the way engineers write code, how to respond to production incidents, or build habits.
Unlike the first two principles, this one is more about people than technology. There are no technical practices here. Learning must be built into the culture, as Mike Rather puts it best in the Toyota Kata: “Toyota’s success lie not in organizational structures, but in developing capability and habits in its people.”
Continuous learning through activities such as fault injection, post-mortems, experimentation, and personal and team learning time creates a resilient culture in which people are excited to participate.
Successful technology companies only get so far with technology. New technologies, like containers, may solve technical problems or attract new talent, but they don’t ultimately define companies. People do. And building DevOps success requires identifying the talent needed to work with the principles discussed.
More about that next week, in Building DevOps Greatness, Part II: Hiring DevOps Talent.
