The principles and practices of the agile movement are quickly moving beyond the IT department and into how firms run their day-to-day business. This new way of organizing and running business gains further impetus by the headlong rush to use digital transformation to gain competitive advantage, which often requires changing a company’s operating model through many iterative steps known as a journey. Using the agile approach, they minimize risks and can validate that their efforts are meeting the desired outcome as they move forward on their journey. Unfortunately, many companies see these benefits of an agile approach, but they struggle to do that. What are they missing?
Read more in my blog on Forbes
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.
Rise in digital means rise in agile networks: As enterprises launch more digital projects, demand for agile and programmable networks rises
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:
- 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.
Senior Vice President
In the last few years, enterprise preference for IT service delivery has shifted subtly toward in-house delivery. While IT support remains predominantly outsourced, share of delivery from Global In-house Centers (GICs, or shared services centers) has risen steadily.
Top 20 startup trailblazers across the spectrum:
- Continuous build
- Continuous integration
- Release management
- Continuous deployment & configuration managementVisit the report page
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.