Seven Key Factors to be successful with DevOps
Today, every company is also a software company. Every day, the world is becoming more interconnected, automated and intelligent. Infrastructures, assets and devices across the globe are rapidly being digitized, made available 24/7 and transforming everyday products into smarter products that allow people, systems and objects to communicate and interact with each other in entirely new ways. Software is a key driver of differentiation and business innovation. It is a gateway to new services and revenue streams, seamless customer experiences and expansion into new markets. Software includes those programs both visible and invisible to the end user.
Sustainability integrated within the Value Chainleft
Software will save your business
In general, most attention goes to applications, the software used by the users. Software on its own does not actually do anything. The ability to deliver the functionality provided by the software as part of an integral service to the customer is the key. The service includes the software and the human interaction that helps ensure the software remains relevant. Software retains its relevance if issues are solved quickly be they usage or technical issues, if it is updated and improved to match the evolving requirements of the user and if someone provides advice about how to use or integrate the software, or enhance its value in the business process it supports.
DevOps provides the platform for survival
In order to win in today’s fast paced world, companies must fundamentally change the way they build and deliver software. Especially applications exist in an environment of dynamic business needs and at the same time need to remain stable and reliable, whilst depending on constantly changing environments that support them. The ability to roll out business capabilities continuously will be the difference between companies that can evolve and ones that stagnate. This is the background that is driving the adoption of DevOps. DevOps (an amalgamation of DEVelopment and OPerationS), like most new approaches, is only a buzzword for many people. In broad terms, DevOps is an approach based on lean and agile principles in which business owners collaborate with the IT development, operations and quality assurance functions to deliver services in a continuous manner. Thus enabling the business to more quickly seize market opportunities and reduce the time to include customer feedback into business products and services. DevOps leverages the interdependence of IT development and IT operations to create higher quality products and services. It aims to help an organization rapidly deliver the value sought by the customers of IT.
DevOps refers to an organizational philosophy and the professional movement that advocates communication and a collaborative way of working between IT development and IT operations resulting in the fast flow of planned work while simultaneously increasing reliability, stability and resilience of the production environment. Every business wants to move faster without compromising the reliability, stability and security of their systems. And these two seemingly opposing sources of agility and reliability are now possible for every organization to achieve thanks to maturity of DevOps practices and tools.
The 2015 State of DevOps report states that high performing organizations are more agile. They deploy code 30 times more frequently and deploy 200 times faster than their peers. Furthermore, high performing organizations are also more reliable: they have 60 times fewer failures and they are able to restore service 168 times faster than their peers. From the business perspective, we also know that strong IT performance is atrue competitive advantage. Companies with high performing IT make more money and happier employees who consequently, as the research shows, tend to do better work. DevOps promises a great deal in terms of improvement when compared to traditional IT organizations. However, the DevOps philosophy needs to take root in exactly such an environment. Typically, we see (among others) the issues below in traditional IT organizations:
- Inefficient processes, low productivity
- High and unclear costs, ballooning projects
- Weak connection with the customer
- Poor time to market and poor service quality
- Lack of scalable solutions
- Teams working in silo’s
The key problem is that moving to DevOps is a leap of faith, increasingly supported by success
Success factor 1: DevOps is about creating flow.
DevOps taken to its logical conclusion is an exercise in creating flow. The Lean principle of flow means to ensure that all added value work is carried out without waiting time between the process steps. Thus ensuring that customer value is delivered in the shortest possible time. DevOps teams must focus on the flow of work. The challenge is that there are two directions of flow.
Sure, projects go from development into production. But “done” does not just mean that development reaches “code-complete.” DevOps teams also need a direct feedback loop into development. The DevOps team must create a continuous feedback loop: in order to support continuous delivery and integration, the team must also put the processes in place to collect and implement feedback, not just from IT staff but particularly from the business user. This means that the developers within the team will also do their tours of duty as on-call for support issues for their particular service. In one IT organization that adopted DevOps, one of the DevOps teams was actually asked by the customer to slow down because developments were being released quicker than the business team could assimilate them. This is, in fact, a Seven Key Factors to be successful with DevOps 3 clear sign that flow has been achieved; the ability to deliver as and when the customer needs new functionality. The ‘slow-down’ request meant that the team could spend more time improving their own way of working without affecting the delivery of customer requests, thus further enhancing their ability to deliver as and when the customer requires (the essence of the Lean principle of Pull).
Success factor 2: DevOps requires continuously uncovering problems and tackling them.
DevOps is neither a tool nor a technique. It is an organizational and cultural change. Change is feared throughout most organizations of any type, so the adoption of new methodologies can be quite challenging. Therefore, it is vital first to define the business need that brought on the discussion of the potential change as well as the accompanying challenges.
Nowadays, businesses are expected to quickly deliver flawless applications that focus on user experience, but without the right tools, applications, and behavior, this seemingly simple task can turn into a complicated mess. Ultimately, faulty delivery translates into missed business. The first step in creating a DevOps culture is a relentless drive to uncover and solve problems. This attitude supported by a commonly understood and used problem-solving methodology (e.g. DMAIC, Kepner-Tregoe, TRIZ) is the foundation for the successful adoption of DevOps principles. With dedicated, regular and consistent use of problem-solving, the team can create a culture of continuous learning and improvement. And only the IT organizations that can continuously adapt and learn will survive in today’s competitive market environment.
Success factor 3: DevOps requires cross functional teams
As DevOps gains prominence, IT organizations seek to take short cuts by recruiting ‘DevOps Engineers’. The fact is that these people do not exist and the only short cuts are learning from IT organizations that have already taken steps. DevOps is about growing talent internally by creating cross-functional teams. Cross-functional teams have multiple benefits:
- All of the knowledge needed to support and develop the service is in the team, reducing dependencies on others and waiting time.
- Team members can learn quickly from one another
- The flow of information is quick and the information shared is meaningful to all
Open flow of information and open discussion of information within the team regarding the overall performance of the service and about the future development of the service is vital to the success of the team. Building multi-skilled teams that are made up of individual talents (e.g., developers, sysadmins, and testers) can add great benefit, but without the right attitude and mindset, the talent is virtually useless. When people know they can rely on everyone else, the group as a whole also moves much more quickly and efficiently, ultimately leading to happier customers. The right attitude is customer oriented (understanding what the customer perceives as value) and taking overall responsibility for the quality and timelines of the services delivered. Of course, having a wide skill set is beneficial to every aspect of the process, as long as those individuals are willing to be team players.
The first step in a DevOps approach involves recognizing how development, IT operations, and QA are mutually dependent on each other. In its preparatory phase, DevOps relies on cross-departmental collaboration and open communication between the key players in the delivery of the service in order to boost operational efficiency, predictability, and maintainability. The creation of a multi-disciplinary team including all of the relevant actors is the next step. The benefit of cross-functional teams is that even though engineers are associated with a specific function, it does not mean they cannot work on other aspects. For example: quality engineers writing software. Leverage of the strength of each functional role is important, but broadening the capabilities is both motivational for the engineer and improves the robustness of the team. It is, therefore, important to create an environment where people are learning about the other aspects of service delivery because that helps in building better services.
Success factor 4: Demonstrating Lean Leadership behavior
This is where we come to the role of leadership. One of the benefits advertised about DevOps is the self-organizing character of the multi-disciplinary teams. The automatic reaction is that managers see straightaway see a cost-saving: no need for the team management layer!
In fact, in a DevOps environment (especially the larger IT organizations), leadership is absolutely vital for success. And within a self-organizing team, there is always leadership present, maybe not as a formal, hierarchical function, but certainly there is strong technical and organizational leadership within the team. This leadership is found in behavior, rather than formal functions. This does not mean that a DevOps team should not have a formal team leader. The leadership role evolves as the team matures. In either case, it is vital that those playing the leadership role(s) become competent in four areas:
- The ability to define the direction and goals of the team regarding the service delivered and the way in which it will be delivered
- Self-development, continuously seeking to improve their ability to lead the team in the required direction
- The ability to help others to develop, through teaching, coaching and leading by example
- Continuous improvement, continuously seeking out problems (both technical and organizational) to be solved and ensuring that they get solved.
Success factor 5: Build your own DevOps toolbox
When it comes to continuous improvement, one of the greatest challenges is the technical excellence challenge. The ability to create flow and to solve technical problems quickly is completely dependent on the ability of the team to build a set of tools that extensively automates the software delivery pipeline from the development environment to the production environment.
Fortunately, huge steps have been taken in the past five years in the automation of the steps in the software delivery process. A DevOps tool is any tool that supports the automation of the processes and enhances the collaboration of team members and between the teams. However, there is no single tool that does it all, instead a ‘toolset’ approach needs to be employed. The toolset must support flow by covering the entire development-to-operations lifecycle, from infrastructure to business. It should empower the resources to execute the work allocated to them in an efficient manner. The first discipline and associated tooling the DevOps team must master is version control. Without a clear understanding of the power of and need for version control, the DevOps team is doomed to repeat the mistakes made in the ‘old’ IT organization. In fact, disciplined version control is everybody’s business in a DevOps team, whether you are the team’s architect, tester, developer of operations engineer. Everyone must know which version of the software is where in the process. Fortunately, there are tools that support this function. However, even the best tools are rendered useless by inadequate processes and adherence to agreed ways of working. Version control is a classic example of the Lean principle of quality at the source.
Success factor 6: In DevOps everyone is responsible for quality
Every participant in the service delivery is responsible for the improvement of the service the team delivers to their customers. This means the user experience engineer is responsible for the quality of programming just as the developer is responsible for the quality of tests.
Quality is not the responsibility of a single person or an external team, it is the shared responsibility of everyone involved in a service delivery. This is a major shift in behavior and mindset in many IT organizations. Interestingly, this collective accountability for quality is one of the key characteristics of a team: in teams, the participants have a common goal (e.g. the ‘health’ of an IT service) and hold each other mutually responsible for the achievement of that goal. Quality is an integral part of the ‘health’ of an IT service.
Success Factor 7: Get help on your journey towards DevOps
One of the most striking aspects of any DevOps meeting is the drive to share unconditionally. DevOps gatherings exude a collaborative atmosphere in which everyone can learn something. DevOps is recent and the capabilities and knowledge of how to do it are growing on a daily basis. DevOps is about learning.
If your desire to adopt DevOps principle is not accompanied with the humble acceptance that we are all to a certain extent finding our way in a dimly lit space, then you are probably setting yourself up for a huge disappointment. Conferences such as DevOps Days and Enterprise DevOps Conferences provide excellent learning opportunities on all aspects of DevOps, although the technical aspects tends to be quite prominent. Seek out IT organizations that have experience with DevOps. Do realize that they may only have taken the first steps on their journey, and may not yet be achieving huge benefits. These organizations do however have lessons that they have learned regarding early phase pitfalls. In this respect, overcoming traditional structures such as annual budgets, project portfolio boards and centralized architecture boards.
Use available guidance. The Quint DevOps Integration Model is an example of guidance in adopting DevOps, based on both market developments and hands-on practical experience. It identifies the steps that IT organizations need to take from a traditional silo-ed IT organization to a high performance IT organization. It subdivides the development of the IT organization into five key dimensions – Performance, Process, Automation, Organization and Behavior & Mindset. Each of these dimensions has five aspects that need to develop as the IT organization moves towards its DevOps goal. The most important advice is to move, take a step, do something. Doing nothing is no longer an option.
Take a Step
An effective, efficient DevOps practice requires a great degree of collaboration, open communication and cooperation, including willingness to share risks and rewards. Many organizations have been successful at implementing DevOps at a small scale – team level – but often discover that implementing DevOps at enterprise scale is quite challenging. Transitioning to DevOps is, first, a cultural shift, and then a technical, process and organizational shift.
DevOps takes time and effort, requires strong leadership and advocacy, and must be measured in a way that is compatible with the organization’s goals. DevOps will take time. There is no point in time defined as: we’re DevOps now. DevOps is about getting better every day, to keep making better products, deliver better services and to have happier customers. And, in the course of doing so, to make everyone’s job better, easier and more fun.
Global Lead High Performance Transformation
Quint Wellington Redwood
Quint Wellington Redwood