Quality Automation for Agile and DevOps Transformation Success
•Download as PPTX, PDF•
0 likes•309 views
During this webinar, Gernot Brandl, Senior Product Manager at Tricentis, and Dr. Tuuli Bell, Partner Account Manager at Tasktop, discuss how quality automation and value stream integration can help organizations with their Agile and DevOps transformations by: - Automating the flow of defects, requirements, epics, test cases and other information across the value stream for enhanced traceability and visibility - Synchronizing critical data between systems while retaining relationship and context information - Minimizing errors and rework by flowing defects from multiple sources round-trip to development
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Quality Automation for Agile and DevOps Transformation Success
Similar to Quality Automation for Agile and DevOps Transformation Success (20)
More from Tasktop
More from Tasktop (20)
Recently uploaded
Recently uploaded (20)
Quality Automation for Agile and DevOps Transformation Success
- 1. © Tasktop 2017 9 May 2017 – Gernot Brandl & Dr Tuuli Bell Quality Automation for Agile and DevOps Transformation Success
- 2. © Tasktop 2017 GoToWebinar Housekeeping Check your email tomorrow for recording and slides. If you are having technical problems, please contact GoToWebinar: Toll-Free: (855) 202-7959 Long Distance: (805) 617.7049 *United States Numbers
- 3. © Tasktop 2017 Meet The Presenters Gernot Brandl Senior Product Manager, Tricentis Dr. Tuuli Bell Partner Account Manager, Tasktop
- 6. © Tasktop 2017 Agile & DevOps at Scale Top 15 global bank, 20K IT staff Lack of top-down transformation, ended up with 150 JIRA servers across org Fortune 100 bank Attempted ISV inspired toolchain, result is disconnected from business, inability to scale Top automotive, 4K IT staff, dozens of software suppliers Increasing faults and recalls coming from software defects You What are your challenges?
- 7. © Tasktop 2017 Annual Cost of a Fragmented Tool Chain Manual (re)work - value lost $9,868,421 Traceability overhead $270,000 Tool upgrades/migrations $1,779,640 Traceability and compliance Exposed Management Reporting Manual Visibility Fragmented Team engagement At Risk Total costs $11,918,061
- 8. © Tasktop 2017 Solving the challenge with software
- 9. © Tasktop 2017 Transform your Software Delivery Continual pressure for software delivery Agile and DevOps are struggling at scale A Value Stream approach is crucial o Increasing team effectiveness and lifecycle visibility o Creating a modular, responsive toolchain There is no single tool platform that provides a silver bullet Tasktop has the expertise, experience and technology to ensure success
- 10. © Tasktop 2017 Value Stream Integration Connect the disparate activities into one value stream… by connecting the tools into a modular toolchain Increases visibility Decision making, governance and compliance supported by full lifecycle consolidated data Increases team effectiveness through automation Frictionless flow of information across a unified delivery lifecycle Reduce wasted time, errors and dropped balls Increase capacity and velocity Enhanced cross-organization and supply chain/partner collaboration Creates a flexible tool infrastructure Easily adopt new tools as business conditions change Benefits of standardization and best-of-breed strategy
- 11. © Tasktop 2017
- 12. The Challenge Continuous, integrated, automated software testing DevOps Communication Testing Software applications
- 13. © Tasktop 2017 Solving the challenge with software testing
- 14. © Tasktop 2017 Any Questions?
Editor's Notes
- << Pick a couple of these examples.. Suggested ones have asterisk>> With a focus on continually delivering customer value and being able to respond to change, Agile and DevOps have certainly helped improve how we deliver software. And while there have been some successes with Agile and DevOps deployments.. What we’re seeking is that there have been some real challenges for organizations that operate at significant scale and complexity. ** Top 10 global bank, 35k staff – 4 years of failed transformations, each developer still spending 2hrs/day duplicate entry (confidential: HSBC) This bank with 35K IT staff and about a $5 Billion IT budget is in their 4th year of failed transformations. They’ve told us that because of a lack of integration automation across their stakeholders, developers are spending 2 hours every day in duplicate entry. This effectively grinds development to a halt and, it’s so annoying that developers were leaving the company. Why did they have to spend so much time in duplicate entry? Because given their compliance burdens, they must be sure that the information across systems is consistent. So, the rekeying is to keep the information in the systems in sync so they can pass an audit. Top 15 global bank, 20k IT staff lack of top-down transformation, ended up with 150 JIRA servers across org (confidential: Deutsche Bank) This bank didn’t undertake a concerted transformation. But interestingly, when they ran a network crawler, that identified that they had 150 JIRA servers running on their network. So, they didn’t fail at their transformation, they didn’t have one. You can’t stop developers, operations folks and others from wanting to work in the most efficient ways. So what happened here is something we see quite a bit, teams started purchasing and using JIRA without a central mandate. So, as the case in the previous example, if your staff is using JIRA and your corporate policy is to use RTC as the system of record, chances are you’re completely out of compliance. ** Fortune 100 bank – attempted ISV inspired toolchain, result is disconnected from business, inability to scale (confidential: ??) IT leadership goes to these conferences and they hear all these success stories and they endeavor to implement the same tools and processes that companies like Atlassian and LinkedIn used in their early days. Of course a company with 1000 IT staff is operating at significant scale, but that scale is nothing like the scale of a Fortune 100 bank. But what the folks from the bank failed to realize is that their bank is nothing like the companies that spoke at the conference. Not only do they have larger teams, but they have a different culture, a much larger software portfolio (sometimes 10 to 100 times larger) and most importantly, different compliance burdens… particularly when those newer companies are not public companies. People want to be like the next LinkedIn, they just don’t realize that they’re nothing like LinkedIn. Top automotive, 4K IT staff, dozens of software suppliers Increasing faults and recalls coming from software defects (confidential: BMW) You may think of automobiles as engines and wheels and leather seats, but a modern car has a couple hundred lines of code in it. Interestingly, only part of that code is written by the automobile manufacturer. There is a robust supply chain of software developers that provide software components to the car manufacturer. If you look at the warranty and recalls from cars, the number of these problems that are software-based is consistently rising as more of the automotive user experience is from the telematics and entertainment systems. So an interesting aspect of when Agile doesn’t work all that well has to do with the communication and resolution of defects in software components that are supplied by other vendors. Unsurprisingly, agility is thwarted without an automated way of sharing defects and their resolutions across these organizational boundaries. Fortune 100 mutual fund, 15K IT staff Partial success deploying Agile, but cannot measure results (confidential: ??) This company had a successful Agile transformation, but they realized that that couldn’t measure the success of their improvement and prove it to senior management. So, they deployed a massive Big Data initiative and began to stream a lot of data into a data warehouse. Unfortunately, because of the way they collected it, this data wasn’t well organized so they had retrospectively re-structure the data so that they could actually see what happened to any particular defect as it evolved from being identified, fixed, verified and the fix deployed. ** Aerospace software, 3K IT staff Failed to connect requirements to Agile toolchain, lost requirements resulting in lost business (Confidential: Jeppesen) This company rolled out a transformation, purchasing and deploying a well-respected Agile planning tool, but not connecting that tool to the others in the toolchain. Unfortunately, without this level of automation, they managed to lose requirements that were elicited by the product managers, and omitted key features desired by their customer. Needless to say, these kinds of dropped balls can have a direct impact on their customer continuing to award contracts to them. Some organizations feel as though these problems can be solved by purchasing and using a single software delivery platform… but that ship has sailed...
- For those of you recognising that as you scale your agile and devops initiatives, you are seeing some or all of the symptoms of a fragmented toolchain, you might be wondering how big of an issue this is. The answer is, it is big. Our customers and studies that we have done show that this fragmentation results in at least 20 mins unproductive work per IT professional. This is due to factors such as · context switching out of the toolset of choice to go and find the “right” data, · status reviews, · manual re-keying of data across tools and · other frustrating, time consuming and non-value add work which are needed to compensate for the fact that the tools are not integrated and the software artifacts are not flowing to the right people at the right time in the right place. Where this lack of productivity has been measured at scale, the results show teams thrashing and reducing velocity between 20 mins and 2 hours per day. So if we take the absolute low end of the scale here, 20 mins per professional per day, and extrapolate it across an IT organisation with 1,500 devops professionals, this means that the teams are losing productive team equivalent to their salaries of $10M per year. Freeing them from the shackles of this unproductive work would of course enable them to deliver much more than $10M per year (they would work on delivering the next most valuable feature off the backlog, which would bring value to the business substantially greater than the cost of their salaries). But again, in order to be conservative, let’s just use the lowest possible number. In addition to the manual rework, fragmented toolchains make it impossible to show traceability. The solution that most organisations have to adopt is highly manual, brittle and error-prone. In this model we have assumed 2 people dedicated to delivering an excel-based manual traceability solution across your company. Finally, a fragmented toolchain is costly to try and integrate. As agile and devops initiatives introduce new tools, getting those tools to share artifacts becomes exponentially harder. As well as hard factors that can be quantified, there are other factors in play as organisations wrestle with fragmented software development and delivery toolchains. While these are harder to quantify, they are no less important. For example, how important is “good decision-making?” (Implementing Value Stream Integration across the organisation ensures that real, accurate and timely information is not only flowing across the toolchain and teams, but also to program and executive leadership. Better information empowers better informed decisions.) The same goes for visibility, traceability and compliance. Resolving these bottlenecks and manual overheads has a cost saving, but the real benefit to the business is much greater than any cost savings. Finally, forcing teams to go look for data, re-key information or not have access to what they need, when they need it, is frustrating. At the very time when you need teams to be engaged and feel empowered, as devops initiatives are scaled across the business, we find that team engagement is at risk. So in summary, this fragmented world is costing a company with 1,500 IT staff at least 1$12M a year, and probably significantly more than that. I should mention that this cost calculation forms part of the Business Case Modeller that Tasktop offers. WE will work with you to adapt the model to your own particular environment so that the numbers that are generated correspond to you, not a hypothetical similar-sized company. As we move forward together, we would be delighted to share the model and help to pull it together to reflect your world and the likely impact of Value Stream integration at your company.
- Replace “your industry” with the prospects actual industry
- Up to now, pulling together the software delivery process from ideation to production, concept to cash, has been impossible to achieve across all three of these axes - either visibility is compromised, team effectiveness is reduced or the tool infrastructure is to slow, brittle and expensive. Or frequently more than one of these is comrpomised, sometimes all three. What’s needed is a new approach, a new way to support software delivery that looks at end-to-end flow from a value stream perspective. Focussing on the Value stream of the software delivery process itself provides the glue to dewliver dramatic improvements across all three of these axes. The idea of improving a process by looking at the value stream has been around for decades, pioneered by the manufacturing industry. For them, the flow of material through a factory floor on the way to creating a finished product is very visible and very tangible. But taking the same approach for software is something that leading companies have started to do. Details Visibility Coalesced metrics data for management, optimization and governance Enable real-time insight into the state of the application delivery/value creation… from ideation to production. Automated traceability reporting, consolidated dashboards Increased Automation Real-time updates of status, comments, attachments, etc. Eliminate manual work, information scavenger hunt Enhanced collaboration with stakeholders staying in the tools that make them effective Enhanced collaboration with vendors and contractors Increased velocity, reduced errors and rework Establishes traceability across tool Increase practitioner efficiency and satisfaction by providing more current information with less administrative overhead. Flexible tool infrastructure 5 years ago, Jenkins wasn’t nearly as popular as it it today... Vendors continually bringing out new, excellent tools.. Want to be able to use the best tools for the job Any organization that operates at scale faces all of these issues, and we can address them all... But which of these are your greatest concern?
- Software delivery is complex process, involving multiple professional disciplines. Each disciple wants and deserves the best tools for their job. There really is no one-size-fits-all strategy for this. Best of breed has already won. So, using these tools, each of the stakeholders in this process create their work… often in the case of development artifacts like requirements, defects, user stories... Specifically for sharing and collaborating with their colleagues. This diagram is a simplified version of the natural flow of work across the lifecycle.