devopsy.kinsta.cloud

Tag: Bottlenecks

GitHub Introduces Stacked PRs to Ease Review Bottlenecks

GitHub’s new Stacked Pull Requests feature restructures how developers submit and review changes by allowing large code updates to be broken into smaller, interdependent units.

With Stacked PRs, each unit can be reviewed and merged individually while still contributing to the overall feature set. The approach helps developers shift away from monolithic pull requests, which have become increasingly difficult to manage as development continues to move faster.

The release of Stacked PRs is a response to the rise of AI-assisted coding tools, which have greatly increased the volume and scale of code submissions, placing new pressure on review workflows. While large pull requests spanning dozens of files used to be merely inconvenient, they are sometimes now a systemic issue. There is a widening gap between code generation and code review, with reviewers dealing with reduced visibility and slower turnaround times.

With the layered workflow of Stacked PRs, developers can sequence related changes so that each pull request builds on the previous one. Reviewers, in turn, assess smaller, focused diffs while maintaining visibility into how each piece contributes to the overall change. The structure allows teams to merge either individual components or entire stacks, depending on readiness.

Building on Earlier Solutions

Similar workflows, often described as “stacked diffs,” were popularized in earlier code review systems. These systems addressed the same issues around reducing wait times for reviews while preserving development momentum. GitHub’s move brings this model into its native platform, reducing the need for third-party tools that previously filled the gap.

This offers big advantages, particularly for companies managing large codebases and monorepos. In these environments, development can be modular, with teams working on interconnected components in parallel. Traditional pull request models often forced developers to choose between waiting for upstream changes to merge or bundling work into large, unwieldy submissions. Stacking introduces a middle path, enabling incremental progress without sacrificing structure.

GitHub has paired the feature with a command-line extension that automates much of the underlying workflow, including branch management and rebasing. On the interface side, stacked changes are presented visually, allowing reviewers to navigate the hierarchy of updates and understand dependencies between them. This integration of CLI and UI is intended to lower the barrier to adoption.

Cultural Shift

The technical implementation of Stacked PRs may prove easier than the cultural shift required to use it effectively. Developers must reorganize how they structure their work, breaking features into logically discrete units that can stand on their own. This could be a challenge for teams accustomed to broader, less segmented workflows.

This release will likely cause some competitive disruption. By embedding stacked workflows directly into its platform, GitHub is encroaching on tools that built their value around this capability. Vendors that previously offered stacking as an extension to GitHub must now differentiate beyond core functionality.

More broadly, the feature is a recalibration of development priorities. As AI systems speed up code production, the limiting factor is no longer writing software but validating it. Review workflows, once secondary, are becoming central to maintaining quality and stability.

April 15, 2026
DevOps Micro-Inefficiencies: Finding and Dealing With Them

On their own, micro-inefficiencies in DevOps seem negligible. But scale that across hundreds of deployments, sprints and team interactions and you’re suddenly hemorrhaging time, resources and momentum. In a field that lives and dies on iteration speed and system resilience, these micro-inefficiencies are termites in your tech stack — and ignoring them is not an option.

This article explores how to identify the invisible inefficiencies in your DevOps lifecycle and what you can actually do to eliminate or work around them without overhauling your stack or team.

It’s not about huge transformations or expensive tools. It’s about getting a better return on the systems and habits you already have.

Recognizing the Micro Inefficiencies in DevOps

You’d think that inefficiencies would be obvious—they’d be bottlenecks, loud delays, or deployment blockers. But micro-inefficiencies are quieter and even the best software developers are prone to inadvertently ignoring them. They live in the gaps between tools, in undocumented tribal knowledge and the seconds lost to context-switching. A developer waiting 30 seconds for a build to finish doesn’t raise a flag. But across a team of 10 running 20 builds a day? That’s hours lost each week.

Common culprits include CI/CD pipelines that run unnecessary steps, manual reviews that could be automated, alerts no one reads and poorly integrated tools that force you to jump between tabs. Even slow-loading dashboards or unclear test results can drag down velocity without ever tripping alarms.

The hardest part? Most of these micro-inefficiencies don’t appear in retrospectives. They’re normalized as “just how things work here.”

Where to Start Looking

You won’t fix what you can’t see, so the first step is deliberate discovery. This doesn’t mean you need a month-long audit. It means asking your team: “What small annoyances do you work around every day?” That simple question often reveals recurring friction points.

Look at places where humans are still acting as glue between systems. If your QA team regularly pings devs for environment URLs, there’s inefficiency. If deploying to staging requires SSH into a server manually, that’s another one. If someone manually uploads reports to Slack every week, that too.

Tool usage metrics can also help. How often are your engineers using specific dashboards? How frequently are test failures false positives? What steps in your pipeline take the longest but add the least value? Every pattern tells a story.

And don’t overlook temporal friction: Are team members frequently blocked by others due to mismatched schedules, lack of context, or missing permissions? That’s micro-drag too.

Communication as a Hidden Culprit

Even in high-functioning DevOps teams, communication overhead is a subtle but significant inefficiency. It’s not the big misalignments that cause the most friction—it’s the daily trickle of clarification messages, redundant status updates and scattered knowledge.

If a developer needs to ask three people where a configuration file lives, that’s not a

knowledge-sharing culture—that’s inefficiency. If release notes are spread across Google Docs, Jira, and Slack, no one knows what the source of truth is. That breeds second-guessing, and second-guessing slows everything down.

One way to spot this is to trace how decisions are made and communicated. If decisions require multiple touchpoints for clarification or are often revisited because someone missed context, then communication workflows need streamlining. Not with more meetings—but with better defaults: Shared glossaries, clear ownership and centralized documentation.

Tooling: When Integration Isn’t Enough

Many DevOps shops rely on impressive toolchains — Jenkins, GitLab, Docker, Terraform, you name it. But integration doesn’t mean harmony. Micro-inefficiencies often arise at the integration seams.

Does your deployment pipeline require a developer to manually copy an artifact URL from one tool and paste it into another? Does incident reporting require exporting logs, reformatting them and emailing them to stakeholders? These are integration gaps masquerading as routine steps.

APIs and automation can only help if they’re actually being used. So even if two tools “talk to each other,” the way they do so matters. Logins shouldn’t require token gymnastics. Alerts shouldn’t need constant tuning. Make friction visible: Ask your team which tool interactions they avoid or defer because “it’s annoying.”

Good DevOps tooling should rely on shadow deployments and feel like plumbing — invisible when it works. If it’s constantly drawing attention, it’s inefficient.

Psychological Inefficiencies: The Human Layer

Micro-inefficiencies don’t just come from systems and tools. They come from human behavior shaped by those systems. Think of the engineer who doesn’t restart a flaky test because “it usually passes the second time,” or the team that avoids automating something because “last time it broke production.”

These behavioral patterns stem from learned pain, and that pain calcifies into inefficiency. Teams start compensating instead of fixing. They avoid certain deployments on Fridays. They delay code reviews until the last possible moment. They write documentation in a rush post-release, if at all.

Dealing with this requires safety, not just scrutiny. Create a culture where small complaints aren’t dismissed but documented. Where “this sucks but I’m used to it” becomes a red flag, not a badge of honor. Psychological inefficiencies thrive in silence—airing them out is step one.

Dealing With Micro-Inefficiencies at Scale

Once you start spotting inefficiencies, resist the urge to solve everything with a single framework or playbook. These issues are hyper-contextual. A one-size-fits-all approach often creates more friction.

Instead, bake regular micro-inefficiency reviews into your sprint process. Ask for one “small inefficiency” per team member each cycle, then prioritize a few for resolution. Track them publicly, like tech debt. The goal isn’t immediate elimination but long-term awareness.

Also, empower anyone—not just team leads—to fix small friction points. Whether it’s creating a script, automating a webhook, or consolidating docs, decentralizing fixes gives micro-solutions macro impact.

And crucially, celebrate fixes. Don’t just ship them — showcase them in team meetings. Turn improvement into culture. Once your team sees that even 10-second savings are valued, you create a flywheel of continuous optimization.

Conclusion

In DevOps, we often focus on the flashy improvements — new observability platforms, zero-downtime deploys and container orchestration upgrades. But it’s the invisible inefficiencies that quietly erode your gains. Micro-inefficiencies won’t crash your system, but they will slow your velocity until you forget what fast felt like.

The good news? They’re fixable. But only if you make them visible. Only if you value every second saved as much as you do every release shipped. Fixing micro-inefficiencies isn’t about perfection. It’s about momentum. And momentum, in DevOps, changes everything.

July 25, 2025
Breaking Through – Beating Mainframe Delivery Bottlenecks
The mainframe powers large – and vital – elements of the global economy. Mainframe DevOps and new innovations offer the potential for delivering greater value, faster. Yet market data suggests significant challenges in achieving it. What can be done to beat the bottlenecks in mainframe delivery?

The Mainframe: Powering the Future of Enterprise Computing

The mainframe market comprises thousands of well-known, successful organizations and institutions worldwide. These organizations span the financial services, insurance, retail, logistics, transportation, and government sectors, among others, serving millions of clients. Their IT infrastructure is among the most active, processing billions of transactions as they support vast areas of the global economy.

The core business systems of these organizations rely on the IBM mainframe, which is considered by reputation to be the most powerful and resilient machine available.

To learn more about the mainframe market and the opportunities—and challenges—it faces today, PopUp Mainframe recently commissioned a survey, conducted in 2025 by market researchers Vanson Bourne.

The survey revealed overwhelming loyalty to the mainframe platform and a positive outlook regarding the opportunities Linux provides on the mainframe by using the specialist processor IFL. The market responses showed a clear commitment to the mainframe, now and into the future:
- 98% rely on the IBM mainframe to run their organizations
- 94% confirm their potential to leverage additional workload capacity on specialist/Linux environments on Z
- 97% seek to increase the use of specialist mainframe processors
The Challenges Ahead

The same survey, though, highlighted areas of concern. Organizations face significant operational challenges across the mainframe delivery process. Nearly all respondents encountered difficulties during development and testing phases using the mainframe. Concerns over the availability of mainframe environments were widespread, while a third of respondents required four or more teams to complete mainframe deliveries. Additionally, 80% cited staffing and tooling limitations as hindrances to business operations.

The research further emphasized five strategic areas where the mainframe environment struggles to meet aspirations: cost efficiency, flexibility, speed of delivery, risk management, and sustainability. More than 80% of respondents indicated that improvements were needed in each area.

Addressing the Bottlenecks

PopUp Mainframe offers an innovative solution to these bottlenecks and their strategic impacts. It’s instantly available mainframe environment supports development, testing, training, and other typical mainframe activities, accessible with the click of a button. Functionally equivalent to mainframe z/OS, it runs on the customer’s choice of hardware, enhancing availability and usefulness.

PopUp addresses key bottlenecks head-on: in an ideal mainframe scenario, everyone involved in the SDLC—analysts, programmers, QA staff, business users, administrators, DBAs—logs into the mainframe to perform their tasks in sequence. However, in reality operational complexities and restrictions often hamper innovation and impede mainframe delivery. PopUp Mainframe addresses these complexities and provides instantaneous resources for those who need them by enabling dev, test, and training activities in a compatible, virtual mainframe environment.

Cornerstone Capabilities

PopUp Mainframe ensures compatibility with the mainframe z/OS environment it replicates. Key product highlights include:
- Integration with mainframe environments and tools, including IBM, BMC, third-party, and open-source DevOps tools.
- Full compatibility with z/OS applications.
- Support for data compliance and regulation using advanced masking technology, with the option to keep data on the mainframe.
- Easy access and availability, with environments up and running in minutes, supporting IT sustainability goals.
- Universal usability, accommodating both ISPF access and GUI IDE tools simultaneously.
PopUp Mainframe acts as a virtual mainframe environment, designed to support each organization’s unique selection of tooling for mainframe application delivery processes. To do so, the product will integrate with a wide variety of popular mainframe toolchain elements. For example, PopUp Mainframe supports mainframe DevOps setups using VS Code or IDZ as the developer IDE, and open-source tools like Galasa and COBOL Check for unit testing, with orchestration tools such as GitHub managing these processes.

Fully flexible and scalable, the solution allows organizations to deploy as many PopUp Mainframe instances as needed. Two editions of the PopUp Mainframe product are available: Z edition (Linux on Z or LinuxOne installation) and X edition (x86 on premise or cloud installation).

Revolutionary Results

The opportunity for improvement by using PopUp Mainframe is both instantaneous and significant: one client demonstrated the solution’s efficacy by completing a POC in a single afternoon. Another client significantly improved delivery speed by several hundred percent. Other observed outcomes show PopUp Mainframe has helped clients meet several strategic goals:
- Accelerate development and testing while protecting production MIPS.
- Initiate development, testing, training, and R&D projects flexibly and quickly.
- Quadruple mainframe deliveries through efficient resource usage.
- Ensure data compliance in mainframe testing by keeping data on Z.
- Enhance sustainability and reduce emissions by deactivating unused environments.
Futurum Research Perspective

“Hosting critical time- and availability-sensitive business functionality on the mainframe remains a vital part of IT in the enterprise and much of the public sector,” said Guy Currier, Analyst, The Futurum Group. “But change management on the mainframe can be slow and inefficient, especially as business complexity and regulatory pressures increase. Innovative technologies such as PopUp Mainframe offer mainframe teams opportunities to accelerate the delivery velocity of their business-critical systems.”

Learn More

Watch our recent devopsy.kinsta.cloud webinar on demand to learn more about this topic. We will also be presenting at the forthcoming Tech Field Day Extra at SHARE Cleveland 2025 on August 19-20.

For further information, datasheets, and release highlights, visit the PopUp Mainframe website.
June 25, 2025
Unified Enterprise DevOps Platforms Eliminate Bottlenecks
Nearly all enterprise digital transformation projects include moving software to DevOps processes and platforms. The effort, cost and time it takes to be successful with these transformations depend on a lot of factors, but one thing stands out: as indicated in my white paper Unified Enterprise DevOps Platform Why? How? And What?, “An enterprise with many variations of DevOps platforms and tools is at best chaotic, and at worst, is a gross impediment to overall organization agility – undermining the very purpose that DevOps is meant to serve.”

In my recent blog Why a Unified Enterprise DevOps Platform is Necessary, I indicated that “The aggregate set of platforms and tools is like a Frankenstein’s monster, with many incompatible parts resulting in an awkward looking product that is hard to control, replicate and evolve.”

Success with DevOps requires frictionless interplay between the people, processes and technologies that need to cooperate for continuous deliveries to happen effectively. The existence of different DevOps solutions creates organizational barriers to unification, because different groups become dependent on their local variations.

A Unified Enterprise DevOps Platform Accelerates Time-to-Value

Culture barriers, process problems and DevOps platform “wars” all are factors impacting the progress of digital transformations. A unified enterprise DevOps platform would accelerate time-to-value, and realize efficient, safe operation for digitally transforming enterprises and organizations.

The following are general requirements for a unified enterprise DevOps platform.

● A new, unified approach that supports end-to-end capabilities for continuous delivery of software, as a managed service, for multiple streams of pipelines.
● Unified metrics that show business value, costs of the value stream and timing for end-to-end continuous delivery flow across multiple pipelines.
● Unified capabilities including visibility, orchestration, integration, security, governance, traceability and management of flow for application value streams across multiple pipelines.
● Capabilities to unify continuous testing/QA, troubleshooting and debugging.
● A new, unified approach to simplify and accelerate toolchains that support new cloud-native and cloud-adapted applications, infrastructures, machine learning, commercial off-the-shelf and open source software.

A DevOps Platform Blueprint

In my SlideShare DevOps-as-a-Service Values, I described a four-layer blueprint for a unified enterprise DevOps platform that satisfies these general requirements. The main elements in the blueprint are:

● Stakeholders – There are three types of stakeholders: business, appdev users and DevOps admin teams.
● Service access layer – Consists of portals and APIs for business, appdev and DevOps administration users and access security.
● Service layer – consists of user services and DevOps admin services.
- - User Services include things that appdev users need to perform their application development and testing work. This includes capabilities for no-code automation and orchestration, repos for code, artifacts and data, multi-CI/CD pipelines and sandboxes, test data, configuration, continuous testing/QA, service level objectives (SLOs) for business and appdev users and troubleshooting and debugging.
  - DevOps admin services include things that a DevOps team needs to administer and manage the platform. This includes capabilities for platform administration, the ability to import pipelines into the unified platform, integration with enterprise service catalogs, integration with enterprise issues and change request systems, SLOs for DevOps administrators and capabilities to implement governance policies-as-code.
● Resources layer – includes resources that the services need to run including application stacks, infrastructure resources, tools, infrastructure code and topology data.

One of the most important benefits of a unified platform is the ability to unify SLOs for each class of stakeholders. The SLOs need to be chosen to best fit the requirements of each application.

Business value can be demonstrated by the following SLOs:

● Productivity metrics.
● ROI data tracking.
● Agility of services – Lead time for changes and frequency of releases.
● Reliability of services – Change failure rate; time to restore services.
● Governance compliance and security.

Appdev user value can be demonstrated by the following SLOs:

● Platform availability.
● Service response time.
● User experience scores.
● Change request response time.

DaaS team value can be demonstrated by the following SLOs:

● Scope of applications – number of apps supported, number of users per month.
● Number of requests served per month.

Without a unified enterprise DevOps platform, all these SLOs would have to be implemented multiple times, once for each type of DevOps platform.

To realize DevOps-as-a-Service for enterprises with multiple related pipelines, each pipeline needs to be configured to work within a unified model where common tools process each application and microservice continuous delivery task in parallel. Unified control and monitor points are needed – and should be exposed by the unified platform – to realize SLOs in a unified way. Without a unified platform, all of these SLOs will need to be implemented separately, for each platform, and then another system will be needed to aggregate them into a common view.

The SLOs will indicate where the biggest bottlenecks are for a particular pipeline. In many enterprise pipelines, the biggest bottleneck is testing, troubleshooting test failures and debugging to resolve the failures. It is a myth that continuous testing is just the execution of automated tests. The whole range of “testing things” includes test planning, test resource scheduling, test design, test implementation, test environment management, test execution, test results reporting, test result analysis, troubleshooting, debugging, fix retest and test management, and all can be sources of bottlenecks. These “testing things” are all sources of bottlenecks for every stage of a DevOps pipeline, for all Three Ways of DevOps. Without a Unified enterprise DevOps platform, all these testing things must be addressed separately, in accordance with the different pipeline platforms.

Testing, troubleshooting and debugging tasks are a major source of bottlenecks for most DevOps value streams. A unified platform improves continuous testing/QA, troubleshooting and debugging as follows:

● Continuous testing/QA – Orchestration of test environments, execution of tests and reporting test verdicts is unified.
● Troubleshooting – Failures are displayed in a consistent format, including trends correlated to pipeline and application log data, to simplify analysis of test failures.
● Debugging – Causes of failure can be isolated with intelligent analysis of troubleshooting results, and the platform can quickly install the fixes and orchestrate the test environment to verify the fix is working.

These testing, troubleshooting and debugging advantages have a major impact on the ability to accelerate digital transformations.

What This Means

Digital transformation of many enterprises and organizations are being seriously impeded by having too many DevOps platforms and tools. A unified enterprise DevOps platform resolves the technical problems of broken, leaky, “Frankenstein” toolchains and processes. Enlightened leaders that understand the importance and the broad impacts of unified enterprise DevOps platform are wise to recognize the sense of urgency surrounding a migration to a unified platform, and take action to stop the proliferation of too many platforms.

To realize a unified enterprise DevOps platform in an enterprise takes more than simply buying and installing a new platform and telling everyone to start using it in place of what they are used to. With multiple entrenched DevOps platforms in place, there are practical and political considerations that must be overcome. Introducing any changes across a large group of applications in an enterprise can be chaotic, and will often be more costly and take too much time if the changes are not well-coordinated in accordance with a carefully crafted strategy and implementation roadmap that leaders and team members are aligned with.
April 15, 2021
Continuous Testing: The Quest for Quality at Speed

The DevOps goal to reduce lead times by accelerating software deliveries presents a serious challenge for assuring the quality of the software that is delivered. As I indicated In my SlideShare post, “The Quest for Quality at Speed,” testing activities span end-to-end software value streams and often account for more than 50% of bottlenecks.

The answer to these DevOps testing challenges is referred to as continuous testing (CT), which is more than simply automating tests. My blueprint for continuous testing identifies eight pillars of practices, each with strategies to reduce bottlenecks. In this article, I enumerate the strategies for each of the eight pillars of continuous testing and explain how to approach implementation for greater adoption of CT across an organization.

Continuous Testing Pillars

Continuous Testing Tenets

There are five tenets which are guiding principles that enable continuous testing:
• Shift Left: Conduct each test as early in the pipeline as possible.
• Fail Early: Arrange the tests so the most likely problems are found during the earliest possible stage in the DevOps pipeline.
• Fail Often: Run tests frequently and with many different conditions.
• Test Fast: Arrange tests to run in quick cycles.
• Be Relevant: Focus on the most important tests and results.

Leadership and Culture

Leadership and culture practices have a major impact on influencing behaviors and habits of everyone involved in testing across the DevOps value stream. Bottlenecks to CT include inadequate funding of testing due to lack of quality vision and goals at the executive level, and bottlenecks caused by distrust and lack of cooperation between Dev, QA and Ops. Executive sponsors need to clarify the definition of quality for the organization, and emphasize quality’s importance. Executives can communicate the vision and goals for quality and establish incentives that foster a culture of collaborative behavior.

Test Strategies and Plans

Test strategies and plans are needed to guide testing approaches for each product/service pipeline. Bottlenecks to CT include confusion caused by lack of product/service test strategies, and unplanned testing activities and resources are not included sufficiently in planning process. It is important to establish test coverage standards, test case standards, gate criterion and planning process that include testing requirements. CT strategies include making sure test coverage requirements are defined, all types of tests required are identified, allocate tests that are required at input gates, indicate test results are required at output gates and enforce that test tasks are included in planning backlogs and sprints.

Test Management

Test management is needed to coordinate testing resources and test schedules. Bottlenecks to CT include poor utilization of test resources due to lack of visibility and schedule bottlenecks due to lack of coordination of test schedules. It is important to have a database of tests and test resources, and test scheduling tools. CT strategies include version management of tests and resources, an inventory of test resources and dynamic test scheduling.

Test Automation

Designing, creating, selecting and executing tests in an automated fashion to get to a verdict as fast as possible is the primary strategy to accelerate testing. Bottlenecks to CT include slow test creation, slow test execution and slow time to realize verdicts. It is important to have effective automation strategies for test design, test creation, test selection, and test execution. CT strategies include test design templates, advanced test creation tools (E.g., TDD, keyword, behavior, model-based), dynamic test selection, tests designed for fast verdicts and horizontal and vertical scaling tests.

Test Tools

Test tools are designed to automate specific types of tests and integrate with DevOps platforms through APIs for orchestration, execution and reporting. Bottlenecks to CT include test tools that are not designed to scale, limited test configurations and lack of complete APIs, which make integration with DevOps platforms inefficient and error-prone. It is important to have scalable test tools with good APIs. CT strategies include limiting the selection of test tools to ones that are DevOps-ready or DevOps-native and that have well-defined, stable APIs.

Test Environment Management

Scheduling and setting up resources into the needed topologies for running different types of tests for developers and testers can be a major bottleneck if not managed efficiently. Bottlenecks to CT include lack of test resource scheduling, which causes conflicts for resources, manual test setups, which are time consuming, causing long wait times for testing and delayed retesting. It is important to have test resources scheduling, test environment orchestration and resource utilization management. CT strategies include test environment inventory tools, test environment sharing tools, test environment orchestration tools and monitoring test environment utilization.

Test Results Analysis

Reporting and analyzing test results can be a major bottleneck after test execution is completed. Bottlenecks to CT include poorly written tests which can report confusing results and that take a lot of time to analyze. It is important to have design standards for test results and test results reporting standards. CT strategies include test verdict design in test cases, common test reporting tools and test analysis tools.

Steps To Implement Continuous Testing

Start with one or two services and a small set of critical CT practices, then expand to more services and more advanced CT practices.

A gap assessment is a great way to determine the current state of CT practices, and will help focus the implementation plan. Given a list of practices from each of the pillars in the continuous test blueprint, a cross-functional team of developers, testers and ops people can assign scores to measure importance and current level of practice to generate a gap score. The combined set of gap scores will give guide and direct current priorities for the CT plan.

For example, beginning CT priorities could be to establish a strategy sponsor, define quality goals, obtain an inventory of test resources and requirements, put in place version management for tests and test standards, tool selection and test refactoring to match the standards.

An intermediate CT goal could be to complete tool integrations with DevOps platforms, automate test scheduling, orchestrate test environments and optimize test results reporting.

With maturity, advanced CT goals could be to put in place advanced test creation strategies, accelerated test execution, automated test environment management and optimize test results analysis.

What This Means

Testing activities are typically a major source of bottlenecks that slow the quest for quality at speed. Continuous test strategies that accelerate all aspects of testing can have a major impact on speeding up lead time for continuous delivery of quality software. Implementation strategies that start by applying specific continuous test strategies to a targeted small number of applications, and then expand to more advanced strategies applied to more applications is an effective approach to CT adoption across the organization.

April 9, 2021
Boosting Time-to-Market by Improving Software Development
Today’s business environments require “agility” in terms of being able to quickly understand and adapt to information, trends and new developments. For example, a company might employ a business intelligence suite that provides them with real-time information on product sales, which allows them to dynamically adjust content or strategy.

Set a Baseline

You can’t measure improvement in a business process without first establishing a baseline. The first step in reducing the time-to-market for software development is to look closely at the current development process. Review the steps involved in turning an idea into a live product or product feature and identify any bottlenecks, inefficiencies and constraints. Once this review is complete, set realistic goals that reflect the current situation and the improvements you want to see within a certain time period.

Eliminate and Optimize

During the review and baseline phase, you might come across activities that do not add value and do not speed up the process. Perhaps there are some unnecessary meetings during the mid-phase of the development process that typically do not uncover any problems and hold no real value. Or, there’s a documentation step that is a drain on human capital and takes away valuable time from testing and innovation.

Identifying problems and bottlenecks is vital, but the efforts will be wasted if there aren’t open lines of communication. Poor communication causes software release delays, so establish efficient processes, set up the right team structure and adopt tools and technologies that allow transparent and fast communication between cross-functional teams. When it comes to teams, you want to find the right balance of staff. Generally, a winning team includes the right analysts, marketing managers and DevOps resources who can work together towards a common goal.

Streamlining and Developing Incrementally

As the team moves into development, there are steps you can take to increase efficiency. Independent tasks should be performed in tandem; for example, test scenarios built while various features are defined. Do not wait until development is completed before creating test environments; encourage the team to split parallel tasks that best match with their individual talents.

When it comes to enhancements for business apps, there’s an inclination to go for the “home run” by greatly changing the application and including many new features with every update. For reliability and speed to reaching the market, you instead want an incremental approach, by which you develop controllable enhancements and bug fixes that provide immediate value to the users. Prioritize the “wish list” of feature sets so you can better manage and plan the updates that will go into future releases. Get buy-in from other departments and then build and create an enhancements schedule.

Test Often and Embrace Automation

In addition to having testers test the application, you should actively engage with clients and select users early in the development process so they can provide input on the overall functionality and user interface as well as help discover bugs. Your time-to-market can be greatly impacted if bugs aren’t caught early on, and you might even need to pull a newly launched application if the glitches impact users adversely.

Improving this process requires defined and repeatable testing procedures and, to reduce time-to-market, these procedures must be automated at least partially.

Consider these other benefits of software testing that will improve your DevOps:
- Discovering bugs and software errors can improve the system’s capacity
- Testing can improve the security of your applications
- Improve customer engagement and satisfaction through a high QoE score
- Reduce the total cost of ownership
- Better meet industry standards and compliance regulations
Other automated processes should be introduced into the development cycle, including environment provisioning, data or API mocking; builds management; and standards enforcement. For instance, automated deployment solutions give DevOps a repeatable process so engineers have more time to focus on crafting new features. Another example is release automation tools that manage workflow as software moves between development, production and testing. These tools not only speed up the process, they also eliminate potential for human errors.

The modern business relies heavily on applications to communicate, complete sales and operate more efficiently. Companies strive to bring these apps to the market quickly so they don’t miss opportunities and can adjust to market conditions. To accomplish these goals, companies must adopt the right software development processes and tools to improve their time-to-market speed and capture a competitive advantage.

About the Author / Ajay Kaul

Ajay Kaul is managing partner at AgreeYa, bringing more than 27 years of experience in sales, consulting and managing small to large IT projects worldwide. Kaul has led AgreeYa through 16+ years of success, leading the company in highly competitive and complex markets and driving significant profitable growth with global workforce of more than 1,500. Prior to founding AgreeYa, he was responsible for managing engagements for Deloitte serving private and public sector clients across United States. Connect with him on LinkedIn.
March 1, 2017
The Big DevOps Question: How Do We Get Started?
Every conversation I have with clients regarding DevOps eventually reaches a point where the client wants to know my recommendations for getting started with a DevOps program. Some have already embarked on a DevOps program, but want me to critique their approach against what I see others doing. Others simply don’t have a clue how to make the necessary changes in their organization.

Ultimately, I sense in all these conversations a lack of confidence that their intended outcome is achievable and that they’re on the right path.

The first questions I ask clients are, “What are you looking to accomplish, and what are your business drivers?” Interestingly, 90 percent of the time clients are unclear why they want to embark on this journey. Sure, DevOps makes sense academically, but if you don’t have a clear understanding of your expectations for improvement most likely you’ll end up with more questions.

Sometimes it helps if I give prompts:
- Are you looking to improve quality in your production releases?
- Do you need to release updates and patches into production more quickly?
- What metrics are you currently looking at, and what makes you believe these are not optimal for your business?
This last question is really important. Quite often data represents invalid perspectives. Other industries’ and services’ metric of how often they deploy to production or how long it takes execute a release cycle might not be right for your business or industry. I hope medical device and airplane equipment manufacturers take a lot longer to bring something to production and test it more robustly than Netflix does its website.

In an earlier post I wrote that the need for DevOps is effectively the admittance of a problem; to wit, the cure is continuous delivery. Hence, I often tell clients that a very realistic place to start is not with the actual work, but with the communications methods and pathways that will affect implementing continuous delivery within the organization.

So many clients want to start their DevOps journey in application development and talk about what they’ve done with continuous build. That’s fantastic, but it has more to do with Agile software development than it does DevOps. If all that work creates bottlenecks in testing, you’ve accomplished very little. Now you must fix the flow to balance out development and testing. Trying to achieve continuous development through serial analysis and correction will take a long time and show little progress along the way—and often leads to abandonment.

However, if all the leaders of all the various areas involved in the continuous delivery cycle discuss how their efforts are impacted by what the other leaders’ groups do, everyone can see the bottlenecks and constraints and they can prioritize changes. Management often fosters much of the cultural impairment, as these changes can impact everything from workload to bonuses. Getting everyone involved in working together to eliminate the bottlenecks often buys credibility for the program and minimizes some of the individual adoption issues.

Don’t jump into the deep end of the DevOps pool just because everyone else is. Before embarking on your DevOps journey, do a deep analysis of your organization’s goals and baseline your current levels of performance. Discuss what needs to change based on real business goals and drivers (e.g., it takes us too long to issue regulatory changes to the system). Identify bottlenecks and constraints that exist in the current environment today and put together a plan to eliminate as many as possible.
January 18, 2016
The Conundrum of Adopting DevOps within Organizational Constraints

I wish I had a dollar for each time I’ve now heard, “we’re adopting DevOps, but we have to operate within the constraints of what the business is ready to accept.” Basically, this is becoming the battle cry of many enterprise IT professionals that are DevOps believers, but are stuck with the limitations of operating within a complex, political and immovable business structure.

One on hand, it is very pragmatic to approach adoption of new methods, techniques, technologies, etc. on a small scale and then expand based upon success. However, what is the result of a DevOps initiative in which existing organizational constraints and bottlenecks continue to remain in place?

If you’ve been in the business world for more than a few years you’ve probably already had the experience of having a really good idea only to come to the realization that implementation of that idea requires cooperation of another organization. For example, Marketing might have a great concept for how to acquire new customers, but would require sales management to provide incentives to the sales team for it to succeed. For purposes of this example, let’s assume that marketing has made its case to sales and sales rejects the proposal (many times there is a perception that the idea will be rejected limiting those from even trying; this is a worst-case scenario for any business). In this case, Marketing might attempt to operate around the need for the sales incentive and, ultimately, come to the realization to abort the plan or lower expectations for results.

Is anything more debilitating to morale then end up with these two outcomes as the only choices? What would you do if you were in the position of driving this for Marketing?

Often times in businesses there is no grievance committee. To steal a line from “A League Of Their Own”, “there’s no crying in business!” What DevOps is surfacing is that business is about relationships and managing cross-departmental and extra-departmental relationships is not something that many IT professionals have had to or want to foster. Ultimately, this will have a detrimental impact on DevOps adoption.

In most cases, DevOps requires that some leader within IT steps up with the idea to foster a frictionless ideation-to-operation lifecycle. By frictionless I mean the removal of as many bottlenecks and constraints for transitioning from the idea phase to a production-ready support application. Like Marketing in my earlier example, this may require this leader to “sell” their idea to the heads of IT Operations, Application Development, Quality Assurance, Information Security, and potentially C-level executives. A “No” response by any of these teams will result in the leader working around this limitation resulting in no change for the processes and work output of that particular group or attempting to do what they can within the organizational boundaries within their control.

Hence, business agility is tied to velocity of accepting change, which is further dependent upon individuals fostering a strong enough personal relationship–at a minimum one of mutual respect–to be willing to accept risk in support of a larger goal. I believe many would see this as a high-risk constraint on the business agility deliverable.

One way to increase likelihood of avoiding this trap? DevOps needs to be sponsored from C-level management from the start inclusive of the necessary incentives required to help drive the changes that will lead to more rapid adoption of DevOps practices and speed the way to business agility. There’s enough evidence now available to convince most C-level executives that a DevOps program is a worthy investment in moving their IT organization toward greater alignment with their business goals, producing faster, reducing operating overhead and improving quality.

As with most changes within IT, and DevOps adoption is no different, there is a requirement for bottom up support as those closest to the work need to believe, and there is a top-down requirement that provides the coverage, financing. motivation and accountability to the business to allow the change to occur.

November 20, 2014