How To Use Scrum with DevOps
In today's video, I'm going to be talking about "How to use Scrum with DevOps". Yes, I do know that Scrum and DevOps do not conflict with each other and in fact, they complement each other. But from time to time I keep on getting questions from people whether they should use Scrum or DevOps. So in today's video, I'm going to bust the myth that you cannot use Scrum and DevOps together. If this is something for your appetite, stay tuned don't go anywhere, folks. A lot of people think that DevOps is only about tools. Well, it really depends on who's promoting DevOps. Most tools vendors will emphasize DevOps as tools. But as we will learn in today's video DevOps is not more than attitudes and behaviors. In 2008 during an Agile conference in Toronto, Canada Patrick DuBois presented a talk about agile infrastructure and operations. As someone with a sysadmin and infrastructure background Patrick envy agile software development teams who are agile in their delivery. He wanted the infrastructure teams to be as agile as software development teams. He brought some agile software development concepts into infrastructures such as infrastructure as code, refactoring, test-driven infrastructure and also continuous deployment not only for applications but also for operating systems, virtual machines, databases, and application servers. In his presentation, he also shared how the infrastructure team should also be part of the Scrum team and how development teams should also have more infrastructure skills. By breaking down the silos and merging infrastructure and software development into one combined team organizations can increase their agility in delivering value to customers. Patrick then extended his talk further by organizing the first conference about agile infrastructure and operations, but he found the name was too long, and he fell for the term DevOps instead.
The first DevOps days conference was held in Ghent, Belgium in 2009. In 2013 Gene Kim, Kevin Beer, and George Stafford extended the idea of DevOps by merging not only the infrastructure and operations team with the development team but also the business team into one cross-functional team. They wrote this idea in their famous book called the Phoenix project. In this book, they also came up with the DevOps in three ways. The first DevOps way is about optimizing the flow of value from left to right. To be able to optimize the flow of value from left to right we must first define the whole value stream, that is starting from when the idea emerges or starting from when the customer gives feedback until that idea or that feedback becomes something valuable for the customers. After we have defined the whole value now we need to have a team that's able to process the work that is flowing from left to right into something valuable for the customers. If the team is not cross-functional they will be dysfunctional. If the team is dysfunctional they will not be able to deliver value to the customers. So I've I already made a video on team compositions in Scrum and the importance of having cross-functional team in Scrum, if you haven't watched that video click the link up here to watch the video. Limiting the number of Product Backlog items that flows through the whole value stream from left to right is another strategy to optimize the flow of value. Some teams may do mob programming to ensure there is a single-piece flow rather than big batching. Refining the Product Backlog items that are flowing through the value stream into a fine granular level is one of the strategies to optimize the flow of value from left to right because a small piece of work will flow faster than a bigger chunk of work. Awesome Scrum teams as written on Scrum guide will spend at least 10% of their time within the Sprint to refine the Product Backlog items for the upcoming Sprint. Automate everything that can be automated, starting from automated build, automated tests, automated deployment, and even automated provisioning is another strategy to optimize the flow of value from left to right. Every automations that will be done by the Scrum team should be listed in the Definition of Done. So I've already made a video on the Definition of Done, if you haven't watched that video click the link up here to watch the video. The whole Scrum team should also collaborate to remove any impediments that are blocking the flow of value from left to right because removing impediments is not only the Scrum Master's job. The second DevOps way is about optimizing the flow of information from right to left or in other words to amplify feedback. To be able to amplify feedback, we need to have feedback loops. What's so interesting is Scrum already has built-in feedback loops called the Sprint and also the Daily Scrum.
At the end of the Sprint, there are two opportunities to gather feedback. The first one is the Sprint Review which is to gather feedback about the product's performance in the market. The best way to run a Sprint Review is to use an outcome-driven metric as an input rather than just discussing the features completed within that Sprint. The whole audience mindset during Sprint Review should always be about outcome over output. Besides the Sprint Review, the Sprint Retrospective is also an opportunity to gather feedback. The purpose of the Sprint Retrospective is to gather feedback regarding people's interactions and also process from the Sprint that has just finished. Besides the Sprint review and the Sprint Retrospective, the Daily Scrum itself is also a feedback loop. The purpose of the Daily Scrum is for the development team to inspect their progress towards achieving the Sprint goal. So I've already made a video on how to create an outcome-driven Sprint goal. Having an outcome driven Sprint goal will make your Sprint Review really different. Your sprint review will not look like that boring User Acceptance Test (UAT) event. If you haven't watched that video click the link up here to watch the video. Besides doing Sprint Review, Sprint Retrospectives, and also the Daily Scrum, the Scrum team can also add additional feedback loops within the Sprint by doing daily deployments. By doing daily deployments the whole Scrum team can generate outcome-driven metrics to be discussed during Sprint review much earlier. Another strategy to amplify feedback is to practice test-driven development (TDD) because by practicing test-driven development the development team will be able to get feedback about the quality of their code and also whether they have broken something in their existing code base. Practicing test-driven development is one of the fastest ways to amplify feedback.
The third DevOps ways are about optimizing learning and experimentation. To be able to optimize learning and experimentation we need to do experimentation deliberately within the Sprint. Scrum itself is about continuous improvement. Sprint Retrospective is an opportunity for the whole Scrum team to improve the people's interaction and process for the next Sprint. Scrum requires that at least one actionable item to go in the next Sprint Backlog and must be implemented in the next Sprint. This is to ensure that the whole Scrum team is improving from Sprint to Sprint. Another strategy to optimize learning and experimentation is to practice hypothesis-driven development. The first step to take is for the Scrum team to convert their Product Backlog items into hypotheses to be validated rather than just features to be implemented. So I've already made a video on how to create your Product Backlog items as a hypothesis, if you haven't watched that video click the link up here to watch the video. To ensure learning and experimentation is optimized, the Scrum Master must influence everyone in the organization, including the management, so that psychological safety is embedded within the organization. A psychologically safe organization is where people do not have fear of taking risks and also do not have a fear of getting blamed for making mistakes. The Scrum Team has a Sprint retrospective which usually occurs at the end of the Sprint but there is nothing stopping the Scrum team to have an ad hoc retrospective and also blameless postmortem in the middle of the Sprint. Having ad hoc retrospective and blameless postmortem in the middle of the Sprint is another strategy to optimize learning and experimentation. So that is all from me today folks I hope you enjoyed today's video. If you enjoyed this video don't forget to smash that like button and don't forget to subscribe to my channel so that you won't miss any of my videos in the future. And also don't forget to share today's video so that more and more people can understand how DevOps actually complements Scrum.