- [Instructor] Hi, and welcome back. In lecture eight, we look at sharing, shadowing, and evolving. In this lecture we will explore and explain DevOps Days, we'll look at DevOps in the Enterprise, the roles, DevOps Leadership, and the organizational considerations. How we get started, some of the challenges, risks, and critical success factors. Fundamental to DevOps is that DevOps encourages a sharing culture. Actively sharing tools, knowledge, discoveries, and lessons learned. This helps Dev and Ops to identify new collaboration opportunities. We want to avoid redundant work and overcome silo cultures. We want to create common vocabularies and mindsets. And we want to create active exchanges of ideas and innovation. A lot of this comes back to respect for each others' skills, expertise, and commitment. Let's listen to Gareth Rushgrove outline what the culture of sharing looks like in DevOps.

- DevOps is definitely about a lot more than just tooling and automation. It's really all about culture and sharing. And that's even more true if you're the manager of a group trying to instill DevOps practices. From the management perspective, it's useful to think about that sharing between those groups we mentioned. So, between the operation group and the development team. Between the developers and operators as well. And between both of those groups and management. It's also worth considering that there are lots of other parts of the organization that support you, so whether that's security colleagues or compliance colleagues, or even facilities, bringing all these on board in a way that makes sense can really help you push through DevOps practices. The groups to focus on when it comes to sharing the organization are, to begin with, often the development group and the operations group. That's sort of where the term DevOps comes from. In reality, there's a lot more to any successful DevOps implementation than just developers and operators. Management plays a massive part in any large-scale change in the organization. Other groups, as well, play a huge supporting role, and bringing along colleagues from security, bringing along colleagues even from facilities, and finance really help an organization adopt DevOps practices. It's a really good idea as a manager to encourage your team to take collective ownership rather than individual ownership over tasks and work. The reason here is that the whole is definitely more than the sum of its parts, and rather than relying on everyone knowing everything, which is never gonna happen, you can rely on the team knowing everything in combination. This only works if people are willing to work together and to take ownership collectively.

- [Instructor] Internal DevOps days are a proven format for encouraging engagement and driving overall success. An open space is where attendees have an opportunity to propose topics, and those interested in those topics can join in discussions that are relevant to them. It's the two feet approach, where an attendee's feet can take them where they want to be, and an example of self organization in a corporate setting. For DevOps days the format can include a traditional 30 minute presentation from internal, external and resources, it can have Ignite, which is like rapid fire topic-specific sessions, or an Open Space with break-out discussions on suggested topics. In the enterprise space, there is no secret to creating digital magic. If we look at Disney, we see the organization-wide shift to a DevOps culture has created opportunity and adversity. The digital expansion of business means more work and firefighting. However, it takes 30 minutes to update 100 servers instead of taking eight hours. There is less system drift, and Disney has half the cost of delivering content, which is an impressive metric. Let's examine the roles we see in DevOps. So addressing the DevOps skills gap, the demand for DevOps resources is making it difficult for organizations to attract and retain talent. The talent to fill needed roles may be within the enterprise IT or within shadow IT groups already. It may be outside the organization, and some organizations are hiring or contracting talent from outside the IT organization as needed to jumpstart DevOps initiatives. The best strategy in my view is to focus inward, and try and evolve using training and certification as the way of encouraging people to learn new skills. Immersion and coaching programs can really, really help. Supplementing internal teams with outsourced talent gives people a chance to watch and learn from people who come into the business on a temporary basis. And of course recruiting bonuses can always help attract the right talent. Today's CIO's are looking for workers who can shift gears and adapt to changing technology, so we need to ensure individuals have the needed soft skills, and are a good cultural fit as well as being a good technical fit. The demand for DevOps skills is rapidly rising. We have a series of skills and characteristics that are forming around the DevOps professional. They have a business knowledge, or a knowledge of business priorities and processes. They can be a specialist with broad general knowledge or T shaped specialists, their soft skills are good with communication, collaboration, and teamwork. And one of the key standouts is their self management ability, so ability to take initiatives, time and stress management to be certain, self motivated and focused, and some of the characteristics we see are adaptable, customer focused, curious, data-driven, engaged, and transparent Generalist technical knowledge includes an understanding of DevOps practices, modern software engineering practices, and modern architectures/ So what are some of the DevOps roles? Well, DevOps roles are always evolving, and here are a few that are becoming prominent as teams aim to match skills with resources. DevOps evangelist or leader, software engineers, developers, and testers, release manager, automation and continues delivery architect, build engineer, security engineer, quality assurance, and experience assurance, DevOps operational engineer. So what is a DevOps engineer? DevOps engineers are often viewed as the people who sit between or within development and operations, and facilitate the use of technology to help their organizations deliver better software, faster, and more reliably, but this role, however is not without its own controversies. Since there is not a standard job description or set of roles and responsibilities, many leading proponents in the DevOps space believe we should not have job titles, just roles, and that we should all be engineers. Some of the general characteristics we want to see is people who want to contribute his or her technical talent to the business and process improvement initiatives. They need to be comfortable with collaborating with others, and they want to be in a workspace that promotes a shared culture. So let's look at some of the leadership or transformation challenges. "The goal of leadership is not "to command, control, berate, or intimidate. "It's not even to evaluate workers "through some state of contrived metrics. "Instead, the job of leaders is to help organizations "become better at self-diagnosis, self-improvement, and to make sure that local discoveries "can be translated and converted to global improvements." That's a quote from Dr. Stephen Spear, cited by Gene Kim in Beyond the Phoenix Project. The characteristics of transformation leadership are highly correlated with IT performance. Some of the dimensions of transformation leadership are vision, personal recognition, intellectual stimulation, inspirational communication, and supportive leadership. If you look at the digital transformation according to Jason Cox from Disney, some of the crucial ingredients are collaboration, the ability to break down silos and have mutual objectives, curiosity to keep experimenting, courage, candor, with a no blame culture. The leadership challenges are the politics of command and control, how new leadership can take a company in a new direction, and the blame bias of who versus what. So some of the organizational considerations in DevOps organizational structures. As the planet frequency increases the need for communication and coordination increases as well. Some organizations are assigning Ops liaisons to Dev and Scrum teams, or creating cross-functional product, versus project, teams, adopting matrix or market orientated, versus function oriented, structures, and creating shared Ops services that support multiple Dev teams. Because they typically require a great number of handoffs, organizations with function orientated services may struggle to maintain the required high state of flow. Some organizations address this need for greater collaboration by designing an Ops liaison for application or service teams. These liaisons are team Dev stand-ups, and bring their needs back to the Ops function orientated structures, so to optimize for expertise and the division of labor. Market orientated structures optimize for responding quickly to customer needs. The matrix organizations attempt to balance the needs of function and market orientated structures by sharing resources. Matrix organizations can be complex, and can create conflict of efforts if they aren't made to reduce ambiguity, and that's in terms of people's priorities, and the reporting structures. So there is no ideal structure for a DevOps team. The creation of DevOps departments, or teams, is a growing trend. 27% of the 2017 state of DevOps survey respondents indicated that they were part of a DevOps department. The number of respondents who indicated they were a part of a DevOps department is up from 16% in 2014, and up from 19% in 2015. So it's definitely on the increase. There are pros and cons to creating a DevOps team. For many organizations, what is enabling these teams to work is that they are cross-functional teams, organized around products or services versus being organized around projects. In some organizations, the DevOps team's responsibility is to help ensure the smooth running of the source control repository, to build systems, and to help build the automated environments for testing and developing. Dedicated DevOps teams are often made up of experienced operations people with a mix of skills, including using version control, writing infrastructure as code, and continuous delivery. So some of the perceived downsides of a dedicated DevOps team are less engagement across the IT value stream, there's potentially a risk of being another silo, and that Dev and Ops wash their hands of accountability, so problems can fall between the gaps, so to speak. And DevOps activities become someone else's problem. So DevOps must be everyone's responsibility, not just those who are part of a DevOps team. So introducing a DevOps team could lead to yet another silo. Dev and Ops may now be even further removed from each other, so collaboration, learning, are stifled, if we do break things down into a team. So regardless of structure, a DevOps team should be flat with continuous engagement and the right balance of people, practices, and automation skills. So how do we get started? Well, I think Melissa Sergeant sums it up very well. She's a senior director of product and solutions marketing with CA technologies. Melissa says "It's a journey, not a silver bullet, "and leaders need to avoid getting caught "in analysis paralysis. "Start making the changes, get the wins, "and let the organization evolve." In the words of Damon Edwards, "DevOps is not your why, not your co-workers' why, "and certainly not your business' why." So we need to get clear on the business opportunity, what is the why? We need to get the right people together. We need to get everyone on the same page. We need to invest in training and skills development. We need to build capabilities that lead to lasting change. We need to focus on critical behaviors, experimentation, and thinking lean. And we need to consolidate gains, and produce more change. So learning by doing is the best approach to getting started. Create a pilot where you can maximize the probability of success. You should keep it small, where success is apparent and understood, and the consequences of failure aren't so large that a mistake could shut down the entire initiative. But it should be large enough that you can show proof of improvement, and you earn the right to make future improvements. We need to consolidate gains and aim to produce more change, which requires us to communicate the successes, and the failures, and the lessons learned. We need to document and make available reusable artifacts and measurements. We need to expand our cycles of improvement, and to continuously invest in education. But making available reusable artifacts and measurements is key. We want to avoid requiring others to reinvent the wheel. So we need to build momentum and go faster with every improvement iteration, by building on what's been done before. Start simple, and get more sophisticated as you go. You can't get from level one maturity to level five without going through levels two, three, and four. We need to anchor our results. So prove the new way of doing things is better. Reinforce new behaviors with incentives and rewards, and be prepared to lose some people along the way. We need to reinforce the new culture with every new employee. Culture changes only after people see the new ways of doing things are better. You want to incentivize and reward the people who are willing to embrace the new way of doing things. "Change sticks when it becomes "the way we do things around here." Some of the critical success factors in evolving to a DevOps way of working. Management contribution to cultural change, creation of a collaborative learning culture, training and continuous skills improvement, common values and vocabulary, systems engineers that span Dev and Ops, meaningful metrics, a balance between automation and human interaction, application of agile and lean methodologies, open and frequent communication, these critical success factors are common to any type of cultural change. So what are some of the challenges and risks? Essentially, a lack of commitment or clarity, transforming a them and us culture, a lack of education, training, and skill. Now these challenges and risks are common to any type of cultural change. So what are likely to be the biggest challenges for the expansion of DevOps? This information from Gartner demonstrates there may be many challenges that are common between organizations. 50% Amy be with people issues, i.e. culture. 37% may be process issues, the way we do things. Only 8% is likely to be technology issues. And further, an even smaller 5% will be information issues. So this shows the importance of investing in people, culture, and learning in order to make DevOps a reality. That brings us to the end of lecture eight. I will see you in the summary.