Introduction
Are you interested in implementing DevOps practices but not sure what it can do for you? If so, you’re not alone. Many organizations are interested in the benefits of DevOps, but are unsure how to apply it to their specific situation.
This article is designed to help organizations decide how to apply the DevOps process and tools to minimize initial resistance.
- Understand different projects and systems to guide the journey.
- Select a project to start the DevOps transformation.
- Identify groups to minimize initial resistance.
- Identify project metrics and Key Performance Indicators (KPIs).
It is important to note that an understanding of DevOps and its concepts is a prerequisite for getting the most out of this post. If you are not familiar with DevOps, it may be helpful to first familiarize yourself with its fundamental principles before reading on.
So, what can DevOps do for you? By applying DevOps practices, organizations can improve their software development and delivery processes, leading to increased efficiency, faster time to market, and higher levels of customer satisfaction. DevOps can also help organizations reduce the number of defects and errors in their software, leading to fewer issues and improved quality.
To get started with DevOps, it’s important to first identify a project that is a good fit for a DevOps transformation. This could be a new project or an existing one that is in need of improvement. Next, it’s important to identify the groups within the organization that may initially resist the change to a DevOps model. By addressing their concerns and working to minimize resistance, it will be easier to successfully implement DevOps practices.
Finally, it’s essential to identify appropriate metrics and KPIs to measure the success of the DevOps transformation. This could include metrics such as deployment frequency, deployment speed, and mean time to recover, among others. By tracking these metrics, organizations can measure their progress and make informed decisions about how to continue improving their DevOps practices.
In conclusion, DevOps can bring numerous benefits to organizations that are willing to embrace it.
Explore greenfield and brownfield projects
The terms greenfield and brownfield are commonly used to describe software and DevOps projects, and have their origins in residential and industrial building projects. A greenfield project is one that is done on undeveloped land, while a brownfield project is one that is done on land that has previously been used for other purposes.
On the surface, it may seem that a greenfield DevOps project would be easier to manage and more likely to achieve success. This is because there is no existing codebase, no existing team dynamics or politics, and possibly no rigid processes in place. As a result, it is a common misconception that DevOps is only suitable for greenfield projects and is best suited to startups.
However, DevOps can also be successful with brownfield projects. These types of projects often involve large gaps between customer expectations and delivery, and the teams involved may be motivated to change the status quo due to the challenges and limitations they have experienced with their current processes.
The beauty of brownfield DevOps projects is that they offer the opportunity to make significant improvements to the way things are done. By applying DevOps principles and practices, teams can streamline their processes, improve efficiency, and deliver higher quality software to their customers.
While greenfield DevOps projects may seem easier at first, it is important to remember that DevOps can be successful in both greenfield and brownfield projects. By embracing the principles of DevOps and being open to change, organizations can improve their software development and delivery processes and achieve greater success.
Decide when to use greenfield and brownfield projects
When starting a DevOps transformation, organizations often need to choose between greenfield and brownfield projects. While it is a common misconception that DevOps is better suited to greenfield projects, brownfield projects can also be ideal for DevOps transformations.
Greenfield projects, or projects that are starting from a blank slate, may seem like an easier starting point for a DevOps transformation. They offer the opportunity to implement everything the way you want and may allow you to avoid existing business processes that do not align with your project plans. For example, if your current IT policies do not allow the use of cloud-based infrastructure, you might be able to sidestep those policies by starting a greenfield project that is designed specifically for that environment.
However, brownfield projects, or projects that involve existing codebases, teams, and technical debt, can also be good candidates for a DevOps transformation. When teams spend large percentages of their time maintaining existing brownfield applications, they have limited ability to work on new code. A DevOps transformation can help reduce that time and make software releases less risky. Additionally, the limitations of the existing system may have worn down the team, making them more open to experimenting with new ideas.
Ultimately, the goal of a DevOps transformation is to evolve the entire organization. While many organizations choose to start with a greenfield project, brownfield projects can also be a good starting point, particularly if they are critical to the organization and there is strong management buy-in.
Regardless of whether you choose a greenfield or brownfield project, the first step in starting a DevOps transformation is to identify a project that is a good fit and to begin the process of implementing DevOps practices. With the right approach and a willingness to embrace change, organizations can successfully transform their software development and delivery processes and achieve greater success.
Decide when to use systems of record versus systems of engagement
When selecting systems as candidates for starting a DevOps transformation, it is important to consider the types of systems that your organization operates. Some researchers suggest that organizations often use a practice called Bimodal IT, which involves managing two separate, coherent modes of IT delivery – one focused on stability and predictability and the other on agility.
One type of system that is often encountered in organizations is a system of record, which provides the truth about data elements and has historically evolved slowly and carefully. Examples of systems of record include banking systems, which must accurately reflect a customer’s bank balance, and HR systems, which must accurately reflect an employee’s job title and salary. Systems of record emphasize accuracy and security.
Another type of system that is commonly found in organizations is a system of engagement, which is used to solve new problems through experimentation and is modified frequently. These systems prioritize making quick changes over ensuring that the changes are correct. Examples of systems of engagement include customer-facing applications and marketing websites.
There is a perception that DevOps is better suited to systems of engagement than systems of record. However, the lessons from high-performing companies show that this is not the case. DevOps practices can be applied to both types of systems, and the most significant outcomes often come from transforming systems of record.
While it may be easier to start with a system of engagement when beginning a DevOps transformation, it is important to remember that DevOps practices can be applied to both types of systems. By embracing DevOps principles and practices, organizations can improve their software development and delivery processes, leading to increased efficiency, faster time to market, and higher levels of customer satisfaction.
Identify groups to minimize initial resistance
Not all staff members within an organization will be receptive to the change required for a DevOps transformation. It is important to identify those who are open to new ideas and willing to embrace change, as they will be key to the success of the transformation.
In discussions around continuous delivery, it is common to categorize users into three general buckets: canary users, early adopters, and general users. Canary users are willing to test bleeding edge features as soon as they are available, while early adopters are willing to preview releases that are considered more refined than the code that exposes canary users. General users consume the products after they have been tested by canary and early adopters.
When selecting staff members to be involved in a DevOps transformation, it is important to find those who are willing to test new features as soon as they are available and are highly tolerant of issues. Development and IT operations staff may generally be less conservative than users, but they will also range in terms of their willingness to embrace change.
To ensure the success of a DevOps transformation, it is important to roll out changes incrementally. Large-scale systems that are rolled out all at once have a poor record of success, and it is often better to start small and build upon successes. When starting a DevOps transformation, it is essential to find an improvement goal that can be used to gain early wins, is small enough to be achievable in a reasonable timeframe, has benefits that are significant enough to be evident to the organization, and allows for constant learning from rapid feedback and the ability to recover from mistakes quickly. By following these principles, organizations can successfully implement DevOps practices and realize the benefits of improved efficiency, faster time to market, and higher quality software.
Identify project metrics and key performance indicators (KPIs)
Identifying project metrics and key performance indicators (KPIs) is an important aspect of ensuring that the goals of a DevOps project are specific, measurable, and time-bound. While there are no one-size-fits-all metrics and KPIs that apply to all DevOps projects, there are some that are commonly used.
One key area of focus in DevOps projects is faster outcomes, which can be measured using metrics such as deployment frequency, deployment speed, deployment size, and lead time. Increasing the frequency and speed of deployments, as well as reducing the size of each deployment, can help improve the overall efficiency of the project. Lead time, or the time it takes to complete a work item from creation to completion, is also an important metric to track.
Efficiency can be measured in several ways, including the server to admin ratio (i.e., the number of servers per administrator), the staff member to customer ratio (i.e., the number of staff members serving a given number of customers), and application usage and performance.
Quality and security are also critical concerns in DevOps projects, and can be measured using metrics such as deployment and application failure rates, mean time to recover, bug report rates, test pass rates, defect escape rates, availability, and service level agreement achievement. Mean time to detection, or the time it takes to detect a failure, is also an important metric to consider.
Finally, it’s important to consider the culture of the organization and the impact of the DevOps project on employee morale and retention rates. These metrics can be challenging to measure, but can be assessed through periodic, anonymous employee surveys and by tracking retention rates.
In summary, identifying and tracking appropriate metrics and KPIs is essential for ensuring the success of a DevOps project. By focusing on faster outcomes, efficiency, quality and security, and culture, organizations can measure the progress of their projects and make informed decisions about how to improve them.
