devopsy.kinsta.cloud

Category: Software Delivery Management

Reimagining AI-Assisted Coding for Team Scale in Enterprises

AI coding tools have advanced rapidly, but most are still designed around the individual developer. Their effectiveness depends heavily on a user’s ability to write understandable prompts, preserve architectural coherence across sessions, and identify areas that require additional work. This model works for some engineers, but it is far less dependable for a large organization’s development team, where software must align with defined standards, delivery processes and governance requirements.

Today, AI development systems that reduce reliance on individual judgment are coming to market. They bring embedded structure, constraints, and verification directly into the platform. For organizations, customer-facing products and portals, building custom, design-led, mission-critical applications, the question is no longer whether AI can generate code. The real question is what an AI coding platform must look like to enable repeatable, reliable delivery at AI speed.

The Limits Of Prompt-Based Development In Enterprise Software Delivery

Software delivery follows established patterns in most mature organizations. Teams work within approved technology stacks, design systems, security policies, and clear expectations around testing and release quality. General-purpose coding agents, however, typically require these constraints to be recreated through prompts. Developers end up pasting in long instructions and specifications, repeatedly re-establishing project context, reminding the model of standards, and defining what “done” looks like despite limited context windows that can drift as the codebase grows in size, scope, and complexity.

This model carries a hidden cost. Teams spend valuable time following and keeping track of instructions instead of building features, and results vary widely depending on who is using the tool. In environments with multi-disciplinary, cross-functional teams, that variability becomes a real risk. It can degrade user experience, undermine architectural integrity and increase review cycles and remediation efforts downstream.

AI coding products built for teams should treat specs, application architecture, context, and guardrails as historical context and information, embedded in the system, rather than as prompts.

Rules Before Creativity For High-Functioning Architecture

Historically, clean architecture was rarely the primary challenge in mature application environments. The real priorities were, and remain, user experience, consistency, long-term maintainability, and adherence to established standards. An AI development product built for teams should reflect that reality by providing a range of acceptable output so generated code always aligns with organizational patterns.

For this to be a reality, AI coding platforms must come with realistic, modern defaults and enforceable policies. This includes how components are prioritized, how data is accessed, which security checks are required, how errors are remediated, and which dependencies get the green light. When these constraints are built into the system, developers spend less time reviewing and correcting output and more time focusing on functionality and outcomes.

Specifications Should Be Structured, Modular And Enforceable

Specifications used in AI-assisted development are more effective when they are not treated as a single document. A spec should be structured in a way that aligns with how agent-based systems operate and modular enough for teams to apply only the relevant portions to a given feature without reintroducing full project context each time.

In practice, a specification model requires clearly defined sections for scope, constraints, project structure, conventions, and boundaries. Versioning enables changes to be tracked over time, while enforceability allows the system to detect deviations or violations rather than relying solely on text generation that appears compliant. This approach can function as a shared operating model for a team rather than a collection of individual prompts.

Structured Intermediate Models Help Preserve The Design

A key design consideration for AI coding systems is whether code is generated directly from natural language input or derived from a intermediary that captures intent before code generation occurs.

For team-based development, a multi-stage approach is often most effective. Here, requirements and design inputs are first translated into a structured representation of the application, such as screen composition, component mapping, bindings, and constraints, before framework-specific code is produced. This effectively eliminates the need to regenerate large portions of the codebase, limiting drift across iterations, and establishing a more stable reference point that can be reviewed and validated.

In design-led workflows, an intermediate representation also supports collaboration by allowing designers and product stakeholders to review intent at a level closer to their domain, while engineers retain responsibility for how that intent is implemented in code.

Policies Should Be Built-In And Consistently Applied

Organizations rely on policies or safeguards to manage risk and reduce variability across teams. When AI coding systems require individual users to define these policies in their prompts, the outcomes can vary significantly between developers and teams. Platforms intended for organizational use typically need to apply guardrails at the system level so they are shared and consistently enforced.

These policies should be in place at all levels. Some may take the form of hard constraints that prevent undesirable patterns and others may function as policy checks confirming architectural rules, security requirements and coding conventions. Workflow-related controls, such as review and approval steps, are also relevant. In design-led applications, user interface rules surrounding components, design tokens, and accessibility baselines play a similar role.

The purpose of these policies is not to limit the work being completed, but to ensure that increased development speed does not introduce additional operational risk or quality degradation.

Completion Criteria Should Be Provable And Clear

One recurring challenge in AI-assisted development is determining when work is complete. While code generation can be rapidly created, teams still need the confidence to determine when outputs meet acceptance criteria, pass required tests, integrate correctly, and comply with relevant policies. AI coding systems designed for team environments benefit from providing a clear, machine-verifiable definition of completion.

In practice, this involves associating requirements with acceptance criteria, expecting appropriate test coverage, executing checks automatically, and identifying gaps between the specification and the current implementation. Systems that can iterate in a controlled manner, proposing corrections and stopping when criteria are met, reduce the need for repeated reviews and increase confidence in the output.

Collaboration And Governance Must Be Supported By The Product

For AI coding systems to be effective in team environments, collaboration and governance capabilities need to be integrated into the product itself. Shared standards, templates, and design systems are necessary to ensure consistency. Role-based permissions help distinguish between who can modify standards and who can generate or modify features. Auditability is also important, enabling teams to understand which specification version informed an output and how changes were introduced.

Integration with existing delivery infrastructure, such as source control, CI/CD pipelines, and issue tracking systems, further supports adoption in established environments. Without these capabilities, AI coding tools are more likely to function as individual productivity aids rather than systems that support organizational delivery processes.

Distinguishing Between Tools And Delivery Systems

One way to assess the maturity of an AI coding product is to consider how much it depends on one’s ability to use it. When consistent results require advanced prompting skills and strong architectural judgment, adoption is likely to be limited. Systems that possess structure, preserve intent through stable representations, apply shared policies, and define what completion means are more accessible to typical development teams.

For organizations building design-led, customer-facing applications, this matters. The focus shifts from generating code more quickly to enabling predictable, repeatable delivery that aligns with existing standards and operational expectations.

May 4, 2026
Infographic: 8 Trends Shaping Software Delivery in 2022

[pdf-embedder url=”https://devopsy.kinsta.cloud/wp-content/uploads/2022/09/INFOGRAPHIC-8-trends-shaping-the-future-of-software-delivery-in-2022-Final.pdf” title=”INFOGRAPHIC – 8 trends shaping the future of software delivery in 2022 – Final”]

September 7, 2022
How Financial Services Companies Compete Better with DevOps
What will it take for financial services companies to compete (and win) in today’s software-driven marketplace? There’s no question the sector is hyper competitive – and getting tougher all the time. Tightening regulations, roller-coaster markets, competition from innovators and disruptors and consumer demands are keeping every player on its toes.

On the product development front, many financial services companies are challenged to keep up. Tool sprawl, legacy systems, calcified processes and the lack of automation can slow innovation and hobble efforts to meet compliance and governance mandates that get stricter every year.

Market leaders know that it’s no longer enough to be a great bank. The best ones are transforming to become digital disruptors and using DevOps principles to propel growth with innovation, out-compete rivals and deliver value to customers faster.

I recently hosted a webinar featuring executives from U.S. Bank, Broadridge and Forrester to find out where the financial services industry is headed and the ways digital transformation is turning great banks into technology-driven powerhouses.

These experts agree on the big picture: There’s a historic transition underway from brick and mortar banking to a new digital-centric world characterized by banking everywhere, anywhere and anytime.

This new reality is putting pressure on banks to fundamentally rethink how they deliver and govern new digital systems and redefine customer value.

A better way to innovate

To be competitive in the sector today, experts told us, innovation is paramount – even more so than speed. “While it helps to be fast, the focus should be on leveraging speed as a buffer that affords you the time to innovate and discover new routes to value,” says Charlie Betz, a principal analyst at market researcher Forrester.

Innovation will require experimentation, Betz says, and also a new form of decision-making. It’s an approach that is akin to going through a revolving door: It’s easily reversible. Of course, that way of thinking is what DevOps is all about: Continuous integration, automated delivery and a reliance on fast feedback so you can make fixes and changes earlier rather than later.

Think of it this way: By the time you pack that parachute and walk through that revolving door, the competition has been around that door half a dozen times and figured out a better way to deliver value to customers and has taken some of those customers from its competition. It’s no surprise, then, that when it comes to DevOps priorities, the leaders we talked with are focused on “shifting left” — that is, moving software testing and feedback closer to the early stages of development, allowing for faster fixes and more efficient experimentation.

Driving developer efficiency

At many financial services companies, a crucial objective for IT is to boost developer productivity, which in turn can help increase software velocity and quality. Measuring efficiency can be a bit elusive, though, but Steven Weinstein, senior vice president of technology service and solutions at Broadridge Financial settled on a good proxy: the number of Jenkins jobs they run per month. (They are currently up to 30,000 per month and increasing that total by 2,000 new jobs per month.)

Steven Weinstein, senior vice president of technology service and solutions, Broadridge
“By using CloudBees, we estimate we can save 15 to 25 minutes per run, freeing up developers to focus on product enhancements, eliminating software vulnerabilities and accelerating time to market,” Weinstein says.

Leaders also stress the importance of driving consistency and knowledge sharing across teams, and many are moving to a common software deployment platform powered by a single, integrated portfolio of tools. Breaking down silos and fostering cross-functional enterprise teams are important priorities for many of these organizations.

Others are ensuring a common experience by moving development to the cloud and mandating the use of a shared set of automation processes and tools prior to moving there. They are also sponsoring DevOps “communities of practice,” centers of excellence and self-service portals to help developers thrive in the new environment.

New governance models

Governance and regulations loom large in the financial services world and the leaders we talked to felt that the process of governance will change significantly in the digital era. Although the process would be slow, ultimately the new governance model must become more focused on principles versus processes. “It will be more about ‘what,’ not ‘how,” Forrester analyst Betz told us.

Specifically, a new governance model will need to accommodate increasing levels of technological dynamism, such as microservice-based architectures and continuous delivery, which is swiftly replacing what used to be a fairly predictable transactional architecture.

Experts foresee the end of “stage-gated governance” – a model better suited to the old world of “waterfall” software development. That’s when you paused after every “batch” so experts could come in to check over the code. “It’s like when guards in medieval times checked your cart before you could enter the city gates,” Betz says. “The industry will need to replace that model with new governance models based on the continuous software flows that now predominate in DevOps-powered organizations.”

Getting started

How do financial services firms get started on their journey to a DevOps transformation? Leaders say that it’s smart to start small with a project that you can be reasonably sure will generate business value. Getting early wins will inspire confidence among developers and business colleagues.

Swati Shah, senior vice president of emerging technology, U.S. Bank

What’s more, don’t take on too much risk by experimenting with a project that could put the business in jeopardy. And for the same reason, don’t try to tackle too much at the same time. “Don’t try to bottle the ocean,” says Swati Shah, senior vice president of emerging technology at U.S. Bank. “Start small then gradually go faster.” It’s also safer to target components that are architecturally modernized, such as APIs and microservices, which allow for faster experimentation. Finally, Shah recommends choosing a team of people who are genuinely excited about DevOps and passionate about learning new things. “This will help ensure success,” she says.

It’s about outcomes!

At the end of the day, financial services leaders say that the goal of DevOps shouldn’t be about DevOps itself but about business outcomes. DevOps is not an end in itself. It’s about striving for particular outcomes, making things better for our employees and more importantly, our customers.

Learn more about how DevOps can help financial services organizations compete better by clicking here .
August 3, 2020
The 2020 State of Software Delivery Management Report

To read the latest software industry research from Accelerate Strategies Group, download the report. To hear ASG discuss the results, listen to episode 77 of DevOps Radio here.

Despite years of embracing DevOps, organizations are nowhere near extracting maximum value and efficiency from their software delivery pipelines. That’s one of the key takeaways from a just-released survey of software organizations by Accelerated Strategies Group, an analyst company whose mission is to democratize access to industry expert knowledge.

The survey’s author, Principal Analyst Sanjeev Sharma from Accelerated Strategies, and Mitch Ashley, the company’s CEO, shared this frank assessment during a wide-ranging discussion with DevOps Radio about the current state of software delivery management in the enterprise. “Organizations are still working in silos 10 years after the DevOps movement started,” Sharma says. “And they’re still struggling with breaking down those silos.”

The fragmented development environment hurts productivity by blocking the flow of information from the people who have it to the people who need it. “Cross-silo information flow is still really bad,” Sharma says. “You have to jump through hoops to get the information you need to do your next task.”

CEO Ashley agrees. “Our mantra is ‘knowledge wants to be free,’” he says. By identifying and clearing bottlenecks in the flow of information across function, companies can better understand the business value of their software and deliver the “right software at the right time at the right place.”

Sharma says the point of effective software delivery management isn’t about deploying software faster or more frequently, but producing successful business outcomes – and that requires connecting the software development process with meaningful business value. “It’s totally irrelevant how fast you’re going if you’re going in the wrong direction,” he says. “That just results in software nobody uses, and it’ll cost you more to get back on track.”

Ashely and Sharma say companies will need to improve software delivery management to deal with the profound transformations happening in today’s economy, from the shift to remote working and commerce, to increasing cloud adoption, to the impact of emerging technologies like AI and machine learning. “When you’re talking about how you’re going to engage a customer and how you’re going to change your business model, those experiments, if not done properly, can result in investing a lot of money down the wrong path,” says Sharma.

In the recent survey, Accelerate Strategies segmented front-line “practitioners” from management-level “non practitioners” and found that most developers didn’t have as much visibility into the data as top managers. Too many managers believe that the data is for their eyes only and often try to control and sanitize the data before reporting it “upstream” to executives.

The result is that “practitioners feel cut off, they feel lost,” Sharma says. “It’s these cultural attitudes, these us-versus-them mindsets, that are contributing to the problem.”

The split can potentially sap the organization’s effectiveness, the survey suggests, often giving leaders a rosier view of what’s really happening on the ground and preventing development teams from making the fast course corrections needed to navigate a volatile market landscape. “If you believe you need to be able to fail fast, you have to be able to fail,” says Ashley. “You just have to do it on smaller scales, much quickly, and learn from it very quickly.”

The best strategy, Ashley and Sharma say, is to make data freely available to anybody who needs it through the right kind of dashboards, with appropriate security safeguards. “The mentality of joint ownership is what really creates the right environment for end-to-end software delivery management, where everybody has a part in the process,” Sharma says.

Tune in to Episode 77 of DevOps Radio to hear more from Sharma and Ashley about the state of software delivery management and their personal experiences navigating the world of DevOps.

August 3, 2020
Creating Software-First Businesses with SDM

Organizations striving to be “software-first” businesses are focusing their investments narrowly – on creating the best development and deployment practices they can. They’re implementing DevOps cultures, standing up CI/CD pipelines, integrating new sets of tools, training staff, and organizing new procedures – all to make software delivery more efficient.

To an extent, the moves are paying off. Tech leaders such as Netflix and Facebook are releasing multiple times per day, and cloud-native development initiatives are helping newcomers become more nimble. Organizations of all sizes and scope are deploying code faster, failing less, and recovering more quickly from downtime than ever before.

But is the software-first movement succeeding in its larger mission – to deliver quality apps that impress end users and generate optimal value for organizations themselves? That’s a question that stretches beyond metrics. It zeroes in on how organizations define the actual software delivery function and how high a priority they put on that function. Does software delivery begin and end in the DevOps process?

Or does it extend in both directions – further left, to how the product is envisioned, planned and prioritized, and right, to the way it’s marketed and sold – and back through a rapid feedback loop, to be continuously improved? Are organizations committing to sustaining end-to-end software delivery systems that remove any blockers?

They try. But they’re hamstrung by the toolsets and processes that govern today’s software sector. As organizations grow their DevOps maturity and then attempt to scale into the software-first mode, most will hit a ceiling. Unless they’re able to a) measure, manage and continuously improve their core CI/CD capability, b) fully connect software development efforts to the broader product and software organization, and then c) ultimately connect those efforts to the rest of the business responsible for bringing software successfully to market, they’ll fall short and no longer be competitive.

The root cause of this disconnect is that information is locked into stand-alone software tools and isolated within teams and functional groups. The teams have their mandates, and work within silos, without common processes, a common data model, a common language, or universal, shared insights. They collaborate amongst themselves but not as well with other teams and other functions across the organization. If they can’t work together, talk to each other, or share information, they’re flying blind. They don’t have the visibility they need to continuously increase and augment the value generated by the software.

This problem, of course, isn’t new. Organizations have been hunting for a software delivery “holy grail” for years. Plenty of SDLC/ALM fads based on shiny new “fully integrated” and opinionated tools end up costing money and wasting effort without generating much true value. All-in-one solutions usually involve ripping out the trusted tools, forcing engineering and development teams to learn a whole new way of work. They might be able to streamline some procedures within a small segment of the delivery process — but prevent using the right tool that best gets the job done, ultimately slowing things down.

What’s needed is a management layer that connects – and guides – all the functions related to software delivery. Here’s a look at a new concept called Software Delivery Management (SDM) that proposes a way to do this. It’s not a set of tools. It’s not based on proprietary technology. It’s not another process. It’s a foundation that brings organizations tools, teams, and processes together.

Software Delivery Management

Software Delivery Management (SDM) is a way of connecting teams and tools across an organization, enabling visibility, collaboration, and governance through a unified process and common data, to deliver better software faster, resulting in increased value to the customer and measurable business outcomes.

Just like DevOps breaks down the walls between the development and operations teams, SDM breaks down the walls between development, product management, UIX teams, documentation teams, support, and product marketers. It allows them to communicate better, understand each other’s needs, and ultimately make software that isn’t just bug-free, but also effectively addresses the business needs and creates value for the customer.

How do organizations build an SDM function? They can start by creating systems that enable the four pillars of an SDM model – common data, connected processes, universal insights, and all functions collaborating.

Establish a system of record: Build or buy a system of record with a common data model that brings in your different data elements. This would include a persistent and extensible data store, modeling software delivery lifecycle entities, and recording all software delivery activity to support subsequent queries, visibility, analytics, insights, and workflow orchestration. You can organize that data in a common model and language that everyone can access.

Have a flexible common data model to get universal insights: Either through APIs or some other way, you need to be able to connect different tools. The idea is to go beyond just your DevOps toolchain and bring in information from data sources such as CRM, Financials, and Support. Then you find a way to leverage that data – either through queries which then could bring invisibility or through insights that could then be turned into a policy.

Find a way to bring those things together. It’s the only way you can democratize that information so the development teams understand who’s doing what and when and with different components. Then your different stakeholders – product marketing, sales, customer success management, support – also have a view into this data. They may get it through a weekly report that someone is manually putting together and pushing out. But it still enables that visibility so people can plan and support the big initiatives that software delivery is putting together for a particular set of users or customers as improvements over what they’re using today.

SDM in Action

How does SDM work in practice? Here’s a hypothetical example of how a typical software delivery organization gets blocked by existing practices and how a software delivery management layer might help remove those blockers.

Let’s say the Product Leader at a music delivery business wants to upgrade a music player by adding three principal features: a better UI, an improved editing function, and a different way to package a playlist. Without an SDM strategy, this would likely be written in a standalone document as a set of complex requirements and then sent to the development team — and the dev team has no context on why the features are important. The Dev team would translate the requirements into a tracking system as user stories or features but without a complete understanding of the customer and business drivers. The fact that the CEO’s idea comes from data pulled from customer support tickets and RFEs is completely obscured.

Unfortunately, the display and editing capabilities weren’t expressed clearly in the original requirements document, and even more, was lost in the translation into stories. This gap goes unnoticed. The playlist capabilities were implemented incorrectly. The project is released to customers, but adoption is lackluster. Instead of the hoped-for reduction in support requests, support teams get a flood of requests from customers who don’t understand the user interface or are having problems getting it to work.

Meanwhile, a competitor who had the same market challenge releases a new set of features. The competitor’s new capabilities aren’t the same, but they meet the same customer needs. At first, the competitor also sees weak adoption but can rapidly integrate the feedback from the sales and support teams into new releases. After fixing the confusing user interface and providing appropriate documentation for the product marketing team, adoption soars. The competitor wins industry innovation awards, and our CEO’s music delivery company loses customers, revenue, and possibly even key developers who leave to work for the competitor.

If developers had known at the beginning why the new features were being developed, could they have suggested tweaks that deliver the same business goals? Better yet, had they understood the customers’ need, they may have been able to suggest an alternate approach that was even better. If support and development had access to common information and connected processes, could they have collaborated better? This is why it is important to bring development teams into the mainstream of business operations and planning.

SDM Strategy Adopted

If the music delivery company followed a Software Delivery Management strategy, the entire software development organization, and related areas would engage when the data from customer support was being discussed, before the display, editing, and playlist capabilities were settled on. Instead of a requirements document being thrown over the wall, development and product stakeholders would be able to engage in a conversation and have the context related to the business needs the features are being designed for.

Each story assigned to a developer would be linked back to a concrete business goal with the associated customer, market research, and expected outcomes. The developer would have the context and insights necessary to build and deliver the right functionality that meets customer requirements. Support could weigh in with input they have received from customers about the new functionality. Finally, the field organization could share what they have been hearing and seeing in customer and prospect accounts they have visited.

When the conversation about business goals and customer impact includes development, product management, UIX teams, doc teams, support teams, product marketers, and the field organization, everyone gets a more complete picture of how a feature is or is not meeting customer desires. Together, they can determine the best way to meet the business goals creatively and efficiently. If a feature isn’t working for end-users, that information is surfaced quickly and immediately integrated into future iterations.

If development on a particular feature has a bottleneck or blockage – a security vulnerability, a code quality issue, or a pull request waiting for review in the repository connected to this feature – information may be in the tools today, but it’s not surfaced centrally in the context of a feature. With SDM, multiple teams can see this immediately and act proactively immediately.

This will help the scrum team assess any potential blockers to surface this immediately, while you’re working, bringing this information transparently to the teams. If such blockers become a frequent issue, a good way to manage this is through the use of policies. Implementing policies along the software development process can help teams work more efficiently while also ensuring specific actions are taken promptly, or certain thresholds are met before moving to the next stage. The result is delivering quality, secure software to customers.

SDM also gives management the ability to assess the organization’s performance in different ways. In specific teams, tooling is in place to assess those teams’ efficiencies. But how did the business performance across multiple teams, across multiple workstreams, using different tools? It becomes more and more difficult to assess this holistically in one single place and connect it properly. And then, from that analysis, how did the business perform to create this output?

This goes into the CD and the CD process. Then from there, it lands in front of the customer. Who has access to it? Is it feature flagged? Is it accessible to everyone? What is the performance of this feature after we’ve implemented our improvement, our enhancement, or our new feature? How does this relate to what we set out to do – to improve the player’s user experience and to increase the engagement for our users? Can we measure this?

SDM gives more stakeholders more visibility into what others are doing. It’s really about sharing information to collaborate better – the intersection points between teams and roles and people. Like between Dev and Ops, it’s a collaboration between product owner, business and development teams. SDM is about connecting all the roles and functions for the full lifecycle – from ideation, plan, build, test and release, to realizing value to the business, along with a fast feedback loop to improve. Sales, field, and product marketing can use the information more effectively and plan better around it. Organizations can release products more quickly because of CD, but using SDM they can build supporting processes around it so they’re more effective.

Software Delivery Management not only allows for better decisions and expectations at the beginning of the software lifecycle – but it also extends the feedback loop throughout the software delivery process, through actual customer success, and back. This provides an endless loop of input about what’s working — and maybe most importantly, what’s not — to drive continuous improvement in software quality and functionality. This reframes the role of software delivery in the enterprise, recognizing it as a key business driver.

A Post-COVID Future

Creating a management layer on top of existing processes and tools is important in any environment. It makes sure products are getting out on time, they’re being developed with high quality, they’re secure and they’re meeting the needs of your users. Today, with the disruptions caused by COVID-19, it’s even more important. When you look across your software delivery process, you need to know where things are, where people are, how your work is progressing, and if blockers need to be removed. Manual steps that were OK before aren’t now. You have to automate it.

That’s where SDM comes into play. CI/CD is all about building the code, testing it, and getting it out. SDM gives stakeholders, both left and right, visibility into every aspect of the software delivery process. By linking information, teams, and processes, organizations get that extra level of visibility and insight to continue to evolve into software-first businesses in the future.

August 3, 2020
Why Software Delivery Management Matters
Continuous Everything: Why Software Delivery Management Matters

In the DevOps world, implementing continuous integration and continuous delivery (CI/CD) is a long and arduous digital transformation process. That said, many organizations are succeeding and reaping the benefits of automation. Despite an organization’s ability to deliver software faster, there’s still missing gaps from silos that exist between various business functions across the organization. This slows down the flow of information about the software delivery process and hampers the ability to optimize various departmental functions based on lack of – or outdated – information.

Enter the emerging category of Software Delivery Management (SDM).

SDM breaks down silos, providing visibility across an organization into the software development lifecycle. It relies on four foundational pillars:
- Common Data
- Universal Insights
- Common Connected Processes
- All Functions Collaborating
These pillars support a unified system of record in which all functions can enjoy continuous insights and feedback, resulting in faster software delivery and positive impact on the business.

To learn more about SDM, this whitepaper will help you understand how and why SDM is evolving and the benefits it will provide to your organization. Break down the silos and see how the business of DevOps and Software Delivery Management can transform your organization into a faster software delivery machine.

If you’re interested in participating in the CloudBees SDM Platform Preview Program, click on this link.
August 3, 2020
DevOps Chat: ASG State of Software Delivery Management Report

Accelerated Strategies Group has just delivered its “State of Software Delivery Management Report,” commissioned by CloudBees. In this DevOps Chat, we speak with Mitchell Ashley, CEO, founder of ASG, about the report and why it is important for everyone managing software delivery today.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

devopsy.kinsta.cloud · State of Software Delivery Management Report, Accelerated Strategies Group

Transcript

Alan Shimel: Hey, everyone. This is Alan Shimel, and you’re listening to another DevOps Chat. I have a really great chat lined up for us today because I’m joined by my partner, Mitchell Ashley, founder, CEO of Accelerated Strategies Group. Mitchell, welcome to another DevOps Chat.

Mitchell Ashley: Well, very nice to be here. It’s great to be on this side of the microphone for a change. [Laughs]

Shimel: It is kind of. I mean, Mitchell, before we jump into the report out of Accelerated Strategies Group we want to talk about, just as little history for our audience. Mitchell and I have been doing podcasts together now –

Ashley: Oh my.

Shimel: Fifteen years?

Ashley: At least. 2004 or ’05, something like that. Yeah.

Shimel: So it’s still secure after all these years.

Ashley: I was waiting for the,”This is Alan Shimel and this is Mitchell Ashley.” [Laughs]

Shimel: Exactly. Do you remember those days? Oh my goodness. You know what’s old’s new. It’s good to have you on with me, Mitchell. You know, as you said you’re often on this side. You and I kind of split up our hosting duties for DevOps Chat. But we’re here today because Accelerated Strategies Group just dropped a report on the state of software delivery management, SDM.

Ashley: We did.

Shimel: And the report was commissioned by our friends at CloudBees but it really is the independent analysis and research of you, Sanjeev Sharma, principal analyst at Accelerated Strategies Group, and the rest of the Accelerated Strategies team. So, you know, we’ve done a little video on this, Mitchell, but I’m going to assume our audience listening here on DevOps Chat maybe didn’t see the video.

Ashley: Okay.

Shimel: Why don’t we start off – when we talk about SDM, what are we talking about here?

Ashley: You know, we used to – we’ve had all kinds of names for methodologies, you know, software development lifecycle management, blah, blah, blah. You know, what I think it’s really about, software delivery management is about the whole delivery, the end-to-end process of how do you manage the software process from here’s money, we’re going to invest in something that we think is going to be created through software; how do you know through the whole machinations it goes through to actually create the software that you know where you are and what you think you’re going to be getting? And then when it’s all done how do you know that you got what you thought you paid for? To think about is sort of as a business view into managing the software process.

So not just IT and product teams but also the executives, senior leaders, can find out what the heck is going on and how well – it’s really about how well do we develop software and how well – our ability to manage it.

Shimel: Yeah. I agree. You know, we had this discussion earlier with Sanjeev as well, correct, and, you know, in my mind it’s about how do we manage the factory rather than how do we work on the assembly line? A lot of software today, especially in the DevOps world, is about how do we work on the assembly line? And that’s a noble, worthy thing to do.

Ashley: It’s important, yeah.

Shimel: Right. That software delivery pipeline, that factory, you know, assembly line as we move software left to right. But, you know, someone needs to be managing the controls, right? And are we doing it just in time? Are we using lean? And if so, how? You know, even lean you always need to be turning a dial and checking things out.

Ashley: Exactly.

Shimel: I’d like to talk a little bit, Mitchell – well, let me – let’s first start with this.

Ashley: Sure.

Shimel: Of course the mantra at Accelerated Strategies is information wants to be free, and in that vein this report is free and open to anyone – anyone – who’d like to download it, right?

Ashley: It is. That’s our belief. I mean that’s really what we founded and you were part of founding Accelerated Strategies group two, is let’s do something disruptive in the analyst industry. You and I have paid an awful lot of money to analysts for sometimes questionable [laughs] – what are we getting for it? – but we have to do it, right?

Shimel: Well we paid for access.

Ashley: We paid for access even though that’s – you know, everyone says it’s not true –

Shimel: [Inaudible comment]

Ashley: – but it is. I mean let’s be honest about it. I think it is anyway. With Accelerated we said, “Look, we’re not going to pay –” you know, every time you touch an analyst you had to pay him. Every time you said something to him you’re like dropping in another coin. And let’s do this the right way. Let’s do this – when you’re working with us, engaging us to do something for you, you know, do some research, assess the market, advise you, do a strategic project, do some competitive analysis, all of those things for a research report, that’s when we’ll make our money. You are welcome to distribute that as freely as you like.

We’re not going to hold you behind a paywall and subscription fees and licensing. The customer’s give us all that information. Why don’t we give it back to them in some meaningful way [laughs] instead of making them pay for it? That’s –

Shimel: You know what, Mitchell? I think back to the days where we would pay, you know, a certain large analyst company to send an analyst out to spend the day with us, and we’d pick them up at the airport and get them breakfast and lunch and, you know, keep – wine and dine them all day while trying to get him to understand our point of view, and when I drop him back off at the airport, I’ll be honest with you, I felt a little dirty.

[Laughter]

Ashley: And it kind of felt like, why do I feel like we know more about this space than the analyst?

Shimel: Yeah, there was no doubt that I felt like I knew more about that space, but, you know – and I’m not – look, everybody needs to make a living and there’s the oldest professions in the world, but I really felt like I – I didn’t like paying for it. You know what I mean? And there was definitely some of that involved. But enough about the analysts. _____.

Ashley: We could do, like, three podcast episodes on that or more.

Shimel: Yeah. We can go off on that. What I want you to talk about though, Mitchell, is would you share with our audience a little bit of insight? How was the research done here, the analysis? I know Sanjeev Sharma, principle analyst, was lead author on this report, but give us an idea of, you know, the ASG methodology, if you will.

Ashley: Well really any research has to start out with some hypothesis; what do we believe about the market or what do you think we believe about the market? And really the hypothesis here was around what’s the maturity level of our ability to manage the entire software delivery process? Connecting it to the business, not just inside of IT. So we started with that and we have a target audience who we’re trying to talk with, both individual contributors, leaders in the software development part of this but also executives, product people, CIOs. So we really tried to cast a big enough net but not so broad that it all got watered down and you couldn’t tell who said what.

We really spent some time focusing on who we wanted to talk to. And it wasn’t a short survey but it wasn’t a long one. There were really some insightful questions around do you know what your backlog looks like and what it costs you to delay a release or to trade something off one feature for another? Do you really know when you’re going to get the release or the functionality that you’re paying for so you can move the business forward based on those plans, or are you kind of shooting in the dark and you’re just hoping that it comes out sometime in the next quarter and we’re good and then we’ll kind of get everything running from there? So we did a survey, but we did a lot of kind of research going into it, talking to different people in those roles before we ever built the questionnaire.

So it’s not just a research firm that says, “Okay, what do you want us to ask? Let’s build you a survey.” You know, Sanjeev and the other analysts with Accelerated Strategies Group are all practitioners. They’ve done this, they’ve worked in this field, they’ve led software teams, projects, companies, they’ve consulted with big enterprises, small startups, medium-size companies. So all that to say it was really, you know, our best attempt at let’s get the best information we can when we go out and ask people for where they think they are with their maturity curve and where they really see the challenges, and we got some fantastic results. It was super, super insightful and kind of exciting to see, you know, what things we thought were true and what maybe some things were, hm, that’s a little bit of a surprise.

Shimel: Yeah. Okay. I guess you kind of opened that box now.

Ashley: Did I set it up well enough?

Shimel: Yeah. I think you got it. So let’s start with the surprises.

Ashley: You know, so one of the biggest things that everyone – I don’t want to say everyone – one of the biggest outcomes of this research was around everyone’s ability to understand the value they’re going to get from their investment, right? Spending how much money on this software IT organization, product team whatever, and what am I really going to get at the end? So it’s very clear it’s very unclear to the people funding the work, that they essentially understand what they’re going to get. You just can’t get to that information or get a straight answer.

We aren’t connected well enough into it to really understand it, which kind of goes to the second key finding was the communications around the whole software creation process is broken. It may work within a development team that’s really functioning tightly together or an Agile team with a product leader that they’re working with day to day, but outside of that, both kind of horizontally but also vertically in the organization, the perception at senior leader levels versus the individual and the team levels that are building software can be much, much different. So can you imagine making – well, we’ve done this right, Alan? – making multimillion, maybe much, much, much larger decisions based on what you think is going on and that’s not really true.

So that’s a huge issue. If we really believe in software is leading the world, that all businesses are software companies, you have to be – you’ve got to fix that. That’s got to be taken care of. And then the third area is basically all the way through the delivery pipeline and understanding the value flow. Where are you creating value and where are you actually spending energy and not getting value? Maybe getting the wrong output out of the software process. Because an example I like to use is software teams like to measure how many releases we get out per day, sometimes per hour. I mean that’s a great thing. It sounds like a really awesome thing to accomplish. But if it’s the wrong thing, wrong software, it doesn’t matter if we’re releasing it a million times an hour. I’ll take one release a month if it’s the right thing instead of a million releases every day and all of them aren’t hitting the mark.

Shimel: Yeah, I agree.

Ashley: That’s an extreme, but that’s really what it is, is understanding through that whole – and again, we’re talking about not one pipeline of work, one value stream of work; it’s across multiple, because almost every app touches all kinds of systems, data, you know, especially in a large enterprise – mainframe, stuff in the cloud, stuff that’s maybe kind of the older client server but still around, whatever it might be. So those are the three key areas that we identified that if you can assess where you are and how well you do that part of the software development, that will make the biggest difference in sort of upping your game and your ability to deliver software.

Shimel: Agreed. Agreed. You know, I guess I’m not surprised but I am surprised in that, you know, the first thing I learned about DevOps was it’s about breaking down silos, bringing dev and ops together. We’re going to break those silos. Kind of like the Macintosh 1984 commercial, remember?

Ashley: [Laughs] The girl and the hammer, yeah.

July 23, 2020
State of Software Delivery Management Report 2020
Accelerated Strategies Group conducted the State of Software Delivery Management 2020, surveying software delivery practitioners and key industry leaders to assess the current state of software delivery management (SDM) and examine the impact of SDM adoption as a capability. The primary research, commissioned by CloudBees, was published on Tuesday, July 21.

The State of Software Delivery Management Report 2020 defined SDM as “a core competency for any organization or team responsible for delivering business value via software applications and systems.” The report studies the impact of SDM and how it helps organizations accelerate their digital transformation by providing the necessary tools to effectively and efficiently deliver software.

The report identified three key SDM capabilities to help organizations increase their software delivery efficiency and effectiveness:
- Organizations must quantify the impact of their investment in software delivery.
- Organizations must enhance the ability of software delivery teams to communicate and collaborate.
- SDM can provide end-to-end visibility into the value flow of their software delivery streams.
Based on the results of the research, adopting SDM strategies can help mitigate major challenges faced by software delivery practitioners, IT management, product stakeholders and executive leadership, and improve an organization’s ability to deliver software in a lean and agile manner. SDM capabilities provide businesses the ability to effectively make decisions on where in the value stream to invest, and to quantify the impact of their investments.

Download the State of Software Delivery Management 2020 to learn more about SDM and to get insights and access to all the data Accelerated Strategies Group gathered from one-on-one interviews with key industry experts.
July 21, 2020
Software Development Management Drives Business Value

How much business value does your software group generate for your organization?

That’s the existential question an international corporation’s software leader poses, kicking off the 2017 book “The Business Value of Software.” It’s also a topic we’ve all likely wrestled with from time to time. It’s the essence of the value we personally bring to the business through our daily actions.

The problem is, value is hard to define and hard to measure. But, it’s easy to see how business value can seep away from software initiatives when software projects start to experience problems.

When production is delayed, and software releases don’t go out on time, sales will fall short of projections. When a release doesn’t satisfy customer needs in a specific market, negative user reviews will spike–and that could impact future sales. When market trends shift suddenly, and business unit leaders have no clear way to push the development team to add new features to the product, that’s a missed market opportunity.

With every misstep, you’ve lost a certain amount of business value.

Conceptually, every one of these situations is fixable. To an extent, some companies have adopted practices that can catch certain problems before they become unfixable. But, to a greater extent, the inability of software-driven companies to anticipate trends, flag problems, share information, iterate on solutions and learn from mistakes is costing them business.

In this blog series, we’ve discussed how software delivery management (SDM) presents a framework for organizations to change the way they think about software and streamline delivery processes. SDM seeks to connect all aspects of the software delivery process to not only become more efficient but also drive toward a common goal of delivering maximum business value.

The SDM model is built around four key pillars: ensuring everybody is working with common data; sharing insights and continuous learning across the organization; connecting processes to bring ideas to market; and enabling closer collaboration across software-related functions and teams to amplify value creation efforts. It emphasizes that software doesn’t have to go it alone–the whole organization is rallying around software and making it a top priority.

How does an interconnected, collaborative, information-driven software organization create business value using SDM? Here are a few ways.

Leaning on Analytics

Rather than just using discrete build-test-deploy processes, make sure management, developers, marketers and engineers are all incorporating key analytical measures in their iteration processes. These stakeholders shouldn’t go on hunches–they should base their decisions, at least in part, on data. The data includes downloads, adoption figures, conversions, support requests and customer experience performance ratings. Armed with information, the organization will do a better job delivering the software customers want and are willing to pay for.

Helping People Ask the Right Questions

Developers are a prideful bunch. They want to build great software that users love to run. Without insight into business needs and user preferences, they’ll do their best with features and functionality. With data sharing and communications channels in place, they can ask questions like “Where is this feature being deployed?” or “Why will customers want a whole new interface?” Consequently, ops pros can ask, “Who pushed this new release to production and when?” VPs can ask whether the latest round of releases will be ready for the big marketing push to launch it. If you’re asking the right questions early enough in the process, you’re going to make better decisions and be doing a better job delivering on business goals.

Being Nimble Enough to Change Quickly

Organizations pride themselves by their ability to act in an agile manner. But, are they really set up to move on a dime? Say a well-researched release flops unexpectedly. Sales and support rapidly gather feedback that European users hate the color and APAC users hate the navigation path. Because all the stakeholders are aligned and ready to move, developers tweak the features, ops leaders juggle the release schedule, management relaunches with regional marketing campaigns, sales follows up with targeted incentives and developers watch for more user feedback that can be incorporated into future releases.

Your company has worked hard to turn itself into a software-driven business. Using the principles of SDM, your business can drive business results to the next level. It can generate more sales. It can make unhappy customers happy. It can make happy customers even happier. It can improve its own responsiveness, up and down the organization. Most of all, it can use software to achieve its ultimate goal: to drive business value.

April 30, 2020
How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes
Since Jez Humble and David Farley popularized the term in 2010, continuous delivery has revolutionized software delivery practices.

Creating mature continuous integration/continuous delivery (CI/CD) pipelines has helped enterprises deliver software that performs better, based on a long list of metrics. Failure rates have dropped from 50% to under 15%, and cycle times are measured in hours, not weeks. Organizations get to market faster and release products into production with fewer bugs.

But, there’s a limit to what CI/CD can provide. CI/CD connects only the parts of the software lifecycle that happen inside DevOps. It doesn’t provide insights into where the delivery cycle is breaking down, whether the software is helping the business meet its internal key performance indicators (KPIs), how customers are responding to it or whether last week’s release is achieving the internal efficiencies the business was projecting.

A More Holistic Approach

This is where a more holistic approach to software delivery can help. As we discussed in a previous blog, there’s a move afoot to recognize software delivery as more of a core business process and connect all the aspects of this process in one new, interconnected discipline.

The new discipline, called software delivery management (SDM), changes the game by going beyond CI/CD and empowering developers and other stakeholders to best collaborate and creatively solve problems. It gives them the data, insights and best practices that allow them to truly continuously improve, keep value flowing and efficiently develop and deliver the right products and features to customers.

To follow SDM principles, a management solution needs to rest upon four key pillars: common data, universal insights, common connected processes and having all functions collaborating.
- Data: All information within and around software delivery activity would need to be captured and stored with a consistent domain model to enable and facilitate connected processes, shared insights and collaboration.
- Insights: Visibility and insights would need to enable a common understanding and continuous learning from data across, up-and-down and throughout all functions in the organization.
- Processes: Processes would need to orchestrate the entirety of the software delivery value stream and connect functions together to efficiently bring ideas to market with maximum value and adoption.
- Collaboration: All functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.
This holistic approach helps organizations in a number of ways. Here are three benefits DevOps managers can net in terms of the way they work, collaborate with development teams and connect with peers throughout their organizations.

Faster Development

The current process can be slow and tedious. Developers use tools configured to perform one task, and getting a complete end-to-end view across the toolchain is difficult. An SDM solution stores all the artifacts and data from disparate tools that move software from idea to deployment in a unified common data layer. The information is connected and available for those who need it, when they need it and in a form they can use. Just forging these connections will save hours of time looking for data, checking statuses and tracking issues throughout the delivery process.

Better Software

If stakeholders have no end-to-end view of the development and delivery process, they have no way of knowing if the software is meeting the organization’s business objectives. With SDM, the continuous feedback loop established with CI/CD and DevOps is extended to fully include all stakeholders from the ideation phase through user adoption and back to ideation. Better insights are tracked more closely and shared more widely, helping developers do a better job of delivering what the users want.

Better Collaboration

Developers and business leaders don’t collaborate well for a number of reasons. Developers often don’t have a good feel for how a product is going to be used, and business leaders usually don’t have insight into what’s in development or when it will be delivered. This is complicated by scattershot communications processes–where both sides have to sort through spreadsheets, connect over email threads and wait for meetings to move processes forward. With SDM, the silos between the software organization and other stakeholders are broken down, so both sides can share information, communicate more directly and drive toward solutions.

In an upcoming blog, we’ll explore other examples of SDM in action and dive into the business value it creates for organizations.
April 23, 2020