devopsy.kinsta.cloud

Tag: software delivery

  • Infographic: 8 Trends Shaping Software Delivery in 2022

    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”]

  • On-Premises Software Delivery Tool: Build or Buy?

    On-Premises Software Delivery Tool: Build or Buy?

    The on-premises software market is four times larger than the SaaS market, but harder to reach. Every software vendor who wants to pursue it has to decide how they are going to package and deliver applications inside customers’ firewalls, automating away the complexity of keeping applications deployed and running. Should they build or buy a deployment tool (and how should they think about the features they’ll need beyond just deployment)? Both have their pros and cons, but as demand to reach the larger enterprise market grows, more software vendors are choosing to buy.

    Deploying apps on-premises used to be very different. Fifteen years ago, sysadmins and database administrators (DBAs) would manually configure servers and the applications that ran on them. When something broke in production, admins would often troubleshoot and fix by SSHing in to tweak a config file or setting. But now, particularly within agile development organizations, everything is done via automation (i.e., the evolution of DevOps and SRE). As a result, customers have lost patience with 150-page installation manuals and bespoke, hand-written scripts.

    Today, any ISV looking to modernize an existing on-premises app (or SaaS-only company considering creating their first on-premises offering) is, most likely, going to default to using Kubernetes because it abstracts away the technical overhead of keeping production-grade applications operating.

    With that in mind, software vendors should consider seven areas when deciding whether to build or buy a delivery and management solution. These include:

    Maintenance

    There are free or low cost resources if a software vendor wants to go it alone. Kubernetes and cloud-native technologies let capable engineers stand up a solution in months. But software vendors often overlook the long-term cost of keeping the tool up and running. There is a lot of tooling “around Kubernetes” the vendor has to build to successfully operationalize this. Sure, if you’re going to deploy to up to five customers, you don’t need formal tooling and processes that make it easy to engage whole teams of people (favoring a small build and manual effort), but when you want to go from five to 50, or 50 to 500 customers, you need advanced tooling (favoring buy).

    Cost

    Purchasing a ready-made solution comes with up-front costs, but building and maintaining a bespoke solution can be much more expensive. The obvious costs of building a deployment tool are design, engineering, support and operational costs. There are larger, long-term costs to consider, most notably pulling away one of your greatest assets, software engineers, to spend months (or years) on ongoing support needs. Redeploying your engineers results in opportunity and productivity costs, such as neglecting your core application(s) and stalling your business growth.

    Internal Resources

    You also need to evaluate your internal resources. Building a bespoke deployment tool is a commitment because the tool becomes a product in and of itself. Do you have a team with the available time and the technical skills? If your team isn’t large enough, you may incur costs for expanded headcount or contractors. If you don’t have added FTE costs, you may have a skills gap. When developing a custom deployment tool, most teams focus on the features that enable software distribution and installation, but they don’t consider management and troubleshooting features. In these situations, the FTE and skillset costs may be higher than paying for a comprehensive solution.

    Business Continuity

    Most homegrown solutions are created by an engineer or two who become experts in the systems they’re developing. This makes tons of sense for core business logic, apps that are constantly going to be improved and onto which new members will be onboarded. However, for ancillary systems that support the core business, these applications end up becoming a silo of knowledge. The question isn’t, “How much time will this take me to maintain after I build it?” but rather, “Who will maintain this after me, and who after them?” followed by, “How will they learn the intricacies of this system?” If the answer(s) to this question isn’t clear, this approach should be reconsidered.

    Beyond The First Team

    If you expect that your team will be the first, or one of the first, teams within your company to face the problem you are solving for (but you are certain others are sure to follow), then this decision is even more complex. A common customer delivery and management platform can increase cross-sell by simplifying the marginal effort for your customers to deploy a second, third, fourth, etc. application from your company. Buying will likely require a long-term relationship with a vendor dedicated to solving the problem. Similarly, building a solution will require extra investments. Beyond the initial technical/product requirements of abstracting a home grown solution to meet the needs of additional teams/architectures/products, there are also the other implications. The winning solution will win because it will evolve to meet the needs of multiple teams and have strong internal advocacy. Depending on the size and complexity of the company, this internal advocacy can be quite time consuming and require more than just engineering talents (generally, this is what customer success and account managers do 100% of the time).

    Target Environments

    Your application may need to be deployed in varied on-premises environments and may not have the time to adequately address all of them. If your team has not previously built an installer, they may not have the skillset to build out richer features in AWS, Azure, VMware and others, to solidify the customer experience and day 2 operations, beyond just bringing the application up. An AWS Cloud Formation template might get you out the door, but when the next customer says, “I need GCP,” you’d have to start over.

    It’s rinse-and-repeat for each of the target environments, which slows your time-to-market, potentially losing high-value sales. Conversely, if you look at ready-made solutions, you can select the best out-of-the-box experience for your customers.

    Control and Compatibility

    There are situations where your team must build the on-premises deployment tool themselves. For example, when the app requires so much last-mile configuration for each customer deployment that there just isn’t a way to standardize it. Or if you don’t have enough customers to justify paying for a commercial product, it might make more sense to do a quick sprint and hack something out.

    An off-the-shelf solution can significantly accelerate your time to market, but you have to order off the menu. Also, if you have access to your customer’s infrastructure, then building your own tool may make more sense. On the other hand, requirements such as faster time-to-market, an off-the-shelf comprehensive solution and lower costs over time may outweigh customization. If speed, lower costs and quality are important, a solution from a focused vendor who has thought through all of the technical and operational challenges, with no surprises or last-minute fixes, is the way to go.

    Competitive Advantage

    Your software engineering team may be your company’s greatest resource. But it’s far better to keep your engineers focused on innovation, adding value to your application and winning more customers through improved software. Coding a deployment tool is undifferentiated overhead. It does not make your business more successful. Installers and support tooling are table stakes to deliver a good customer experience, but the reality is that no customer is going to pay you more money for that capability.

    The Bottom Line

    Simplified access to the on-premises software market is one of the greatest opportunities for software vendors today. Kubernetes and cloud-native technologies make it easier to develop tools to package, deploy, manage and troubleshoot apps. But the job isn’t for everyone. The costs, both up-front and long-term, favor ready-made commercial applications for most software vendors. Consider your resources and customer needs to decide if it makes more sense to build or buy your solution.

  • CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    CircleCI Report Finds DevOps Teams Adjusting to New COVID-19 Normal

    An annual State of Software Delivery report published today by CircleCI suggests that after a spike in developer activity last spring at the beginning of the COVID-19 pandemic, the pace at which code is moving through a continuous integration/continuous delivery (CI/CD) platform has returned to normal levels even as developers continue to work from home.

    CircleCI CEO Jim Rose said after any initial rush last spring, it appears maintaining that level of productivity is simply unsustainable for most organizations. If heroic measures are continuously required, Rose noted it’s only a matter of time before DevOps teams start to burn out.

    Based on an analysis of 55 million data points gathered from 160,000 projects spanning more than 44,000 organizations, the CircleCI report finds that despite the ability of a handful of organizations that can deploy code multiple times per day, most organizations on average run workflows less than once (0.7 times) per day.

    However, Rose noted, there is too much focus on the number of times per day code is being deployed. The more important metric is duration. Half of the 11 million workflows measured by CircleCI finished in less than four minutes. Three-quarters finished in less than 11 minutes, with 95% of all workflows measured finishing in less than 35 minutes.

    Rose said durations are longer than in previous years, which suggests more testing is being included in workflows. In an ideal world, Rose said workflow durations should be in the range of five to 10 minutes.

    The report also finds 50% of the workflows went from failing to being successfully deployed in 55 minutes on average, with the median success rate 61% of workflows. Splitting the workflows by the ones run on default branches versus the ones run on non-default provides more insight, and the median rates are 80% for the default branch and 58% for the non-default branch. Failure rates for the non-default branch are higher because that’s the branch most developers employ to experiment in a way that doesn’t impact the primary workflow.

    Rose said the report also suggests there is a correlation between larger team size and better overall engineering performance. In times of uncertainty, IT leaders should consider increasing the size of teams to reduce burnout and maximize flexibility. Depending on the scope of the project, Rose said the CircleCI data shows that somewhere between five and 20 code contributors is the optimal number of team members. IT organizations would also be well-advised to consider how those team members are geographically distributed to maximize the number of hours in a day any project is being worked on without having to overwhelm a small number of developers working in the same time zone.

    As has always been the case, DevOps success over the long term requires organizations to balance multiple factors and metrics. After all, the primary goal for most organizations is not so much to increase the amount of code being deployed as much as it is to increase the quality of the code that ultimately gets deployed in a production environment.

  • A Daily Gemba Walk for a Software Delivery Organization?

    A Daily Gemba Walk for a Software Delivery Organization?

    Lean thinking has had a substantial influence on helping enterprises to improve the flow of value across their software delivery organization. Yet, for many companies in what industry visionary Brian Solis calls the “Novel Economy,” where market conditions have yet to be identified or understood, the degree of responsiveness and agility required to adapt and remain competitive is still not sufficient.

    By measuring how value flows through a product’s value stream, however, everyone from practitioners to business leaders can initiate “daily Gemba walks” to obtain real-time continuous insight into the software delivery value streams that serve internal and external customers. You can see what’s slowing you down today and where to invest resources to continuously improve where it matters to support both the customer and employee experience.

    Unique Challenges in Software Delivery Value Streams

    A software delivery value stream is the sequence of activities an organization undertakes to respond to a customer need that results in the delivery of value. Yet, they are not so easy to identify and measure because much of the work is knowledge-sharing. While Lean practices such as value stream mapping have helped us to identify the current state of processes, learn to see where bottlenecks are and learn to improve with experiments to reach a desired future state, there are significant challenges.

    Logistics such as scheduling time, people and the right kind of meeting room, as well as extracting objective data for improvement strategies, make it difficult to keep a regular cadence of assessing the value stream. And, within a relatively short amount of time, the information we captured goes stale, because priorities and strategic initiatives are dynamic and ever-changing.

    Furthermore, since the software delivery work from ideation to operation is mostly cognitive and often complex, it is difficult to accurately map the flow of value. The process flow is not linear—it’s more like a network. The complexities of the interrelated components and variability of how teams work are difficult to capture in an understandable manner. As a result, we lack complete and objective visibility into the end-to-end flow of work to make time-critical decisions to improve performance.

    Going to the Gemba

    There’s a concept in Lean thinking of learning by going to the place where the actual work happens—“the Gemba”—to observe the work first hand. However, in software delivery at scale, even if we take a Gemba walk through the floors of our buildings where members of the value stream are working, we won’t gain much understanding of what’s going on. We might see kanban boards, huddles and charts, but what we mostly see are people working on their laptops at their multi-screened-in desks. We only really see a small slice of the set of activities that create value.

    So how do we see all the activities across the whole value stream at a continuous cadence to help us make both reactive and proactive decisions to improve flow in the most pressing areas? One approach is Flow Metrics, as described in Mik Kersten’s book, “Project to Product,” via the Flow Framework.

    A lean and prescriptive approach that guides organizations on what and how to measure in software delivery at scale, the framework uses Flow Metrics to provide business and IT leaders with shared, real-time insights into the relationship between technology delivery and business outcomes. It helps you to establish your baseline to see where you are today and pinpoint where you need to focus your energy.

    These value stream metrics track the flow of business value by correlating the investment in accelerating flow for each product’s value stream with the desired business outcome. We can use these metrics to scale what we used to do in our value stream mapping sessions to a daily Gemba walk based on objective data without interrupting the teams involved.

    We can see first hand the velocity at which our teams are producing value. We see the efficiency and distribution of their work. We see the work-in-progress (WIP) and the lead time for value creation. We see the correlation between the product value stream contributors’ hard work and the resulting business results (such as a new feature for revenue; fixed defects for product quality/customer; paying down tech debt to improve delivery speed, security and risk work to protect against breaches, and so on).

    Business-level Metrics That Count

    The Flow Metrics are:

    • Flow Velocity gauges whether value delivery is accelerating. It is the number of flow items of each type completed over a particular period (also known as throughput).
    • Flow Time can identify when the time to value is getting longer. It measures the time it takes for flow items to go from work start to work complete, including both active and wait times.
    • Flow Efficiency can identify when waste is increasing or decreasing in your processes. It is the ratio of active time versus wait time out of the total Flow time.
    • Flow Load monitors over- and underutilization of value streams, which can lead to reduced productivity. It measures the number of flow items currently in progress (active or waiting) within a value stream.

    Alongside the above set of Flow Metrics, the measurement of Flow Distribution helps prioritize specific types of work during specific time frames to meet the desired business outcome. Flow Distribution measures the ratio of the four flow items (feature, defects, debt and risk) completed over a window of time.

    Flow Metrics ideally should be displayed in a single dashboard, providing IT and business leaders with a complete view of value delivery and an understanding of how the metrics are affecting each other. Here’s an example:

    Flow Metrics are opening a real-time window to see the value stream activity that we previously could not see as frequently and as objectively. Consider taking a daily Gemba walk for software delivery to ensure you’re meeting the most pressing needs of your customers, internal and external, to navigate through the opaqueness of the Novel Economy.

  • 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.

  • CloudBees Extends SDM Service Reach

    CloudBees Extends SDM Service Reach

    CloudBees has extended the integrations embedded within its software delivery management (SDM) platform to add support for additional services provided by Google.

    Moritz Plassnig, senior vice president cloud and general manager for SDM at CloudBees, said these integrations with Google Cloud Build and Tekton pipelines are being provided as part of a long-standing alliance between the two companies to advance the adoption of best DevOps practices. The CloudBees SDM service runs on the Google Cloud Platform (GCP).

    As part of that effort, CloudBees has been making investments in an SDM platform that enables DevOps teams to pull metrics from any tool or platform. That data is then fed into an analytics cloud service through which CloudBees surfaces insights that identify, for example, how delays to a project might impact overall revenue goals.

    Interest in software delivery analytics has risen in the wake of the COVID-19 pandemic as organizations accelerate the building and deploying of digital business applications, said Plassnig. With employees and customers alike working from home to combat the pandemic, organizations are investing more in creating applications that provide digital alternatives to engaging end users, he noted, adding delays to any of those projects are likely to have a much bigger impact on business continuity strategies today than they did just a few short months ago.

    The CloudBees SDM service provides DevOps teams and business managers alike a real-time view of all product and feature development occurring across the organization, as well as a policy engine to trigger actions to better optimize the software delivery process. Organizations can also model and visualize the software delivery process while measuring overall DevOps performance.

    Rather than requiring organizations to standardize on a single platform to achieve that goal, Plassnig said CloudBees is leveraging application programming interfaces (APIs) to integrate metrics across a broad range of DevOps tools. That approach, he said, makes it possible to meet organizations wherever they are in terms of DevOps maturity.

    Support for Tekton pipelines is significant, Plassnig noted, because it’s expected that most continuous integration/continuous delivery (CI/CD) platforms in the future will be built using Tekton pipelines, which provide an open source framework for building platforms that are designed to be deployed on Kubernetes clusters. Jenkins X, originally developed by CloudBees, is one of the first CI/CD platforms to support Tekton pipelines, which were originally developed by Google. Jenkins X and Tekton pipelines are now being advanced under the auspices of the Continuous Delivery Foundation, an arm of the Linux Foundation.

    As more CI/CD platforms embrace Tekton, the platforms themselves will become less of a black box from an analytics perspective, noted Plassnig.

    In the meantime, CloudBees also expects Google to continue to gain momentum as a cloud service provider, he said. While Google trails Amazon Web Services (AWS) and Microsoft in terms of overall market share by a wide margin, Plassnig noted that with the arrival of Anthos, a cloud operating system capable of being deployed on multiple cloud and on-premises IT environments, it’s only a matter of time before services such as Google Cloud Build are employed more widely.

    Whatever the platform used, the one thing for certain is the rate at which software is being generated and deployed on various platforms will be watched much more closely.

  • Report: Software Delivery Slowed During Pandemic

    Report: Software Delivery Slowed During Pandemic

    A survey of more than 500 IT and development professionals conducted by Atlassian finds two-thirds of respondents have slowed down the frequency of software delivery since the advent of the COVID-19 pandemic.

    Patrick Hill, head of reliability process at Atlassian, said while developers may be creating more code than ever while they work from home, IT operations teams working from home are struggling to keep pace.

    In fact, the survey finds more than half of respondents (51%) reported incident response times have been slower since they began working remotely. At the same time, there’s been a 73% increase in demand for the digital services being provided, the survey finds.

    It’s too early to say to what degree slowing down the application delivery process might be a byproduct of the “new normal.” It’s more likely that IT operations teams need more time to re-engineer processes to return to the software release levels typically achieved prior to the pandemic, said Hill.

    In many cases, IT teams may also need more time to shift toward cloud-based frameworks for managing application release cycles that can be accessed from anywhere. Hill said Atlassian has seen a significant increase in the use of its IT management platforms since March. New signups have increased by approximately 125%, he noted.

    It’s also unclear to what degree an application release backlog may be building inside organizations. While developers may be launching more projects, Hill said many of those projects may be only to address bug fixes. As such, it may not take that long for IT operations teams to recover from the disruption caused by the pandemic.

    Nevertheless, Hill said most organizations are still coming to terms with the human impact of the pandemic. Many organizations, for example, might not decide to bring IT teams back into the office at all. In fact, there may not be any office to return to—many organizations might conclude there is no need, especially if productivity levels have not declined substantially. No doubt many organizations consequently will be closely monitoring application release cycles in the weeks and months ahead to determine to what impact working from home is having on IT productivity.

    Of course, not every member of the IT team is cut out to work from home. While many IT professionals may be introverts by nature, there are also a great many distractions at home that adversely impact productivity. Conversely, some IT professionals might even discover they have begun to work longer hours.

    In the meantime, Hill said IT managers would be well-advised to focus more on outcomes than metrics. The amount of code being released in a given week is not likely to be as important as making sure the right code is being released at the right time. With more demand than ever for application services, the greater the need there is for DevOps teams to focus their efforts on the components of an application that make the most critical difference to the business.

  • 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

  • Provide Continuous Value with Product-Centric Delivery

    Provide Continuous Value with Product-Centric Delivery

    Software engineering and management has borrowed many practices over the years from traditional industries such as construction, automotive and manufacturing. One such practice is the notion of managing software development and delivery based on projects.

    According to the Project Management Institute (PMI), a project is defined as “a temporary endeavor undertaken to create a unique product, service or result. A project is temporary, in that it has a defined beginning and end in time, and, therefore, defined scope and resources.”

    Many enterprises today manage software delivery via a project-centric software delivery approach. New software projects are identified based on probable business cases. Business opportunities are identified and prioritized based on potential business benefits and estimated cost. This is done with the assumption that the exact market needs, the estimated cost, start and end dates, and potential benefits are certain and known up front. Once the business case is approved by senior management, projects are initiated. In an environment where the scope, schedule and cost of projects can be defined upfront, this provides a predictable approach for software delivery management and governance. 

    But, do we live in a world of total certainty? In the volatile and uncertain world in which we live—with the very fact that software is not a physical good—accurate predictions of market needs, cost, timing and end-user benefits are far from reality. In addition, companies are competing in the marketplace by exploring innovative ways to create and deliver new products and services.

    Why is the project-centric delivery approach used by so many IT organizations if it is a challenge? Projects can no longer be the vehicle for software development and delivery if enterprises want to stay ahead of the competition. Then, what is the alternative approach?

    Introducing the Product-Centric Delivery Model

    A product-centric delivery model is a new way of organizing people, and continuously delivering valuable software to customers.

    Let’s take a look at the steps an enterprise needs to follow in order to transition from project-centric to product-centric software delivery. 

    Identify Products Instead of Projects

    What are software products? Organizations across the world provide value to their customers in the form of goods and services. These goods and services are called products and are often driven by software and IT systems. For example, to a bank that provides digital banking services to its customers, its online banking solution is a product, not a project. Similarly, for a retail company, its catalog and product search becomes a product. These kinds of products are different from the actual physical goods that these companies sell.

    Organize and Fund Stable Teams Around a Product, Not a Project

    Once your products are identified, the next step is to organize and fund your software teams around these products. These cross-functional teams include members from business development, IT development, support and operations. This team must be empowered to build and deliver the product on their own and will collaborate, decide what to build, how to develop it and how to manage the product with frequent updates. The team must be outcome-oriented, long-living and cross-functional. They can be organized as a team-of-teams or squads, resulting in better collaboration, focus and ownership from any corner of the world. This will also help in scaling the overall capacity of the product. A common shared services team, supporting multiple products might be an added advantage. 

    Define Product Vision, Define Objectives, Deliver and Measure Value

    After the products and the teams are in place, you need to define the product vision. The product vision defines the reason for its existence and the long-term goal that it is trying to achieve. This also aligns business objectives with IT delivery and provides guidance for all decisions made regarding the product development and delivery.

    The business stakeholders define the product vision and derive the near-term objectives that will guide the teams to further decide the set of initiatives they need to work on.

    The teams then identify relevant product features, plan and deliver those in short increments or time boxes, thereby delivering continuous value to end users.

    At the end of each time-box, stakeholders will measure the product outcome with the stated objectives and changes in the market needs. The findings will help the business decide on whether to continue investing in the product or not.

    Conclusion

    Product-centric delivery paves a new way of organizing people and continuously delivering software value with more emphasis on outcome rather than the output. It provides a continuous flow of work to the product teams and continuous value to the end users. It aligns the business strategy to software development and execution, while empowering the teams to decide what is best for their product.

    — Prabhu Arumugham