devopsy.kinsta.cloud

Tag: Software Delivery Management

  • CloudBees Makes Software Delivery Management Apps Available

    CloudBees Makes Software Delivery Management Apps Available

    CloudBees, during an online event today, officially launched the first two modules of what will become a portfolio of software delivery management (SDM) tools delivered via the cloud.

    The first two modules have been previewed for the last year, now are generally available. The first is the CloudBees Engineering Efficiency module, which provides a system of record to normalize data in a way that makes it possible to surface metrics, analytics and actionable insights.

    Shawn Ahmed, senior vice president and general manager for software delivery automation for CloudBees, said the analytics application initially will pull data from CloudBees DevOps platforms and complementary third-party tools such as GitHub and Jira and eventually will expand to include data pulled from other continuous integration/continuous delivery (CI/CD) platforms. CloudBees Engineering Efficiency connects to more than 70 different DevOps tools. CloudBees is also making available an application programming interface (API) through which third parties can extend the module.

    The goal is to enable DevOps teams to make decisions that are informed by data rather than just gut feel, said Ahmed, noting that data can then be employed to coach DevOps teams in a way that allows them to become more efficient.

    The second module is CloudBees Feature Management, which gives DevOps teams control over how individual features are released. Organizations can manage features holistically by grouping and controlling sets of feature flags that determine what capabilities are exposed within an application. That capability makes it possible for organizations to de-couple the release of a specific feature from the rest of the delivery of an application.

    At a time when organizations are accelerating the rate at which applications are being developed and deployed to drive their digital business transformation initiatives, the ability to control how features are rolled out has become a critical element of managing the overall end user experience.

    SDM tools are part of what has become commonly known as value stream management applications. The debate that is currently occurring is to what degree these applications should be provided by the vendor that makes the CI/CD platform versus an independent software vendor (ISV) that aggregates data from multiple platforms. CloudBees is betting that as DevOps processes mature within organizations, more of them will prefer to deal with a single vendor capable of providing both the underlying DevOps platform and the tools required analyze and manage DevOps processes.

    Longer-term, Ahmed said the infusion of predictive analytics capabilities enabled by advances in machine learning algorithms means it won’t be long before organizations will be able to know if a build will fail even before it runs.

    It will be up to each organization to determine how they will apply analytics tools for DevOps processes. Ideally, the DevOps culture in place stresses collaboration and training. However, there may be some organizations that will look to use these applications to increase productivity by weeding out members of the DevOps team who lack the appropriate level of expertise. The applications being provide by CloudBees, however, are designed to identify issues in the aggregate rather than enable organizations to identify the faults of a specific member of the DevOps team, noted Ahmed.

    Like it or not, analytics applications soon will be applied more broadly to DevOps processes. The challenge and the opportunity now is determining the next best course of action based on the insights they surface.

  • DevOps Chat: ASG State of Software Delivery Management Report

    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.

    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.

  • State of Software Delivery Management Report 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.

  • SDM and the DevOps Delusion of Connected Organizations

    SDM and the DevOps Delusion of Connected Organizations

    How Software Delivery Management Clears Up the Confusion of Embracing and Implementing DevOps

    Since the term was coined back in 2009, it wouldn’t be a stretch to describe DevOps as an impactful if not tectonic shift in software development and delivery in the past two decades. The move to implement DevOps has encouraged, among other things, better collaboration between siloed Dev and Ops teams, more reliance on automation, more focus on culture and better use of feedback loops to refine delivery processes.

    In theory, DevOps has been a game-changer. But, in practice, its usefulness is more difficult to define. As DevOps enters its teenage years, the idea of a fully integrated software delivery function aligned toward a common goal of generating business value is more illusion than reality.

    Are DevOps teams themselves as connected as they should be? The reality is that developers and operations personnel tend to have their own versions of “dev DevOps” and “ops DevOps,” working against each other inside supposedly integrated teams. Though they may have set up deployment pipelines, each side tends to use its own tools, access its own information and follow its own cadences, leading to occasional missed handoffs and delays in delivery schedules.

    Looking across the enterprise, DevOps cultures fray further. A perfect DevOps practice envisions teams in different departments, business units and geographies all in sync, delivering value via software on a reliable cadence. In reality, enterprise DevOps is difficult to pull off because most organizations haven’t implemented shared languages, comment processes and best practices across all of their teams with management buy-in.

    Then there’s the issue of connecting DevOps functions with the rest of the organization. Some definitions of DevOps extend the concept of collaboration to other stakeholders beyond conventional engineering functions, such as quality assurance, testing and security. But how extensively does a DevOps culture tie together the goals, needs, resources and processes of others in the organization that rely on software delivery, such as product marketing, sales and executive management?

    Delivering Better Software

    Gartner describes DevOps as being focused on “rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach.” In other words, delivering faster and in a more organized manner. But has DevOps helped software-first organizations deliver better software? Has it helped them institute the right processes to deliver the right software at the right pace to drive the most value possible to the organization’s bottom line? Paraphrasing the “If a tree falls in the forest …” proverb: If you deliver software and no one is there to consume it, have you truly delivered value?

    Even if you’re doing DevOps relatively well, there’s a level of integration that’s missing from today’s software cultures. It’s the mission to tie together all functions of software delivery—not just those relating to what goes on in the labs. It’s the commitment to do more than just deliver better metrics. It’s the mentality to define everything relating to software delivery as a discipline all its own, like finance or sales—not just serving other disciplines.

    A new technology category is emerging that aims to build on what DevOps has accomplished and extend those gains across the software delivery function. It’s called software delivery management (SDM). An SDM strategy is based on four foundational pillars that elevate software delivery to a core business priority, reflecting the level of importance software has achieved in today’s business environment:

    • Common Data – All information within and around software delivery activity is captured and stored with a consistent domain model to enable and facilitate connections to processes, shared insights and collaboration.
    • Connected Processes – Processes orchestrate software delivery and connect functions together to efficiently bring ideas to market with maximum value and adoption.
    • All Functions Collaborating – All functions and teams within and around the software delivery organization work together to amplify value creation efforts.
    • Universal Insights – Visibility and insights enable understanding and continuous learning from data across, up and down and throughout all functions in the organization.

    Driving Improvements Across Organizations

    Adopting an SDM strategy on top of an existing DevOps culture can help an organization in a number of ways.

    Having disconnected tools, disconnected data and a lack of common language make it difficult for one side of the organization to know what the other wants. Even in mature DevOps implementations, software delivery ends up being a patchwork of different processes for different teams.

    It’s also difficult to determine if our teams are delivering the right end product if there’s no shared visibility and insight. SDM helps by establishing common data and common processes, giving visibility and insights across teams of different maturities, different tools and different technologies so you get all functions to collaborate. That way you can be sure you’re not just deploying more—you’re actually delivering continuous value.

    You can’t manage what you can’t measure. What SDM offers is a model to understand how you’re performing with DevOps by and large, what teams are performing well and what teams aren’t, and how you can leverage those insights to improve.

    Tips for Implementing SDM

    Here are five ways SDM build on the successes of DevOps:  

    • Integrate your tools: Disconnected toolchains make it difficult, if not impossible, to orchestrate a delivery process end to end. Try to get DevOps tools onto a common platform where they can share information across teams and organizational functions.
    • Capture data: Ensure you’re establishing an audit trail and capturing data on events and actions that are taken across that end-to-end process. Then collect those data points in a common data store as normalized objects. Making common data accessible across functions allows you to, for example, reconcile a particular support request to the right user story and commit to the right change that is being deployed out to a server.
    • Don’t fail to communicate: Once you’ve created your data store, establish a strong relationship and regular communication with the business side of the organization. Continuous delivery isn’t just for developers anymore; software delivery functions have to address business needs. That can’t be done without high levels of communication.
    • Establish KPIs: You should have a taxonomy or hierarchy of business objectives you’re trying to achieve with your DevOps implementation. Establish the hypotheses that can achieve those objectives and then integrate the features/user stories or implementation-level entities that will drive you toward them.
    • Leverage observability practices: This needs to be done so you can measure those performances against KPIs. If you believe that updating your user interface will increase the amount of time users spend in your SaaS application, you need to establish what that target KPI is. Then, as those changes are delivered, measure, analyze and adjust to continue to drive those toward the hypothesis.

    Conclusion

    DevOps has taken software delivery a long way and implementing an SDM strategy can take it the rest of the way. It won’t change DevOps, but it could reinvigorate the practice. Deploying both strategies in concert, software delivery management and DevOps can focus less on automation and tools and more on the outcomes and on the people and steps involved in driving those outcomes.

  • Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint Dives Deeper into Software Delivery Analytics

    Pinpoint has extended its platform for managing software delivery to include the ability to analyze historical events to facility team reviews as well as more accurately predict where bottlenecks are likely to emerge based on the past performance of the DevOps team.

    Company CEO Jeff Haynie said the company’s namesake software is employed today mainly to identify existing software development bottlenecks. Pinpoint is now making greater use of machine learning algorithms and advanced analytics to surface additional insights and recommendations, he said.

    Designed to collect data from multiple tools and platforms spanning a DevOps process, Pinpoint automates most of the tedious tasks associated with collecting the metrics required to manage a distributed development team, Haynie said. With more developers working from home in the wake of the COVID-19 pandemic, that ability to collect metrics automatically also plays a key role in allowing application development managers to set more meaningful agendas for meetings that now occur via videoconference rather than in a physical conference room.

    In effect, the application development process can no longer be managed by simply walking around the office to find out what everyone is working on, he noted.

    The analytics should also serve to make events, otherwise known as ceremonies, more meaningful because they can include metrics detailing what was actually required to achieve a specific goal, he added.

    Ultimately, the goal for any DevOps team should not be to simply write more code faster. IT leaders need to make sure the right code is being delivered at the right time to ensure application development projects stay on track.

    Providers of various DevOps platforms have been investing in tools to manage the software delivery process. However, each of those offerings is optimized for a specific platform. The Pinpoint dashboard can be integrated with any platform, including Azure Team Foundation Server (TFS), GitLab, GitHub and Bitbucket. Assignments made in Pinpoint can also then be automatically reflected in these platforms as well as project management applications such as Jira, said Haynie.

    One of the biggest issues with software engineering is that, from a business perspective, it’s been a “black box” that has made it difficult to plan. The more dependent a business is on software, the more problematic that issue becomes. Many issues could be avoided if only there was more visibility into how software development resources are being applied when and where. In fact, as more organizations prioritize digital business transformation in the wake of the COVID-19 pandemic, the more critical it becomes to maximize use of limited software development resources.

    Of course, organizations have been trying to manage software development projects using spreadsheets and project management applications for decades. The tools are not likely to be replaced anytime soon simply because of the level of process inertia attached to them within most organizations. However, given the current state of application development, it should be apparent those tools are not enough to get the job done on time.

  • Software Development Management Drives Business Value

    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.

  • How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    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.

  • Software Delivery Management: New Mindset

    Software Delivery Management: New Mindset

    Innovation and mindset can take a while to evolve. It was the case with social media, wireless communications and the Internet of Things.

    Software delivery is a good example of a concept that’s ready to stand on its own. As software becomes more integral to companies and to society at large, the way it’s designed, built and distributed has evolved. Today, the delivery process is far more sophisticated than it used to be, with more resources in the mix and more moving parts. After years of looking at aspects of the software delivery process as separate pieces, people are thinking differently about how all the pieces fit together.

    That change in thinking is putting momentum behind the creation of a new IT category called software delivery management (SDM). SDM pulls together under one umbrella all the teams, tools, information sources and processes that relate to the delivery of software. It aims to eliminate inefficiencies that have cropped up along the way and help create a more value-driven process, aligning organizations’ resources toward a common set of goals.

    The Road to SDM

    For decades people divided IT into two basic camps: hardware and software. The categories were analyzed largely in terms of output. Experts tracked how many computer boxes a big integrated manufacturer such as IBM or Digital Equipment Corp. made, or how many software disks Microsoft spun off its production lines. Companies had their own methods of getting products out the door. Management techniques such as TQM helped guide these processes, but little outside attention was paid to specific steps companies took along the way.

    All of this changed as software itself started to evolve. The internet, smartphones and more versatile operating systems opened up the software market to everybody. Software producers (manufacturers and individual companies alike) spent a lot of cycles working to perfect aspects of the software delivery process. Companies created teams to research, scope, develop, engineer, produce, integrate, test, market and sell software apps. They applied a variety of tools to accomplish specific tasks and implemented processes such as continuous integration and continuous delivery (CI/CD) to help streamline the engineering functions.

    These advancements brought software to where it is today—companies are delivering apps quickly and updating them often. Operations teams are collaborating with developers, and organizations are doing their best to anticipate customer needs and institute quality control mechanisms. Software is achieving things never thought possible.

    Stashed in Silos

    But the delivery process isn’t perfect. Too often, pieces are separated from each other. Tools don’t work together. Teams don’t talk to each other enough. Information is stashed in silos that one side of the organization isn’t sharing with another. Data that does get shared hasn’t been updated.

    Disconnects like these cause ripple effects throughout the organization. Projects get delayed; apps get delivered with bugs and/or vulnerabilities; developers find themselves overworked, restarting initiatives because they didn’t have the information they needed to do it right the first time. Executives get frustrated that teams aren’t delivering on their goals.

    The disconnects can’t really be blamed on a particular team, tool or misplaced plan. They’re the fault of the overall process itself. A development team might be doing a great job with a top-quality tool and a well-thought-out plan. But if the product development group supplied developers with out-of-date information and a testing tool doesn’t integrate with a tracking database, the project will run into problems.

    All Processes Connected

    What’s needed is a new category that looks at software delivery from a holistic vantage point. Everything connects with everything. SDM provides those connections. It outlines a set of pillars to unify data, insights, processes and functions—aligning organizations around a common set of goals.

    In upcoming blogs, we’ll look more closely at how SDM works, what kinds of benefits it can provide and how it can generate true business value for an organization.

    — Anders Wallgren

  • Whitepaper – Continuous Everything: Why Software Delivery Management Matters

    Whitepaper – Continuous Everything: Why Software Delivery Management Matters

    Software Delivery Management 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.

    [su_button url=”https://www.cloudbees.com/resource/whitepaper/continuous-everything-why-software-delivery-management-matters” target=”blank” background=”#ef2d3f”]Download Now[/su_button]

  • How CloudBees Makes Software Delivery Management Possible

    How CloudBees Makes Software Delivery Management Possible

    Editor’s Note: This is the third blog in a series about Software Delivery Management written by Shawn Ahmed, CloudBees vice president of product marketing. 

    Today, I’m so excited to announce CloudBees’ entry into the Software Delivery Management (SDM) market with our solution for SDM. It’s been a long time coming, in which CloudBees has reimagined how we could tie all the disparate and siloed tools from across an organization’s teams and departments to provide better, software faster.

    In my previous blog posts, I talked about recognizing the limitations and gaps we see in DevOps and software delivery today. We know there’s little controversy about the benefits of a mature continuous integration/continuous delivery (CI/CD) pipeline. They include reducing the failure rate for changes to under 15% from over 50%, recovery time after downtime measured in minutes instead of weeks and cycle times measured in hours, not weeks. CI/CD helps enterprises deliver software that works better, from a technical standpoint: better performance, fewer failures.

    But there’s a limit to what CI/CD can provide to all those organizations undergoing their own DevOps transformation today.  CI/CD only connects the parts of the software lifecycle that happen inside the software engineering department. It starts with a bug or feature ticket and ends with a deployment. But when you talk to developers, engineering managers, operations and other stakeholders, they will tell you that things still aren’t perfect.  Even if they are able to implement multiple best practices, and achieve the quality and velocity promised with effective CI/CD and DevOps, there is still work to do. Developers don’t have visibility into the real business or customer need, or adoption; engineering management is still scrambling to understand where things are and continually communicate this to management; operations and shared services are still wrestling with multiple disconnected tools.  We are delivering faster, but are we delivering better? Delivering the right thing for the business goals? For the customer? More importantly, it doesn’t tell us if the software is actually meeting the needs of customers.

    Software Delivery Management (SDM) truly 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.

    At CloudBees, we are right in the heart of this exciting new category. We’re extending the feedback loop to integrate the entire software lifecycle, starting with researching market demands and customer needs and then evaluating how software can be used to meet those needs, all the way from code through to customer support.

    CloudBees Solution for SDM

    The Software Delivery Management strategy is all about recognizing software delivery as a core business process and any solution developed to support SDM needs a comprehensive management system. I previously outlined the four pillars of SDM that a solution needs to rest upon:

    • COMMON 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.
    • UNIVERSAL 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.
    • COMMON CONNECTED 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.
    • ALL FUNCTIONS COLLABORATING – And finally, all functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.

    Our new CloudBees solution for SDM  will help organizations facilitate collaboration between software development teams and other business stakeholders. You can expect our solution to include some of the most important capabilities that close the gap for software delivery.

    Initially, our solution will be comprised of a platform to support SDM and will include modules for the product hub and value stream management.  Future modules will become incorporated into the solution as it evolves. The CloudBees solution for SDM  doesn’t replace our existing products such as CloudBees Core, CloudBees Flow and others. Instead, those products will become modules. Our customers can continue to evolve with us towards SDM as our solution for SDM unfolds.

    I’m excited that our solution will support some of the most important needs of SDM now and in the future such as:

    • One unified system of record  – With the CloudBees solution for SDM, information spread across multiple software planning, development and delivery tools can be captured, linked and cross-referenced The building of a single, unified system of record means everybody can see up-to-the-minute software delivery status via connected processes and get the information they need, when they need it.

    • Workflow engine – Software development is fundamentally about giving highly educated people the tools they need to find creative technology solutions to business problems. With the CloudBees workflow engine, it’s possible to tie together all of the low-value steps that need to happen as the software is developed, allowing engineers to focus their energy on high-value, creative projects—including collaborative brainstorming with other business stakeholders.
    • Recommendations engine – CloudBees’ SDM tool will provide intelligent recommendations to fuel continual, incremental improvement in terms of both the software delivery process and how well the software meets customer needs, based on feedback and real-world data, such as from feature flagging.

    CloudBees Solution for SDM: Preview Program

    While Software Delivery Management emerges as a market category, we want your voice to shape our solution. We’re also launching the CloudBees Solution for SDM Preview Program to ensure our solution meets the needs of organizations.

    Using software to build business value isn’t just about delivering faster, it’s about creating software that appropriately addresses customer needs. Software Delivery Management is the only way to make sure the software your organization creates is meeting customer desires and building value for the business.

    Learn how CloudBees makes software delivery management possible and visit our booth at DevOps World | Jenkins World. Download our new whitepaper on SDM —  Continuous Everything: Why Software Delivery Management Matters.