[MUSIC] When I first started getting more exposure to DevOps and Lean I started to encounter quite a few skeptics. I had people saying to me, Agile is the new DevOps or Lean practices don't apply to software delivery, it only works in manufacturing. It was comments like theses that prompted me to do some additional research into Lean, and some of the additional fundamental elements of DevOps. That additional research naturally led to Dr. William Edwards Deming's work on system thinking. If you aren't familiar with Deming, I'd suggest you read up on him. He basically led Japan's rise in industrial manufacturing after World War II and is credited as having had more of an impact on Japan's dominance in production quality control than any other non-Japanese person. Japan even created the Deming Prize which has become one of the highest honors in the world related to total quality management. As I began my research, I stumbled upon a quote by Deming that was helpful as I started to talk through why we needed to evolve. One of my favorite Deming quotes is, it is not necessary to change. Survival is not mandatory. When I first encountered this idea I was in retail, and we are seeing a lot of disruption in the industry with the rise of Amazon, and other specialty and digital retailers. For me, that quote was really helpful to get a conversation started with people about systems thinking. In this video we are going to touch on systems thinking a bit, we are going to focus on something known as the "three ways" which is a key DevOps principle that bring the core values of DevOps, culture, automation, lean, measurement and sharing calms to life. After watching this video you should be able to describe the three ways and explain each of them and how it contributes to these core values. Okay let's dive in. The three ways model was developed by Gene Kim and Mike Orzen. And the three ways they identify are Systems thinking, amplifying feedback loops and a culture of continuous experimentation and learning. I'm going to introduce you to each of the ways that you can read up on this model more in the devops handbook. So the first way, systems thinking really emphasizes the performance of the entire system as opposed to the performance of a specific silo work group or team. This is a really important elements of DevOps. DevOps is about collaboration across functional lines, really breaking down those silos and focusing on the value streams that IT enables. Really, some of the outcomes of using systems thinking include not passing any defects to downstream work, not allowing local optimization, always seeking to increase flow, and always seeking to achieve a profound understanding of the system. That's per Deming as well. Another really relevant quote related to DevOps from Deming is that, quality is everyone's responsibility. A major piece of DevOps is that again, you're not handing off your work to other teams. DevOps is intended to be a one team mindset. Another one that I really like is learning is not compulsory, neither a survival. Again, DevOps is about continuous learning and amplifying feedback loops. And figuring out how you can continue to learn as you are delivering value. Let me share an example of the first way. When I was at Nordstrom, we were organized in silos and when we decided to document the value stream for delivering features to our customer mobile apps, we quickly saw that we were sending defects to our QA team, and often all the way through to production. Once we did the work to understand the entire system, we were able to show with data that we were sub optimizing. This discovery led to investments in automated tests, breaking down silos by embedding quality and operations engineers within the development teams, and measuring our quality in cycle time, so we could understand how we were improving the system, so that's the first way from the DevOps handbook. The second way, is all about amplifying feedback loops. And really shortening those so that any corrections to the product that need to be made can be made continuously. And let's talk about what is meant by a feedback loop. it's a term that's thrown around a lot, and it isn't always correctly understood. Basically a feedback loop is a process that allows for reflection on its own output before determining the next steps that need to be completed. It's really an important part of any product life cycle. And if we can compress the time it takes to do that reflection, or even figure out a way to use automation so that decisions and next steps can be made more efficient will be better off. The outcomes of the second way include understanding and responding to all customers, internal and external, shortening and amplifying all feedback loops, and embedding knowledge where we need it. In my experience there are many ways to improve feedback loops. One way is to build automated tests into the pipeline so developers can get feedback early and often. Another way is to embed operations engineers into the development teams. That way the team will learn from others. At Starbucks, we had a quality dashboard on a screen out in our team area. I walked by it everyday. It showed the health of our automated test scripts that ran every night, and if a certain threshold was met, in our case, the percentage of tests that failed, than the dashboard would turn red. We would halt the release until we were back within our acceptable quality range. This is an example of a feedback loop. Our teams could easily see early and often if we had quality issues, and could deliver that feedback to the developers. The third way is a culture of continual experimentation in learning. So it's all about creating a culture that fosters both of those things. Taking risk, learning from failure, and understanding that repetition and practice is the prerequisite to mastery. You need both of these things. You need the experimentation to help to improve and the mastery of skills so that you can navigate out of a situation if needed. The outcomes of the third way are about making sure that you're allocating time for that improvement work. You're rewarding teams for taking risks. And really introducing faults into the system to increase resilience. I think the third way is the most challenging for most organizations. It definitely has been in my experience. At Nordstrom, we created a culture of experimentation and learning by focusing on innovation, and creating capacity in our teams, so that they could test and learn. It became part of our DNA. But that didn't happen overnight. It took investment and strategic alignment with our leaders to make sure we protected that capacity for the teams. And we also created frameworks to use to make decisions about whether an experiment would continue or stop. It helped with managing expectations about what was a test and what was intended to scale. When I was at Starbucks, our CTO was a big advocate for innovation and experimentation. She made sure teams had space to participate in innovation days and hackathons. In both companies, we leveraged test stores so we could try new solutions in a real environment before we went big. It was a great way to learn. At Nike we also have hackathons and teams are encouraged to allocate capacity for learning. Some follow the Google 20% model and others have modified the percentage to match what makes the most sense for them. The biggest challenge in any large organization is figuring out how to protect the capacity. Often if pressures come in, that time will get used for feature delivery and teams will start to burn out and have low morale. A critical component is having leaders honor the capacity and encourage the experimentation and learning culture. Regarding taking risks and introducing faults into this system. There are a lot of external materials about chaos engineering. This was made famous by Netflix and the use of a chaos monkey that would randomly shut down services in production. Your organization may not be ready for that level of chaos. I know for me, I tend to talk about resilience engineering and how we can better prepare for outages if we practice, by creating or injecting a failure into the system and practicing our response to that incident. This also creates a culture of safe risk taking. Sometimes taking risk can be really scary. But if it's practiced in a controlled structured way, teams will be more engaged. And they can practice and build mastery through this technique versus high pressure situations. So, that's the three ways. Systems thinking, amplifying feedback loops, and creating a culture of continuous experimentation and learning. These represent a lot of the foundational material of DevOps mindset, and I encourage you to learn more. Again, a great resource to check out is the DevOps handbook, which explores the three ways in great detail.
