Progress, not perfection. Large-scale culture shifts are made from a series of small-scale adjustments that accumulate over time. It’s unrealistic to expect people to instantly break old habits and adopt a DevOps model overnight. Here are a few quick wins that can be implemented at the team level for more efficiency now and to bring others on board with driving change.
Investigate the Five Success Factors of Transformational Leaders
Top performers have team leads who excel in the following areas: vision, inspirational communication, intellectual stimulation, supportive leadership, and personal recognition. The 2017 State of DevOps Report found that those five factors were “highly correlated with IT performance. High-performing teams have leaders with the strongest behaviors across these dimensions.”
This is a “need to have,” not a “nice to have.” Gartner predicted that by 2020, half of the CIOs who had not yet transformed their teams according to these factors are likely to lose their position in digital leadership.
Post the Rules of the 12-Factor App
There's a great deal to remember and many unhealthy habits to forget when transitioning to a DevOps model. A visual reinforcement helps cement the DevOps methodology in the minds of key team members. The 12-Factor App methodology can guide teams in moving towards greater consistency. For example, Rule 1: Build on top of one codebase, fully tracked with revision control, and many deployments.
Setting down these rules as a foundation helps teams scale up quickly and adapt with greater agility. Leads can use them to determine if the team uses branching appropriately or is creating too many active branches in the code repository.
Understand and Document Processes
Typically, it is the Product Owner that is driving the DevOps adoption. As such, she should start by asking herself or the Development/Operations teams, “Why are we doing ____ this way?” “How long does ____ take on average?” “How long does it take to build, hand to Ops, go to production?” Upon investigating current processes, whether they are documented or just long-standing, a good starting point would be to pick a manual process that is not adding value and look for opportunities for automation. Additionally, making sure all processes are documented and implementing a lightweight change approval process serves to add clarity and remove roadblocks for the collective team.
Start Building a Healthier Code Base
While the Product Owner is busy investigating and documenting processes, the Dev team can start ensuring that their codebase is as healthy as possible. They can do this by implementing unit testing, conducting code reviews, and practicing continuous integration. The process of writing unit tests nudges developers in the direction of the YAGNI principle (You Ain’t Gonna Need It) of doing the simplest thing that can possibly work, which lies at the foundation of Agile. It is a key component of continuous delivery. Taking it a step further, adopting continuous integration will help developers integrate changes with the rest of their teams while maintaining a clean build environment and reducing the risk of costly bugs, merge conflicts, or duplicate work.
Assess Performance and Research Automation Tools
Concurrent with the prep work that the Product Owner and Dev team are conducting, the Ops team can take the opportunity to start auditing their environment to uncover any performance issues, opportunities for automation, or opportunities for creating repeatability in the deployment process. This would also be the ideal time to start researching performance monitoring tools like Dynatrace or automation tools like Chef, Puppet, or Jenkins. Reviewing current processes, doing a small proof of concept with some new tools, and brainstorming ways to avoid setting up all environments manually, are all good foundational steps the Ops team can take to prepare for a shift to a DevOps model.
The Road to DevOps
Even the most traditional IT professionals accustomed to working within skill-centric silos can learn to adopt a DevOps culture by taking baby steps. While Product Owners have their eyes on the transition process, it’s up to the (maybe still separate) Dev and Ops teams to take steps that will pave the way forward. Nothing is as motivational as joining a winning team, and there are contributions each group can make in the quest to become a unified force for rapidly building and deploying more reliable software.
