The Forgotten Side of DevOps
•Download as PPTX, PDF•
0 likes•324 views
This document discusses different approaches to planning and releasing software. It compares traditional sequential planning methods to Scrum's iterative team-based process. Various software development concepts are mentioned like epics, requirements, defects, testing, and patterns. Examples are provided to illustrate some software development techniques and tools.
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
The Forgotten Side of DevOps
- 7. Traditional planning and release approach Team level Scrum process
- 9. Epic Epic Problem Defect Defect Requirement x Alert Defect Test Case
- 10. Pattern Applies to Example
Editor's Notes
- Solutions Architect Work with customers to identify and deliver integration strategies for their disconnected tool suites. Before tasktop I was part of a centralized testing organization where oversaw the test automation and test tool administration.
- The title of my talk “The forgotten side of DevOps” implies there are multiple sides. Let’s start by looking at what they are? At the most basic level we have Assets, the things that are worked on, they are treated like an investment and incur debt. And Work, the things that DRIVE what gets worked on. Work is associated with time and has a cost. How do we stress communication, collaboration and integration with assets and work?
- Talks today have been very focused on moving assets around with build and release automation or continuous integration and delivery. It’s about communication, collaboration and integration by automating the flow of assets.
- But my focus is going to be on the work. There are a lot of different things in play. In the middle you have the different categories that cover almost everything from ideation to end-of-life. Above that are the various methodologies that get mixed and matched. Waterfall, agile, scaled agile, water-scrum-fall, itil, etc. And in the green box are the different artifact types that represent the WORK being shared across the lifecycle So how can you improve communication, collaboration and integration by removing manual processes and replacing them with the automated flow of work?
- The image on the right is a real world look at how manual processes, regardless of whether it’s related to work or assets, impact large-scale software projects. Each one of the red Ms represent a manual process. Clearly the work is not flowing freely across the lifecycle. This results in lack of visibility. I’ve written my requirements but I don’t know if development is working on them. I don’t know if they are passing testing. Customer tickets are logged by ops but no one knows what the plan is to fix it. When you don’t have access to real time information it takes longer to get feedback and longer to complete work and results in longer cycles and potentially project failures
- DevOps wants to break down the barriers between the greater development organization and Operations by improving communication, collaboration and integration. But also remember that within the “Dev” side there are even more barriers. Each one of the silos is made of of people, process and tools. Agile, Scaled Agile and DevOps focus on breaking down these silos by improving team composition or processes. But each one of these silos also have their own tool stacks that meet their specific needs for managing work. So unless you also have an integrated tool strategy you are still left with disconnected silos and a broken end to end value stream.
- This is what it ends up looking like. Using scrum at the team level but still trying to do traditional planning and releases. Eventually you throw something over the wall to Ops. Most tools do one thing great, whether it’s test management or agile planning or change management. Some do multiple things great. Some vendors have a platform that supports the whole lifecycle from ideation to end of life. The reality is, even if you decide to move forward with a single vendor platform it doesn’t take long for new tools to sneak back in. Dev manager decides his team should use JIRA so they use credit card to buy some licenses. New company is acquired and they have their own tools suite. Partner with an offshore testing or development company that has their own tool preferences.
- Now that we’ve discussed the problem, let’s talk about the types, styles and patterns of integrating work then we’ll take a look at a couple real world solutions. First of all, there are different types of integration. It’s not just one thing. One type of integration is synchronization. Creating a copy of the work in each system and keeping changes up to date in each system in real time. Collaboration can be considered a form of synchronization. Think about synchronizing comments on work items between two systems. You are enabling a social conversation between individuals using different tools. Integration of your work can be strictly reporting. Gathering data from across multiple tools and presenting it in a single view. Finally, traceability or “linking” is about creating relationships between work items in separate systems. Similar to how integration is not just one thing, an integration strategy is not just one thing either.
- Next let’s look at different styles of integration. The different styles focus on how work that lives in different tools is the same or similar or different. They start to lay the groundwork for not only HOW the data should flow between systems but WHAT data should flow between systems. So what do we mean by “styles” of integration. Well, sometimes we mean that fundamentally the artifact is the same artifact with *some amount* of the shared information – like in our EPIC example. Other times, the artifacts are actually fundamentally different but through a morphing process there is still shared information. For example, The problem ticket contains information about related incidents, the customers impacted, etc. The defect contains information about who is going to fix it and when. They share information about how to reproduce. Then there is the kind where the work is 100% exact replicas of each other. A defect is a defect. Sometimes it is actually two totally different artifacts, and it is simply the link between them that provides the inherent value. Like a requirement with test coverage. And finally, there is the one I call “fire and forget” – I passed that baton and never looked back. For example, alerts generated from your APM tool result in a defect created in your development tool.
- The third aspect of integration is looking at the integration patterns and continuing to think about how the work flows. These examples are generally associated with the synchonization approach to integration. For example, defect integration…. Or requirements traceability… Or Supply Chain Integration…
- What might it look like when defects or tickets don’t flow? Ops takes a customer call and logs a ticket. 1st and 2nd level support activities take place. If the ticket is determined to be software related and needs fixed by dev they turn around and update a shared spreadsheet with relevant details. Maybe the ticket is high severity and they email a developer or team directly. The problem is this information doesn’t flow. The spreadsheets become stale. The details are trapped in the inbox of a select few. How does project management understand the impact of developers and testers being pulled to work on production tickets? How does test know that a fix needs tested or what to test? How does the service desk or the customer know the status of a fix?
- The first example is focused on the Service Desk Escalation pattern but that is only a small part of the overall integration strategy. This customer also implemented defect unification and requirements traceability between Rally/ HP ALM and Microsoft TFS
- A large credit card and electronic payment processor conducted a massive overhaul that included the people, processes and tools across all silos. The moved from waterfall to the scaled agile framework, implemented ITIL, and they standardized their tool suite. Rally for Scaled Agile, TFS for development, ALM for testing and ServiceNow for Ops. As part of the transformation it was critical for them to understand ALL work being executed on by their development organization, not just the work that originated in their PMO. Often times the work that originates from customer reported tickets or even production alerts is overlooked because it is handled out of process. In this example the goal was to integrate ServiceNow and Rally so that problems and incidents reported by customers appeared in Rally so they could be planned and executed on by the development and testing teams. As that work flowed through Rally details about the work was synchronized back to the original problems in ServiceNow so Ops had realtime feedback. In addition to integrating problem management they wanted to automate the population of the known issues database in ServiceNow. Every time code is released in to production there are defects in that code that haven’t been fixed. Since these defects are known there is value in automatically getting that information into the hands of Ops. Now when the service desk takes customer calls they have a more complete view of the known issues. They can avoid unnecessary support activities just to discover something that is already a known. In addition to knowing initially that the defects were released in to production, the ongoing state information flows from Rally to ServiceNow. When the defect is fixed and released the known issue again that information synchronizes automatically and the known issue is ServiceNow is marked as resolved.
- This next example is focused on the Dev side of the house with defect unification and requirements traceability. The tools they integrated were HP ALM and JIRA
- The Blackrock iShares platform manages over $1 trillion in assets therefore delivering quality software releases is critical. They had a major problem with lack of flow and visibility among their QA, BA and Dev teams. To make things worse development had multiple JIRA servers with individual teams using different development practices, workflows and templates. They wanted to plan, execute and deliver with confidence. To do that the centralized quality group needed traceability from end to end. By integrating their multiple JIRA environments with HP ALM they were able to use HP as their central repository for traceability. Requirements traced to tests, which traced to test executions, which traced to defects, and back down the line. That end to end traceability ultimately allowed blackrock to eliminate spreadsheets and emails while keeping their centralized quality processes
- In closing, when putting together a devops initiative be sure to focus on improving communication collaboration and integration for BOTH assets and work