A successful DevSecOps transformation requires a dedicated team that is empowered to iterate rapidly to improve performance. This team must also develop new ways of working such as reserving time for improvement and using tools that reinforce desired behaviors which formed the foundation for the organization's DevSecOps journey. [MUSIC] Successful organizations perpetuate processes that made them successful. Maybe the existing way of doing business has its challenges but it's difficult to ignore years or decades of positive reinforcement. As we learned earlier approaches to problems that have worked repeatedly eventually become a perceived reality that is there is no other viable way to accomplish the task. Unfortunately, changing market conditions often preclude maintaining the status quo, specialization, focusing on efficiency and repeatability, and bureaucratic approval processes. All provide tangible benefits to organizations, but they also limit organization's ability to innovate. Thus a DevSecOps transformation will bring us into conflict with these existing ways of working. So what should we do to unshackle ourselves from these constraints? The other side of innovation solving the execution challenge, a search that organizations must create a dedicated transformation team with the authority to operate independently. This team is responsible for a specific outcome, such as reducing the deployment lead time by 50%. To be successful, the transformation team should be free to operate outside the organization's existing processes. That is not to say that existing expectations, such as ensuring customers receive high quality products are relevant to DevSecOps. On the contrary, the existing processes almost certainly have some value, but they are not the only way to achieve the desired outcome. For example, a change approval board may review changes to assess their impact on existing services, but code reviews by the developers and IT operators responsible for those services are likely to be more effective. As an example of this concept, National Instruments created a dedicated team to explore software as a service offering for its lab view platform. This small team of developers and IT operators subsequently delivered the cloud product in one year vs three years for National Instruments other software products. Every time I start a performance cycle, I'm reminded of the smart criteria for goal setting. Smart is a pneumonic for specific measurable, achievable, relevant, and time bound. Although I hate developing mandated goals for personal development, preferring instead for these goals to surface more organically. The smart criteria are essential in the context of the DevSecOps transformation. For example, the shared goal for the dedicated transformation team might be reducing the time spent on unplanned work by 50% deploying 95% of changes to production in less than one week. Or integrating controls for regulatory compliance in the deployment pipeline. The goal and timeframe typically between six months and two years should be agreed upon by executives and known throughout the organization. Obviously the shared goal will not be accomplished overnight. The dedicated transformation team must decompose their strategic goal into tactical goals. Each tactical goal must be amenable to iterative and incremental progress stated differently, the team should practice the improvement kata. A short planning horizon has a number of benefits. First, it provides flexibility to reprioritize when necessary. Second, it allows us to recognize the changes that make meaningful differences in our daily work. Decreasing the delay between a change and realized improvement strengthens the feedback loop which reinforces desired behaviors. Third, it reduces the risk that the DevSecOps transformation is stopped before we're able to demonstrate any improvements. If we've already reduced the amount of unplanned work by 25% after three months, then it is more difficult to argue that the team members should return to their prior responsibilities. Furthermore, a successful DevSecOps transformation requires us to address technical debt. A rule of thumb devised by Marty Kagan is that teams should reserve 20% of their time for refactoring automating routine tasks and non-functional requirements such as scalability and reliability. These activities, though not directly visible to users not only support the development of new features but also reduce the likelihood of failures without reserving this time for improvement. Technical debt increases until services are so fragile that new features cannot be delivered due to developers and IT operators constantly working around existing issues. In other words, servicing that debt requires all available time. Finally, we must use tools that reinforce desired behaviors, most importantly developers and operators on the dedicated transformation team should have a common backlog of work and work queue. Too often teams use different tools such as development using Gira and IT operations using service now. But multiple tools perpetuate silos between teams and undermines focusing on global goals stated differently. A single system makes it immediately obvious when there is an issue and when that issue should halt other work. Another important tool is a shared communication platform such as IRC channels or slack that facilitates the fast flow of information throughout the team. Logs are particularly important in the case of production incidents, as logs offer a permanent record of what happened, when it happened, and how it was resolved. A word of warning though, instant messaging is best when active collaboration is essential, even a brief interruption requires 45 minutes for individuals to refocus, which quickly degrades their performance. And impedes the fast and smooth flow of planned work thus make sure that tools reinforce desired behaviors rather than undermining them. To conclude, let's examine a case study from LinkedIn in 2011, just after going public, LinkedIn struggled with problematic deployments of its monolithic Java application responsible for servicing page requests. And managing database connections, every new feature led to outages requiring staff to work around the clock to fix problems. In a bold step, Kevin Scott, the vice president of Engineering stopped the development of all new features to focus on replacing the monolithic application with smaller services. This effort quickly led to significant improvements in the form of software and tools designed to automate many processes, including the deployment of new features to LinkedIn's production environments. Unfortunately, this total halt was the outcome of accumulated technical debt over the prior decade. If we want to avoid similar scenarios in our own work, we must reserve time for improvement, allowing us to create safer systems of work and enabling innovation. [MUSIC]
