We've spent a good amount of time defining and talking about the basics of DevOps in this course and we've thrown in some tips and tricks along the way. But it's time we really start talking about how to implement DevOps within organizations effectively. That's what we're going to do in this video. After watching, you should be able to discuss the importance of iteration, including the evolution of roles, and starting small with a DevOps change before rolling it out to an entire organization. It may be surprising to those of us aspiring to implement DevOps within our organizations, but it's actually very common for organizations to not recognize the value of starting things small and iterating. I found that the best way to introduce these concepts is to start small and learn what works and what doesn't, before scaling the approach to the entire organization. In a previous video lesson, I shared the example of when we were first conducting the Value Stream workshops at Nordstrom. There was a group of people who really wanted us to train the entire technology organization and "go big" having all of the organization teams taking on a lot of important work all at once. Instead, we did pilots with two teams, in the form of an AB test. To make sure things would work well and boy, we learnt so much. If we hadn't taken that approach, I think we would have missed out on incorporating what we learned into the next round of workshops, introducing the new approach. It's really the same concept at Nike, where I currently work. Right now, we're focusing on six teams to go through the value stream mapping exercise, before rolling it out to the rest of the organization, which is literally hundreds of teams. It would take a long time for us to train everyone. So again, we're learning a lot just through these pilot examples. This also applies to feature delivery. The smaller you can make something, the faster you're going to learn. You can act fast on that feedback, if you can get your feature broken down into the smallest valuable component. Get it into your customer's hands, as fast as possible and start gathering feedback and adjusting as needed. Traditionally, a lot of organizations will have silos. They'll have developer teams, QA team, and operations team et cetera. We had that basic structure when I was working at Starbucks and decided to experiment with one team, where we embedded QA and operations into the development team. We were able to organize that team around the value that they were delivering. Within days, we had feedback that we had never had before. At least, not that quickly. The development team was working on a feature and the Ops person said, "If you put that into production, it's going to break these other two things" and the developers had absolutely no idea. By the time they would have released it, and then we found the issues in production, we would have had to probably go through incident remediation to get that issue resolved. Instead, by taking this embedded approach, we were able to be proactive and fix the code before it even got into our test cycle. That's an example of how designing and acting on feedback loops can be very helpful. So, that's the basic idea there. When rolling out important organizational changes, start small, run pilot groups before rolling out the change to the entire organization. You'll likely learn a lot and in the end, we'll save yourself a lot of time, money, and effort. The other topic I want to discuss with you in this lesson is about the evolution of some organizational roles, in a transition to a culture enacting classic DevOps principles. Throughout my career, I've seen this progression, where a lot of business systems analysts start taking on more of what's considered to be a product owner role within the development teams. It's a really great evolution and opportunity for those business analysts to take on. In fact, the product owner role is one of the most critical in the team. It's someone who is helping the team make sure they're working on the right things, and working closely with the business community, to make sure that the right priorities are in the backlog. The product owner is really the day-to-day decision maker on the work. So, that's one role that's evolved. Another role evolution is on the part of developers. As you're rolling out these principles in an organization, it's important to help a developer change her mindset from simply, "I'm a developer, I write my code and then I send it to QA and release", to becoming more of an engineer who is also accountable for quality, security, some of the non-functional requirements and capabilities that traditionally have not been part of the developer's role. Sometimes that can be hard, but it's so important to talk with your developers and help them see the bigger picture, and the additional value that they can bring to their team and organization. The other thing I'll say, is that there's a lot of blurred lines around roles. It's not that everybody does everything, because I think that makes work a little more challenging than it should be. But there's definitely not as much of a boundary between who-does-what anymore. In traditional software delivery, it was pretty clear if you were the tester, you knew what your role was and what you needed to do. If you were the business analyst, you knew what your role was. You wrote the requirements and then you handed them to the developers, and then the developers wrote the code, and then they gave it to QA, and then QA did their job. Then, when the code was ready, it usually went to a release function to send it to production. Very clear and distinct roles and responsibilities. But when we adopt a DevOps and Lean culture, there will likely be times when people are playing multiple roles within a team. It's really more about how we organize the organization in the most effective way to deliver value to the customer, and how do we achieve that, given a new context and new capabilities. So, let's discuss another example to help bring this home. At Nordstrom, we were rewriting our product webpage, which is basically the moneymaker of any e-commerce experience. For this effort, we had this opportunity to really rethink how we were structuring the team. We put all the roles needed to deliver that value in one team. We had our product manager, we had our engineers who were also accountable for quality, and security, and support. They built all of their continuous integration and continuous deployment pipelines in instrumentation, so that they could get feedback on the product and basically built all of that into the product when it went live. As a result of this, they were able to quickly deliver value. They were deploying multiple times a day and could identify an issue and have it resolved within hours. The newly restructured team was one of the strongest practitioners of these DevOps principles at Nordstrom and their outcomes matched accordingly. They were driving a ton of revenue on that product page. They were able to run multiple experiments, learn and adjust as needed. They were able to restore any service issues quickly. In fact, if you can imagine the crawl, walk, and run model, they were more on the run side of that. They were definitely leading the way with how they were practicing these concepts. So, as we wrap up here, it's important to remember, that as with any major organizational change, adopting DevOps principles requires people to reevaluate and change their roles. As more people become accountable for things like quality and security, it definitely requires a shift in thinking amongst all team members. Because of this shift, you can expect that kinks will need to be ironed out at a team level, that's why it's wise to start out small with just a few pilot teams and work out any major issues before going big and rolling out changes to the entire organization. This is a common theme that I think you'll continue to see as we move through the course.
