By 
DevOps is like Agile but applied beyond the software team. The real question, however, is: which approach would win in a fight?
In one corner, we have the certified Scrum Master, known to his friends as “the extreme programmer,” and his children as the “LeSS SAFe DAD”: Agile!
In the other corner, the lean culture professional relies on continuous delivery and infrastructure as code. He calls his left arm Dev, the right Ops: DevOps!
I may have exaggerated a bit, but when you hear opinions about Agile and DevOps, you might think they are entirely different ideas. Adding to the confusion is that both concepts seem to defy definition. They even have their jargon and slogans. Agile as the older approach may be a little less vague, but at least for DevOps, there are a dime a dozen definitions. This lack of clear explanations has resulted in common meanings being confused.
Agile is often equated with Scrum, DevOps with Continuous Delivery. This over-simplification creates unnecessary tension between Agile and DevOps. You might be surprised that the two are best friends.
The historical connection between DevOps and Agile cannot be denied. When Patrick Debois and Andrew Clay Schafer tried to agree on the “Agile Infrastructure” at the Agile Conference 2008, they built the bridge to DevOps. The term “DevOps” was coined later by Patrick Debois, but the Agile Conference still cherishes this connection with the DevOps track. If we take a closer look at Scrum and Continuous Delivery, we discover that there are also practical connections between Agile and DevOps in addition to the story.
Agile is more than Scrum.
In some teams, Scrum makes the difference between constant, frustrating struggle and productive, successful teamwork. In other groups, Scrum replaces political moves and over-engagement with objectivity and a clear focus. It can also be represented as a dogma. If the circumstances in the company or at work require something different, an agile team uses the basic Scrum principles. Still, it adapts the corresponding practices to work more effectively. This is particularly important when using Scrum outside of software development.
Planning for unplanned tasks
Agile members of the DevOps community know that Scrum helps keep track of unplanned tasks. Operations teams’ functions can be planned: the releases for a significant system change, the migration between data centers, or the implementation of system upgrades. Most of the work of ops teams, however, consists of unplanned tasks resulting from performance peaks, system failures, or security incidents. Such events require an immediate response. The unit cannot wait for the appropriate lessons in a backlog for the next sprint planning session.
For this reason, many DevOps-oriented teams use Kanban instead of Scrum. In this way, you can track planned and unplanned tasks equally and analyze the interplay between the two. Some groups also use a hybrid approach, which is often referred to as “Scrumban” or ” Kanplan ” (Kanban with backlog).
In many respects, the fact that Scrum is so widespread is that it does not prescribe any technical practices. The lean management processes of Scrum are a tremendous advantage for many teams. Previously, the priorities of several masters competed with each other, and there is now only one set of importance in the backlog. A specific schedule has replaced the previous excess of ongoing work based on experience. Together, these two changes can bring a whole new level of productivity to the team. The team may still lack technical practices such as code reviews, automated acceptance testing, and continuous integration.
Proponents of other agile processes like Extreme Programming are convinced of the importance of technical practices for sustainable speed in the team and transparency towards management and stakeholders. Some scrum teams go over to recording technical tasks in the backlog. Although this approach is in line with the guidelines of Scrum, in practice, it quickly leads to problems due to the bias of the product owners concerning the features. If the product owners are not technology experts, they are quickly overwhelmed with the cost-benefit analysis of the technical practices. This applies in particular to technical tasks that impact reliability, performance, and security and thus on the operations area.
The product owner and service owner
At Atlassian, we have recognized that we can cope better with two different roles for the products we operate. Our product owners know which features the users need but are less able to weigh these features against non-functional aspects such as performance, reliability, and security. For this reason, Atlassian also has a service owner for some SaaS products who is responsible for prioritizing these non-functional aspects. Except for occasional negotiations between the two responsible parties, these roles can be represented in independent teams. Indeed, there are other ways to “reinforce” the feedback from the operations team, but this method helps us overcome the common feature bias of product owners. The two-person approach isn’t the only path to DevOps. It is only essential to consider the non-functional aspects as “features” and plan and prioritize them in the same way as the functional user stories.
Ultimately, all of these criticisms regarding Scrum cannot be traced back to Scrum itself. As with agile methods, Scrum has integrated mechanisms for process improvement, which are referred to as “retrospectives.” We, therefore, assume that some Scrum teams use DevOps as a source of inspiration and optimize and adapt their approaches towards DevOps with Scrum retrospectives. However, very few teams get by without food for thought from outside. As long as DevOps is not yet mainstream (and maybe even taught during studies or training), it does not naturally result from Scrum. It probably doesn’t matter whether the team hires an Agile or DevOps coach, as long as they have experience in automating the creation,
DevOps is not just about continuous delivery.
When implemented correctly, Continuous Delivery (CD) helps limit ongoing work (WIP), while automated deployment helps ease restrictions. In this way, a team can use CD to achieve more frequent, higher-quality releases instead of choosing between speed and quality. However, as with Scrum and Agile, it should be noted that teams focused on continuous delivery may miss the broader context of DevOps.
CD does not address communication issues between the company and the software team. If the company has a year-round, budget-driven planning cycle, the group pushing the commits to production may have to wait several months for the company to respond. The reaction is then often only an emergency solution, for example, canceling the project or – even worse – doubling the project team (which is to be assessed negatively because the addition of a large number of new team members leads to interruptions ).
You Might Also Be Interested In:
Mobile payment: everything you as a retailer need to know about the new payment method.
Agile Fluency model
In the Agile Fluency model, the focus on value, where teams focus on transparency and coordination, is the first level of fluency. CD quickly degenerates into an endless cycle of technical improvements that do not significantly benefit the company. A team may get fast, high-quality deliveries on a product with little benefit to the end-user or the business. Even if many users comment positively, everyday use may become apparent when looking at the entire company portfolio. Without this adeptness, a team can find it difficult to trade-off technical practices and features. This is especially true for groups with a legacy codebase without automated testing and a design designed for frequent deployments. In a legacy environment, a transformation to CD can take several years. It is therefore imperative that the team be able to highlight the benefits to the company.
The three ways
DevOps is more than just an automation of the deployment pipeline. According to John Allspaw, DevOps means that members of the operations team think like developers and vice versa. With this in mind, Gene Kim explains the basic principles of DevOps as “The Three Ways”:
The first way of Systems thinking, the performance of the entire system is considered instead of a single work silo or a single department. It doesn’t matter whether the contribution comes from a whole division or a single employee.
The second-way Reinforcement of the feedback loop This is about creating the structured feedback loop. Almost every process improvement initiative aims to shorten and expand feedback loops to make the necessary corrections.
The Third Way Corporate culture of constant experimentation and learning- Creating a corporate culture that encourages two things: on the one hand, persistent experimentation, risk-taking, and learning from mistakes, on the other hand, knowing that repetition and practice make perfect.
At the heart of Continuous Delivery is The First Way:
Automating the process from Dev to Ops. Automation naturally contributes significantly to the acceleration of a deployment system. However, the systems mindset does not only apply to automation.
The Second Way is based on the principle “Developers have pagers too.”
Pagers may not be required, but developers should be included in the operations of the operations team. This enables them to better assess the consequences of their development decisions. With this in mind, you might want to place log messages in a more convenient place and make the messages more meaningful. It’s not just about awareness. The developers also contribute to troubleshooting with their internal system knowledge to find and implement solutions more quickly.
The Third Way refers to incremental experiments.
In the system as a whole, not just through changes to the application in the pipeline. It is relatively easy to see how long the automation will take and how it can be further optimized with an increasingly powerful infrastructure. Less obvious is the creation of delays due to handoffs between different roles or organizations. So the teams check and adjust the entire delivery workflow to improve human collaboration. Constant adjustments and optimizations are essential for CD. If the team does not think about how to work more effectively and adjusts its behavior to other points, the CD will not develop further. The team needs to be able to solve its own problems.
In Scrum, every retrospective is an opportunity to improve practices and tools. This opportunity is wasted, however, if the team does not resolve short-term and long-term technical problems in the course of the retrospectives and instead waits for the Product Owner to add CD tasks to the backlog – which will never be the case.
DevOps is like Agile but applied beyond the software team
Scrum primarily refers to the Agile principle “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” (Welcome change requests, even at late stages of development. Agile processes use changes as a competitive advantage for the customer.).
Continuous delivery is mainly related to the Agile principle “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” (The top priority is to keep customers happy by providing valuable software early and continuously.)
What agile means
Above all, agile means that incoming and outgoing changes are viewed positively. Rituals like stand-up meetings and sprint planning are less important. Ten further principles are laid down in the “Agile Manifesto.” However, teams should not make a selection from these principles but should consider them all. Together, the principles represent an attitude towards change that applies to both Agile and DevOps.
Agile and DevOps also have this focus on business benefit in common. These teams face the challenge of operating sensitive systems that are of enormous importance to the company. Even the most urgent change requests affect these critical systems. The positive attitude towards change that is typical of Agile does not welcome change for its own sake. Rather, the development team should take responsibility for the quality of the changes and improve the overall capacity to add value to the company.
In conclusion, it should be noted that neither Agile nor DevOps should be understood as independent corporate goals. Both are culture-related movements designed to inspire the company for better ways to achieve goals. Agile and DevOps work better together than in rivalry. If you want to avoid confrontations between the two ideas, you have to deal with the values and principles they are based on. Fast, too narrow definitions lead to silo thinking. Now that you know that there is more to Agile than just Scrum and there is more to DevOps than just CD, you can take advantage of the powerful combination of Agile and DevOps.
You can also visit our sister sites for similar posts: Business.
Comments