DevOps-Enablement-Teams.pptx

Editor's Notes

1. Talking Points: Let’s take a look at a few concepts to help define what DevOps is all about. Notes: watch the short video for background http://itrevolution.com/the-history-of-devops/
2. Talking Points: Agile = In the beginning, we were trying to solve the problem of “how do I build the right software?” Brings together the business teams and the development teams. Focus on building software that creates value Ability to change and adapt ALM (Application Lifecycle Management) = Once we got good at building the right software…then we needed to scale our capabilities across the organization which then posed the problem of “how do we develop software with quality?” As Agile teams matured and scaled, we needed ways to ensure consistency and quality How do we view a portfolio of work across dozens of Agile teams? (TFS, VSTS) How do we ensure we are building testable requirements? DevOps = Now that we can deliver the right software, with Quality, we are now faced with the problem of “how do I deliver the software faster”? This is what we will explore throughout the rest of the session today…
3. Talking Points: 7 habits of DevOps based upon Microsoft experiences Flow of value. This means keeping our backlog ranked according to what matters to the customers and focusing on the delivery of value for them. We always spoke of this during the first decade of Agile, but now with DevOps telemetry, we can measure how much we are succeeding and whether we need to correct our course. Evidence and data. We instrument everything, not just for health, availability, performance, and other qualities of service, but to understand usage and to collect evidence relative to the backlog hypotheses. For example, we will experiment with changes to user experience and measure the impact on conversion rates in the funnel. We will contrast usage data among cohorts, such as weekday and weekend users, to hypothesize ways of improving the experience for each. Management of technical debt. Any technical debt you carry is a risk, which will generate unplanned work—such as Live Site Incidents—that will interfere with your intended delivery. We are very careful to be conscious of any debt items and to schedule paying them off before they can interfere with the quality of service we deliver. (We have occasionally misjudged, as in the VS 2013 launch story above, but we are always transparent in our communication). Agile scheduling and teams. This is consistent with Agile, but more lightweight. Feature crews are multidisciplinary, pull from a common product-backlog, minimize work in process, and deliver work ready to deploy live at the end of each sprint. Production first mindset. That data is reliable only if the quality of service is consistently excellent. We always track the live site status, remediate any live site incidents at root cause, and proactively identify any outliers in performance to see why they are experiencing slowdowns. Hypothesis-based backlog. Before DevOps, the product owner groomed the backlog based on the best input from stakeholders. Nowadays, we treat the backlog as a set of hypotheses, which we need to turn into experiments, and for which we need to collect data that supports or diminishes the hypothesis. Based on that evidence, we can determine the next move in the backlog and persevere (do more) or pivot (do something different). Cloud ready. We can only deliver a 24x7x365 service by continually improving our architecture to refactor into more independent, discrete services and by using the flexible infrastructure of the public cloud. When we need more capacity, the cloud (in our case, Azure) provides it. We develop every new capability cloud-first before moving into our on-premises product, with a few very intentional exceptions. This gives us confidence that it has been hardened at scale and that we have received continuous feedback from constant usage.
4. Talking Points: Planning vs. Delivering We know that we cannot define an entire product backlog upfront with a new or existing application. We need to start shifting our focus from this initial planning to delivering the software and then learning how it is being used. Compete vs. Collaborate We are not competing with internal business teams, we all need to be working together for a common goal. Static vs. Flexible We need to break down the silos of static roles and form more cohesive, cross functional teams that will pick up “what’s next” for work items help deliver the value to the business. Productivity vs. Value We should be measured by what our team is able to accomplish as a group rather than how many lines of code I write or how many bugs are found. As we mentioned in the “Team R and Team D” storyline, we need to measure what is important which is value delivered to the business. Efficiency vs. Effectiveness Efficiency is important but making sure we are always aimed and the right business outcomes is what makes that efficiency really valuable. Assumptions vs. Learning It is natural in software design and development to try and predict how it might be used but generally this is based on opinion rather than what we see in production. We need to be measuring how our software is actually working and being used in production and them let that information help drives us in the right direction. Estimating vs. Measuring We can guestimate how we think the software will perform but until we see it in production we really cannot truly measure the performance.
5. Talking Points: How does DevOps look from a team perspective? Integrated Delivery Teams – Business, Development, Testing, and Operations all working together Unified Backlog – we are all working towards a common goal and prioritize business features with operational support items Feedback Loops – incorporating business vision, operational performance, customer feedback, market conditions to drive product development Operational Deliverables – build out of environments, NFR’s, and monitoring are all work items that contribute to the overall deliverable; these need to be part of the unified backlog. Production Experimentation & Monitoring – Feature flags, soft roll outs, fail forward & Application Monitoring Application Driven Infrastructure – allow applications to drive the hardware and software requirements needed rather than having it “fit” into a shared server model. This allows for maximum efficiency in delivering software.
6. Talking Points: Let’s now take a moment and look at what DevOps means for me and my role within a team. Talk through each of the roles and how DevOps affects them…
7. Talking Points: Now that we have had a chance to see how DevOps affect the culture and mindset, the Integrated delivery teams, and people’s roles and responsibilities, let’s see what the process looks like… Talk through each of the transitions Author code, infrastructure, tests = this is where business innovation happens and where companies create that differentiation with competitors. This is where we want to spend the maximum amount of our development resources since it will generate the most business value. It is also important to note that we are building the infrastructure to support the application and checking that infrastructure configuration into version control so that we can manage changes. This is the same for the automated tests. Version control, builds, tests, code coverage = We need to have continuous integration setup to kick off the automated builds of the application and validate our Quality checks like code coverage and analytics along with unit testing. Artifact Repo = once that build is successful and passed initial validation we know we can automatically (or via electronic approval process) deploy it to the Test environment to validate our automated testing suite. Staging & Production = after the automated testing suite has completed successfully, we are ready to deploy to the staging environment and then onto production once we are ready or have the allocated timeslot for deployment. Feedback = now that the application is in production we can now start monitoring how well it is performing and how users are using the various feature we just deployed. This information and telemetry will provide the insight to the backlog of new features and capabilities to develop next. Background: Penetration test A penetration test, or sometimes pentest, is a software attack on a computer system that looks for security weaknesses, potentially gaining access to the computer's features and data. The process typically identifies the target systems and a particular goal—then reviews available information and undertakes various means to attain the goal.
8. Talking Points: Lead in: Now that we know the development and deployment process behind DevOps, let’s take a look at the metrics we should be monitoring and measuring. What is a Lead Time? The Lead time is the time from the moment when the request was made by a client and placed on a board to when all work on this item is completed and the request was delivered to the client. So it's the the total time the client is waiting for an item to be delivered. What is a Cycle Time? The Cycle time is the amount of time, that the team spent actually working on this item (without the time that the task spent waiting on the board). Therefore, the Cycle time should start being measured, when the item task enters the "working" column, not earlier. So... what is the difference? From any business perspective, it's clear that the improvement efforts should be focused on the Lead time, as the Cycle time can be manipulated just by changing the process alone. What the clients are perceiving is the Lead time only, since they rarely have access to the inner processes Work-in-progress (WIP): The amount of work in a system that has been started but not finished. Mean Time To Repair (MTTR) is a basic measure of the maintainability of repairable items. It represents the average time required to repair a failed component or device. Deployment lead times not only predicts deployment and reliability outcomes, but it also measures how quickly Design and Development value stream can receive feedback from the customer and how quickly new customer experiments can be performed. This is a significant predictor of IT performance and organization performance. The Design and Development value stream more resembles Lean Product Development, which is highly variable and highly uncertain, often requiring high degrees of creativity and performing work that may never be performed again. On the other hand, the Test and Operations value stream more resembles Lean Manufacturing, while also requires creativity, expertise and experimentation, strives to be predictable and mechanistic, with the goal of achieving work outputs with minimized variability (e.g., lead times, process times, defects, etc.). Process times in the Design and Development value stream are usually longer (e.g., days or weeks to complete) than process times in the Testing and Operations value stream (e.g., minutes, hours). To achieve DevOps outcomes of fast flow and high reliability, we need Testing work to happen simultaneously with Development work (or even earlier, with techniques such as Test Driven Development). NOTE: Refer back to the Team R and Team D example and highlight how these two teams would have been viewed if we had focused on these metrics? It completely changes the goals for each team. “Mean time between failures” or “MTBF” refers to the amount of time that elapses between one failure and the next. Mathematically, this is the sum of MTTF and MTTR, the total time required for a device to fail and that failure to be repaired.
9. Talking Points: One fact you many not know is that as of August 2016, Bing + Yahoo Search (which is powered by Bing) own over 30% of the Search Engine market. Google owns around 60% of the Search market. This is an incredible fact considering how much of a lead Google had before Bing was even created. That team has made tremendous progress over the past few years and DevOps was instrumental to that success. So how do we get started on our DevOps Journey?
10. Talking Points: We will share our experience in working with a client that was in need of making a transition to deliver higher quality software to their customers with a much faster delivery cycle. Talk through the Client Example overview and What they asked for… Background: Client Example: Insurance services provider Large mainframe investment Small pockets of Agile 10 teams transitioning to modern development What they asked for? DevOps Roadmap to enable teams to deliver software to customers faster with more reliability Move towards a more modern architecture Visibility into the progress of the DevOps Journey
11. Talking Points: Outline each of the steps in this process DevOps Assessment At the heart of DevOps is learning from metrics and data. In order to effectively kick off a DevOps Journey we have to know where we are starting from. The DevOps Assessment will provide the foundational information and data to use in order to identify the actionable plan to start the DevOps Journey. Organizational & Team Backlogs This actionable plan will be broken down into a backlog of work items per team taking the assessment as well as common challenges facing all teams. DevOps Enablement Team The DevOps Enablement Team will start by addressing these common challenges as well as setting the initial framework that will be used by all teams as the start their DevOps Journey. Delivery Team Rollout The rollout of the enablement strategy will springboard from the DevOps enablement team and will allow each team to start working their backlog of work items. Re-Assessment After 3 or 6 months into the DevOps Journey it will be important to measure how each of the teams is doing to determine if there are other areas that need to be addressed. Now let’s spend some time and look at each of these steps in a little more detail…
12. Talking Points: Overview As we have discussed several times to this point, Metrics are keys to understanding and making informed decisions own how to continually improve. In order to grow your DevOps maturity you must understand the what areas are key to DevOps enablement but also how each team is doing with these practices. Outline the key areas of focus Culture, People, Process, Tools Aligned to the 7 habits Flow of customer value, evidence based learning, production first mindset Call out to a few key competencies Application AND infrastructure monitoring capabilities. Building in time to the process for continued improvement. The only thing more important than doing daily work is improving daily work. Building security into the development process as operational work items so that it becomes an application level requirement with test cases and validations.
13. Talking Points: x
14. Talking Points: x
15. Talking Points: Siloed Teams Generally only focus on what defines success for their team and not success for the overall project. Siloed teams also lead to lack of communication between other functional areas Story: the 5 minute task to configure an TLS certificate in IIS takes 5 days. Why? Commonly one of the main reasons is the hand off time between disparate teams. DevOps Enablement Team Why do we start with the DevOps Enablement team? First, every company today is a software company. We believe that in order to have effective cultural change, you need to eliminate the barriers of today that are preventing teams from achieving business agility through software delivery. We start with the “tools” and “process” because they can change behavior and behavior can change culture. Organizational Challenges These are commonly the biggest challenges most organizations face when trying to implement automation from end to end. Rather than have each Delivery team try and address these challenges, we have the Enablement team provide the roadmap of tools and processes that can be immediately leveraged by the other Delivery teams. We believe that this will that this will not only help with the adoption of DevOps habits and practices but also reduce friction or adverse feelings towards automated software delivery. Delivery Teams Cross functional teams focused on a common goal of efficient software delivery that provide ROI to the business and value to our customers. These teams are usually made of up between 7 to 9 team members that are cross functional in roles and responsibilities. These teams will also stay together dedicated to the backlog of work or feature team for 12 to 18 moths with minimal to no interruption with other initiatives.
16. Talking Points: Talk about the steps by the enablement team Discuss how the organizational themes will most likely need to address some Modern Architecture topics Discuss how a skills assessment to develop a training plan on both the Modern Architectures but also the tools needed to support the DevOps Journey will be required. Discuss the rollout of the training and team backlog to each of the teams.
17. Talking Points: Review the bullet points on the slide