The Culture of DevOps

As we enter what some call the second decade of DevOps, there is a concern that the once underground movement has become mainstream and DevOps is now fully integrated into any software development lifecycle. Even large companies like Adobe [1] have made the migration. However, not everyone who is doing DevOps is doing DevOps. Those who have gone through the process know DevOps needs to be initiated internally to be successful. There are no third-party solutions that will make a company successful without people and culture shifts.

They are the 3Cs: - Culture - Collaboration - Continuous Improvement

A cultural shift does not always mean a reorganization, though. Many of the concepts of DevOps can be achieved through little changes to everyday processes and routines. This course will look at some of those concepts and how they can help make the necessary changes.

CALMS

CALMS is a model that can help determine the level of DevOps maturity within a team or an organization. Each part of the model can be implemented over time, together or separately.

CULTURE: Technology adoption should be a benefit to the business rather than an investment in the technology itself. When software shows success in deployment, enabling business success, it is easier to convince the business to invest in DevOps.

AUTOMATION: Every developer and systems admin automates some feature of their work. DevOps not only encourages automation of routine tasks to reduce needless toil, but it also promotes cross-platform automation, further reducing the risk of technical debt across platforms.

LEAN: As more and more toil is removed from the system, resources become available to enhance the product further or reduce costs in other areas. A balance must be maintained between ensuring there are resources available to continue to advance and continue to pay the run costs of operations.

MEASUREMENT: Effective software development has to be measured. The effect of change, impacts on the future state, and modeling costs cannot be done without good metrics.

SHARING: At the end of the day, if teams are not sharing information openly between each other, it is hard to make efficient progress. With the increased complexity of modern systems, the days of the lone developer or hero operations systems administrator are gone.

The Three Ways

The Phoenix Project presents the Three Ways as the set of underpinning principles from which all the observed DevOps behaviors and patterns are derived

The First Way enables fast left-to-right flow of work from Development to Operations to the customer. In order to maximize flow, we need to make work visible, reduce our batch sizes and intervals of work, build in quality by preventing defects from being passed to downstream work centers, and constantly optimize for the global goals.

The Second Way enables the fast and constant flow of feedback from right to left at all stages of our value stream. It requires that we amplify feedback to prevent problems from happening again, or enable faster detection and recovery. By doing this, we create quality at the source and generate or embed knowledge where it is needed—this allows us to create ever-safer systems of work where problems are found and fixed long before a catastrophic failure occurs.

The Third Way enables the creation of a generative, high-trust culture that supports a dynamic, disciplined, and scientific approach to experimentation and risk-taking, facilitating the creation of organizational learning, both from our successes and failures. Furthermore, by continually shortening and amplifying our feedback loops, we create ever-safer systems of work and are better able to take risks and perform experiments that help us learn faster than our competition and win in the marketplace.

Setting the Stage for DevOps

The DevOps engineer role is one of the highest paying and most in-demand tech jobs in today’s market. But wait a second. What exactly is a DevOps engineer? What makes the role different from a software engineer or an IT professional? Why exactly is this role in such high demand?

DevOps In The Enterprise

Enterprise-level DevOps has additional complexities over departmental levels. Resource utilization, team integration, and shared resources exist at higher levels and involve more players.

Continuous Improvement

DevOps can be considered a snowball rolling downhill. Once you get started, more and more things get added to the process. But unlike a run-away snowball, fast-fail leads to course corrections and constant change. The change, however, should lead to improvement, and with each iteration, a decrease, or elimination, in technical debt. With each course correction, improvements are added to the system, until it reaches the point of diminishing returns. Ideally, given the complexity of modern systems, it is a continual process.

Kanban Change Leadership: Creating a Culture of Continuous Improvement (Optional Reading)

This book provides an understanding of what is necessary to properly understand change management with Kanban as well as how to apply it optimally in the workplace. The book emphasizes critical aspects, several traps which users repeatedly fall into, and presents some practical guidelines for Kanban change management to help avoid these traps. The authors have organized the book into three sections. The first section focuses on the foundations of Kanban, establishing the technical basis of Kanban and indicating the mechanisms required to enact change. In the second section, the authors explain the context of Kanban change management—the options for change, how they can be set in motion, and their consequences for a business. The third section takes the topics from the previous sections and relates them to the social system of business—the goal is to guide readers in the process of building a culture of continuous improvement by reviewing real case studies and seeing how Kanban is applied in various situations.