In its dozen years of existence, the DevOps movement has had a significant impact on how we approach software delivery and how we support collaboration between teams and individuals on the technology side of the business.
Bundling successful practices from companies leveraging cloud computing and creating a fertile ground for new practices to emerge, the movement has helped the industry revisit and review the speed-or-stability dichotomy and match the speed of change in IT with that required by the rest of the business.
Some professionals, especially but not limited to those who have started their careers in a modern startup, have been lucky to experience all of this firsthand from day one. Others have had to learn about the improved ways of working from books (e.g., the eye-opening novel The Phoenix Project), by attending conferences (e.g., the global Velocity and DevOpsDays events), or by signing up for a training course.
What they learn differs, and sometimes the differences are fundamental. Here's why you need to move beyond tooling in your DevOps training.
The cargo-culting of practices
Often, learning about the new approach in a standard professional training course focuses on the theoretical "how"—the things successful organizations, claiming to use this new approach, actually do. While this is extremely useful knowledge, it does sometimes push the focus of the improvement initiative in the wrong direction.
Minute details become the main sources of confusion, disagreement, and tribal wars before the "why" has even been answered. It also creates false hope through technical cargo-culting: "If we start doing the same things, we too will be successful." History has demonstrated that following another company's practices is no guarantee for success, and that the "how" in organizations that flourished looks spookily similar to what could be observed in organizations that perished.
Even more problematic is the instant focus on the purely technical "how"—the tooling. Whatever the current challenges, the promise goes that as long as software product XYZ is implemented, all things will be good, and "you are now DevOps." We have seen similar approaches in the past—expecting that a time and budget management tool will lead to successful projects, a collaboration tool to organization-wide agility, a ticketing tool to customer satisfaction, and sticky notes to improved culture.
If following the rigid rituals and halfheartedly going through the motions don't seem to deliver expected results, or if the investment in tooling is at risk of being seen as a failure—with potentially significant career-limiting consequences—the most common scapegoat is the nebulous phenomenon that is the culture.
Everything would have worked well, possibly even better than expected, if only the company had the right culture. Or the right people, depending on the corporate coroner's final report. That is usually also the cue for starting the next transformation project—to implement XYZ v2 and make sure everyone is aligned. Ahem.
[ Also see: How to stay relevant in the DevOps era: A SysAdmin's survival guide ]
Better living through principles
Helping people acquire new knowledge and then apply that to real-world situations is something I've been doing for the past 20 years, in one form or another. I've answered the same "What's a mouse?" question from successful business people while delivering Computing 101 courses in the late '90s, and from digitally native pre-schoolers quite recently. I have taught the basics of ethics to high schoolers and board members, and written globally used practical guidance for IT service management professionals.
And, in many cases, I've found that focusing on principles is the most effective approach to internalizing what has been learned.
The principles are the "why" to the "how" of practices. Principles make it easier to link what is being planned to expected outcomes. This avoids the oh-so-common circular logic that "the implementation of x has been a success because we now have x," an approach that usually focuses on outputs (and individual career progression).
And while the focus on practices can easily turn into an obsession about recipes, the focus on principles encourages creating new dynamic and creative context-sensitive recipes that respect the ingredients—your people, your organization’s objectives, ever-changing market dynamics, and new opportunities.
When I talk about principles in the context of the enterprise, I visualize them as a permeable net around the organization. The knots float and move around, the threads between the knots are flexible, and the shape of the net never stays stable, as it's modified by both internal and external forces. But it holds well, while allowing for new information to come through, and value co-created with the customer.
This net can be used for decision making at all levels of the organization: If you have options to choose from, then which ones are aligned with the principles? How can you best leverage these options while making sure you don’t go against the principles? What are the things you need to keep in mind, and what are the things to avoid?
It helps to make sure we don’t forget the "why" (and "why definitely not") when assessing and debating the "how."
Practice makes perfect
It is not enough to just accept a set of principles to achieve expected outcomes. The problem with principles is that they can often sound too obvious, just basic common sense. It is easy to learn about something and, if the narrative was coherent, respond with, "Sure, makes sense."
This acknowledgment does not mean you will actually change the ways you work or approach problems. You need to consciously practice applying the principles in different situations, with different and often rapidly changing constraints, and learn about the practicalities beyond the commonly sloganesque wording of principles themselves. We know that collaboration is good, yet we often run solo; we have learned that customer focus is important, yet we have a hard time moving away from feature factories, etc.
If you're lucky enough to work in an organization where the continuous discovery of better ways of working is the norm—that is, an agile organization, one might say—then it might be relatively easy to adopt a new approach. The data is there, as well as the willingness and readiness to change.
Sometimes, though, the principles are much harder to truly accept and put into practice. "This will never work in our company" and "Sure, sounds good, but we don't have time to start experimenting with these new things" are not uncommon responses. Demonstrating success, even on a small scale, goes a long way toward winning minds and persuading stakeholders, but often there are limited opportunities for safe-to-fail experiments.
This is where I've found various versions of experiential learning to be useful, especially when participating as a cross-functional team that includes members of management layers. When there's a need in your organization to adopt or at least explore new principles, don't limit the learning activities to hearing about them, nodding along, and then filling in a multiple-choice test.
Often, that leads to frustration; you now know what should be tried, but others might not agree. Instead, invite the stakeholders to experience the application of these principles with their direct involvement—and not on their pet project, which must be guarded at all costs, but in a safe environment with a good facilitator.
Simulate, don't fake
Experiential learning allows the team to experience the value of following specific principles, as well as the pains of trying to keep true to new ways of working and not falling back to old habits. And, if old habits do come back, this is highly visible and can be addressed immediately, in a playful context, rather than being perceived as an attack on someone's professional persona.
It allows going beyond "Aha, yes, sure, whatever" and blends experimentation with almost instant reflection, which in turn helps to build a solid foundation for real-world change in the organization, now with shared experience.
[ Also see: The state of DevOps education: Can training keep up with the tech? ]
There are several options for DevOps-focused experiential learning on the market, usually in the form of a one-day business simulation (or "simulation game," as it is sometimes called). While there are no silver bullets, and no training or certification can guarantee that the new knowledge will indeed be applied, I've seen relatively higher rates of courage and willingness to try new ways of working when it follows demonstrable success in a simulated environment. The context might be fake, but the experience is real.
Here's some participant feedback from one of The Phoenix Project DevOps simulations (yes, modeled on the aforementioned bestseller) that I recently delivered:
"If you read a book or draw a system design, the paper can handle everything. However, if you try to put it into practice, that's where the challenges start. The simulation gives you a taste of that."
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
