In earlier lessons in this course, we've discussed the importance of leveraging feedback loops. But we haven't really talked about how best to create and use them, and making them as fast as possible. In this video lesson, we're going to do just that. After watching this video lesson, you should be able to discuss the importance of garnering fast feedback loops, as well as describe strategies for making feedback loops faster, as well as how to counter challenges to accelerating feedback loops. As we've discussed in other lessons, faster feedback loops provide an immense value to teams and organizations, and there are many examples of this. One common example is to build quality into the product early, so developers can get immediate feedback on the product. Often, this is done through automation, and gets away from the old way of delivering the product through handoffs to a quality assurance team. I've been in situations where developers handoff code to QA and it was literally weeks before feedback was delivered back to the developers. That's obviously not ideal in today's development world. Relying on this old method, places organizations at a significant disadvantage because, more often than not, developers have moved on to developing the next feature. Having to stop the work on that feature and then taking time to remember what code they wrote weeks ago, is two huge problems that slow down the software release cycle significantly. This method leads to low-performing organizations, and, of course, we all want to be part of high-performing organizations. A core principle of DevOps is building quality in. This is also a key principle at the heart of continuous delivery. In the book Accelerate, there's a quote from Deming that I like. "Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place". What that quote is getting out for us is that shorter product lead times are better, since they enable faster feedback on what you're building, which in turn allow us to course-correct and ultimately learn more rapidly. Short lead times are also important when there is a defect or outage, and we need to deliver a fixed rapidly and with high confidence to avoid significant downtime. Another metric to consider is batch size. Reducing batch size is another way to accelerate feedback. We will talk more about batch sizes in more depth in a later lesson. But for now, just know that breaking down work into something small is a great way to improve feedback loops. The smaller the change, the easier it is to know what impacts that change creates. In traditional software delivery, when deployment frequency is low, often, the delivery of features is a long list, and it can be really hard to understand what's impacting what, and how to recover if an incident occurs. Another strategy to use, is A/B testing. If you're unfamiliar with the term, it refers to the idea of testing two different approaches to doing something presented randomly to end-users. It's extremely important as you start to deliver more digital solutions. Old methods for getting feedback are hard to scale. Before I used A/B testing, we would gather feedback via face-to-face interviews. Timed studies, literally using a stopwatch to see how long it took for a user to complete a task, and other analog methods for getting feedback. As we started our digital transformation at Nordstrom, we invested heavily in A/B testing. It was such a great way for us to get quick feedback from our customers at scale. We could experiment with two different experiences, and let the customer feedback help us decide which one to implement. Nordstrom had always been a customer-centric organization, and we sought feedback from our customers frequently. But, when we move to obtaining this information digitally, well, it was a big needle mover for us. We suddenly had an increase in feedback from customers at a pace much faster than before. In shortening our feedback loop this way, we were able to influence our feature set and make better decisions even speedup decision-making. The speed of decision-making is a challenge in a lot of organizations, especially large enterprises. It can be hard to shift to a speed based approach if traditionally the organization has been optimized for cost, and/or has grown fast and has not evolved its processes. That's typically what I've experienced. When organizations are in growth mode, often, there is no focus on evolving processes and structures to keep up with the growth. In fact, sometimes you'll see decision-making slowdown just when you really needed to speed up. Another challenge I've experienced is speed of mobilization. If you've been in a project model, typically, there's a very structured way for kicking off and winding down projects. Then, you spend the next one up and assign the team and resources accordingly. Usually projects have a one to two year timeline, so speed of mobilization is not a concern. When you start to need to pivot to customer feedback and/or the market, it is critical to focus on speed and mobilization. Often, organizations will leverage a Tiger Team. A Tiger Team is a diversified group of experts brought together for a single project need or event. They are usually assigned to investigate, solve, build, or recommend possible solutions to unique situations or problems. Tiger Teams can definitely speed up mobilization, but it's also important to figure out how to do this at scale. I often call this creating a learning culture. If you are learning and adjusting as you go, then your organization becomes adaptive and you can truly achieve speed to mobilization. In my experience, having clear prioritization, a structure for ingesting feedback and making adjustments accordingly, and a clear cascaded communications strategy, can greatly speed up mobilization, and it helps the team's understanding why they're moving to another priority. In both cases, speed of decision-making and mobilization, you will likely encounter skeptics who will say, "Speed should not be the focus." I disagree and believe that if you start to focus on speed, you'll make better decisions, and it's important to focus on progress over perfection. As long as you have a good Plan > Do > Check > Act cycle, then you know you can always adjust if you learn something new along the way. So, I hope you see the importance of feedback loops. It starts with strategic focus on how work gets to the teams. Then, once work is in the team, feedback loops can be leveraged to create a learning environment. Building quality in enables developers to get feedback early and often. A/B testing allows for experimentation and feedback from customers at scale. Breaking work down into the smallest increment as possible is another way to get fast feedback. Ultimately, you're trying to speed up decision-making and mobilization. Focusing on speed will create the best opportunities to learn.
