10 steps of software delivery

Introduction

Software delivery is a complex process that involves various stakeholders and a series of predefined steps to develop tailored functionality for business processes. This blog post is the first one in a series of posts where I will describe the software delivery process, the possible pitfalls and challenges and how you can address them. In this first post I will describe ten typical steps in the software delivery cycle and the roles that participate in that process.

I will focus on software delivery, assuming that the product strategy and future roadmaps are known and agreed upon within the organisation. I’ve also omitted any discussions about changes to business processes and procedures for the sake of simplicity. Lastly, I did not include any roles or activities related to infrastructure and hardware, also for the sake of simplicity.

It’s important to note that, not every step is mandatory for every project. Furthermore, the list of key players and steps is not exhaustive. Specific steps and their order may vary based on the development methodology, project requirements, and team dynamics. However, knowing these steps is important in understanding the complexity that comes with creating software.

This is a long post, if you want you can skip all the details and go to the conclusion here.

Six roles involved

Before we dive in, let’s introduce the key players in the software delivery cycle.

Business Stakeholder

Business stakeholders are individuals or groups within the organisation who have a key interest in the software’s success. They may include executives, managers, and end-users. Business stakeholders provide input, define project goals, and ultimately approve or reject changes based on their alignment with business goals and objectives. Business stakeholders are typically distinct from the development team.

Product Owner (PO)

The product owner is responsible for representing the interests of the business or product users. They gather and prioritise requirements, define the project’s goals, and make decisions about the product’s features and functionality. The PO acts as a bridge between the development team and business stakeholders, ensuring that the software aligns with business objectives.

User Experience (UX) Designer

A UX designer is responsible for creating user-friendly and visually appealing interfaces for software applications. They focus on designing the overall user experience, including layouts, navigation, and interactions, to ensure that the software is intuitive and easy to use.

Developer

Developers are responsible for writing the actual code that makes the software function. They follow software design specifications, coding standards, and best practices to implement the required features and functionality. Developers may specialise in front-end (user interface) or back-end (server-side) development or work as full-stack developers handling both aspects.

Code Reviewer

Code reviewers are fellow developers who review code changes submitted by their colleagues. They assess the code for correctness, adherence to coding standards, maintainability, and potential bugs. Code reviews are essential for maintaining code quality and ensuring that multiple perspectives are considered.

Quality Assurance (QA) Engineer

QA engineers, also known as testers, are responsible for verifying the quality and correctness of the software. They design and execute various types of tests to identify defects and ensure that the software meets the specified requirements.

In larger software development teams, the roles mentioned are typically performed by one or more individuals, each specialising in their respective areas of expertise. This division of labor allows for specialisation and efficiency, as each role requires unique skills and knowledge. However, in smaller teams, these roles are often combined and may be performed by the same person or shared among a few individuals. This flexibility in role combinations enables smaller teams to maintain a more hands-on approach throughout the software development lifecycle.

Ten software delivery steps

Next, let’s explore the different steps within the software delivery cycle, emphasising a high-level overview. It is important to recognise that within each of these steps, a significant amount of detail and complexity exists.

Intake

At the outset, the product owner conducts in-depth discussions with key stakeholders, including business managers and users. The goal is to gain a comprehensive understanding of the business problem or opportunity that necessitates software development.

When a product strategy and roadmap are already in place, the product owner will use them as a foundation. The product strategy sets the long-term vision for the software, defining its primary goals. The roadmap offers a timeline of planned features and releases, helping the product owner prioritise development and ensure changes align with strategic goals.

The product owner takes the insights gathered from business discussions and formalises them into a clear, concise document. The document outlines the specific objectives, scope, requirements and expected outcomes of the proposed software changes. This document also acts as the starting point for the next step, creating work packages.

Defining work packages

The product owner will translate the requirements into actionable work packages and tasks. Work packages are often created in the form of tickets. Tickets are like task cards that help teams organise their work and track progress. These tickets are often created in free-form text, providing flexibility in how the details are presented. It is up to the skill and experience of the Product Owner to determine the appropriate level of detail for each ticket.

Each ticket typically includes a description, the acceptance criteria, specifying the conditions that must be met for the work to be considered complete and satisfactory. Often, tickets are assigned a priority, indicating their relative importance within the development queue and an estimated workload. One or more tickets will act as a work-package for the development team members.

Refinement

The development team, consisting of the product owner, developers, UX designers, and QA engineers, collaborates to review and refine the tickets.The level of discussion depends on the complexity of the proposed change and the combined skills and expertise of the team members involved. For more straightforward tickets, discussions may centre on minor clarifications or quick alignment. However, for challenging tasks, these discussions can delve into technical details, design considerations, and potential trade-offs. The primary objective remains consistent: to eliminate ambiguity, address potential issues, and ensure that everyone on the team shares a clear and common understanding of what needs to be done. Refinement can also be used to make estimates regarding the duration and resources required to complete the tickets.

UX Design

In cases where the change involves the user interface, a User Experience (UX) designer comes into play. They create detailed mock-ups that will indicate how the user interface will look, feel, and behave. Sometimes, even before the refinement process begins, the product owner may collaborate closely with the UX designer to produce these mock-ups. This early involvement of the UX designer ensures that the development team has a visual reference that clarifies the expected user interface changes and behaviour.

Creating Code

Once the team has a clear set of refined and prioritised tickets, developers start writing the actual code. This phase is where the ideas and plans start taking shape in the form of software. To ensure the code’s quality and long-term viability, developers will use coding standards, industry best practices, and design principles. These guidelines serve as the foundation for writing clean, structured, and error-resistant code.

In addition to writing code, developers are also responsible for writing unit tests to validate the functionality of individual components and functions. These tests are designed to catch any issues or regressions early in the development process, ensuring that each piece of code behaves as intended. When necessary, developers also develop integration tests to assess how different components of the software interact and function together as a cohesive system.

When requirements or objectives are unclear, developers will discuss the tickets with the product owner. It is important to keep the whole team in the loop of what is discussed and decided.

Code Review

Once a developer completes their work, they create a pull request (PR) or merge request of all the code changes. These changes undergo a review process by one or more peer developers. The reviewers will check the code for compliance to coding standards, correctness, potential bugs, and overall code quality. If needed the code will undergo revisions and edits. The code review step is a collective effort aimed at producing code that is not only functionally sound but also maintainable over time.

Deployment to Test environment

After the code review and any necessary revisions, the developer deploys the code to a test environment. The test environment provides a safe, isolated and controlled space for testing of the newly developed features or changes.

During the deployment, a series of tests are executed. First, unit tests are run to validate the correctness of individual code components and functions. Following that, integration tests assess how different parts of the software interact within the system. These tests may include regression tests to confirm that the new changes have not introduced issues in previously functioning areas of the application.

Acceptance by QA

Testers, often Quality Assurance (QA) engineers, play an important role in ensuring the software’s quality and reliability. The tester will validate if the newly created software meets the acceptance criteria determined by the product owner.

Testers document their findings, including any issues, defects, or discrepancies discovered during the testing process. Based on these findings, the developer takes on the task of addressing and rectifying any identified issues or defects. Once the changes have been made, the QA engineer will retest the change to ensure that the issues have been effectively resolved and that the modified code now aligns with the acceptance criteria.

Acceptance by Stakeholders

Before the changes can be deployed to production, the product owner will take initiative to accept the changes by the stakeholders. This is often done by organising a demonstration of the newly developed features. This demo should illustrate how the software’s capabilities and functionality directly align with and contribute to the business goals. When stakeholders approve, the last step is to deploy the changes to the production environment where all end-users can start using it.

Production deployment

Before proceeding with the deployment to the production environment, a series of automated tests are conducted to ensure the reliability, integrity, and readiness of the software for the live environment. These pre-deployment tests, may include functional tests to confirm that all features and functionalities are working as expected, integration tests to verify the compatibility of the new changes with existing system components, performance tests to gauge responsiveness and scalability, and security tests to identify and mitigate potential vulnerabilities.

When all tests pass, the changes are deployed to production. It is common to perform a final test to check if everything has been deployed correctly and the software is functioning as expected in the production environment. Often the team sends out release notes to inform stakeholders about the deployed changes.

Conclusion

The software delivery process comprises of at least ten steps where six distinct roles which contribute their skill sets and expertise. The competency of each team member plays a crucial role in the end result. Managing ten steps with six roles involved can be challenging. Challenges can include longer timeframes for feature delivery, potentially high and unpredictable development and maintenance costs, and difficulties in achieving complete alignment with business goals.

In next blog posts I will address these challenges in more detail and discuss how to improve the software delivery process.