Scaling in an application development environment can take many different shapes and forms. For the purposes of this blog, let’s agree that scaling implies:
Now that we’ve set the stage…our research suggests that over 90 percent of enterprises have adopted some form of Agile, and 63 percent believe DevOps is becoming a de facto delivery model. Having tasted initial success, most enterprises plan to scale their Agile/DevOps adoption.
The first thing we need to address here is the confusion. Does increasing adoption imply scaling?
Purists may argue that scaling across different projects isn’t really scaling unless they are part of the same program. This is because scaling by its very nature creates resource constraints, planning issues, increased overhead, and entropy. However, the resource constraints primarily relate to shared assets, not individual teams. So, if team A on one program and team B on another both adopt Agile/DevOps, neither team will be meaningfully impacted. Both can have their owns tools, processes, talent, and governance models. This all implies that this type of scaling isn’t really challenging. But, such a technical definition of scaling is of no value to enterprises. If different projects/programs within the organization adopt Agile and DevOps, they should just call it scaling. Doing so makes it easier and more straightforward.
The big question is, can – and should — Agile/DevOps be scaled?
Some people argue that scaling these delivery models negates the core reasons that Agile was developed in the first place: that they should thrive on micro teams’ freedom to have their own rhythm and velocity to release code as fast as they can, instead of getting bogged down in non-core tasks like documentation and meetings overload.
While this argument is solid in some respects, it doesn’t consider broader negative enterprise impacts. The increasingly complex nature of software requires multiple teams to collaborate. If they don’t, the “Agile/DevOps islands” that work at their own pace, with their own methods and KPIs, cannot deliver against the required cost, quality, or consistent user experience. For example, talent fungibility is the first challenge. Enterprises end up buying many software licenses, using various open source tools, and building custom pipelines. But because each team defines its own customization to tools and processes, it’s difficult to hand over to new employees when needed.
So, why is scaling important?
Scaling delivers higher efficiency and outcome predictability, especially when the software is complex. It also tells the enterprise whether it is, or isn’t, doing Agile/DevOps right. The teams take pride in measuring themselves on the outcomes they deliver. But they often are poorly run and hide their inefficiencies through short cuts. This ends up impacting employees’ work-life balance, dents technical and managerial skill development, increases overall software delivery costs, and may cause regulatory and compliance issues.
What’s our verdict on scaling Agile/DevOps?
We think it makes sense most of the time. But most large enterprises should approach it in a methodical manner and follow a clear transitioning and measurement process. The caveat is that enterprise-wide scale may not always be appropriate or advantageous. Enterprises must consider the talent model, tools investments, service delivery methods, the existence of a platform that provides common services (e.g., authentication, APIs, provisioning, and templates,) and flexibility for the teams to leverage tool sets they are comfortable with.
Scaling is not about driving standardization across Agile/DevOps. It’s about building a broader framework to help Agile/DevOps teams drive consistency where and when possible. Our research on how to scale Agile/DevOps without complicating may help you drive the outcomes you expect.
What has been your experience scaling Agile/DevOps adoption? Please contact me to share your thoughts.
Complimentary 60-minute webinar to be held on Thursday, September 27, 2018 | 9 a.m. CDT, 10 a.m. EDT, 3 p.m. BST, 7:30 p.m. IST
Questions we’ll address:
As frequent delivery and customer satisfaction become the new currencies for IT organizations, a greater number of enterprises are embracing Agile and DevOps methodologies to rapidly deploy useful software. As traditional, Waterfall-based contracts are unable to manage the ambiguity and complexity related to Agile, the increase in Agile adoption is causing sourcing groups to reassess outsourcing contract templates.
Who should attend, and why?
This webinar will provide Strategic Outsourcing & Vendor Management groups with practical insights for structuring and negotiating Agile contracts.
Presenters
Jimit Arora
Partner
Everest Group
Abhishek Sharma
Partner
Everest Group
Moderator
Alan Wolfe
Senior Vice President
Everest Group
By its nature, digital transformation is difficult as it’s fraught with the complexities and magnitude of change. The reason so many digital journeys don’t succeed is because the company fails to implement the operating model necessary to make the digital platform work. By operating model, I mean organizational changes, policy and process changes, talent model changes and the go-to-market changes.
Why do companies often fail to implement the operating model that’s necessary for the digital platform they build? Simply stated, they take a fractured approach to the digital journey. Although the executives say the operating model is changing, they don’t build a common vision that allows it to happen.
Read more in my blog on Forbes
AstraZeneca, MediVector case studies illustrate two of many potential applications of DevOps in pharmaceutical value chain.
The pharmaceutical sector, which typically lags behind other industries in technology adoption, is crying out for change as its IT organization is unable to reform itself fast enough to deal with an increase in drug safety breaches and slow time to market for both products and business solutions. Everest Group maintains that pharmaceutical companies can address these challenges by employing DevOps—a methodology successfully implemented in the software industry to respond to fluctuating demands, provide a better customer experience and reduce time to market.
Potential DevOps use cases abound across the pharmaceutical value chain: drug discovery and research, clinical and pre-clinical trials, manufacturing operations, sales and marketing, and supply chain management and distribution are just a few examples.
As illustration, Everest Group points to two successful DevOps implementations:
Everest Group cautions, however, that although a wide variety of DevOps use cases are feasible, pharmaceutical companies should prioritize their DevOps investments based on potential business impact and ease of implementation.
These findings and more are discussed in a recently published Everest Group report, “Life Sciences Annual Report 2018: Pharma’s DevOps Factor for Digital Transformation.” This report takes a look at the concept of DevOps, puts forward a number of DevOps use cases across the pharmaceutical value chain and evaluates each to decide which is the most suited for implementation if progressive business impact is to be realized. The report also lays out a three-stage future implementation roadmap for pharmaceutical enterprises.
Across many industries, the adoption of DevOps is being linked directly to time to market and customer centricity,” said Abhishek Singh, practice director at Everest Group. “As Astra Zeneca and MediVector cases exemplify, the time seems ripe for pharmaceutical companies to make DevOps their next big bet. Indeed, most pharma firms are currently looking to experiment with DevOps, with a long-term goal of enterprise-wide DevOps-enabled digital transformation.”
Additional Key Findings:
With DevOps’ core goal of putting applications in users’ hands more quickly, it’s no surprise that many enterprises have started to release and deploy software up to five times a month, instead of their earlier once-a-quarter schedule. Everest Group research suggests that over 25% of enterprises believe DevOps will become the de-facto application delivery model.
However, there continues to be a disconnect between what business users want and what they get. To be fair to developers and IT teams, this disconnect is due, in part, to end-users’ difficulty in articulating their needs and wants.
AI Systems have strong potential to help product management teams cut through the noise and zero-in on the features their users truly find most valuable. Consider these areas of high impact:
There are multiple other areas in which AI can potentially assist in understanding what the users want. For example, as we discussed in earlier research, AI can help developers create secure, performance-tuned, and production-ready code without being bogged down by typical feedback on features from the field.
The good news is such an AI system will not burn a massive hole in enterprises’ budgets and should not require the zillions of data points that most typical, complex AI systems do. I believe these systems can be based on simple log data, performance feedback cycles, feature files databases, requirements catalogues, and other already existing assets. If that’s the case, they have great potential to help enterprises develop software their end-users really want.
Have you deployed AI in your Agile DevOps delivery cycle? I’d love to hear about it at [email protected].
Top 20 startup trailblazers across the spectrum:
While pervasive digital technologies have lead to improved and seamless user experiences, they also have increased exposure to cybersecurity threats and data breaches. As a result, software engineering teams need integrate security into their products, weaving it into both Dev and Ops processes.
Startup activity across the full product spectrum, from ideation to management
©2024 Everest Global, Inc. Privacy Notice Terms of Use Do Not Sell My Information Research Participation Terms
"*" indicates required fields
