Each organization involved in creating software eventually has a need to deliver that software. It is what we call the software delivery process. Typically, software delivery starts at the moment that a developer has written code locally and wants to publish it. Or, as Martin Fowler puts it: From the developer finishing the feature to getting that feature into production. At Qxperts, we have a more holistic view on software delivery.
Successfully solving the problem of your consumers requires a multitude of facets. An organization needs more than just a working software delivery pipeline. First, what is being developed needs to add value for the consumers by solving a particular problem they face. Second, what is being developed needs to be of the desired quality. Third, the organization structure and team setup have to be well-designed to prevent impediments in the software delivery process. So, in short, many aspects determine the quality of software delivery.
High-quality software delivery requires organizations to optimize the process from cradle to grave. For us, it starts at having the right vision and mission for the company, capturing the right requirements collaboratively with the business, having engineering principles instilled and monitoring the deployments.
Over the years we have observed five key areas that determine the quality of your software delivery. Each of these five areas can be seen as a lever. Some areas may need more attention than others. This is dependent on the maturity of the organization, or simply stem from the requirements of the problem domain. For example, an e-commerce company requires different things than a financial institute.
Build the right thing
Before a solution or functionality is built, it is necessary to thoroughly understand the problem. Who are our users? What problem do they have? Does it fit our product vision? How do we measure the impact and success of this feature?
Typically, Product Owners or Product Managers are responsible for answering these questions. Nevertheless, the answers are interesting for the entire team since the answers support the team in finding and testing different solutions. Techniques like story mapping and impact mapping can significantly help to provide an answer to these questions.
Change autonomously
Increasingly, the software we develop is part of an interconnected system of features. As a result, a change in the software has impact on other parts of the software or systems. This impact can be minimized through a proper software architecture and a proper organizational design. The software architecture characterizes the ability to make a change in isolation. A team that can make changes within their own boundaries will be able to deliver a change faster and easier than a team with a high number of dependencies.
A thorough look on the software architecture and the organizational design can help to identify and remove undesired or unneeded dependencies. Defining boundaries and technical patterns can help to increase autonomous working.
Applying engineering principles
Engineering principles applied during development have a large impact on the software quality. Are we simply designing and developing to solve the problem at hand, or do we consider non-functional requirements as well? How do we cope with scalability or reliability issues? How do we ensure that our solution is solving the problem according to the rules of the business?
Instilling engineering principles is extremely supportive towards the quality of the software. There are many techniques and tools that contribute to software engineering. For example, using Test-Driven Development to help design, document and test your software architecture.
Deploying and Monitoring
Once the software has been created it is still quite useless. The value of the software only is realized as soon as that software is available for the consumers. The name of the game is not solely the delivery of the software. Quality of delivery is also determined by the impact of that delivery. Can the software still be being used after we deployed a new version? In short, software release monitoring is crucial to measure the success. As such, automated deployment pipelines need to not only focus on publishing software but also consider checks that can determine the success of the deployment. One of the ways to do this is to enhance software observability, one of the key elements in progressive delivery.
Organizing for success
All these things are dependent on the way a software company is organized. An organization that is silo-ed will have to bear with a high number of handovers and communication lines. Take for instance software deployments: these will require several teams to be involved. Conversely, an organization designed around value streams will be able to work more autonomously.
It is not just how we are organized. We need to take it one step beyond that. What kind of power structures are in place? Who can make decisions? Is there a vision that guides the teams? Is the culture helping or working against the goals of the company?
Working in an organization for a longer period tend to make people indifferent to the organization’s performance in all these different areas. We focus on tangible things (the symptoms) rather than the causes. Fresh perspectives on the organization can help to determine where performance can be improved, in line with the goals of the organization.
Previously posted on https://qxperts.io.
Recent Comments