Software Development Life Cycle (SDLC) is a process employed by the software industry. It helps to style, develop and test top quality software. it’s a technique which has clearly defined processes for creating low-cost and high-quality software. It provides a well-structured flow of phases which help a corporation to supply high-quality software quickly which is well-tested and prepared for production use.

Why do we need SDLC?  

A system development life cycle helps to minimize the complexity of developing a system from scratch. It’s important to possess an SDLC in situ because it helps to rework the thought of a project into a functional and completely operational structure. Additionally to covering the technical aspects of system development, SDLC helps with process development, change management, user experience, and policies. Another advantage of an SDLC is that it allows for planning before time, determine costs and staffing decisions, define goals, measure performance, and validate points at each phase of the cycle to spice up the standard of the ultimate product.

What are the Benefits of the Software Development Lifecycle?

• Gives an outlined view of the complete system, resources, timeline, and goals
• Design reviews help to make sure the reliability and quality of the ultimate product
• Enhanced control over large or complex projects
• Involves clear and comprehensive steps
• Provide goals and deliverables that meet the standards of every party involved within the project, requires keeping detailed documentation throughout the whole process.
• Easy estimation of costs and growth of the developed system.

What are the SDLC phases?

The seven phases of SDLC are:

1.Planning- In the Planning phase, project leaders evaluate the terms of the project. This includes calculating material and labor costs, creating a timetable with target goals, and creating the project’s teams and leadership structure. It can even include feedback from stakeholders. This step should clearly define the scope and purpose of the appliance. It plots the course and provisions the team to effectively create the software. It also sets boundaries to assist keep the project from fluctuating from its original motive.

2.Analysis-The analysis stage incorporates accumulating all the specific informations needed for a new system as well as shaping the first ideas for prototypes.

Developers may:

• Explicate any prototype system requirements
• Evaluate alternatives of the prototypes existing
• Carry out research and analysis to to see the necessities of end-users

Besides, developers will often create a software requirement specification or SRS document.This includes all the specifications for software, hardware, and network requirements for the system they attempt to build. This will prevent them from overdrawing funding or resources when  engaging at the identical place as other development teams.

3.Design- Some facets of the design include:

• Architecture – Specifies artificial programming language, industry practices, overall design, and use of any templates or boilerplate
• User Interface – Defines the ways customers interact with the software, and the way software responds to input
• Platforms – Defines the platforms on which the software will run, like Apple, Android, Windows version, Linux, or perhaps gaming consoles
• Programming – Not just the programming language, but including methodologies of solving problems and performing tasks within the application
• Communications – Defines the methods that the appliance can communicate with other assets, like a central server or other instances of the appliance
• Security – Describes the steps taken to secure the application, and may comprise of SSL traffic encryption, password protection, and secure storage of user credentials

4.Development- This is the particular writing of the program.  A tiny project may be written by one developer, while an oversized project can be choppy and worked by several teams. Use an Access Control or Source Code Management application during this phase. These systems help the developers to track changes to the code. They even help and ensure compatibility between different team projects and to ensure target goals are being met. Software developers admire instructions and explications. Documentation can be a proper process, which includes wiring a user guide for the application.  It can even be informal, like comments within the source code that designate why a developer used a particular procedure. Even companies that strive to form software that’s easy and intuitive take pleasure in the documentation. It can be a fast guided tour of the application’s basic features that display on the primary launch. It can be video tutorials for complicated tasks. Documentations which are written like troubleshooting guides, user guides and FAQ’s help the users resolve problems or technical questions.

5.Testing- It’s critical to check an application before making it accessible to users. Most of the testing can be automated, like load testing. Other testing can only be carried out in a particular environment – consider creating a simulated production environment for complex deployments. Testing should make sure that each function works properly. Different parts of the application should even be tested to act seamlessly together—performance test, to cut back any hangs or lags in processing. The testing phase helps lower the amount of bugs and glitches that users come across. This results in a higher user satisfaction and an improved usage rate.

6.Implementation- After testing, the whole design for the software will come together. Different modules or designs are going to be integrated into the basic source code through the efforts of the developer, generally by leveraging training environments to identify further errors, faults or defects. The information system will be merged into its environment and will be installed in due course. After going by this stage, the software is theoretically ready for market and can be provided to any end-users.

7.Maintenance- Now, the event cycle is nearly finished.  The application is finished and being operated in the field. The Operation and Maintenance phase still continues to be of importance, though. During this stage, users encounter bugs that weren’t observed during testing. These defects has to be resolved, which can generate new development cycles. Along with bug fixing, models like Iterative development plan additional features in future releases. For every release, a new Development Cycle can be introduced.

What are the different types of Software Development Life Cycle Models?

• Waterfall Model- Waterfall is the most aged and least complicated of the structured SDLC models — finish one phase, then march on to the subsequent. There is no way back. Each and every stage relies on information from the preceding stage and has a project plan of it’s own. Waterfall is simple to understand and effortless to manage.

• V-Shaped Model- Also called the Verification and Validation model, the V-shaped model came or grew out of Waterfall and is distinguished by a corresponding testing phase for every development phase. Like Waterfall, each stage begins only after the last one has finished.
• Iterative Model- The Iterative model is repetition embodied. Instead of starting with well known requirements, you enact a set of software requirements, then test, evaluate and pinpoint further requirements. A brand new version of the software is generated with each phase, or iteration. Rinse and repeat until the total system is ready to go.
• Lean- The Lean model for software development is stimulated by “lean” manufacturing practices and principles. The seven Lean principles (in this order) are: eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, incorporate integrity, and see the full. The Lean process is about working only on what must be worked on at the time, so there’s no room for multitasking. Project teams are focused on finding opportunities to cut down waste at every turn throughout the SDLC process, from dropping unnecessary meetings to reducing the documentation.
• Spiral Model- One of the most adjustable SDLC models, the Spiral model takes a cue from the Iterative model and its repetition; the project goes through four phases over and over in an exceedingly “spiral” until completed, with multiple rounds of refinement.

• Big Bang Model- A bit of an anomaly among SDLC methodologies, the massive Bang model follows no specific process, and extremely little time is spent on planning. the bulk of resources are thrown toward development, and even the client might not have a solid grasp of the wants. this can be one in every of the SDLC methodologies typically used for tiny projects with just one or two software engineers.
• Agile Model- By breaking the merchandise into cycles, the Agile model quickly delivers a working product and is taken into account a awfully realistic development approach. The model produces ongoing releases, each with small, incremental changes from the previous release. At each iteration, the merchandise is tested.

• DevOps- The DevOps model is that the newcomer to the SDLC scene. As this article explains, it emerged from two trends: the appliance of Agile and Lean practices to operations work, and also the general shift in business toward seeing the worth of collaboration between or together closely — and sometimes in concert team — to accelerate innovation and therefore the deployment of higher-quality and more reliable software products and functionalities. Updates to products are small but frequent. Discipline, continuous feedback and process improvement, and automation of manual development processes are all hallmarks of the DevOps model.

Which SDLC Model is Best?

DevOps model is that the best one as developers and operations teams work together closely and side by side — and sometimes jointly team — to speed up innovation and therefore the deployment of higher-quality and more reliable software products and functionalities. Updates to products are small yet frequent. Discipline, continuous feedback and process improvement, and automation of manual development processes are all hallmarks of the DevOps model.

Ultimately, any development team in both the IT and other industries can take pleasure in implementing system development life cycles into their projects. Use the above guide to spot which methodology you would like to use in conjunction together with your SDLC for the simplest results.

The Disaster That Started the Conversation

In April 2018, TSB migrated billions of customer records onto a new core-banking platform. The project had been in planning for over 18 months and involved more than 1,000 professionals. Within 20 minutes of the cutover, customers began reporting missing savings balances and incorrect transaction histories. Weeks of service disruption followed, costing the bank an estimated £330 million and driving approximately 80,000 customers to switch to competitors.

The post-incident analysis pointed to a single, preventable root cause: insufficient rigorous testing before go-live.

TSB is not an isolated case. Across industries, digital leaders facing executive pressure and fixed delivery deadlines routinely compress or skip testing phases—especially when complex legacy systems are involved. The result is almost always the same: defects surface in production, where fixing them is far more expensive and damaging than catching them earlier.

Why Testing Gets Treated as an Afterthought

In traditional waterfall delivery models, testing sits at the end of the pipeline. By the time testers receive a build, the delivery deadline is imminent and any defects discovered are unlikely to be fully resolved before go-live. This creates a self-defeating cycle:

• Testers flag issues late in the cycle.
• Business stakeholders override the concerns because timelines are fixed.
• The product ships with known or unknown defects.
• Incidents occur in production at far greater cost than earlier remediation would have required.

Testing is perceived as the “troublemaker”—the discipline that causes delays rather than the one that prevents them. Reframing that perception is the first step toward more resilient delivery.

How Agile Transforms the Testing Mindset

Agile methodology fundamentally changes when and how testing happens. Rather than a single testing phase at the end of a project, testing is distributed across the entire software development lifecycle (SDLC):

• Testing in sprints: Testers are embedded within cross-functional Agile teams and participate in every sprint, not just the final one.
• Continuous feedback: Each sprint’s test results directly inform the scope and priorities of the next sprint, creating a tightening feedback loop.
• Shared ownership: The whole-team approach means every team member—developer, business analyst, tester—is responsible for product quality, not just the QA function.
• Broader tester skills: Testers in Agile environments need strong communication, collaboration and exploratory-testing skills alongside their technical expertise, because they are active participants in sprint planning and retrospectives.

This shift means that defects are found and resolved when they are cheapest to fix: during development, not after deployment.

Test Automation: The Critical Enabler

Embedding testers into Agile teams is necessary but not sufficient. The volume of testing required to support continuous delivery at pace makes manual-only testing unsustainable. Test automation is what allows teams to move quickly without sacrificing coverage.

What to Automate

• Regression testing: Running the full suite of existing tests against every new build manually is prohibitively slow. Automated regression suites catch regressions overnight or within a CI/CD pipeline run.
• Smoke testing: A fast automated smoke test validates that a new build is stable enough for deeper testing before human effort is invested.
• API and integration tests: Automated contract and integration tests verify that services communicate correctly as codebases evolve.

Freeing testers from repetitive manual regression work allows them to focus on higher-value exploratory testing—the kind of creative, scenario-driven testing that automated scripts cannot easily replicate.

The ROI of Automation

According to the original case study, a large telecoms provider previously required two full-time testers and two weeks to execute 8,000 tests at a cost of approximately £7,000 per cycle. After implementing automated testing, the same test suite ran overnight at a fraction of that cost. The two testers were redeployed to process improvement and exploratory testing—adding direct value to the delivery pipeline rather than executing repetitive checks.

Note: This specific figure comes from the original devopsonline.co.uk source and has not been independently verified.

Test automation requires upfront investment in people, tooling and process design. It also demands sustained discipline: automation suites rot if they are not actively maintained alongside the product they test. Teams that treat automation as a one-time project rather than an ongoing engineering discipline consistently see their suites degrade in value over time.

Dynamic Test Automation: Letting Data Drive the Tests

Standard test automation typically executes test cases in a fixed, predetermined order. Dynamic Test Automation takes a different approach: the test data itself carries indicators that determine which tests run and what the expected outcome should be. This surfaces hidden dependencies that linear test execution would miss.

“If we always work through our automated tests in the order 1, 2, 3, 4, 5 we will never find out what happens if we test 1, 2, 3, 5, 4.”

Adam Pettman, 2i

Because unknown dependencies are more likely to be exposed when test execution order varies, dynamic approaches tend to find defect categories that traditional scripts would miss entirely.

Generating Test Data

Dynamic automation requires quality test data. Live production data is usually unsuitable for test environments for privacy and compliance reasons. Two practical approaches exist:

Approach 1 – Anonymisation

Live data is transformed so that personally identifiable information (PII) is replaced with realistic but fictional equivalents. For example, “Bob Smith, Accountant” becomes “James Brown, Finance Associate.” The data relationships and realistic value distributions are preserved, improving test coverage compared with purely synthetic data. The limitation is scale: anonymising data consistently across large relational databases with many foreign-key relationships is complex and may not be feasible in every context.

Approach 2 – Generating Data from Scratch

Test data is created synthetically, working with Product Owners and business stakeholders to ensure all key scenarios are represented. Brief workshops to define the required data rows require an initial time investment, but that investment pays back quickly: synthetic data that covers edge cases catches defects before User Acceptance Testing (UAT), dramatically reducing the number of surprises at that stage.

Breaking the Data Intentionally

A complete test strategy must verify not only that valid inputs produce correct outputs (the “happy path”) but also that the system handles invalid or unexpected inputs gracefully (the “sad path”). Introducing deliberately malformed or boundary-violating data in a controlled way—sometimes called negative testing or fault injection—validates that the system catches errors correctly rather than silently producing wrong results.

Case Study: Dynamic Test Automation for an Eco-Tech Start-Up

Testing firm 2i partnered with a cloud-native start-up to embed Dynamic Test Automation into their delivery pipeline. The engagement spanned the full team, from CTO to junior developer. The technology choices made in this implementation illustrate how the theory translates into practice.

Generating Test Data with Python

Test data was generated from scratch using Python scripts that produced a series of JSON files ready for upload through the application. This gave the team full control over the data’s structure, volume and variation without any dependency on production data or anonymisation tooling.

Breaking the Data with Python

A separate Python script randomly injected invalid values into the JSON files. Files with injected values were tagged so that the test framework knew to expect failures when processing them—providing a clean mechanism for sad-path testing without manual intervention.

UI Test Automation with Cypress and Cucumber

Cypress was selected as the browser automation framework to interact with the web application and drive test execution. All test cases were written in BDD (Behaviour-Driven Development) format using Cucumber, which allowed test scenarios to be expressed in plain language (Gherkin syntax) while the underlying implementation remained hidden from business stakeholders. This enabled non-technical Product Owners to read, review and even contribute to test case design.

Test cases covered both happy paths (valid JSON files processed successfully) and sad paths (files tagged as “Broken” rejected as expected). The full suite formed the basis of the ongoing regression pack.

Embedding in the CI/CD Pipeline

The complete Dynamic Test Automation suite was integrated into the team’s GitOps CI/CD pipeline. Every commit triggers the test suite automatically, giving the engineering team continuous confidence that new code has not broken existing functionality—without slowing down their deployment velocity.

Where Quality Assurance Is Heading

Test automation will continue to expand its scope. Several trends are already visible:

• Low-code and no-code automation tools are lowering the barrier to entry, enabling teams without deep scripting expertise to build and maintain automated test suites.
• AI-assisted testing is beginning to augment test case generation, defect prediction and visual regression detection—though this area is still maturing.
• Shift-left security testing (integrating security checks earlier in the pipeline) is following the same pattern that functional testing has undergone with Agile.

However, automation does not eliminate the need for skilled testers. Human expertise remains essential for:

• Defining relevant test scenarios and acceptance criteria.
• Exploratory testing that probes the edges of expected behaviour.
• Overseeing automation suite quality and preventing test rot.
• Translating business requirements into testable conditions.

The organisations that will deliver the most reliable software at the highest velocity are those that combine strategic test planning, well-designed test cases, disciplined automation and skilled QA engineers—all embedded directly in the delivery pipeline from the first sprint, not bolted on at the end.

Original article by Adam Pettman, first published on devopsonline.co.uk. Implementation referenced was delivered by 2i.

Why the Agile Tools Market Matters to DevOps Teams

Agile methodologies — Scrum, Kanban, SAFe, and their variants — depend on tooling to make workflows visible, measurable, and repeatable. Without the right platform, sprint planning, backlog grooming, velocity tracking, and release management become error-prone manual processes. As DevOps practices push for tighter integration between development, QA, and operations, the tools teams choose directly affect delivery speed and quality.

The market for these tools spans small SaaS startups to large enterprises, and competitive pressure has driven rapid feature development across the board. Understanding the major vendors helps teams make informed procurement decisions.

Major Agile Development Tools and Platforms

The following platforms are widely recognized in the Agile tools space. Each has a distinct focus area, pricing model, and integration ecosystem.

Jira (Atlassian)

Jira is arguably the most widely adopted Agile project management tool in enterprise software teams. It supports Scrum and Kanban boards, sprint management, customizable workflows, and deep integration with the Atlassian ecosystem (Confluence, Bitbucket, Bamboo). Jira’s strength lies in its flexibility and extensive marketplace of plugins, though that flexibility can introduce configuration complexity for smaller teams.

VersionOne (now Digital.ai Agility)

VersionOne targets enterprise-scale Agile and scaled frameworks such as SAFe and LeSS. It provides portfolio management, program-level planning, and cross-team dependency tracking. It has since been rebranded under Digital.ai following an acquisition, and is well-suited to organizations running multiple Agile teams that need a unified view of delivery.

Pivotal Tracker

Pivotal Tracker is a lightweight, velocity-driven Agile tool popular with product teams using Extreme Programming (XP) or Scrum. Its story-based backlog, automatic velocity calculation, and simple interface make it appealing to smaller teams or startups that want low overhead. It is less suited to large-scale portfolio management.

LeanKit (now Planview AgilePlace)

LeanKit focuses on Kanban-style visualisation and flow management. It is particularly useful for teams practicing Lean or continuous delivery who need to visualize work in progress (WIP) limits and identify bottlenecks across the value stream. It has been acquired by Planview and rebranded as Planview AgilePlace.

Planbox

Planbox positions itself as an innovation and Agile work management platform. It combines project tracking with ideation and continuous improvement workflows, making it relevant for teams that want to connect strategic innovation to day-to-day Agile delivery.

ActiveCollab

ActiveCollab is a project management tool aimed at agencies and mid-sized teams. It combines task management, time tracking, and invoicing. While not as Agile-specific as Jira or VersionOne, it supports iterative workflows and is popular for client-facing project delivery.

Telerik TeamPulse

Telerik TeamPulse was an Agile project management tool built by Telerik (now Progress) with native integration into the Microsoft development ecosystem. It offered Scrum boards, backlog management, and feedback portals. Note that TeamPulse has been discontinued; teams previously using it have typically migrated to Jira or Azure DevOps Boards.

Agile Bench

Agile Bench was a simpler Scrum-focused tool designed for small teams. It provided basic sprint and backlog management. Its market presence is limited compared to the larger vendors listed above, and its current development status should be independently verified before adoption.

Key Factors Driving Agile Tool Adoption

• Remote and distributed teams: Cloud-based Agile tools provide a shared source of truth for teams spread across time zones.
• Scaling Agile frameworks: Enterprises adopting SAFe, LeSS, or Disciplined Agile need tools that support program-level and portfolio-level planning beyond a single team.
• CI/CD pipeline integration: DevOps teams require Agile tools that integrate with their CI/CD pipelines (Jenkins, GitHub Actions, GitLab CI) so that code commits, builds, and deployments can be linked to stories and epics.
• Reporting and metrics: Velocity, cycle time, lead time, and burndown charts help teams identify process bottlenecks and communicate progress to stakeholders.
• Compliance and audit trails: Regulated industries need documented traceability from requirements through to release.

Evaluating Agile Tools: A Practical Checklist

When assessing any Agile development tool for your team, consider the following criteria:

1. Supported methodologies: Does the tool support the specific framework your team uses — Scrum, Kanban, SAFe, XP?
2. Integration ecosystem: Does it integrate natively with your version control system, CI/CD toolchain, and communication platforms (Slack, Microsoft Teams)?
3. Scalability: Can the tool support multiple teams, programs, and portfolios as your organisation grows?
4. Reporting depth: Does it provide the metrics your engineering and product leadership need without requiring custom exports?
5. Hosting model: Is a cloud SaaS model acceptable, or does your organisation require a self-hosted or on-premises deployment?
6. Total cost of ownership: Account for per-seat licensing, add-on costs, training, and migration effort from existing tools.
7. Vendor stability: Several tools in this space have been acquired or discontinued. Check the current ownership and product roadmap before committing.

Market Landscape: Geographic and Competitive Dynamics

Agile tool adoption is strongest in North America and Western Europe, where software-driven enterprises have invested heavily in Agile transformation programs. The Asia-Pacific region, including India and Japan, represents significant growth opportunity as technology sector expansion continues and global delivery models proliferate.

Competition in this market is intense. Atlassian (Jira) and Microsoft (Azure DevOps Boards) hold dominant positions in enterprise adoption. Smaller or more specialised vendors compete on simplicity, pricing, or specific methodology support. Acquisitions have consolidated some players — LeanKit into Planview, VersionOne into Digital.ai, TeamPulse being discontinued by Progress — meaning teams should evaluate vendor longevity alongside feature sets.

Conclusion

The Agile tools market offers a wide range of solutions, from lightweight trackers suited to small product teams to enterprise platforms capable of coordinating hundreds of squads. DevOps engineers and engineering managers evaluating this space should anchor their selection to concrete requirements: team size, methodology, integration needs, and hosting constraints. Given the pace of acquisition and consolidation in this sector, it is also worth verifying the current status and roadmap of any tool before committing to adoption.

What Oracle Generation 2 Cloud Infrastructure Offers

Oracle Cloud Infrastructure (OCI) provides foundational building blocks—flexible compute options, reliable storage, and high-speed networking—alongside advanced services that differentiate it from first-generation cloud platforms:

• Autonomous Database: A self-provisioning, self-configuring, self-tuning, and self-patching database engine designed to eliminate routine DBA overhead.
• Oracle Analytics Cloud: A managed analytics service that enables business intelligence, data visualization, and machine learning without managing underlying infrastructure.
• Oracle Cloud Applications: A suite including ERP, EPM (Enterprise Performance Management), HCM (Human Capital Management), and Customer Experience (CX) applications.
• Security-by-design: Security controls embedded throughout the infrastructure layer rather than bolted on afterward.

Real-World Deployments: Enterprise Case Studies

Federal Bank: ATM Performance Analytics

Federal Bank, with over 1,200 branches and 1,600 ATMs across India, needed a unified view of ATM performance across its entire network. As an early adopter of Oracle Autonomous Data Warehouse, the bank built a user-friendly analytics solution—complete with drill-down and roll-up reporting—in under four weeks. Integrated with Oracle Analytics Cloud, the solution now delivers actionable intelligence to senior leaders, enabling faster decisions based on customer behavior data collected nationwide.

Sharda University: Shifting Focus from IT Maintenance to Learning

Among the first universities globally to adopt Oracle Autonomous Database, Sharda University moved away from routine IT management tasks entirely. With Oracle Analytics Cloud, the university now extracts deeper operational and academic insights to support strategic decision-making, freeing its technology team to concentrate on improving the student experience rather than maintaining databases.

Hindalco: Finance and IT Collaboration with Oracle EPM Cloud

Hindalco, one of India’s largest aluminium producers, adopted Oracle EPM Cloud to bring finance and IT functions into closer alignment. The platform enabled the company to automate routine financial planning processes, consolidate data, and deliver sharper, more timely insights to senior management—all in a cost-effective cloud deployment model.

The Autonomous Cloud Vision: Self-Managing Infrastructure

At Oracle OpenWorld (San Francisco), Chairman and CTO Larry Ellison outlined Oracle’s long-term goal: delivering what he described as the “world’s first completely and truly autonomous cloud.” The roadmap involves progressively automating every layer of the infrastructure stack.

A notable addition announced at the event was Autonomous Linux and a companion Oracle OS Management Service. According to Ellison, the new version of Oracle Linux provisions itself, scales itself, tunes itself, and applies patches while running—mirroring the self-managing behavior already present in the Autonomous Database. Oracle reported that this technology was already deployed on hundreds of thousands of servers inside its own cloud before being made available to customers for on-premises use as well.

Cloud Applications: ERP, EPM, HCM, and Digital Assistants

Oracle’s suite of cloud applications received significant updates, with new features across ERP, EPM, HCM, and Customer Experience (CX) products. A cross-cutting addition is the rollout of Oracle Digital Assistants across the full application portfolio, expanding the range of tasks users can complete via conversational AI interfaces without navigating traditional UI screens.

VMware Workload Support on OCI

A significant move for enterprise migration strategies: Oracle announced support for VMware workloads running on Oracle Cloud Infrastructure. Customers can lift existing VMware-based workloads into OCI while retaining full administrative access to their VMware environments. This removes a common migration barrier—the fear of losing control over virtualization layer management—and makes OCI a viable target for organizations with large VMware estates that are not yet ready to re-architect applications.

Oracle’s Enterprise Cloud Strategy at a Glance

• Autonomous Database first: Grow the Autonomous Database franchise and migrate existing Oracle Database customers to it.
• Full-stack autonomy: Extend self-managing capabilities from the database up through the operating system and, ultimately, the entire infrastructure stack.
• Application modernization: Use cloud ERP, EPM, HCM, and CX applications as a forcing function for customers to modernize back-office and customer-facing processes simultaneously.
• VMware compatibility: Reduce migration friction for enterprises with large on-premises VMware footprints.
• On-demand economics: Provide access to advanced technologies—including AI and autonomous services—on a consumption-based pricing model suitable for organizations ranging from startups to global enterprises.

This article is based on reporting originally published by Financial Express (financialexpress.com) and statements made at Oracle OpenWorld.

Why Agile Still Matters

Agile has earned its place in the business lexicon. For almost two decades it has helped companies of all sizes break free from the inflexibility of traditional top-down hierarchies and rigid long-term planning. You will hear talk of “squads”, “chapters” and “tribes”, and although different flavours of Agile exist, certain patterns recur: teams work in short sprints, they are empowered to make decisions, and success is measured by responsiveness to customer demands rather than adherence to a fixed plan.

Justin Rodenbostel, Vice President at digital transformation agency SPR, argues there is no “after Agile”. He sees adjacent movements such as DevOps, Continuous Delivery, and Lean as direct extensions of Agile thinking, and believes organisations will continue drawing on the original Agile Manifesto to evolve how they work and respond to customers.

But Agile is also demanding. It requires intense, sustained commitment and depends heavily on organisational culture to succeed. According to the annual State of Agile survey, the top three challenges are general resistance to change, inadequate management support, and a culture at odds with Agile values. Below, practitioners share the most common pitfalls — and how to navigate them.

Pitfall 1: Short Sprints Can Obscure Long-Term Vision

One of Agile’s biggest draws is that annual planning is replaced by shorter-term milestones. Teams focus on delivering value now rather than executing a fixed multi-year roadmap. That responsiveness is powerful, but it carries a risk: teams can lose sight of where the organisation is ultimately heading.

Ian McClarty, CEO of global IT service provider PhoenixNAP, puts it plainly: “When teams are so heavily focused on the current sprint, communication about long-term vision may be put aside or ignored, leaving the team with a feeling that there is no grand plan they are supporting.”

The most straightforward remedy is deliberate, regular communication of larger business objectives — whether that is doubling headcount within two years or reaching a specific revenue milestone. McClarty also notes that Agile itself can reshape those goals by helping organisations fail faster and learn from mistakes sooner. He explains: “The ability to carve a project into many smaller pieces helps us create a sense of continued progress and motivation within teams, and also helps us create cleaner stop points — dropping features out of iterations to allow for faster time to market to see if the product will be successful before investing too much.”

Practical steps

• Share business-level OKRs or strategic goals at each sprint planning session so teams understand context.
• Run quarterly “big picture” reviews that sit above the sprint cycle and revisit organisational direction.
• Use product roadmaps — even lightweight ones — to communicate intent without locking in rigid plans.

Pitfall 2: The Agile Mindset Requires Constant Reinforcement

Christopher McFarlane, Agile Project Manager for Walmart Canada, identifies two distinct hurdles in building an Agile mindset: convincing internal team members of its value, and educating external customers and suppliers on how to engage with Agile teams.

“Encouraging team members and partners to understand the benefits of this new way of working — fast failure, constant communication, transparency — is the first hurdle,” McFarlane explains. “The second is a technical understanding of the components of an Agile methodology and educating stakeholders on how to engage with the Agile team, which is different from other areas of the business.”

Dr Matt Poepsel, Senior Vice President of Product at Predictive Index, found that a successful mindset shift required coaching individuals in the soft skills Agile demands: flexibility, collaboration, discipline, and a focus on results. He notes that any business transformation demands a simultaneous talent transformation: “We coached each individual by examining where their natural behaviours and approach were well-suited to some of these activities and where they needed to stretch to succeed.”

Chris Steel, Head of Transformation for North America at PA Consulting, emphasises the importance of early wins. “Where we have seen organisations struggle is where they approach it in a half-hearted way without the right sponsorship. The change to culture and ways of working required to achieve the best results is too significant without full engagement.”

Practical steps

• Identify and publicise early successes to build internal credibility for Agile practices.
• Invest in soft-skills coaching alongside technical Agile training.
• Secure visible sponsorship from senior leadership — Agile transformations stall without it.
• Create onboarding materials specifically for external stakeholders explaining how to collaborate with Agile teams.

Pitfall 3: Teams Slide Back into Traditional Management Styles

Adopting Agile is not a one-time event. Without sustained attention, teams can revert to the top-down, hierarchical structures they were accustomed to — particularly under delivery pressure.

David Fort, Managing Director at Haines Watts Manchester, describes it this way: “Being an Agile business isn’t a start-stop scenario; it’s a constant shift in culture and balance that has to be regularly revisited. If you stop running as an Agile business, you’re likely to seize up. The real challenge is ensuring the agility is fresh and team members remain focused on being Agile.”

Fort also advises factoring Agile compatibility into hiring decisions — prioritising candidates who demonstrate adaptability and comfort with ambiguity alongside technical skills and academic credentials.

Practical steps

• Schedule regular retrospectives that explicitly examine whether Agile principles are still being followed — not just whether delivery targets are being met.
• Include Agile values and behaviours in performance reviews and hiring criteria.
• Rotate Agile coaching and facilitation responsibilities to avoid over-dependence on a single champion.

Pitfall 4: Agile Does Not Scale Automatically

Rodenbostel identifies what he considers the most common mistake: assuming that success achieved by a small Agile team can be replicated at scale simply by applying the same practices to larger groups. “What works for small groups often doesn’t work for larger or different groups,” he warns. “Customers, business stakeholders, software assets, and government or industry regulation can all have an impact on what works and what does not. We see a tendency when scaling to standardise in a way that is often too prescribed.”

He also notes that the Agile move away from big upfront annual planning is particularly challenging in publicly traded companies, where investor expectations can push leadership back toward rigid, predictable roadmaps. The goal, he says, is to determine the appropriate balance rather than insisting on Agile purity in every context.

Practical steps

• Treat scaling frameworks (SAFe, LeSS, Nexus, etc.) as starting points, not prescriptions — adapt them to your specific constraints.
• Run a deliberate pilot with a small team before scaling Agile practices organisation-wide, and document what worked and what did not.
• Acknowledge regulatory and investor-relations constraints explicitly and design your Agile practice around them rather than ignoring them.
• Avoid standardising processes across teams prematurely — let teams develop practices that suit their context before rolling out a uniform model.

The Bottom Line

Agile is not a silver bullet, but it is a durable and well-evidenced approach to building adaptive, customer-focused teams. Its failures are rarely about methodology — they are almost always about culture, commitment, and communication. The organisations that get the most out of Agile are those that treat it as an ongoing practice rather than a project to be completed, invest in the human side of the transformation, and are honest about the contexts where a more structured approach remains necessary.

As Rodenbostel puts it, the concepts in the original Agile Manifesto are not going away. The challenge is applying them with the discipline and self-awareness they demand.

Too many IT workers operate under a cloud of fear and frustration. The 2017 congressional testimony from the former Equifax CEO — in which he pointed to a single IT employee as the cause of one of the largest data breaches in history — illustrated exactly why that culture persists. The DevOps Enterprise Summit (DOES) 2018 offered a very different picture: one where engineering teams are empowered, data-driven, and increasingly willing to challenge long-held assumptions. Here are three substantive lessons from that event.

1. Legal Teams Can Be Engineering’s Ally in Legacy Modernization

Anne Bradley, Nike’s Chief Privacy Officer, and Courtney Kissler, Nike’s VP of Digital Platform Engineering, delivered one of the conference’s most memorable sessions. Their topic: how to kill legacy systems that the business has been unwilling to retire.

Their approach was counterintuitive. Rather than building a purely technical case for decommissioning aging infrastructure, they framed the problem in legal and financial terms. Anne Bradley introduced the concept of negative ROI — calculating the expected cost of regulatory fines if a non-compliant legacy system remained in production. Modern data privacy regulations (such as GDPR and similar frameworks) create real, quantifiable financial exposure for organizations running systems that cannot meet current compliance standards.

Courtney Kissler used that legal and financial analysis to build an executive-level business case for shutting down the offending systems. The retirement was celebrated with an Irish wake, a cake, and poetry — a cultural signal that ending a system’s life is worth acknowledging, not mourning.

The practical takeaway: Engineers often fail to retire legacy systems not because the technical argument is weak, but because they fight the battle alone. Partnering with legal, compliance, or risk management functions transforms the conversation. When a legacy system carries a potential fine measured in the hundreds of millions of dollars, decommissioning it stops being a technical debate and becomes a straightforward risk decision. Look for allies outside your team when you need to drive modernization.

2. Databases Must Be Part of Your DevOps Transformation

Dr. Nicole Forsgren and Jez Humble from DevOps Research and Assessment (DORA) presented findings from the 2018 State of DevOps Report. One of the more noteworthy additions to that year’s research: the role of the database in DevOps performance.

The DORA research found that organizations actively incorporating database practices into their DevOps initiatives — version-controlling schema changes, automating database deployments, and treating database changes with the same discipline as application code — showed a positive correlation with overall IT performance.

Equally important was a finding about universality: database practices were described as non-differentiating in terms of where an organization sits on its DevOps maturity curve. Whether you are just beginning your DevOps journey or are already operating at an elite level, addressing your database practices produces measurable benefit.

The practical takeaway: Database changes are frequently the last piece of an otherwise automated delivery pipeline to remain manual. Schema migrations applied by hand, change scripts stored outside version control, and database deployments requiring a separate approval window all introduce risk and slow down releases. If your CI/CD pipeline handles application code but still treats the database as a special case, that is where your next investment should go. As the familiar saying goes: the best time to plant a tree was twenty years ago; the second-best time is today.

3. External Change-Approval Processes Hurt Software Delivery Performance

Nicole Forsgren’s book Accelerate (co-authored with Jez Humble and Gene Kim) attracted significant attention at DOES 2018. One distinguishing characteristic of the book is its foundation: years of empirical survey and analysis data, rather than anecdotes or vendor-sponsored case studies. None of the three authors worked for a technology vendor at the time of publication, which reduces the usual conflicts of interest found in this genre.

One of the most striking findings — discussed in detail in the book — concerns the approval process for software releases. The DORA researchers asked organizations to self-identify which of the following release approval models they used:

• All production changes must be approved by an external body (such as a manager or a Change Advisory Board)
• Only high-risk changes (for example, database changes) require external approval
• Changes are managed through peer review within the team
• No formal change approval process exists

The data produced a result that directly contradicts decades of received wisdom in IT operations: teams that required approval from an external body achieved lower software delivery performance across key metrics including deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate.

This does not mean that governance and oversight are unimportant. What the data suggests is that concentrating approval authority in a committee or manager external to the delivery team creates bottlenecks and does not provide the safety benefit commonly assumed. Teams operating with peer review — code review by colleagues who understand the system — consistently outperformed those relying on external change advisory boards.

The practical takeaway: If your organization runs a Change Advisory Board that reviews and approves every production deployment, the evidence suggests this process is slowing you down without meaningfully reducing risk. A more effective model invests in automated testing, deployment pipelines, and peer code review so that quality is built into the process rather than checked at the gate. External approval can be reserved for genuinely high-risk or regulatory scenarios rather than applied uniformly to all changes.

Key Takeaways

• Find non-technical allies when driving legacy modernization. Legal and compliance teams can make the business case that engineering teams alone cannot.
• Extend your DevOps practices to the database. Version control schema changes, automate database deployments, and treat database migrations as first-class artifacts in your pipeline.
• Rethink change approval. Peer review within the team produces better outcomes than external change advisory boards. Invest in automated testing and code review instead.

The themes from DOES 2018 — modernization, database inclusion in CI/CD, and evidence-based governance — remain as relevant today as when they were first presented. The DevOps community continues to accumulate data that challenges assumptions baked into traditional IT operations, and the organizations willing to act on that data are the ones pulling ahead.

What Is Jenkins Configuration as Code?

Jenkins has long been the de facto CI/CD system for enterprises, but managing it has traditionally required a dedicated administrator who manually configures Jenkins and its large ecosystem of plugins through verbose XML files. CloudBees addressed this operational burden by releasing version 1.0 of the Jenkins Configuration as Code (JCasC) plugin, which allows administrators and developers to define Jenkins configurations in human-readable YAML instead of XML.

With JCasC, teams can:

• Write Jenkins configuration in plain-text YAML files that are easy to read and edit
• Store those configuration files in a version control system such as Git
• Validate and test configuration changes before applying them
• Reuse a single configuration file to set up multiple Jenkins instances consistently

Why Configuration as Code Matters for Jenkins

Jenkins supports over 1,400 plugins, and configuring each one manually through the Jenkins UI or raw XML is error-prone, time-consuming, and difficult to audit. JCasC applies the same principles used in modern software development — version control, code review, repeatability — to Jenkins configuration management.

Mike Wolf, managing director and modern delivery leader specializing in DevOps and Agile at KPMG, speaking at DevOps World | Jenkins World 2018 in San Francisco, noted that configuration as code removes tedious manual processes and supports more industrialized, scalable use of Jenkins across large organizations. Equally important, it encourages system administrators to adopt the rigor and discipline of the modern software development lifecycle.

Mik Kersten, CEO at Tasktop Technologies, framed it as part of a broader industry shift:

“Over the past decade, the DevOps community has started taking all of these deployment and configuration steps and thinking of them as a part of the program — as code. This means we can start applying programming concepts, such as immutability, to the entire delivery pipeline.”

— Mik Kersten, CEO, Tasktop Technologies

Is YAML Good Enough for Jenkins Configuration?

Not everyone in the DevOps community is convinced that YAML is the right medium for configuration as code. Companies such as Atomist and Pulumi have pushed further, enabling developers to express configuration and infrastructure using real programming languages — JavaScript, TypeScript, and Python — rather than markup or domain-specific languages.

Rod Johnson, founder and CEO of Atomist, argued that YAML has inherent limitations when describing complex behaviors:

“There is a role for configuration, but whenever you are describing rich behaviors, code is a lot better. Too often configuration like YAML becomes a bad imperative programming language.”

— Rod Johnson, CEO, Atomist

Kohsuke Kawaguchi, then CTO of CloudBees and creator of Jenkins, acknowledged these alternative approaches but defended JCasC’s pragmatic scope: the plugin is designed to be “good enough for ordinary users of Jenkins.” His reasoning is that user adoption itself drives the plugin’s evolution — as more teams use JCasC, they will push its boundaries and drive further development.

The Broader Shift: Infrastructure and Configuration as Real Code

JCasC sits within a broader industry movement toward treating all infrastructure and configuration decisions as software artifacts. Joe Duffy, CEO of Pulumi, described this shift:

“Configuration as code has been a key addition in the DevOps toolkit over the past decade, to apply more rigorous software engineering practices to configuration problems across an enterprise infrastructure, from virtual machines and containers to databases and networks.”

— Joe Duffy, CEO, Pulumi

Key engineering practices that become possible when configuration is treated as code include:

• Version control and change history: Every configuration change is tracked with a commit message and author attribution
• Code review: Peer review of configuration changes catches errors before they reach production
• Automated CI/CD pipelines: Configuration files can be tested and deployed through the same pipelines used for application code
• Reusable abstractions: Shared modules and packages allow teams and communities to standardize common configurations
• Unit testing: When configuration is expressed in a real programming language, it can be unit tested — something that is difficult or impossible with YAML or XML alone

Atomist’s Johnson also pointed out that code written in modern languages benefits from IDE tooling — syntax highlighting, autocomplete, refactoring support, and static analysis — advantages that flat configuration files cannot offer. Modern languages are also inherently more modular and reusable, making it easier to share and maintain configurations at scale.

Practical Takeaways for DevOps Teams

Whether a team adopts JCasC’s YAML-based approach or a full code-first tool like Pulumi, the underlying principle is the same: Jenkins and infrastructure configuration should be managed with the same discipline as application code. For most Jenkins shops, JCasC offers a practical, low-friction entry point:

• Start by exporting your existing Jenkins configuration to a YAML file using the JCasC plugin
• Commit that file to a Git repository and establish a pull-request review workflow for future changes
• Use the same YAML file to spin up staging or test Jenkins instances for validation before applying changes to production
• As complexity grows, evaluate whether a full programming-language approach (Pulumi, Atomist, or Groovy-based Jenkinsfile pipelines) better fits your team’s needs

The DevOps community’s direction is clear: configuration is too important to manage manually. Tools like JCasC lower the barrier to adopting this discipline without requiring teams to overhaul their existing Jenkins investments.

The Mainframe Skills Gap Is Blocking DevOps Adoption

Despite decades of predictions to the contrary, the mainframe remains central to enterprise computing. A study cited by Forrester at the time of this report found that 64 percent of enterprises planned to run more than half of their critical application workloads on the mainframe. Yet only 37 percent reported being able to keep pace with the demand for skilled mainframe professionals.

That gap between mainframe reliance and mainframe expertise is a significant barrier to modernization. As workloads grow—driven by analytics, blockchain integrations, and increased mobile traffic—enterprises face pressure to accelerate mainframe application delivery using the same Agile and DevOps practices already standard on distributed and cloud platforms.

Compuware Updates zAdviser with AI and Real-Time Metrics

To address this challenge, Compuware announced updates to its zAdviser platform, a solution designed to help mainframe development leaders track, measure, and improve development velocity, quality, and efficiency. zAdviser applies artificial intelligence and machine learning to surface connections between individual developer behaviors and key performance indicators (KPIs), and to identify DevOps trends and patterns across the organization.

The updated release introduced several notable capabilities:

• Improved dashboard interface built on Elastic’s Elastic Cloud Service, providing a more accessible and unified view of mainframe DevOps data.
• Advanced behavioral and operational metrics to give teams deeper visibility into how developers interact with their toolchains.
• Near real-time data streaming, enabling faster detection of issues and quicker response cycles.
• Expanded AI and algorithmic correlation, helping teams identify whether high defect rates follow specific code changes and whether developers are making effective use of their DevOps tooling.

The practical outcome is that engineering managers can make data-driven decisions about training, tool adoption, and process improvement—rather than relying on anecdotal evidence or delayed retrospective reviews.

“Enterprises that have put off their mainframe modernization efforts must move quickly to bring their DevOps practices on the platform up to par if they want to stay competitive in a marketplace where continuous digital innovation has become table stakes. Rich, fact-based insight into their current state—and into whatever might be impeding them from achieving their desired state—is essential for accelerated adoption of mainframe DevOps.”

— Daniel Howard, Senior Researcher, Bloor Research

Partnership with CollabNet VersionOne: Value Stream Management Comes to the Mainframe

Alongside the zAdviser updates, Compuware announced a new partnership with CollabNet VersionOne to extend enterprise DevOps automation to mainframe environments using a Value Stream Management (VSM) approach.

The integration connects two complementary tools:

• Compuware ISPW — a DevOps-enabled source code management solution purpose-built for mainframe environments, handling version control, build automation, and deployment pipelines on z/OS.
• CollabNet VersionOne Continuum — an enterprise pipeline orchestration and value stream management platform designed to track, automate, and coordinate software delivery workflows across heterogeneous environments.

By connecting ISPW’s mainframe source control capabilities with Continuum’s orchestration layer, enterprises gain end-to-end visibility into mainframe software value streams alongside their distributed system pipelines. This helps break down the historical silo between mainframe and non-mainframe development, moving away from waterfall-bound delivery cycles toward iterative, Agile-aligned practices.

“As large enterprises digitally transform to compete in today’s fast-moving markets, the smart ones are aggressively transforming their mainframes away from siloed, waterfall-bound development, leveraging the Agile and DevOps best practices they’ve brought to their other platforms. This announced partnership combines Compuware’s modern take on mainframe tooling with the cutting-edge enterprise value stream management from CollabNet VersionOne.”

— Jason Bloomberg, President, Intellyx

Why Mainframe DevOps Matters

For organizations running core banking, insurance processing, retail transaction systems, or government workloads on z/OS, the mainframe is not a legacy curiosity—it is the production system of record. Yet many of these organizations struggle to apply the same CI/CD, automated testing, and pipeline tooling that their distributed platform teams take for granted.

The combination of AI-driven observability (via zAdviser) and value stream orchestration (via the CollabNet VersionOne integration) represents a practical path forward: make the mainframe a first-class citizen in the enterprise DevOps toolchain, rather than treating it as an exception that requires entirely separate governance and delivery processes.

As Forrester noted at the time, customer-obsessed enterprises need to modernize application delivery across all platforms—including the mainframe—to remove roadblocks to innovation and keep pace with digital transformation demands.

Key Takeaways

• The mainframe remains critical infrastructure for a majority of large enterprises, but the skills gap threatens their ability to modernize delivery.
• Compuware’s updated zAdviser platform uses AI and ML to surface actionable DevOps metrics specific to mainframe development teams.
• The Compuware–CollabNet VersionOne partnership integrates ISPW with Continuum to bring Value Stream Management to mainframe software pipelines.
• VSM on the mainframe allows organizations to achieve end-to-end pipeline visibility across both mainframe and distributed environments.
• Enterprises delaying mainframe DevOps modernization risk falling behind competitors who are already applying Agile practices across all platforms.

Many practitioners treat DevOps and Agile as competing approaches, but they are more accurately understood as complementary stages on the same spectrum. Agile provides the iterative structure; DevOps provides the operational and tooling layer that automates and sustains that structure at scale. Together, they have become the primary drivers of business automation across industries.

Drawing the Connection Between DevOps and Agile

At its core, DevOps is a development philosophy that seeks to unite product development, testing, and deployment into a single, streamlined workflow. The goal is faster, more reliable delivery of software and services — with fewer handoff delays and less siloed decision-making.

Agile laid the groundwork for this model. As teams adopted Agile practices — sprint planning, daily standups, retrospectives, and incremental releases — they naturally began identifying bottlenecks that automation could address. Manual testing, manual deployments, and manual environment provisioning became obvious targets. DevOps emerged as the framework for automating those steps while maintaining the cross-functional collaboration that Agile encourages.

A practical example: in an Agile software team, each increment of code is tested before it moves to the next stage. DevOps extends this practice by introducing continuous integration (CI) pipelines that automatically run tests every time code is committed. All stakeholders — developers, testers, operations engineers — can see results in real time, catch defects early, and iterate faster.

How Agile and DevOps Drive Business Automation

The combined influence of Agile and DevOps has accelerated automation across three key dimensions: production speed, customer satisfaction, and scalability.

Shortening Production Times

One of the clearest benefits of business automation is reduced cycle time — the interval between identifying a requirement and delivering a working solution. Agile contributes by decomposing complex workflows into discrete, automatable steps. Each step can be handed off to an automated system — a build server, a test runner, a deployment pipeline — without requiring human intervention at every stage.

DevOps complements this by giving operations teams visibility into automated processes through monitoring, logging, and alerting. When an automated stage fails or degrades, the team is notified immediately and can respond before the issue compounds. The net effect is shorter delivery cycles and fewer production incidents.

Improving Customer Satisfaction

Customer expectations evolve rapidly, and businesses that cannot adapt quickly risk losing ground. Automation — guided by Agile and DevOps principles — enables teams to ship updates, fix defects, and respond to feedback on a much shorter timescale than traditional waterfall approaches allow.

Agile’s iterative delivery model means customers receive working increments of a product early and often, rather than waiting for a single large release. DevOps ensures that each increment is tested and deployed consistently, reducing the risk of regressions that erode user trust. Because both methodologies emphasize collaboration across roles — product, engineering, QA, and operations — the end product reflects a broader set of quality and usability inputs.

Building Products at a Larger Scale

Scalability is a prerequisite for automation, and both Agile and DevOps are designed with growth in mind. Agile gives teams a repeatable, measurable process that can be applied to progressively larger and more complex projects. DevOps provides the tooling and cultural practices — infrastructure as code, container orchestration, automated provisioning — that allow teams to scale without proportionally increasing headcount or operational risk.

This combination allows businesses to increase output, enter new markets, and respond to demand spikes without rebuilding their delivery process from scratch each time. Automation is not a one-time investment; it is an ongoing capability that compounds in value as the scale of operations grows.

Key Takeaways

• Agile and DevOps are complementary, not competing. Agile provides the iterative structure; DevOps automates and sustains it.
• Automation reduces human error and shortens cycle times when grounded in the incremental, feedback-driven approach that Agile and DevOps share.
• Continuous integration and continuous delivery (CI/CD) are the most visible technical expressions of this Agile-to-DevOps continuum.
• Customer satisfaction improves when teams can release smaller, higher-quality increments more frequently.
• Scalability requires a repeatable process. Agile and DevOps together provide the framework that makes scaling automation practical.

For engineering teams evaluating where automation can reduce friction, auditing the handoff points between Agile sprints and operational deployment is a practical starting point. Those handoffs — build, test, release, monitor — are where DevOps automation delivers the most immediate and measurable value.

Gartner coined the term AIOps to describe AI applied to IT operations (ITOps). The same principles extend naturally into DevOps pipelines. Below we examine the most pressing pain points in DevOps today and eight concrete ways AI can address them.

Common Pain Points in DevOps Today

Before exploring AI’s role, it helps to understand the problems it is meant to solve:

• Human error: Manual testing and deployment steps introduce mistakes that are difficult to reproduce and fix. When development is outsourced or siloed, coordination gaps between dev and ops teams compound the problem.
• Environment inconsistency: Code that works perfectly in a development environment can break when promoted to staging or production because each environment carries different configurations, libraries, or infrastructure settings.
• Outdated change management: Many organizations have formal change management processes designed for slower release cadences. In a continuous-delivery world these processes become bottlenecks — reviews and approvals that once took days cannot keep pace with multiple daily deployments.
• Insufficient monitoring: Monitoring only infrastructure metrics is no longer enough. Application performance, business KPIs, log analysis, and distributed tracing all need to be tracked simultaneously, which quickly exceeds the bandwidth of even experienced SRE teams.

1. Better Data Access

DevOps pipelines generate enormous volumes of logs, metrics, traces, and events from dozens of tools. In practice, engineers tend to focus on outliers and anomalies rather than reviewing the full dataset — which means subtle patterns are routinely missed.

AI systems can aggregate data from disparate sources — CI/CD platforms, APM tools, infrastructure monitors, security scanners — and normalize it into a coherent, queryable dataset. Organized, centralized data is the foundation for every other AI-driven capability: predictive analytics, root cause analysis, and intelligent alerting all depend on having clean, accessible data in the first place.

2. Superior Implementation Efficiency

Most DevOps environments today operate on rules defined and maintained by humans: threshold-based alerts, manually tuned deployment gates, and hand-crafted runbooks. These rules degrade over time as systems evolve and rarely keep up with the pace of change.

AI can shift DevOps from a static, rules-based model toward self-governing systems that continuously learn from operational data and adjust their own parameters. Instead of an engineer deciding that CPU utilization above 80% triggers a scale-out event, a machine learning model can learn the relationship between CPU, memory, request latency, and downstream impact — and issue more nuanced, accurate recommendations as a result.

3. Root Cause Analysis

When an incident occurs under time pressure, engineers naturally gravitate toward the fastest fix rather than the deepest investigation. A workaround that restores service is understandably preferred over a multi-hour forensic analysis — but it leaves the underlying cause intact and free to cause future incidents.

AI-driven root cause analysis (RCA) tools correlate signals across the entire stack — application logs, infrastructure metrics, deployment history, network events — to surface likely root causes automatically. By mapping relationships between events, an AI system can trace a customer-facing error back to a misconfigured database connection pool updated three releases ago, a chain of causality that would take a human team hours to reconstruct manually.

4. Intelligent Automation

DevOps already leans heavily on automation, but today’s automation is largely scripted and deterministic — it handles tasks that follow well-understood, predictable paths. Many real-world tasks do not fit that mold: they require contextual judgment, pattern recognition, or handling of edge cases that a static script cannot anticipate.

A well-trained AI model can extend the scope of automation to cover more complex, variable scenarios. Examples include automatically selecting the safest deployment strategy based on current system load, rolling back a release when anomaly scores exceed a threshold, or triaging support tickets by correlating user-reported symptoms with known infrastructure events. Offloading these judgment-intensive tasks to AI frees engineers to work on problems that genuinely require human creativity.

5. Reducing Operational Complexity

A typical DevOps toolchain spans source control, CI runners, artifact registries, container orchestrators, monitoring platforms, log aggregators, and security scanners. Each tool produces its own alerts and dashboards, forcing engineers to context-switch constantly and manually correlate signals from multiple interfaces.

AI platforms can present a unified operational view by ingesting data from all tools, correlating related events, and surfacing only the information that is actionable. Alert prioritization, anomaly scoring, and automatic event grouping reduce the cognitive overhead on the team and make it far easier to identify what actually needs attention at any given moment.

6. Predicting Failures Before They Happen

Reactive incident response — waiting for a page, then scrambling to fix it — is expensive and stressful. Predictive failure analysis shifts the model to proactive: identifying the early warning signs of a failure before it affects users.

Machine learning models trained on historical failure data can recognize subtle pre-failure patterns in metrics and logs — gradual memory growth that precedes an out-of-memory crash, a creeping increase in database query latency that signals index fragmentation, or a rising error rate on a downstream dependency. By detecting these patterns early and alerting on them, AI gives teams time to intervene before the failure propagates through the system and delays a release cycle.

7. Continuous Metric Optimization

Production systems do not behave uniformly throughout the day, week, or release cycle. A configuration that delivers optimal performance during off-peak hours may be inefficient at peak load, and vice versa.

Adaptive machine learning systems can monitor a target metric — uptime, latency, throughput, cost — in real time and recommend or automatically apply configuration adjustments to keep that metric within its optimal range. This could mean dynamically tuning thread pool sizes, adjusting cache TTLs, or modifying autoscaling policies based on learned traffic patterns rather than static thresholds set at deployment time.

8. Intelligent Alert Management

Alert fatigue is one of the most widely reported problems in DevOps and SRE. When monitoring systems generate hundreds or thousands of alerts per day, many of them redundant or low-priority, on-call engineers inevitably start ignoring them — including the ones that matter.

AI can address this at multiple levels:

• Deduplication and grouping: Related alerts from different tools are clustered under a single incident, reducing noise immediately.
• Priority scoring: Alerts are ranked by likely business impact so engineers address the most critical issues first.
• Classification: Models trained on historical alert data can distinguish true positives from false positives, suppressing known-benign alerts automatically over time.
• Contextual enrichment: Each alert surfaces relevant context — recent deployments, correlated metrics, historical similar incidents — so engineers spend less time gathering information and more time fixing the problem.

Conclusion

The common thread running through all eight areas is data. AI’s ability to ingest, correlate, and reason over large, heterogeneous datasets is precisely what makes it valuable in DevOps environments that generate more operational data than any team can manually process. Better data access is the prerequisite; everything else — predictions, automation, optimization, alert management — follows from it.

None of this replaces the judgment and creativity of experienced engineers. Rather, AI handles the data-intensive, repetitive, and pattern-recognition tasks at a scale and speed that humans cannot match, freeing engineering teams to focus on the complex, context-dependent decisions where human expertise genuinely matters. For DevOps teams looking to scale their practices without scaling their headcount proportionally, AI is becoming a practical and necessary part of the toolkit.

Organisations embarking on a DevOps journey quickly discover that transformation is hard and almost always takes longer than anyone expects. It spans multiple geographies, technologies, cultural backgrounds, and skill sets. The three-step framework below is not a rigid, sequential checklist. It is an agile approach — sometimes sequential, sometimes concurrent — that must always be aligned to the culture and capacity of your organisation.

Step 1 – Expand Agile Practices Beyond IT

A common misconception is that DevOps is solely the mandate of the IT department, while C-level executives and the broader business have little interest in — or understanding of — how software is delivered. In reality, software has become central to almost every business strategy. Mobile apps, web platforms, and internal tooling are now revenue-generating or operationally critical assets. That reality has brought senior leadership much closer to software delivery than it was even a decade ago.

The shift toward agile and DevOps practices resembles the lean manufacturing movement of the 1980s and 1990s, which demonstrated that quality and speed improve when waste is removed from the entire value chain — not just one department. The same principle applies here.

For DevOps to succeed, every part of the organisation must participate:

• C-level leadership must champion the transformation, allocate resources, and remove organisational blockers.
• Product and marketing teams need to feed customer insights directly into the delivery pipeline.
• Customer support and operations teams close the feedback loop between production systems and development priorities.
• Finance and procurement must understand iterative investment models rather than big-bang project budgets.

Breaking down silos is not a technical problem — it is an organisational one. Sustainable DevOps transformation requires full leadership support and a shared understanding that software delivery is a business-wide concern.

Step 2 – Shift Left Within a Continuous Culture

Shifting left is a testing philosophy that moves quality activities earlier in the software development lifecycle (SDLC), rather than relying on a dedicated test phase at the end. The earlier a defect is found, the cheaper and faster it is to fix. Discovering a bug in development costs far less — in time, money, and customer impact — than discovering it in production.

In a DevOps context, shifting left typically means:

• Automated unit and integration tests run on every code commit, not just at release gates.
• Security scanning (DevSecOps) is embedded in CI pipelines rather than performed as a final audit.
• Performance testing begins in development environments, not only in staging.
• Customer feedback is gathered continuously — through feature flags, beta programmes, and telemetry — rather than after a full product launch.

A continuous culture extends this idea beyond testing. It applies lean thinking to every workflow: continuously identify and eliminate waste, continuously improve processes, and continuously deliver value to the customer in small, verifiable increments. Practices such as continuous integration (CI), continuous delivery (CD), and continuous monitoring operationalise this culture at the tooling level.

Shifting left reduces long back-end dependencies, shortens feedback cycles, and improves overall quality — all of which accelerate the pace at which teams can safely deliver software.

Step 3 – Build a Fail-Fast Culture, Not a Fail-Silently One

In many traditional organisations, the default response to failure is to mask it, deflect blame, or quietly hope the problem disappears. This fail-silently culture is toxic to DevOps transformation. It suppresses the feedback signals that teams need to learn and improve, and it creates hidden technical debt and operational risk.

High-performing engineering organisations replace this with a fail-fast philosophy: surface failures quickly, learn from them openly, and use that knowledge to improve. This is not about celebrating recklessness; it is about creating psychological safety and feedback loops that make the organisation more resilient over time.

Four complementary failure modes support this culture:

• Fail Early — Detect problems as close to their source as possible. Automated tests, linting, and pre-commit hooks catch issues before they propagate downstream.
• Fail Fast — When a failure does occur, surface it immediately. Fast feedback loops — tight CI pipelines, real-time alerting, feature flags that can be toggled off instantly — minimise the blast radius.
• Fail Often — Encourage experimentation. Teams that run more small experiments generate more learning. A/B testing, canary releases, and spike work are all practical mechanisms.
• Fail Better — Conduct blameless post-mortems after incidents. Document what happened, what was learned, and what systemic changes will prevent recurrence. Over time, this compounds into significantly better systems and practices.

Putting the Three Steps Together

Successful DevOps transformation is not achieved by reorganising a development team or deploying a new CI/CD tool. It requires the entire organisation to adopt a mindset of continual improvement: testing ideas early, empowering customers with faster and more reliable software, and learning from failure rather than hiding it.

The three steps — expanding Agile beyond IT, shifting left within a continuous culture, and empowering a fail-fast mindset — are mutually reinforcing. Progress on one accelerates progress on the others. Start where your organisation has the most capacity for change, iterate, and remain aligned to the culture you are actually working with rather than the one you wish you had.

Transformation is hard. It takes longer than anyone wants. But organisations that commit to these principles consistently find that the investment pays off in faster delivery, higher quality, and greater organisational resilience.

The instinct in some quarters is to ditch ITSM entirely, or to let the ITSM team operate in a separate orbit from DevOps practitioners. According to several practitioners and analysts, that would be a serious mistake.

“DevOps aims to deliver high-quality software to the business faster and in shorter cycles. However, it still does not eliminate the need for controls.”

Krishna Mohan Reddy, VP and Deputy Global Head of Cognitive Business Operations, Tata Consultancy Services

ITSM and DevOps are often described as the yin and yang of modern IT operations—contrasting viewpoints that, when integrated thoughtfully into a single operating model, can be highly complementary.

“Maintaining the proper balance between ITSM and DevOps helps organizations scale, grow, and become more organized. Both in harmony will increase efficiency and reduce the blame-game within the organization.”

Sachin Agarwal, DevOps Engineer and Solution Architect, Mantra Labs

As organizations work toward that harmony, here are three key pitfalls to avoid.

Mistake 1: Letting Tribal Preconceptions Block Progress

Both camps carry baggage. DevOps and Agile practitioners often automatically discount input from colleagues with ITIL certifications, viewing process-heavy frameworks as the enemy of speed. Meanwhile, traditional operations and development teams can view DevOps practitioners as undisciplined “cowboys” who ignore governance at their peril.

“You need to compromise. A lot of the new, young practitioners in DevOps and Agile will pretty much automatically discount opinions coming from people who have got ITIL certifications. And vice versa—a lot of traditional operations and development teams will look at the people in DevOps and Agile and think they’re all cowboys. But they all have something to learn from each other.”

Andi Mann, Chief Technology Advocate, Splunk

For DevOps practitioners specifically, it is worth recognizing that ITSM controls—service requests, change management, structured incident and problem tracking—do not inherently slow teams down. Done well, they provide exactly the visibility and structure that enable sustainable speed.

“In IT, just like in science, if it isn’t seen, measured, and reproducible, it doesn’t really count. ITSM is actually the perfect complement to DevOps because it aids in the visibility, measurement and reproducibility of key DevOps processes.”

Troy Vetter, COO, Coda Global

The practical takeaway: create cross-functional forums where ITSM and DevOps practitioners design processes together rather than having either side impose its assumptions on the other.

Mistake 2: Ignoring the Change Management Problem

If there is one single flashpoint where DevOps and ITSM consistently clash, it is change management. Traditional Change Advisory Boards (CABs) were designed for a world of infrequent, high-risk releases evaluated in scheduled weekly or bi-weekly meetings. Continuous delivery pipelines can push dozens—or hundreds—of changes per day. Those two realities are fundamentally incompatible without deliberate redesign.

“Change management has often been where DevOps and ITSM collide. The stereotypical Change Advisory Board must radically revise its approach to be in sync with the enormous amount of change that DevOps can produce in a day.”

Roy Atkinson, Service Management Analyst, HDI

The good news is that the ITSM community has been actively rethinking change management for CI/CD environments. The emerging model shifts change management from a gate at the end of a delivery pipeline to a continuous, embedded practice woven throughout the development lifecycle.

“There is some excellent recent thinking in the ITSM world about how change management can serve its intended purpose without being a roadblock—by acting as an enabler of change and being involved all along the way, rather than a bolt-on quality check at the end of the line before the production environment.”

Roy Atkinson, HDI

Practical approaches organizations are adopting include pre-approving standard changes that have been tested in the pipeline, automating change record creation from CI/CD tooling, and restructuring the CAB into a lighter, asynchronous review process for high-risk changes only.

Mistake 3: Maintaining Separate, Disconnected Toolchains

Even when both ITSM and DevOps teams are willing to collaborate, organizational goodwill can be undermined by incompatible tooling. When developers track work in one system and the ITSM team tracks incidents and requests in a completely separate platform, handoffs become manual, error-prone, and slow.

“You might have a tool that developers use for tracking bugs or product backlog and then there’s a completely separate IT service management tool. So what you end up doing is forcing developers to use some process that’s outside of their norm in order to address issues.”

Donna Knapp, Curriculum Development Manager, ITSM Academy; author, DevOps Institute’s ITSM for DevOps course

A significant part of DevOps resistance to ITSM has historically been driven by monolithic, manually-operated ticketing systems that added friction without adding value. Modern ITSM tooling has evolved considerably, but only delivers value if it is properly integrated with the DevOps pipeline.

“Self-service requests, automation flows and IT orchestration are now our front door to actions, and IT service management can and should be happening in the background, automagically created, maintained and measured by our DevOps tools.”

Troy Vetter, COO, Coda Global

Bridging the toolchain gap typically means one of three approaches: integrating existing tools via APIs so that events in the CI/CD pipeline automatically create or update ITSM records; adopting a platform that spans both use cases; or establishing a shared data layer that both toolchains write to and read from. The right choice depends on existing investment and team size, but any of the three is preferable to maintaining two siloed systems.

Bringing It Together

DevOps and ITSM emerged from different problems, but they share the same ultimate goal: reliable, high-quality IT services delivered as fast as the business needs them. Organizations that treat integration as a cultural and process challenge—not just a tooling decision—are far more likely to get both disciplines working in concert.

• Encourage cross-functional empathy. Create shared forums, rotating roles, or joint post-incident reviews so both camps understand each other’s constraints.
• Redesign change management from the inside out. Embed change controls into the pipeline rather than appending them at the end.
• Invest in toolchain integration. Automate the handoffs between development, operations, and service management systems to eliminate manual overhead.

The collision between DevOps and ITSM is real, but it is not inevitable. With deliberate design and a willingness to compromise on both sides, the two can operate as a unified, high-performing system.

Original reporting by devops.com. Quotes and attribution preserved from the source article.

Why Silos Are the Enemy of Speed

Customer expectations around delivery speed have risen sharply. Markets are more dynamic, global competition is intensifying, and the gap between organisations that ship quickly and those that do not is widening. DevOps addresses this directly by replacing rigid, department-based structures with cross-functional, outcome-oriented teams.

The core promise of DevOps is straightforward: combine agile methods, automated processes, and collaborative culture to shorten development cycles, improve product quality, and reduce time to market. But the tooling is only part of the story. The harder — and more consequential — part is organisational change.

DevOps Is a Cultural Shift, Not Just a Toolchain

Adopting DevOps requires no less than a fundamental rethink of how teams are structured, how decisions are made, and how work flows through an organisation. Specifically, it demands:

• Cross-functional team formation: Teams should be built around business processes and product outcomes, not around traditional departments such as Dev, QA, and Ops in isolation.
• Autonomous decision-making: Competence teams — composed of developers, UX specialists, and product managers — need real authority over technical and operational choices, including budget and resource decisions within their scope.
• Tolerance for iteration: Leadership must accept that continuous improvement is the goal, not a one-time delivery. This requires both courage and a clear vision of the end state.

Without genuine autonomy, cross-functional teams simply become another layer of bureaucracy. The structural change must be accompanied by a shift in management culture.

The “Always Beta” Mindset

One useful framing for DevOps culture is the mantra “Always Beta”. This does not mean shipping broken software or treating production as a permanent construction site. It means treating development itself as a continuous process — one that allows for incremental improvements while the system is live.

Retail and e-commerce companies illustrate this well. Organisations operating large online shops work with real-time KPIs and understand that even small changes to a page layout can have a measurable impact on conversion. Practices like A/B testing — running two variants simultaneously to determine which performs better — are a natural expression of the Always Beta mindset. They treat the production environment as a learning environment, not a static destination.

Where DevOps Delivers Quickly: Front-End and Cloud-Native Applications

DevOps shows the clearest gains in areas where teams can work in short cycles with fast feedback loops. Examples include:

• Microservices architectures: Small, independently deployable services allow teams to ship and test changes without coordinating a full system release.
• UI and front-end applications: Modern tooling allows interfaces to be assembled and validated rapidly. User interactions can be simulated early, and usability problems identified before they reach production.
• Cloud-native deployments: Platforms such as Cloud Foundry enable automated build, test, and deploy pipelines that reduce manual handoffs between teams.

In these contexts, replacing a traditional waterfall delivery with small DevOps teams and automated test procedures can dramatically compress development timelines.

Where DevOps Gets Hard: Monolithic ERP Core Systems

DevOps encounters real constraints when applied to mature, heavily customised ERP landscapes. The root cause is architectural: ERP systems like SAP are built on a stable, monolithic core that has often been modified over many years to fit specific business requirements.

In this environment, a change that benefits one department can trigger unexpected side effects in another. The system is interconnected in ways that are not always well-documented, and the test scenarios needed to validate a change safely can be expensive and time-consuming to build. This makes the fast feedback cycles that DevOps depends on difficult to achieve at the core level.

The practical implication: when operating within a mature SAP landscape, DevOps teams must invest heavily in test automation and clearly defined acceptance criteria before they can iterate safely. Trust in automated test coverage is non-negotiable.

SAP S/4HANA and the Greenfield Opportunity

SAP’s S/4HANA platform offers a potential path forward. Organisations willing to undertake a greenfield migration — cleaning up years of customisation and aligning more closely with SAP standard processes — can emerge with a system architecture that is more compatible with DevOps practices.

The key shift is that S/4HANA is oriented around business processes rather than organisational departments. This aligns naturally with how DevOps teams are structured. When the underlying system architecture and the team structure share the same logic, agile development at the core becomes achievable rather than theoretical.

The trade-off is significant: a greenfield approach requires substantial upfront investment and organisational discipline. But for companies prepared to make that commitment, it removes one of the principal blockers to applying DevOps practices across the full application landscape.

Key Takeaways

• DevOps is as much a cultural transformation as a technical one. Structural and decision-making changes must accompany tooling adoption.
• Cross-functional teams built around business outcomes — not departments — are the foundation of effective DevOps.
• The Always Beta mindset treats production as a continuous improvement environment, not a static endpoint.
• Front-end, microservices, and cloud-native applications are the easiest places to start and demonstrate value quickly.
• Mature ERP core systems present genuine constraints. Invest in test automation and clearly defined outcomes before iterating at that layer.
• Platform modernisation (such as SAP S/4HANA migration) can unlock DevOps practices in areas where legacy architecture previously made them impractical.

1. Make Everyone Accountable to Shared Goals

Steve Burton, CD and DevOps Evangelist, Harness

Assigning people a “DevOps Engineer” title does not automatically shorten release cycles. Real progress comes from making every team member aware of the business objectives that their work supports and giving them genuine accountability for shared outcomes.

• Developers should be responsible for how their code behaves in production — not just in a test environment.
• Operations engineers should be freed from manually overseeing every release so they can focus on higher-value work.
• Compensation and incentives for both groups should be aligned to business outcomes, not individual task completion.

As Burton puts it, hiring a hundred people with “DevOps Engineer” in their title without shared goals and accountability is like putting a hundred tires on a car and expecting it to go faster. The structure must change, not just the org chart.

2. Cut the Jargon

Fin Goulding, International CIO, Aviva

Technical language creates invisible walls between IT teams and the business stakeholders whose support you need to scale DevOps. Goulding recommends leading conversations with business outcomes rather than acronyms. When pitching DevOps expansion to senior leadership or seeking additional investment, explain what will be delivered faster and more reliably — not the mechanics of CI/CD pipelines.

Goulding prefers the term Flow Teams over labels like “DevOps 2.0,” arguing that holistic, cross-functional teams focused on flow are the model that will define the most successful workplaces going forward. Whatever terminology you choose, prioritize clarity over technical precision when speaking to a mixed audience.

3. Measure Wisely and Choose the Middle Path

Mirco Hering, APAC DevOps and Agile Lead, Accenture

Before you can demonstrate progress, you need to define what success looks like and how it will be measured. Hering warns against two common traps: chasing the promises of over-eager vendors, and losing sight of practical, incremental improvement.

His “middle path” guidance:

• Do not look so far into the future that short-term wins become invisible.
• Do not be so short-sighted that you fail to build toward a longer transformation.
• Challenge the status quo, but do not demand ideological purity at the expense of pragmatic progress.
• Use technology to support your transformation, but do not place all your trust in any single tool or platform.

4. Move from a Project to a Product Mindset

Carmen DeArdo, DevOps Leader, Nationwide

The goal of a mature DevOps practice is to reduce lead time and deliver software more frequently so the business can respond quickly to change. That goal cannot be achieved when IT operates as a cost center that executes discrete projects on behalf of the business.

DeArdo advocates for a product-centric model in which IT is a full partner — not a vendor — working alongside the business to accelerate the flow of value across end-to-end product streams. This shift changes how teams are funded, how they are organized, and how their success is measured. Projects have end dates; products have ongoing owners who are continuously responsible for outcomes.

5. Balance Soft and Technical Skills on DevOps Teams

Robert Reeves, CTO, Datical

DevOps leaders need to build teams that combine human and technical capabilities. Neither alone is sufficient.

Soft Skills

• Communication: DevOps engineers accumulate knowledge that must be documented and shared effectively. Internal wikis, issue trackers, and informal knowledge-sharing sessions help ensure insights are not siloed with individuals.
• Collaboration: Effective collaboration in a DevOps context often involves tooling — for example, using chat platforms to surface alerts and outages, and running structured retrospectives to uncover process failures.
• Customer-first mindset: Even in a non-customer-facing role, DevOps engineers serve internal customers: developers, QA, project management, and business leadership. Empathy, transparency, and the ability to prioritize competing requests are essential.

Technical Skills

• System administration and engineering: A working knowledge of Linux and Windows server administration, networking fundamentals, and common infrastructure layers is foundational for DevOps engineers who need to diagnose and resolve production issues.
• Scripting and automation: Languages such as Python, Ruby, Bash, and Shell enable engineers to automate repetitive tasks, reduce human error, and free up time for higher-value work.
• Configuration management: Tools in this category allow teams to manage many servers and environments consistently — handling kernel updates, network settings, SSH key management, and tool provisioning across data centers and cloud providers.
• Identity and access governance: Controlling who can access which systems and data is both a security requirement and a productivity enabler. Familiarity with SSH keys, LDAP, and remote desktop protocols is part of a well-rounded DevOps skill set.

6. Don’t Let Alignment Goals Delay DevOps Progress

Ben Grinnell, Managing Director, North Highland

Waiting for full senior-leadership alignment before starting your DevOps implementation is a common and costly mistake. Full consensus at the executive level rarely arrives before it is too late to matter.

Grinnell recommends starting on the ground and building alignment in parallel by over-communicating early wins. The examples you share with leadership should be:

1. Easy for senior leaders to understand without a technical background.
2. Significant enough to register as meaningful progress.
3. Relevant enough that leaders can visualize the same pattern applied to a much larger part of the business.

Define a clear direction — a North Star — but avoid getting locked in prolonged debates about a precise destination and timeline. Getting the organization moving with shared direction is more valuable than a perfect plan that never launches.

7. Tap Into the Energy of the Organization

Jonathan Smart, Head of Ways of Working, Barclays

Smart introduces the concept of Aiki — using the organization’s existing energy and momentum to drive the transformation rather than fighting against inertia. In practice, this means:

• Identifying and starting with natural champions — people who are already enthusiastic about better ways of working.
• Rewriting internal standards and processes to embed DevOps principles rather than treating them as exceptions.
• Treating internal audits as allies rather than obstacles, since a well-structured audit process can reinforce accountability and continuous improvement.

8. Beware of Isolated Innovation Teams

Anders Wallgren, CTO, Electric Cloud

Creating a dedicated “innovation team” to pilot DevOps practices can backfire. Isolated groups often become disconnected from the rest of the organization and produce limited transferable value. Wallgren argues that the people most willing and able to adapt to change are the ones who create transformation others can follow — and they are spread across the organization, not concentrated in a single team.

His recommendations for DevOps leaders:

1. Design your organization so that product, development, and IT operations teams share ownership of the software delivery pipeline and treat it as a product.
2. Create an environment where teams can easily collect data on delivery performance metrics and KPIs, capture workflow bottlenecks, and focus on the value and quality of what they ship.
3. Continuously require teams to scrutinize their value streams and set short-term goals to address the biggest bottlenecks first.
4. Build a culture across the entire organization anchored in one mindset: continuously disrupting your own processes before a competitor does it for you.

9. Remember That “Continuous” Is the Keyword

Eran Kinsbruner, Director and Lead Software Evangelist, Perfecto

DevOps, at its core, means having a fully automated workflow for delivering software — and that cannot happen without mature automation. Kinsbruner emphasizes the importance of the three Cs working in harmony:

• Continuous Integration (CI): Developers integrate code changes frequently, with each change verified by an automated build and test sequence.
• Continuous Testing (CT): Automated testing is not a gate at the end of a pipeline but a layer woven throughout it, validating quality at every stage.
• Continuous Delivery (CD): Every code change that passes CI and CT is in a deployable state and can be released to production reliably and repeatedly.

The key to success is a mature Continuous Testing practice that acts as the connective tissue between CI and CD — running automatically for every code change, every day. Without it, the pipeline stalls and the promise of fast, reliable delivery goes unmet.

Putting It All Together

These nine tips share a common thread: lasting DevOps transformation is a leadership and cultural challenge as much as a technical one. Shared accountability, clear communication, measured progress, product thinking, balanced skills, pragmatic momentum, organizational energy, inclusive change, and relentless automation all reinforce each other. Strong DevOps leaders address all of these dimensions simultaneously rather than treating any single one as the silver bullet.

Original insights sourced from the Enterprisers Project.

Speed Without Quality Is a Race to the Bottom

One of the most common mistakes organizations make when adopting DevOps is treating it purely as a velocity play. They invest in CI/CD pipelines, containerization, and automation—and then discover that shipping faster simply means shipping broken software faster. A Forrester study commissioned by Tricentis examined 94 quality metrics across four categories and found that for automation to deliver real value in a DevOps context, teams must track quality throughout every stage of development and deployment.

Clark Golestani, managing director of C Sensei Group, put it plainly: “Organizations adopt DevOps to accelerate the delivery of innovative software that creates positive user experiences. If you start accelerating delivery without also rethinking your approach to quality, you will end up rapidly delivering updates that drive your customers to competitors.”

The research also highlighted a distinction in how DevOps leaders approach measurement. Some focus on contextual metrics—which tie quality signals to business outcomes—while others rely on counting metrics, such as defect counts or test pass rates. Similarly, some teams measure user experience across an end-to-end journey, while others focus on application-specific interactions. Understanding which approach fits your organization’s maturity and risk profile is itself a leadership skill.

5 Practices That Define Effective DevOps Leaders

Whether you are establishing yourself as a DevOps leader or looking to sharpen your existing practice, these five disciplines are central to delivering quality at the pace DevOps demands.

1. Allocate Proper Testing Budgets and Continuously Upgrade Testing Skills

Testing is frequently underfunded relative to development, and that imbalance compounds as release frequency increases. DevOps leaders treat test engineering as a first-class investment—both in tooling and in people. This means budgeting for test infrastructure, allocating time for engineers to learn modern testing frameworks, and recognizing that test automation is skilled engineering work, not a checkbox activity.

2. Implement Continuous Testing to Support Continuous Delivery

Continuous testing means integrating automated tests at every stage of the pipeline—not just at the end before a release gate. When tests run continuously alongside development, teams get immediate feedback on regressions, integration failures, and performance degradation. This is what allows continuous delivery to be a reality rather than a goal. Without continuous testing, a CD pipeline is simply a fast path to production incidents.

3. Embed Testers Within Integrated Delivery Teams

The traditional model of a separate QA team that receives a build at the end of a sprint is incompatible with DevOps cadences. Effective DevOps leaders embed testers—or engineers with strong testing skills—directly into cross-functional delivery teams. When testers participate in sprint planning, story grooming, and design discussions, quality considerations surface early, before they become expensive defects.

4. Automate End-to-End Functional Testing

Unit and integration tests catch many problems, but they do not validate that a complete user journey works as intended. End-to-end functional tests simulate real user interactions across multiple services and interfaces, exposing issues that lower-level tests miss. Automating these tests—and running them as part of the pipeline—ensures that deployment velocity does not come at the cost of user-facing reliability.

5. Shift Testing Left in the Development Lifecycle

“Shift left” means moving testing activities earlier in the development process—ideally beginning at the requirements and design phase. When teams write testable requirements, define acceptance criteria before coding begins, and run tests in development environments rather than waiting for staging, defects are found when they are cheapest to fix. Shift-left testing also changes the culture: quality becomes everyone’s responsibility, not something that happens after the fact.

Understanding Business Risk Is Non-Negotiable

The Forrester research emphasized that successful DevOps leaders understand the business risks associated with both DevOps and Agile adoption. Accelerated delivery pipelines introduce new failure modes—automated deployments can propagate bad code to production faster than any manual process could. Leaders who understand this risk landscape can design appropriate quality gates, rollback strategies, feature flags, and monitoring approaches that mitigate exposure without strangling delivery speed.

Every automated software delivery carries the potential for a negative user experience. The difference between organizations that manage this risk and those that are caught off guard is usually the maturity of their testing practice and the business awareness of their technical leaders.

Expanding Your Skillset as a DevOps Practitioner

Beyond implementing these five practices, DevOps leaders should actively work to broaden their skills across the quality, security, and observability domains. Understanding how to instrument applications for monitoring, how to interpret production telemetry, and how to design systems that fail gracefully are all capabilities that distinguish effective DevOps leaders from those who simply manage pipelines. The goal is not just faster software—it is better software, delivered sustainably.

Partnership Overview

Agile Stacks announced its entry into the CloudBees Elevate Partner Program, a channel initiative designed to extend CloudBees’ enterprise DevOps capabilities through complementary technology and services partners. The partnership pairs CloudBees’ enterprise-grade continuous delivery platform — built on Jenkins — with Agile Stacks’ GitOps automation service, which is aimed at dramatically reducing the time and cost required to stand up production-ready DevOps environments in the cloud.

What Each Company Brings to the Table

CloudBees: Enterprise Jenkins and Continuous Delivery

CloudBees is built on top of Jenkins, one of the most widely used open-source automation servers in the DevOps ecosystem. CloudBees adds enterprise-critical capabilities on top of the upstream Jenkins project:

• Security and compliance controls for regulated industries
• Scalability to support large numbers of development teams and concurrent builds
• Centralized management of Jenkins masters across an organization
• Expert support backed by a dedicated customer success team

CloudBees also supports running Jenkins workloads on Kubernetes, enabling dynamic, containerized build agents that scale on demand — a critical requirement for organizations with variable CI/CD workloads.

Agile Stacks: GitOps Automation and DevOps Cloud Stacks

Agile Stacks describes its platform as a “non-opinionated” GitOps automation service — meaning it does not lock customers into a specific toolchain. Instead, it provides a framework for deploying full-function DevOps cloud stacks composed of pre-tested, integrated open-source tools. Key claims from the company include:

• Deployment of complete DevOps stacks within minutes, compared to typical enterprise rollout timelines that can stretch from six months to two years
• Application Templates that automatically create CI/CD pipelines binding development, test, and production environments to stacks
• A DevOps-first architecture delivered out of the box, reducing the custom integration work traditionally required

How the Integration Works

The combined offering targets enterprise teams that want to run CloudBees Jenkins at scale on Kubernetes without spending months on infrastructure setup. The integration works as follows:

1. An organization uses Agile Stacks Application Templates to provision a full DevOps cloud stack — including networking, storage, security, and tooling — on their chosen cloud provider.
2. CloudBees Jenkins is included within that stack, pre-configured with enterprise-grade settings rather than requiring manual setup.
3. Pipeline configuration is automated by Agile Stacks, linking source repositories, build environments, and deployment targets without requiring hand-crafted Jenkinsfiles from scratch.
4. Teams can scale builds horizontally across Kubernetes worker nodes, using the elastic compute capacity of their cloud provider.

Business Goals of the Partnership

Beyond the technical integration, the partnership involves joint go-to-market activities:

• Joint sales motions targeting enterprise accounts looking to accelerate DevOps adoption
• Co-marketing initiatives focused on educating organizations about GitOps practices and cloud resource management
• A shared emphasis on reducing operational expenditure by automating infrastructure provisioning and pipeline management

Industry Context: Why This Partnership Matters

By 2018, Kubernetes had become the dominant container orchestration platform, but running stateful enterprise tools like Jenkins reliably on Kubernetes remained a significant operational challenge for many teams. Separately, GitOps — the practice of using Git as the single source of truth for infrastructure and application state — was gaining traction as a way to apply software engineering discipline to infrastructure management.

Partnerships like this one reflected an emerging pattern: specialist automation vendors wrapping and extending core DevOps platforms (Jenkins, in this case) to lower the barrier of entry for enterprises that lacked the in-house expertise to build and maintain complex CI/CD infrastructure from scratch.

Quotes from Both Companies

“We empower enterprises in today’s global digital economy to innovate and adapt rapidly using our Agile Stacks automated agile software delivery service, which significantly streamlines the deployment and update management of the many tools they rely on. We are excited to partner with CloudBees in delivering enterprise Jenkins, the DevOps and continuous delivery solution of choice for many enterprises, with our service.”

— John Morada, Vice President of Global Business Development, Agile Stacks

“We pride ourselves on providing enterprise-grade continuous delivery functionality to DevOps teams and then complementing that with companies, such as Agile Stacks, to enable the success of non-opinionated enterprise-grade open source technologies. Working together, we are addressing our customers’ growing demand to run our platform on Kubernetes, while cost-effectively providing the security and compliance, flexibility, and scale capabilities they need to drive their businesses.”

— Aaron Morrison, Director of Worldwide Channel Sales, CloudBees

About Agile Stacks

Agile Stacks provides an all-in-one, non-opinionated GitOps automation service aimed at enterprises building cloud-native platforms. Its stacks incorporate pre-tested, integrated open-source tools that are ready to use from the moment they are deployed, targeting the performance, agility, and scalability requirements of modern digital businesses.

The Reality of Legacy in Most Organisations

Unless you are working in a greenfield startup, your organisation almost certainly runs legacy systems that represent significant capital investment and underpin core business processes. Transforming those systems carries substantial risk and cost — and the appetite to do so is rarely strong enough to justify the disruption.

Modern cloud-native applications built with containerised microservices are not a natural fit with legacy systems developed using older, inflexible technologies and hosted in on-premises environments. But bridging that gap is exactly what most development teams are asked to do.

High-scale technology companies such as Google, Amazon, and eBay continuously re-engineer their entire processing pipeline and invest heavily in keeping their systems current. However, most organisations operate at a very different scale and with a fraction of those budgets. The lessons from those engineering giants are worth studying, but they are solving a different problem. Not every organisation needs — or can afford — the same approach.

A common pattern that has emerged is for organisations to adopt DevOps selectively: applying it to customer-facing services where speed and agility deliver the most immediate business value, while leaving back-office and core processing systems largely untouched. The customer-facing DevOps layer can respond quickly to new promotions, competitive pricing changes, or product launches. But it will almost always need to call into those legacy systems to complete a transaction.

Greenfield vs. Brownfield Development

In software development, a greenfield project is one with no existing constraints — you design and build from scratch. A brownfield project, by contrast, requires you to build around or on top of what already exists. The term is borrowed from urban development, where new construction often takes place on land previously used for industry.

Most DevOps transformations take place in a brownfield context. Legacy components impose data definitions, business rules, and integration contracts on any new development. If a system is too risky or expensive to replace, it is typically the system that defines how the business actually holds and processes its most important data. Failing to understand that reality early leads to a painful integration phase later.

Adopting a Hybrid Approach

When one or more DevOps squads are tasked with delivering a service where a significant portion of the functionality is provided by existing legacy components, the first priority is to understand the constraints those legacy components impose.

This is harder than it sounds. Legacy systems are often retained precisely because nobody fully understands them. Knowledge is concentrated in a small, experienced support team. Documentation is typically incomplete, outdated, or both. Do not assume otherwise.

A realistic hybrid approach acknowledges these constraints and builds process around them. The following sections outline the key areas to address.

Produce an End-to-End Architecture

Before writing significant new code, map the integration points between the components your team controls and the legacy components you do not. Treat those integration points as third-party APIs — but with considerably more complexity than a typical external API. These are the systems the organisation was too afraid to touch. They will require deeper investigation and more careful handling.

A practical example illustrates the risk well. Suppose a registration process requires a date field. Your new service applies a straightforward business rule to that field. But what if the legacy system has been silently accepting a default placeholder date for years — because a contact centre team found it easier to enter a fixed value to avoid an obscure validation error? When your new service enforces the rule properly for the first time, you may discover thousands of existing customer records that do not conform to the rule you thought was already being applied. The integration breaks on day one for a large percentage of real users.

This kind of hidden behaviour is common in legacy systems. Exploratory testing on the legacy components — combined with working closely with the support teams who know them — is essential to surface these issues before they reach production.

Document the End-to-End Journey

Agile rightly emphasises collaboration over documentation, but the complexity of legacy integration demands that constraints are captured clearly and shared across all development squads. If a behaviour is a constraint imposed by the legacy system, it is not negotiable — it must be understood and designed around.

Consider a short architectural sprint at the start of the programme to investigate legacy behaviour, document integration contracts, and identify risks. This upfront investment reduces surprises during development and testing. Any constraint discovered and documented early is far cheaper to manage than one found during user acceptance testing or, worse, in live service.

Once the behaviours and constraints of the legacy components are understood, that knowledge should be shared explicitly with all squads contributing to the service — not assumed to be common knowledge.

Account for Data Latency Across the Service

Many legacy systems use batch processing strategies to optimise performance: updates are queued during the day and processed during overnight batch windows. This creates data latency that can be invisible to a newly developed service designed around real-time interactions.

Consider a scenario where a customer completes an application through a mobile application. The new service confirms success immediately to the customer. But the actual provisioning of that service on the legacy back end is dependent on an overnight batch job. If the batch fails or is delayed, the customer experience and the downstream state diverge. This latency must be accounted for explicitly in service design, in the user experience, and in the testing strategy.

Overnight batch cycles also place hard constraints on end-to-end automated testing. Tests that depend on legacy state changes may take hours to complete a single cycle, making them impractical for continuous integration pipelines.

Testing, Automation, and Continuous Testing in a Hybrid Environment

Testing an end-to-end service composed of modern microservices and legacy components is one of the most technically demanding aspects of this type of programme. The two halves of the service have fundamentally different testing characteristics.

The modern DevOps-developed components can typically be tested through automated unit, integration, and contract tests, and continuously validated within a CI/CD pipeline with relatively little friction.

Legacy components introduce constraints at multiple levels:

• Environments: Legacy test environments are typically shared across multiple development and support teams. Availability windows are limited and coordination is required.
• Test data: Data in legacy test environments is often difficult to set up, slow to refresh, and shared — meaning one team’s test can corrupt another team’s data state.
• Batch dependencies: As described above, state changes in legacy systems may only take effect after an overnight run, making rapid test iteration impossible for certain scenarios.
• Fragility: Legacy systems may have undocumented behaviours that cause intermittent test failures, generating false negatives that erode confidence in the test suite.

A risk-based testing strategy is necessary. Consider stubbing or virtualising the legacy component for the purposes of automated testing of the modern layer. This allows your CI/CD pipeline to continue functioning without a live dependency on a fragile shared environment. Dedicated end-to-end integration testing against the actual legacy system can then be scheduled less frequently, in a controlled manner, with acceptance that it will be slower and harder to maintain.

No approach will be perfect. The goal is to identify and agree on an honest, risk-based testing strategy that all stakeholders understand — rather than attempting to apply a continuous testing model uniformly across components that cannot support it.

Key Principles for DevOps and Legacy Integration

• Invest in discovery early. Run an architectural spike or discovery sprint before main development begins to understand legacy behaviour, data contracts, and constraints.
• Treat legacy systems as complex third-party APIs. Define the integration boundary clearly. Do not assume the legacy system will behave as the documentation (if any exists) suggests.
• Work directly with legacy support teams. Their domain knowledge is irreplaceable. Build a working relationship with them from the start of the programme.
• Use exploratory testing on legacy components. Automated tests cannot discover what you do not already know. Manual exploratory sessions on legacy systems surface hidden rules and behaviours.
• Design for latency. If the legacy system uses batch processing, the service design and the user experience must accommodate delays in state propagation.
• Document constraints explicitly. Constraints imposed by legacy systems are not up for discussion. Write them down and share them across all squads.
• Apply a risk-based testing strategy. Continuous end-to-end testing against live legacy environments is rarely achievable. Stub where you can, integrate where you must, and be explicit about what is and is not covered.

Conclusion

Building new DevOps-driven services that integrate with legacy components is a common, difficult, and often underestimated challenge. Each integration is unique — the constraints you will encounter depend on your specific legacy systems, your organisation’s risk tolerance, and the nature of the service being delivered.

The teams that handle this most effectively are those that invest in understanding the legacy estate before they begin building, document what they discover, share that knowledge across squads, and apply a realistic testing strategy that accounts for the fundamental differences between modern and legacy components. Doing the hard work upfront will not eliminate all the difficulties — but it will significantly reduce the number of surprises, and greatly improve the chances of a successful delivery.

What Is Embedded Testing?

When people discuss software testing in the context of DevOps and Agile, the conversation usually centres on web applications, APIs, and cloud-native services. Embedded testing is a distinct discipline that deserves its own treatment, because the constraints, skills, and tooling involved differ significantly from mainstream software development.

Embedded testing is the practice of validating the software stack designed to run on a specific piece of hardware — firmware, middleware, and application layers included. Common examples include the software running on a fitness tracker (such as a Garmin or Fitbit), a set-top box, medical devices, or automated production line equipment.

Understanding the System Under Test

Before applying any DevOps or Agile methodology, it helps to understand the typical architecture of an embedded system. Most embedded products share the following layers:

• Custom hardware: Consumer-grade embedded devices are typically engineered to minimise cost, which means hardware resources are constrained. It is common for devices to struggle to keep pace with software demands in the years following launch.
• Firmware and driver layer: This interfaces directly with the hardware and is often the most sensitive layer to change. Small modifications here can have cascading effects on the rest of the stack.
• Middleware: Implements higher-level device functionality and typically acts as the bridge between hardware drivers and the user-facing application.
• User interface: The layer through which users send commands, configure settings, or trigger device behaviour.
• Connectivity: Most modern embedded devices communicate with other devices or back-end services, adding a distributed systems dimension to the testing problem.

The goal of embedded testing is to verify that every layer — and the integrated whole — functions correctly and meets quality standards under real-world conditions.

Delivering Consistent Customer Value

Historically, major embedded device manufacturers have operated on release cadences of two to three years for hardware, with software updates arriving more frequently — perhaps three to four times per year at launch, tapering off as devices age. The challenge is to maintain a predictable and meaningful delivery cadence throughout a device’s lifetime.

Several principles borrowed from mainstream DevOps can help achieve this:

Decompose the System and Test Layers Independently

The single most impactful structural decision is to design components so they can be tested — and ideally released — independently of one another. Tight coupling between layers means that a defect in one area can block an entire release. Loose coupling gives teams the freedom to iterate on individual components at their own pace.

Apply standard testing practices at each layer:

• Unit tests for individual functions and modules within firmware and middleware.
• Component tests that exercise each layer through well-defined interfaces.
• Integration tests that verify the components work correctly together — but only after functional correctness at lower levels has already been established.

Reuse Standard Tooling Where Possible

There is unlikely to be an off-the-shelf automation solution that covers the full embedded stack. However, individual layers may be testable with standard tools. For example:

• A UI layer built on a known framework might be testable with standard UI automation tools outside the device itself.
• Back-end services connected to the device can often be tested using conventional API testing frameworks.
• Hardware abstraction layers can sometimes be exercised with hardware-in-the-loop (HIL) simulation environments.

Where no standard tool exists, custom tooling will be required. This is a significant investment, but building a robust, domain-specific integration test harness pays dividends across the entire device lifecycle.

Unique Challenges of Embedded Testing

Resource Constraints and Timing Sensitivity

Embedded systems are heavily optimised and operate with minimal spare capacity. This means that code changes — even seemingly small ones — can alter execution timing and produce unexpected side effects in other parts of the system. Testing must therefore be sensitive to performance regression, not just functional correctness.

Instrumentation Alters Behaviour (Observer Effect)

In conventional software, attaching a debugger or inserting instrumentation code is routine. In embedded systems, doing so can change the timing and memory characteristics of the running software — sometimes masking the very defect you are trying to find. This makes reproducibility and root-cause analysis considerably harder.

Difficult-to-Reproduce Defects and Field Conditions

Some defects in embedded systems only manifest under very specific hardware states, environmental conditions, or usage patterns that are hard to replicate in a lab. For consumer devices in particular, the configuration space is enormous. Collecting telemetry and diagnostic data from devices in the field can significantly improve the team’s ability to identify the conditions required to reproduce and fix such defects.

Non-Functional Testing: Don’t Leave It Until the End

In embedded systems, non-functional characteristics are not secondary concerns — they are often the primary differentiator between a device that works and one that customers actually want to use. Non-functional testing in this context includes:

• Performance and responsiveness
• Load and stress testing
• Reliability and fault recovery
• Security
• Energy consumption (battery life on portable devices)
• Memory usage under sustained operation

Non-functional testing must be integrated into the regular build and release pipeline from the outset. Tracking performance indicators build-by-build helps teams catch gradual degradation early — before it compounds into a costly problem late in the release cycle. Fixing a significant performance regression discovered in a pre-release integration phase is far more expensive than catching it at the component level during development.

Delivery Cadence: Multi-Speed Release Strategies

Not every component of an embedded system needs to — or can — be released at the same frequency. A pragmatic approach is to adopt parallel delivery cadences aligned to the characteristics of each layer:

• Back-end services: These are typically decoupled from the hardware and can follow a full DevOps model with frequent, low-risk deployments.
• Application and UI layer: Depending on the update mechanism, these may support a relatively fast cadence — for example, monthly releases.
• Firmware and driver layer: These require the most rigorous testing and the longest validation cycles. A quarterly or release-driven cadence is more realistic for many teams.

The degree of decoupling between components directly determines how much release flexibility the team has. A tightly coupled system forces everything to move at the speed of the slowest and most risk-prone component. Investing in architectural decoupling is therefore not just a software design concern — it is a delivery strategy decision with direct impact on business agility.

The Role of Test Automation and Exploratory Testing

Test automation is the foundation of any viable DevOps approach for embedded systems. Without it, the test coverage and execution speed required for frequent releases simply cannot be achieved. Automation should span both functional and non-functional testing at every layer of the system.

However, automation alone is not sufficient. Exploratory testing by skilled testers who understand the domain remains essential for:

• Identifying gaps in the automated test suite.
• Validating that automated tests are testing the right things.
• Uncovering edge cases and interaction effects that structured test design does not anticipate.

Summary: Key Principles for Embedded DevOps

Applying DevOps and Agile principles to embedded testing is achievable, but it requires deliberate engineering choices at both the architecture and process levels. The key principles are:

1. Design for testability and loose coupling. Components that can be tested independently can also be released independently.
2. Test at every layer. Use unit, component, and integration tests with clearly defined interfaces between layers.
3. Invest in custom tooling where necessary. Accept that standard tools will not cover the full stack and allocate effort accordingly.
4. Integrate non-functional testing into the pipeline from day one. Track performance, energy, and reliability metrics build by build.
5. Adopt a multi-speed delivery cadence. Match release frequency to the risk and complexity profile of each system component.
6. Combine automation with exploratory testing. Automation provides speed and consistency; exploratory testing provides insight and coverage quality.
7. Collect field telemetry. Real-world data from deployed devices is invaluable for improving lab test coverage and reproducing hard-to-find defects.

The path to regular, predictable embedded software releases is demanding, but it is navigable. The investment in architecture, tooling, and process pays off in reduced integration risk, shorter release cycles, and better outcomes for end users.

Why Culture Determines IT Modernization Outcomes

Legislative and budgetary support for IT modernization—such as the Modernizing Government Technology Act and the cross-agency priority goals in the 2018 President’s Management Agenda—created formal pathways for federal agencies to replace aging systems. But funding alone does not guarantee results.

A persistent structural problem in federal IT is that a significant share of the IT budget has historically been consumed by operations and maintenance of legacy systems, some older than the employees who maintain them. Reduced discretionary budgets, growing cybersecurity threats, workforce attrition, and accumulating technical debt compound the challenge.

The deeper obstacle, however, is organizational culture. Agencies routinely concentrate on selecting the right technology stack while underinvesting in the organizational change required to make new tools effective. Here are three cultural factors that CIOs and agency leaders should address explicitly in any IT modernization plan.

1. Digital Transformation Is a Team Sport

A culture of cross-functional collaboration is the single most important factor in sustained digital transformation. Yet modernization initiatives are frequently run exclusively out of the CIO’s office, with minimal involvement from the business lines that depend on the systems being replaced.

Consider DevOps adoption as an example. A CIO shop may invest in hiring DevOps engineers, standing up cloud infrastructure, and deploying continuous integration pipelines—all reasonable first steps. But DevOps is fundamentally a culture and practice, not a toolchain. If organizational silos remain intact, the tooling delivers little of its intended value. Automation pipelines sitting between teams that do not communicate are not DevOps; they are expensive scripts.

The Department of Veterans Affairs’ transformation of its benefits system illustrates what genuine cross-functional collaboration looks like at scale. The updated Veterans Benefit Management System—one of the largest agile implementations in the federal government—reduced the disability claims backlog by nearly 68 percent from its peak. The effort relied on co-located scrum teams that included not only developers and analysts, but also product owners, program leads, site reliability engineers, cybersecurity experts, and communications specialists. Leadership actively championed the integration between business stakeholders and technical development teams.

Practical steps to build a collaborative culture:

• Map existing organizational silos before purchasing any new tools or platforms.
• Define success criteria jointly with business stakeholders, not only with the CIO shop.
• Co-locate or establish consistent ceremonies (standups, retrospectives, sprint reviews) that include both technical and business team members.
• Empower cross-functional teams to make decisions without unnecessary escalation chains.

2. Start Small, Learn, and Evolve

Large-scale, all-at-once modernization efforts—often called the “big bang” approach—have a poor track record. The complexity and interdependencies of legacy systems make it nearly impossible to anticipate every risk when attempting to replace everything simultaneously. A single miscalculation can stall the entire program for months.

A culture of deliberate, iterative learning is the antidote. Starting with one pilot program on one system allows teams to surface real-world constraints, capture lessons, and apply them before scaling. This approach requires transparency about both successes and failures—and a leadership environment where honest performance data is welcomed rather than suppressed.

The National Science Foundation’s adoption of the Scaled Agile Framework (SAFe) for a portfolio of grant management systems demonstrates this model. The team began with a single release on a single program, methodically documenting what worked and what did not, and sharing that data openly. Over time, NSF expanded mature scaled agile practices across the entire organization. The cultural shift also enabled a technical shift: the organization moved toward a lean microservice-based architecture that allows faster delivery of new capabilities.

Key principles for iterative modernization:

• Identify one bounded system or process as the first pilot—one with enough complexity to be instructive but not so critical that failure is catastrophic.
• Define measurable outcomes before the pilot begins, so results are evaluated against evidence, not impressions.
• Build retrospective reviews into the program calendar; treat them as mandatory, not optional.
• Use pilot learnings to update playbooks, contract vehicles, and architectural standards before expanding to additional systems.

3. Don’t Overlook Procurement Culture

IT modernization culture cannot stop at the boundary of the internal organization. How an agency buys technology and services reflects and reinforces its culture just as much as how it builds them.

A common contradiction: agencies state a goal of integrated DevOps services, then issue solicitations that split development and operations into separate contracts. This procurement structure recreates the silos at the vendor level that the agency is trying to eliminate internally. Vendors delivering against fragmented contracts have no contractual incentive—and often no mechanism—to collaborate.

Some agencies have begun issuing solicitations that procure development services at the sprint team level, which is a meaningful improvement. However, sprint-level contracts often fail to address the broader ecosystem: how application services will integrate, how they will be maintained in production, and how user feedback will flow back into the development cycle.

A related gap is the underrepresentation of non-technical expertise in modernization contracts. Procurements tend to specify technical certifications for developers and architects but omit equivalent requirements for change management professionals, organizational development specialists, and communications leads. These roles are not peripheral to digital transformation; they are often what determines whether end users adopt a new system or work around it.

Procurement modernization recommendations:

• Draft solicitations that require an integrated DevOps service model rather than siloed development and operations contracts.
• Include explicit task areas for change management, user adoption, and organizational communication—not just technical delivery.
• Require experience or certification for change management and communications key personnel, applying the same rigor used for technical roles.
• Address integration, maintenance, and feedback loops in the statement of work, not only initial development deliverables.

The Takeaway

Technology decisions in IT modernization are, in practice, the easier decisions. Selecting a cloud platform, a CI/CD toolchain, or an agile framework involves known options and established evaluation criteria. The harder work is changing how people collaborate, how organizations learn from failure, and how contracts are structured to support integrated delivery.

CIOs and program leaders who treat cultural change as a prerequisite—rather than a side effect—of IT modernization are the ones whose programs deliver lasting results. The technology follows the culture, not the other way around.

A Decade of DevOps Transformation

Over the past ten years, DevOps practices have fundamentally reshaped how software development teams operate. By breaking down silos between development and operations, organizations have been able to ship software faster, improve reliability, and respond more quickly to customer needs. What started as a cultural and philosophical shift has since matured into a discipline supported by a rich ecosystem of tooling and automation.

The Rise of “Day 2” DevOps

As DevOps adoption has become mainstream, forward-thinking enterprises are moving into what practitioners are calling “Day 2” DevOps. If Day 1 DevOps was about introducing automation, continuous integration, and collaboration between dev and ops teams, Day 2 is about operating those practices reliably at scale.

In a Day 2 DevOps environment, the emphasis shifts to:

• Scalability: Managing not one or two pipelines, but dozens or hundreds across the enterprise.
• Teamwork at scale: Coordinating development and operations teams that may each use different toolchains.
• Delivering complex applications: Shipping and managing multiple interdependent applications simultaneously without losing oversight or control.

This maturation of DevOps practice presents new engineering challenges that require more sophisticated tooling than what sufficed in the early days of CI/CD adoption.

IBM’s Response: Two New UrbanCode Releases

To address these Day 2 challenges, IBM announced two significant product releases: IBM UrbanCode Deploy 7.0 and IBM UrbanCode Velocity 1.0. Both tools are positioned to help enterprises manage and optimize continuous delivery at scale across complex, multi-team environments.

IBM UrbanCode Deploy 7.0

UrbanCode Deploy is IBM’s established deployment and release automation platform. Version 7.0 builds on its mature foundation with several meaningful enhancements aimed squarely at enterprise-scale operations:

• New endpoint management layer: Adds improved infrastructure-level control to help teams manage deployments across large numbers of target environments.
• Shared deployment processes: Applications can now share common deployment processes, reducing duplicated maintenance effort and accelerating rollout consistency across teams.
• Safe Edit function: Introduces a code promotion flow around process changes, adding a layer of governance so that modifications to deployment processes go through a controlled review before taking effect in production pipelines.
• Refreshed user interface: A modernized UI designed to reduce the learning curve for new users, helping teams get productive faster.

IBM UrbanCode Velocity 1.0

UrbanCode Velocity is a new addition to the IBM DevOps portfolio. Its core purpose is to aggregate data from across an organization’s various CI/CD pipeline tools and surface actionable insights for engineering and delivery teams.

In most large enterprises, different teams adopt continuous delivery independently and often settle on different tools — Jenkins, GitLab CI, Azure DevOps, and others may coexist within the same organization. Velocity addresses this fragmentation through what IBM describes as a “pipeline of pipelines” model: a unified view that pulls together activity from multiple tool chains, enabling:

• Coordination of delivery activity across teams using different tooling.
• Visibility into value stream metrics and bottlenecks.
• Data-driven insights to help optimize the overall software delivery process.

IBM’s Perspective on DevOps at Ten

“DevOps is ten years young and it is now the moniker for software-driven innovation done well. As enterprises scale DevOps to address Day 2 challenges, the IBM UrbanCode team seeks to help them be as effective as possible. Today’s announcements thrill us: we know we are ready to help more teams to be effective at even greater scale.”

Eric Minick, Program Director, IBM Product Management Lead — DevOps

Why This Matters for DevOps Engineers

The framing of “Day 2 DevOps” reflects a real challenge that DevOps engineers in large organizations face: the practices that work well for a single team or product line become harder to govern, standardize, and optimize as they spread across dozens of teams. Tools like UrbanCode Deploy and Velocity represent one vendor’s approach to bringing order to that complexity without forcing every team onto a single, rigid toolchain.

For teams evaluating enterprise-grade deployment automation and value stream management, both releases are worth examining as part of a broader tooling assessment — particularly in environments that already have IBM tooling in their stack.