Making a move to DevOps can be a daunting undertaking, with many organizations not knowing the right place to start. I recently had some fun taking a few "DevOps assessments" to see what solutions they offered. I varied my answers—from an organization that fully embraces DevOps to one at the beginning of the journey. Some of the assessments provided real value, linking me back to articles on culture and methodologies, while others merely offered me a tool promising to bring all my DevOps dreams into reality.
Tools are absolutely essential to the DevOps journey; for instance, tools can continuously deliver, automate, or monitor your environment. However, DevOps is not a product, and tools alone will not enable the processes necessary to realize the full value of DevOps. People are what matter most; you can't do DevOps without building the people, mindset, and culture first.
Don't 'win' at DevOps; become a champion
As a DevOps advocate at PagerDuty, I am proud to be a part of an organization with a strong commitment to DevOps methodologies, well beyond just "checking the boxes" of tool adoption.
I recently had a conversation with PagerDuty CEO Jennifer Tejada about being a winner versus a champion. She talked about how winning is fantastic—you get a trophy, a title, or maybe even a few million dollars (if it's the lottery). However, in the big picture, winning is all about short-term goals, while being a champion means focusing on long-term successes or outcomes. This got me thinking about how to apply this principle to organizations embracing DevOps.
One of my favorite examples of DevOps tooling is XebiaLabs' Periodic Table of DevOps Tools:
(Click table for interactive version.)
The table shows that numerous tools fit into DevOps. However, too many times, I have heard about organizations "transforming to DevOps" by purchasing tools. While tooling is an essential part of the DevOps journey, a tool alone does not create a DevOps environment. You have to consider all the factors that make a DevOps team function well: collaboration, breaking down silos, defined processes, ownership, and automation, along with continuous improvement/continuous delivery.
Deciding to purchase tooling is a great step in the right direction; what is more important is to define the "why" or the end goal behind decisions first. Which brings us back to the mentality of a champion; look at Olympic gold medalist Michael Phelps, for example. Phelps is the most decorated Olympian of all time and holds 39 world records. To achieve these accomplishments, Phelps didn't stop at one, two, or even 20 wins; he aimed to be a champion. This was all done through commitment, practice, and focusing on the desired end state.
DevOps defined
There are hundreds of definitions for DevOps, but almost everyone can agree on the core tenet outlined in the State of DevOps Report:
"DevOps is a set of principles aimed at building culture and processes to help teams work more efficiently and deliver better software faster."
You can't change culture and processes with a credit card. Tooling can enable an organization to collaborate better or automate or continuously deliver; however, without the right mindset and adoption, a tool's full capability may not be achievable.
For example, one of my former colleagues heard how amazing Slack is for teams transforming to DevOps by opening up channels for collaboration. He convinced his manager that Slack would solve all of their communication woes. However, six months into the Slack adoption, most teams were still using Skype, including the manager. Slack ended up being more of a place to talk about brewing beer than a tool to bring the product to market faster. The issue was not Slack; it was the lack of buy-in from the team and organization and knowledge around the product's full functionality.
Purchasing a tool can definitely be a win for a team, but purchasing a tool is not purchasing DevOps. Making tooling and best practices work for the team and achieving short- and long-term goals are where our conversation around being a champion comes up. This brings us back to the why, the overall and far-reaching goal for the team or organization. Once you identify the goal, how do you get buy-in from key stakeholders? After you achieve buy-in, how do you implement the solution?
Organizational change
Change is hard for many organizations and individuals; moreover, meaningful change does not happen overnight. It is important to understand how people and organizations process change. In the Kotter 8-Step Process for Leading Change, it's about articulating the need for a change, creating urgency around the why, then starting small and finding and developing internal champions, before trying to prove wins or, in this case, purchasing a tool.
If people in an organization are not aware of a problem or that there's a better way of operating, it will be hard to get the buy-in necessary and motivate team members to adopt new ideas and take action. People may be perfectly content with the current state; perhaps the processes in place are adequate or, at a minimum, the current state is a known factor. However, for the overall team to function well and achieve its shared goal in a faster, more agile way, new mechanisms must be put into place first.
How to be a DevOps champion
Being a champion in the DevOps world means going beyond the win and delving deeper into the team/organizational structure and culture, thereby identifying outlying issues beyond tools, and then working with others to embrace the right change that leads to defined results. Go back to the beginning and define the end goal. Here are a few sample questions you can ask to get started:
- What are your core values?
- Why are you trying to become a more agile company or team?
- What obstacles is your team or organization facing?
- What will the tool or process accomplish?
- How are people communicating and collaborating?
- Are there silos and why?
- How are you championing the customer?
- Are employees empowered?
After defining the end state, find other like-minded individuals to be part of your champion team, and don't lose sight of what you are trying to accomplish. When making any change, make sure to start small, e.g., with one team or a test environment. By starting small and building on the wins, internal champions will start creating themselves.
Remember, companies are happy and eager to try to sell you DevOps, but at the end of the day, DevOps is not a product. It is a fully embraced methodology and mindset of automation, collaboration, people, and processes.
2 Comments