Tag: devops

Should You Scale Agile/DevOps? | Blog

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:

  • From one team to a project
  • From one project to a program
  • From a program to multiple programs
  • From multiple programs to a portfolio
  • From a portfolio to a business
  • From a business to the entire enterprise.

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.

Contracting for Agile: Lessons From the Trenches in Sourcing Agile Development | Webinar

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

VIEW PRESENTATION

Questions we’ll address:

  • Is broad-based adoption of Agile Development real or hype?
  • How does Agile impact the delivery model for outsourced services?
  • How do pricing models need to evolve to capture value from Agile?
  • How do Terms & Conditions for Agile contracts need to change to minimize risk and maximize value?
  • What are some best practices to consider when negotiating and managing Agile contracts?

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

Important Lesson For Companies Undertaking Digital Transformation | Sherpas in Blue Shirts

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

Related: Learn more about our digital transformation analyses

Life Sciences Companies, Lagging In Tech Adoption, Can Leap Ahead with a DevOps Approach—Everest Group | Press Release

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:

  • AstraZeneca achieved improved quality, significantly faster time to value delivery (a 40 to 60 percent improvement) and reduced team sizes, which in turn resulted in a 25 to 40 percent cost reduction.
  • Similarly, MediVector successfully applied a DevOps approach to rectify slow quality assurance audits of the machines used in the drug development process.

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:

  • Technology aspects, such as automation and cloud computing, coupled with softer aspects, such as a cross-functional organizational structure and an agile working culture, can drive DevOps enablement.
  • The success of DevOps initiatives in modern enterprises hinges on three pillars: a culture of trust, accountability and shared responsibility; standardization of pocketed adoption and consolidation of tools and technologies; and hybridization of the enterprise portfolio across legacy systems and modern DevOps-enabled applications.
  • DevOps adoption is particularly favorable for industries that suffer from frequently changing market demands, high time to market, poor customer experiences and inefficient operations. Conversely, DevOps adoption is unfavorable for industries that are heavily regulated or have mammoth organizational size, a complex stakeholder environment, or a mandate for cost minimization.
  • Service providers can help enterprises in their DevOps journey by devising roadmaps, aiding with change management and providing the necessary technology support.

***Download a complementary report abstract.***

AI Helping DevOps: Don’t Ask, Don’t Assume – KNOW What Users Really Want | Sherpas in Blue Shirts

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.

Enter AI Systems

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:

  1. Helping developers at run time: Instead of developers having to slog through requirements, feature files, and feedback logs – and likely miss half the input – AI-led “code assister” bots can help them, during the actual coding process, to ensure that the requested functionality is created
  2. Prioritizing feedback: Rather than wasting time on archaic face-to-face meetings to prioritize features requested in the dizzying amount of feedback received from users, enterprises should build an AI system to prioritize requests from high to low, and dynamically change them as needed based on new incoming data
  3. Stress testing feedback: After prioritization, AI systems should help enterprises segregate the features users really want, versus those they think they want. AI can do this by crunching the massive volume of feedback data though machine learning and finding recurring patterns that suggest consensus. The feedback data should also be fed back to business users to educate them on market alignment of demanded and desired features
  4. Aligning development, QA, and production: Through its inherently neutral perspective, an AI system can smooth through the dissonance among the different teams by crunching all the data across the feedback systems to outline disconnects and create the alignment needed to satisfy end-user needs
  5. Predicting features: While this is still far-fetched, enterprises and technology vendors should work toward AI solutions that can predict features that will be requested in the next sprint based on historical data. In fact, AI systems should be able to analyze data across other enterprises as well to suggest relevant features to developers. The predictions could then be validated with real feedback from beta users, and the AI system further trained based on the validations

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.

What about Budget?

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].

From DevOps to DevSecOps | Market Insights™

Sftwr Engrng - devops to devsecops

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.

Visit the report page

Have a question?

Please let us know how we can help you.

Contact us

Email us

How can we engage?

Please let us know how we can help you on your journey.