The role and importance of software in today’s government agencies and organizations has increased dramatically. Digital transformation initiatives across federal, state, and local governments and their agencies have resulted in a new generation of applications that help to increase efficiency in agency operations, improve constituent service and otherwise help government organizations overcome their largest challenges.
Software is even revolutionizing military platforms and weapons systems, with AI and machine learning poised to become part of military weapons and vehicles in the near future.
With software becoming so essential for the government, it’s imperative that development teams that work within government agencies and within the government contracting industry embrace Software Development Management (SDM) best practices to ensure that applications do what they’re supposed to and are delivered when they’re needed.
To learn about the state of SDM within the development community, industry analyst, Accelerated Strategies Group (ASG) recently conducted a survey and one-on-one interviews with key industry leaders and experts. The survey found that, while SDM adoption across development teams is improving, a number of challenges, including organizational silos, software tool sprawl, and cultures that fail to foster the free flow of data, are keeping development teams from being as effective as they could be.
We sat down with Mitch Ashley, CEO for ASG to discuss the findings of their SDM report. During our discussion, he gave us a thorough overview of SDM and how this set of principles can ensure we are delivering projects that often are central to our organizations’ overarching strategies.
Here is what Mitch had to say:
GovDevSecOpsHub (GDSOH): How has the role and importance of software changed within organizations in the past decade? What unique challenges does that create within organizations?
Mitch Ashley: Software has become not just a necessary part of doing business, but really a strategic element of the organizational plan. That’s a result of the adoption of the cloud, and the software teams’ ability to deliver functionality and capabilities more quickly, and more responsibly to the needs of the organization.
The dependency on software is different than what it was ten years ago. Then, software was a business operations component, maybe a way of delivering services or capabilities through an online Web page or application
Today, the challenge many organizations face when delivering software is that they have to do it much more quickly and in much more incremental components. Waiting a year, or two, or three years for a big application to be delivered isn’t an acceptable practice. As a matter of fact, most organizations need changes, whether it’s new capabilities or changes to software that exists, in a matter of days and weeks, sometimes hours. Many organizations face very dynamic challenges, whether in a retail market, or a situation on a battlefield. And that means that the software teams have to respond in a much more rapid and incremental way. So that’s why you see things like Agile and DevOps.
GDSOH: What is SDM? Why do large organizations struggle with it? What negative ramifications can poor SDM have on an organization?
Mitch Ashley: SDM is about looking at the entire process of delivering software, not just writing code and testing. It is looking at what the requirements for the organization are at the front end of the process through to the creation, testing and deployment. That includes validating that what we asked for – paid for – to be developed is actually what gets delivered. That it delivers the benefit that we were looking for.
SDM ensures that what goes in, and what comes out of the development process are a good match. That’s essential because the organization is dependent upon the software being developed. SDM looks at the people, processes and tools across the entire lifecycle – including across non-software groups – to ensure that all elements of the software development process are transparent and that you get a full picture.
Without a full picture of the software development process, all stakeholders within the organization will be unaware of where the application is in the delivery process. They’ll know what capabilities they requested. They’ll know it’s being developed. But they won’t know if it is on time and on budget. They also won’t know if that desired capability will be delivered and that it’ll be valuable to the organization.
It’s also not just about delivering software. There are other parts of the organization that have to be ready to operationalize their capabilities in conjunction with the software delivery. When software hits production, there may be multiple organizations that have to be trained and have processes in place to allow them to make the organizational changes and adjustments required by changes in the software. They need to know what’s coming and they need to be able to rely on what’s going to be produced. This is why transparency and communication about the development process is essential across the organization.
GDSOH: Can you tell our readers a bit about the recent SDM study that your organization conducted? Who was surveyed? What kinds of information were they asked about?
Mitch Ashley: Accelerated Strategies Group was commissioned to conduct a study about software delivery management. This research was commissioned by Cloudbees, which is a product company in the developer space. We surveyed 153 individuals and conducted one-on-one interviews with people that are involved in the software delivery process.
Our goal for the survey was to understand the state of software delivery management across organizations, and what some of the challenges are to delivering software effectively. I think we accomplished both in this research.
GDSOH: Based on the responses you received, what did respondents say are some of the benefits of an effective SDM strategy within an organization?
Mitch Ashley: There were three essential areas that are identified as benefits or keys to successful software delivery management. The first was to be able to quantify the impact of the investment in software delivery. In other words, what is the outcome that we’re expecting? And, are we clear with stakeholders in the organization about that outcome? Because if we’re not clear what we’re looking to have happen, what we’re looking for the software to do, or the capabilities that it needs to deliver right up front, we are going to miss the mark.
The second is the capability of software delivery teams to communicate and collaborate both within the software team and externally. This includes the people involved in creating, testing, and delivering software, putting it into production, and with stakeholders – both vertically in the management chain, as well as stakeholders and other departments or organizations.
That communication – and the fidelity of it, the accuracy of it – is essential to hitting the mark of what we were asking for and what is delivered when software comes out at the end of the process.
The third crucial finding was that end-to-end visibility into the value flow of software delivery streams is crucial. In most cases, software development involves more than writing one application. Usually, when we ask for a capability, there’s more than one application or system involved. Sometimes it’s outside third-party applications.
And the complexity of creating software can be significant, especially if we have multiple software applications, multiple development teams. The timing and the value that’s coming out of each step in the process and the coordination of those different value flows, the streams of work need to be orchestrated to deliver a capability.
GDSOH: What percentage of organizations would you say have implemented an effective SDM strategy? What are some of the roadblocks or challenges keeping the others from doing so?
Mitch Ashley: I would quantify that we really focused on three areas; the ability to prioritize the development of features based on the expected impact, their plans to articulate or promote the value of that capability, and the ability to shorten the lead time for delivering those capabilities.
We found that organizations that emphasized those three areas delivered software successfully approximately 61-67 percent of the time. Interestingly, those that felt they were successful in those three areas also saw some of the same challenges as those that didn’t feel they were successful.
Some of the challenges that we identified included being able to accurately quantify the cost of delays of software capabilities. We always talk about delivering a certain capability at a certain point in time, costing a certain amount of money, or effort, or resources. Approximately 65 percent of organizations – which is a significant majority of the responses – found they were unable to accurately quantify the cost of feature delay or delivery delays.
Why is that important? If software is key to your operations, when it’s late, there’s a cost of the software being late. But there’s also peripheral costs for all the rest of the organization, such as potential lost opportunity and opportunity cost, because the reason we needed it has shifted or gone away.
Another challenge involves communication and collaboration. 84 percent of respondents said that the inaccessibility of information got in the way of their ability to do their jobs or to make data-driven decisions. And this related to silos that impede the free flow of information to practitioners, people developing software, as well as stakeholders, and senior leadership.
Another challenge involved breaking down the total cost of application development. It’s usually more than one group, one team, one organization that’s involved in delivering software. Organizations struggled with identifying the total cost of application delivery across all the functional areas.
Also, more than half of the respondents said that they couldn’t measure the cost of defects found after the release. Once it’s in software, in production, what’s the cost to the organization? That’s essential for teams to know since it can help them identify which defects are the most important to address first. Obviously, defects that are keeping software from operating properly are important. However, if you’re going to prioritize defects, you need to know what’s costing the organization the most and prioritize those near the top of the list.
GDSOH: What would be three tips, steps, or strategies that you would share with an agency or organization looking to implement an SDM strategy?
Mitch Ashley: First, be clear about the expected impact of software – not just the capability or the features. What do we expect software to achieve when it’s being used?
Second, make information transparent across the organization about the state of software delivery, what we’re delivering, what status it’s in, what issues we are running into, so that everybody’s operating from the same information.
Third, use that information across multiple pipelines of software delivery. You need processes and tools to help you have that end visibility and manage that complexity.
To learn more about SDM and see the full results from the ASG SDM study, click HERE.
