When transitioning to a DevOps model, organizations must remember that people are essential to a successful switchover. It's people who must learn new workflows, collaboration techniques, and tools during the move. This process will cause at least some disruption over a period as long as two years. Needless to say, they will need patience and ample support to get through such a substantial change. Fortunately, organizations can help their people acclimate to the new way of doing things. They can start by identifying key stakeholders and pitching their plan for the transition. By listening to that feedback, enterprises can make sure everyone is on the same page and shape their plan accordingly to avoid common obstacles during the transition process. Here are five problems in particular to avoid when changing over to DevOps.
1. Define Your Success Criteria
Organizations need a firm idea of why they're implementing DevOps and what they hope it will mean for the company. In other words, they need a goal in mind against which they can measure the progress of and propose changes to the transition. Companies can achieve this end by asking development, operations and QA to fill out a questionnaire in which they're given an opportunity to define DevOps, express what privileges they're willing to lose and/or take on as well as propose boundaries that they feel should separate DevOps systems from the rest of the organization.
2. Neglecting to Emphasize the Cultural Shift
Important as they may be, tools only represent roughly %25 of the change to a complete DevOps model. The majority of the change comes down to a shift in company culture. What makes up the rest are changes to an enterprise's culture. That is, companies must invest in the human side of things to help create channels of communication and collaboration for employees. Only by facilitating greater teamwork can organizations hope to reap the full benefits of the DevOps paradigm.
3. Overlooking Management Concerns
Transitioning to a DevOps model often causes disruptions in the workplace. One such disturbance affects management's organization. Managers can be very cautious with change, since they know errors and failures that occur within the enterprise often fall on their shoulders. In pursuit of accountability, they are therefore prone to support software development processes and other types of systems that involve multiple levels of approval. These procedures aren't efficient, however. Systems with so many authorization levels slow productivity in an increasingly fast-paced world. DevOps seeks to correct this effect by removing needless hurdles, even if that means reorganizing the way management functions. Such changes should not undermine the organization's efforts towards security and compliance, however. Volodymyr Fedak, CEO of IT Svit, clarifies this point in an article for techburst:
...Removing the need for multiple approvals does not mean removing the need for following the security and compliance restrictions. It simply means the DevOps should be responsible for the consequences of their actions and have the power to correct errors if all hell breaks loose.
While preserving security and compliance, it's crucial for organizations to be transparent with managers as the transition process unfurls. That includes clearly articulating where managers are going under the new model and why. It also means creating channels to make sure the managers get all the support they need and don't feel lost.
4. Insufficiently Preparing for Risk
Every major change has an element of risk. DevOps is no exception. Fortunately, organizations can mitigate much of the risk inherent in the DevOps transition process by automating testing procedures. Doing so can catch problems early at every stage of the development process, thereby avoiding wasted time, money and resources in later phases.
5. Failing to Measure DevOps’ Impact on the Bottom Line
While completing the transition to DevOps, organizations must make sure they have measurable statistics that allow them to determine if they are making progress. One of the best approaches is measuring how the change affects the bottom line. For starters, enterprises should audit their infrastructure to learn how much development costs and how much time it takes. They can then do the same with their infrastructure immediately following and periodically after the transition has completed. With those results, they can compare the difference and figure out if DevOps is indeed saving the organization time and money. To learn more about making the most out of your organization's transition to a DevOps model, download Tripwire's eBook Driving DevOps Security: Scalable Cybersecurity Best Practices for Scalable Teams.
