Scrum & Agile DevOps – Building bridges not walls | Will Jeffrey | Skillshare

Scrum & Agile DevOps – Building bridges not walls

Will Jeffrey, Professional Agile Coach

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
23 Lessons (29m)
    • 1. Welcome

    • 2. Scrum Is Just a Framework

    • 3. Lean Thinking, Systems Thinking & Value Stream Mapping

    • 4. Bringing Together Scrum & DevOps

    • 5. > Scrum Team Composition

    • 6. > Removing Impediments

    • 7. DevOps Three Ways

    • 8. 1. Optimise Flow

    • 9. 1-1. Sprint Planning

    • 10. 1-2. Continuous Delivery to Production Environment

    • 11. 1-3. Flow Based Daily Scrum

    • 12. 1-4. Definition of Done

    • 13. 2. Amplify Feedback

    • 14. 2-1. Sprint Review

    • 15. 2-2. Hypothesis-Driven Development & A/B Testing

    • 16. 2-3. You Ship It, You Manage It

    • 17. 2-4. Pair Programming & Code Review

    • 18. 2-5. Daily Scrum As a Feedback Loop

    • 19. 3. Maximize Learning & Experimentation

    • 20. 3-1. Psychologically-safe And Blameless Environment

    • 21. 3-2. On-demand Retrospectives

    • 22. 3-3. Slack Time  for Improvements

    • 23. Conclusion


About This Class

it's quite common I get a question from someone in the agile community, "Should I use Scrum or DevOps?".

This question deserves attention because of the motivation to choose DevOps over Scrum.

  • People want to go with DevOps over Scrum because they want to be agile but they can't change their organisation.
  • Many people in the agile community whom I've interacted with think that DevOps is only about toolings for continuous delivery.

Both Scrum and DevOps have been proven to work, so bringing the thinking together from both will only make the teams better. We should stop thinking of a development team as working in one way and the operations teams working in a different way,.

By using Scrum together with DevOps, we believe that lines of communication can open even more broadly and through the exact nature of Scrum being empirical, teams can keep learning, adapting and improving. We cannot let delivery get stagnant, we must keep improving and that is a big part of bringing DevOps and Scrum together.

In this course, you're going to learn how to integrate Scrum and DevOps starting from DevOps lense.

What you'll learn:

  • The DevOps 3 ways
  • How to adjust Scrum Events & Definition of Done with DevOps
  • The importance of CI/CD
  • The Flow based model
  • Hypothesis-Driven Development & A/B Testing
  • How to take advantage of XP Practices like Pair-Programming & Code Review
  • The importance of fostering a psychologically-safe and blameless environment
  • The reasons for providing slack time



1. Welcome: It's quite common I get a question from someone in the agile community. Should I use Scrum or Dev ops? This question deserves attention because of the motivation to choose Dev ops over scrum People want to go with Dev ops over scrum because they want to be agile but they can't change their organization. Many people in the agile community whom I've interacted with think that Dev Ops is only about tool ings for continuous delivery. Both scrum and DEV ops have been proven to work so bringing the thinking together from both will only make the teams better. We should stop thinking of a development team is working in one way in the operations teams working in a different way by using scrum together with Dev ops. We believe that lines of communication can open even more broadly and through the exact nature of scrum being empirical teams can keep learning, adapting and improving. We cannot let delivery get stagnant. We must keep improving and that is a big part of bringing to have Upson scrum together We're going to learn how to integrate Scrum and Dev ops. Starting from Dev Ops lands 2. Scrum Is Just a Framework: scrum is just a simple framework for complex product development that is based on values and principles. Scrum is not a prescriptive methodology that tells you how your process should look like. Scrum is highly focused on what is happening during the sprint scrum will not tell you how your process within the sprint should look like scrum is an additive framework. What that means is scrum will only tell you the minimum sets of what you need to have so that you can claim you're using scrum the same as when you need to install a software on your computer. There is a minimum requirement for the computer specifications, but it is not illegal to install the software on a computer that is above the minimum specifications. So with this premise, it is not illegal to add practices that will enhance the flow of your value delivery within a scrum framework. 3. Lean Thinking, Systems Thinking & Value Stream Mapping: Dev. Ops starts from systems thinking and view the whole value stream in the system rather than Onley zooming into the development phase. What that means is how the work gets into the development, the upstream and how the works get delivered to customers. The downstream is also a concern in Dev Ops Systems thinking views how every interconnected element in the system effects one another. In a complex system like a corporate, elements do not work in isolation. Making one change in an element is going to impact another element in this system ah value stream is how processing customer requests into a tangible outcome flow from one element to another element in the whole system. Whenever there is a request, there is a value stream in the system. Besides systems thinking, Dev Ops is also based on lean thinking. Lean thinking is about reducing waste in the value stream. Any activities that are non value added can be considered as waste. I am not going to elaborate on lean and types of waste in this course, lean thinking systems, thinking and mapping. The whole value stream is important and works nicely with scrum because scrum is based on lean thinking when we're using scrum and develops all of the activities in the value stream from customer request to releasing the product to the production environment Order customers happens within the sprint. This does not mean a sprint is in many waterfall where deployment only happens at the end of the sprint or all of the analysis happens at the beginning of the sprint, it could happen at any time during the sprint. 4. Bringing Together Scrum & DevOps: imagine a world where a cross functional, business oriented teams deliver working software continuously and where work flows seamlessly between all the right stakeholders in real time. Add to that where value is clearly understood, measured and reported on this vision is the reality for many smaller startups that have blended business and technology with customer and market to work in a holistic way of delivering customer value. Scrum teams air accountable for delivering software and operations, teams air responsible for putting the environment in place that enables them to do it in a secure, safe, high quality way. 5. > Scrum Team Composition: scrum teams adopting DEV offs will have a different way of working to scrum team who are not adopting develops. Not only their way of working is different. The team composition also looks very different. Scrum says that the development team consists of professionals who deliver the potentially releasable increments at the end of the sprint. Many people see the development team only consists of developers. That is why many come to think that scrum is for development phase only as Dev Ops views the whole value stream and uses systems thinking the professionals and scrum team adopting Dev ops are everyone who processes the product backlog item PB I in the whole value stream from end to end in a scrum team adopting develops The team composition includes everyone but not limited to marketing people Analysts You I ux designers, developers, operations people so sad Mons data scientists and site reliability engineers. They all work together collaboratively as one unit to deliver value to their customers 6. > Removing Impediments: accused break agility because they removed the ability of the team to be in control of the situation. When support organizations are connected to agile teams via cues, it is very likely that the team as a whole will be less effective as they wait for their item in the queue to reach the top. When building the future delivery organization, you should incrementally remove cues and replace them with self service capabilities. Traditional I T functions such as environment provisioning, database security network and even deployment function should be developed and supported as a series of self service capabilities. These capabilities will look much like the services from companies like Amazon Web services AWS, Microsoft, Azure and Google and often will take advantage of these external cloud services, adding the organization specific intellectual properties to make them company compliant. Legacy applications can also kill agility because over time these legacy systems have grown so complex that no one understands them. This complexity makes it very hard for a single team to have all the skills necessary to deliver value. For example, the amount of work and skills required to produce an end to end integration test makes it almost impossible to include in one spring. Unfortunately, there is no secret in solving this problem and instead requires organizations to re architect the systems to enable more modular development, deployment and testing. Helping grow team capabilities means empowering teams to do what needs to be done to release the product instead of creating large amounts of red tape to protect the team from themselves. Empower teams to make decisions on deliver the product, but ensure that the amount of change is small enough that it can be easily backed out of, coupled with environments and architectural practices that are robust enough to handle change. Reducing external dependencies through self service automation rather than connecting the agile team, too. Complex processes provides self service capabilities that allow the scrum team to drive their own outcomes. Examples include provisioning. Virtual machines were getting access to test data supporting teams with shared technical services available without queueing. The simpler the software is, the more Angela the team can be in developing and supporting it. As the complexity and value of the software increases, it becomes harder and harder for anyone team to have all the right skills to support it. But any dependency on external skills can become a bottleneck by concentrating on supporting scrum teams with experts who can coach or mentor teams on a particular technology or approach. You both remove a bottleneck and increase the skill of the team, making them more flexible and agile. Simplifying and module arising, legacy applications look to re factor the legacy systems and supporting infrastructures such as environments and tests to better support agility. That means focus on reducing the overhead of testing provider better support for decoupling and spread legacy knowledge throughout the teams rather than leaving it in one specialized area. 7. DevOps Three Ways: The Dev Ops Three Ways are the set of underpinning principles that make up develops The Dev Ops Three Ways Air, based on lean thinking and systems Thinking Dev. Ops Three Ways Work With Scrum is the Three Ways is not about specific tools and practices that are often Mawr emphasized during any discussion about Dev ops in the Communities. Scrum teams adopting Dev UPS three ways will have a different way of working with scrum teams who are not adopting it. None of the Dev Ops three ways are in conflict with a scrum framework and scrum values. Disclaimer. The practices I elaborate here not a complete list of practices to implement the develops three ways. I will be only elaborating some practices to meet the Dev Ops three ways that are already commonly practiced in the communities. 8. 1. Optimise Flow: the first way in the Dev Ops three ways is optimized flow in Dev Ops were concerned about optimizing the flow of single product backlog item since the first time customer requested it until the customer gets the requested PB I and forms of tangible item ah working feature in the production environment. Anything that gets in the way to make the PB ice flows smoothly in the value stream, maybe a bottleneck that should be removed. Many people in the agile communities believe that flow contradicts with scrum sprint because the premises you plan for the whole PB, I need to be completed for the sprint during the sprint. Planning the sprint is a commitment you can only deliver to production ones after the Sprint Review. This is sprint as many waterfall model, even though there is nothing wrong with this great scrum. Teams should move away from this model as their improving their way of working. We will see why the Sprint works with flow based model in scrum. The scrum master is the role responsible to remove anything that impedes the flow of value delivery to the customers. When the scrum team decides to adopt flow based model. The scrum master needs to learn about flow based model and coaches. The whole scrum team on how Scrum works with flow based model. 9. 1-1. Sprint Planning: when it comes to sprint planning. According to the scrum guide, enough work is planned during sprint planning for the development team to forecast what it believes it can do in the upcoming sprint work plan for the first days of the sprint by the development team is decomposed by the end of this meeting, often two units of one day or less scrum team adopting a flow based model will have a different nature of Sprint planning nothing in scrum. God states that the scrum team fixed the plan for the sprint during Sprint planning. The Sprint planning is more focused and committed with the sprint goal rather than the sprint backlog. The Sprint planning is an opportunity to get everyone's heads down to look at the same goal . The purpose of the Sprint planning is to calibrate the next sprint development with a single goal during Sprint planning enough work is forecasted for the very few days of a sprint. More work may emerge later on during the sprint as long as it does not endanger the sprint goal 10. 1-2. Continuous Delivery to Production Environment: According to the scrum guide, the heart of scrum is a sprint, a time box of one month or less, during which had done usable and potentially releasable product increment is created. Nothing in scrum says that you can only deliver to production environment after Sprint Review. The Sprint Review is not a phase gate, but an opportunity to get feedback about what you have developed in the Sprint retrospectives is an opportunity to improve the process, how you developed the product, even in a flow based model. You need to know whether you have flow into the right direction. Consider the end of the Sprint works like a global positioning system GPS to track where you are at the moment. The Sprint Review and the Sprint retrospective do not and should not block flow, but it should enhance flow. One thing that I would like to highlight here is the Sprint is not a release cadence but of planning and review cadence. At a minimum, you need to have a potentially releasable product increment. At the end of the sprint, for example, scrum teams adopting extreme programming XP delivered to production every night. So there is nothing wrong with releasing the product to production environment more than once in a sprint. If the scrum team is able to deliver frequently more than once in a sprint, that means they've gone beyond the minimum standards that scrum requires. We should celebrate it because not many teams are able or allowed to release to production environment multiple times in a sprint or even multiple times a day. 11. 1-3. Flow Based Daily Scrum: scrum guide reads about daily scrum. The structure of the meeting is set by the development team and can be conducted in different ways if it focuses on progress toward the sprint goal Scrum team. Adopting flow based model will use the daily scrum to inspect the flow of the PB I towards the sprint goal. The daily scrum becomes a tool for the scrum team to optimize flow. Some scrum teams may do it more than once a day because they know that Daily scrum is not about reporting but about synchronizing each other's plan. Some scrum teams will look at their con bond system during daily scrum to optimize flow during daily scrum. New sprint backlog may be added as the team learn more about their progress. The scrum master will work to remove anything that is impeding flow that is discovered during daily scrum. Take our course on daily scrum deep dive if you want to know more about it, 12. 1-4. Definition of Done: scrum teams adopting Dev Ops will have a more ambitious definition of done compared to scrum teams who are not adopting Dev ops because they have an ambition to deliver the product to production environment more than once a sprint, sometimes up to multiple times a day. If their definition of done is not ambitious, they may not meet their ambition. Some practices they may have in their definition of done that will optimize flow are infrastructure as code so that the team has a production like environment at every stage in the value stream. Automated testing that will improve flow from unit testing. Integration. Testing to acceptance testing with supporting practices such as test driven development, behavior driven development acceptance, test driven development, continuous integration continuous an automated deployment. Decouple deployments from release using techniques like canary release or feature toggling architect for low risk releases like using micro services. Some of the practices listed above are already implemented by scrum teams who are implementing extreme programming. The list above is not necessarily a complete list of practices to optimize flow in the value stream as I believe there will be more practices that may be discovered by the community in the future, 13. 2. Amplify Feedback: the second way in the Dev Ops three ways is amplified feedback. Scrum is all about feedback at its core. Scrum has the sprint and the daily scrum is a built in feedback loop scrum team adopting Dev offs will have a different nature of implementing the feedback loops. For example, Scrum Team implementing Extreme Programming has multiple feedback loops with pair programming and test driven development is the smallest feedback loops. 14. 2-1. Sprint Review: scrum team Adopting Dev Ops will have a different way of running the Sprint review because the product is already in the production environment before the Sprint review is held. So instead of giving feedback about the product increments, the whole scrum team, along with a business, will look at a single dashboard of metrics that covers business level metrics, application level metrics, infrastructure level metrics and deployment pipeline metrics. By looking at a holistic view instead of isolated view metrics, the whole business and the scrum team is able to give a sound judgment about the performance of the product in the market and collaborating on creating a strategy they should apply in the next sprint to optimize the value of the product. 15. 2-2. Hypothesis-Driven Development & A/B Testing: scrum team adopting Dev Offs will implement hypothesis driven development for this kind of scrum team. Done does not stop until feature complete only because they believe completed features does not mean the product is successful in the market. For this kind of scrum team. Done is when the feature gained traction in the market. The whole scrum team works together to ensure that every feature delivered is valuable for customers. 16. 2-3. You Ship It, You Manage It: developers in a scrum team adopting DEV. UPS has a higher responsibility and need to learn about maintaining the application, live in stable in the production environment to amplify feedback and reduce wasteful activities. Developers in a scrum team adopting Dev offs get to maintain the application they develop in production environment. The mantra is you ship it, you get to manage it in some organization. This goes as far as giving time shifts to developers to attend to production incidents and outages. Support call not only in Dev Ops developers air given higher responsibility, the management also needs to give higher trust to empower the developers to go above and beyond. 17. 2-4. Pair Programming & Code Review: scrum team implementing extreme programming religiously do pair programming pair programming is not about two programmers doing programming together on one computer. It's more about live feedback on how their code will actually work in production. Scrum team adopting Dev offs will utilize pair programming and code review to amplify feedback. 18. 2-5. Daily Scrum As a Feedback Loop: daily scrum is all about feedback. Daily Scrum is not about a status report. In a complex, unpredictable environment, feedback is very important. Having feedback loops nested within another feedback loop is essential in a complex environment. The feedback in daily scrum will amplify the feedback received at the end of the sprint. The scrum team will learn how they're progressing towards the sprint goal. 19. 3. Maximize Learning & Experimentation: the third way in the develops three ways is maximized, learning and experimentation. The heart of scrum is about continuous learning because Scrum is based on empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known The scrum guide. The purpose of having sprints is to maximize learnings and to improve how scrum teams will operate and deliver value in the next sprint. Sadly, many organizations without a clear understanding of scrum values and principles we'll treat the sprints is a many waterfall and we'll fix the scope for the sprint without any rooms for the scrum team to innovate or to learn something new. The scrum master is the role who is responsible to ensure that the organization has a culture of learnings. 20. 3-1. Psychologically-safe And Blameless Environment: great scrum master will focus and will invest more time and injecting the scrum core values into the scrum team and the whole organization rather than just focusing on this groom mechanics. They know that the scrum core values will contribute to creating a psychologically safe and a blameless environment. In Dev Ops, everyone works together to ensure that the product is valuable and meets the business goal in a psychologically safe and blameless environment. There should be no politics, personal agenda and silos. Everyone in the value stream looks at the same holistic product metrics. Regardless of their role. A blameless culture is important so that everyone in the value stream is collaborative and not just throwing work over each one shoulder. Any incentives that make everyone only cares about their metrics should also be removed. The third way is more about organization re factoring practice than it is about technical practice. The scrum master is the role responsible to coach the management and the human Resource department on changing the incentive system that blocks collaboration and only foster politics and bureaucracy. 21. 3-2. On-demand Retrospectives: According to the scrum guide, the scrum, Mestre encourages the scrum team to improve within the scrum process framework, its development process and practices to make it more effective and enjoyable for the next sprint. One misconception about scrum in the communities is that retrospectives air learnings only happened at the end of the sprint. As we've learned earlier, Scrum is an additive process. Everything in scrum is a minimum set requirements. Sprint retrospectives provides a focus time to reflect back and to learn about what is happening in the sprint. But that does not mean scrum does not allow you to learn multiple times or to have additional retrospectives in a sprint. If the organization becomes a learning organization and wanted to have more learnings that the ones in retrospectives, then we should celebrate it. Because many organizations stopped growing when they stopped learning in a scrum team adopting flow based model learning needs to happen just in time and more frequent. Many scrum teams celebrate learnings during the daily scrums they see Daily Scrum is about inspecting and adapting 22. 3-3. Slack Time  for Improvements: according to the scrum guide. To ensure continuous improvement, it includes at least one high priority process improvement identified in the previous retrospective meeting. Many managers or organization still see scrum Sprint is a mini waterfall or sometimes many deadlines and only about delivering features. People working in these organizations come to think that scrum does not provide time for improvements. This is not true. In fact, Scrum Guide states that at least one item in the Sprint backlog must contain improvements identified during the previous retrospectives. Scrum team Adopting DEV ops will go further by deliberately providing slack time to innovate as much as 20% time or more to improve the value of delivery and the value stream . 23. Conclusion: As you can see, Dev Ops is not about tools and automation in the delivery pipeline. In fact, as we have learned, tools and automation is only 1/3 of develops, I would say it is even less in overall Dev. Ops is about collaboration and collective ownership. Focus on the flow of value delivery and learning and experimentation culture. But sadly, many tooling vendors. Position Dev ops is tools and process for delivery pipeline. The vendors that I've witnessed in my market are more focused on tools, but your experience may be different to mine. This will get the management excited because many managers whom I've met think that after buying and installing the Dev Ops tools without changing their organization will make their company instantly agile. This is like putting the cart in front of the horse from this course. We've seen that scrum and Dev ops actually share more in common than most realize. Just like house groom is not about tools in process. The Dev Ops three ways is also about values and principles. Hopefully, this course, along with the visual, helps you understand how scrum and Dev ops work together and how they do not contradict each other. You should be adopting both scrum and Dev ops rather than choosing either one. Supporting customer centric scrum teams is still fundamental for success and that means radical changes to how changes managed services are provided and teams are organized. There continues to be a need for the develops movement and scrum teams to work together to deliver done software and support each other in their constant need to improve by inspection and adaptation through transparency. I hope you will make the best use of scrum and develops to deliver great products to your customers.