In this video, learn how to break down the silos and establish a culture of responsibility and ownership, and align your teams to support the flow of concept to cash.
- While I've been an engineer for many years, I've also put in more than half of my career as a manager. And I want to bring that perspective to this video, what to consider as a leader during the move to DevOps. Just renaming an existing team DevOps, or making a new team called DevOps, does nothing to achieve these goals. That's all you do, don't be surprised when nothing improves, you need real change. Change is always hard, and changing roles can be seen as threatening. Helping your team through the transition is key to your success. So first, let's talk about organizational issues. DevOps strongly advocates eliminating silos and thrives in an environment of autonomous teams, by putting the right people on a team, focusing them on the business problem at hand, and setting up self service tooling to allow them to develop, test, deploy and operate their own service, you maintain a very high pace, because the team isn't blocked by other teams from making progress, or tempted to abdicate responsibility for the end result, because it's in someone else's hands. It's basic queueing theory at work. When James and I started our first integrated DevOps team at National Instruments, our team was able to deliver three products to the market, in the time it took the other engineering teams on average, to deliver one product to market. Look at the concept of cash value stream of your product, how many teams does your concept have to go through to get to the cash? In many organizations, especially those with infrastructure teams, divided up by the technology they support instead of by business function, it could easily be a dozen. And this leads to the rise of what's called shadow IT or bimodal IT, groups deliberately bypassing the established processes and teams to get things done themselves. While this might not be the right response, you have to understand that this arises due to a significant unfulfilled need. Frequently, throwing the little development at the problem, and giving someone a self service button they can push instead of playing "Mother May I" forever, can drive a huge amount of efficiency. You don't have to reorganize your teams to implement DevOps, but you probably will end up doing it at some point. And some of this is because the kinds of jobs people do, change under DevOps. Some people see DevOps as a threat to their jobs, that's usually not true. Unless they're extremely attached to doing manual work for their job. There's plenty of need for good ops' engineers and good QA engineers and everyone. But there's a lot less need for people who spend their days manually configuring servers or manually testing. The time for that to be a paying job has largely come and gone. Devs have to take responsibility for a failing build or deployment after they've checked in their code, they have to be willing to go on call to support their applications in production. Operations and QA engineers have to change their approach to provide self service platforms and guidance, instead of doing work for other people. And changing the way you approach your work is hard. It was hard for me, I've been doing it worked for more than a decade when I started down the path to DevOps, and it's challenging. I had invested in ways of working and in tools I knew how to use, and the prospect of changing the basics of how I approached problems was daunting. You and the others around you need education, understanding and encouragement to make this change. Now let's shift to talking about process issues. These are interlinked with organizational issues, of course, in fact, there's a well understood concept called Conway's Law, that states that your systems will basically align themselves to your communication boundaries. Organizational boundaries are one type of communication boundaries, but process boundaries are another. In general, agile processes compliment a shift to DevOps. In fact, they're often necessarily linked, I was brought into one stop shop as a release manager to help them because they had moved to agile, and then they realized that they were still bottlenecked because they couldn't release quickly and safely. Only a combination of both approaches got them where they wanted to be. Chef actually has a great Operations Maturity Model, free for download, that lines up practices against the kind of MPPR targets you hope to obtain, and it becomes clear from observing the model. Trying to be very successful in one area, while not advancing in other areas, leaves you unable to hit those goals. The 2016 State of DevOps Report found that a Lean management approach correlated well with organizational performance. They also found that organizations that align on the generative organization culture as defined in Ron Westrum, typology of organizational cultures, was one of the top predictors of organizational and IT performance. I like to implement what I call Minimum Viable Process, and then have the team, have a big say in adapting our process as we go. You don't add process unless everyone thinks some more process is really the solution. And you keep an eye out for processes that you can remove. Processes are often like training wheels, they become vestigial as the organization matures, and some of them need to die and drop off. The assertion that a large shop needs heavy processes is a myth. You can do pure code reviews, instead of having a centralized change review board. You can avoid having decisions blocked, waiting on sign off from somebody at a level so high that they don't really understand the work that's being done and so on. The higher your process walls are, the more Conway's Law comes into play. The more trust and discretion that you can give to the people doing the work, the better results you'll get. Support them as they go through any role transitions, and coach them into using some of the same big picture thinking skills you'll use, while leading the transformation. In closing, the management best practices that I've seen go well with DevOps implementations are reorganizing into independent cross functional teams, understanding the fears people have that are barriers to change, and helping them through it. And using lean agile processes to keep your effort focused on value creation.
In this course, well-known DevOps practitioners Ernest Mueller and James Wickett provide an overview of the DevOps movement, focusing on the core value of CAMS (culture, automation, measurement, and sharing). They cover the various methodologies and tools an organization can adopt to transition into DevOps, looking at both agile and lean project management principles and how old-school principles like ITIL, ITSM, and SDLC fit within DevOps.
The course concludes with a discussion of the three main tenants of DevOps—infrastructure automation, continuous delivery, and reliability engineering—as well as some additional resources and a brief look into what the future holds as organizations transition from the cloud to serverless architectures.
- What is DevOps?
- Understanding DevOps core values and principles
- Choosing DevOps tools
- Creating a positive DevOps culture
- Understanding agile and lean
- Building a continuous delivery pipeline
- Building reliable systems
- Looking into the future of DevOps