One of the key metrics IT leaders care about is the total time it takes for a release to go from development to being live in production. The metric used to measure that duration is called the “release lead time.” It can range from days to months, depending on factors such as team agility, enterprise constraints, and interdependencies.
Although release lead time is a very important metric, IT leaders should understand every step in the software delivery life cycle (SDLC)—including bottlenecks. Path-to-production analysis is a technique for assessing and diagnosing any bottlenecks in the SDLC process.
Path-to-production analysis is a simplified version of value-stream mapping (VSM), which is primarily used in a manufacturing context. Think of building software as an assembly line in a factory, with the business requirements as the raw materials and the business owners as suppliers. In this analogy, manufacturing is done by developers and testers, with the product assembled, packaged, and deployed continuously by CI/CD pipelines. Path-to-production analysis enables IT leaders to identify all the steps in the SDLC process, including the wait time and duration (cycle time) of each of them.
To better understand VSM, let’s look at a simple value stream map of a pizza delivery process:
As the value stream map makes clear, there are wait times in the process that can be optimized to reduce the overall process lead time by 30 percent. Although the software development process has many more steps and complexities than the example above, the overall principles stay the same.
Now let’s look at a software delivery process of a team that uses a hybrid of agile and waterfall methodologies:
As you can see, this team uses weekly sprints for development and functional testing (green boxes) and waterfall for the rest of the delivery process (gray boxes). The team may see a high throughput in the agile steps but then find a high volume of defects in later testing cycles, such as integration, accessibility, mobile, security, and performance testing. We know that the later we find defects, the more expensive they become to fix. So, let’s try to improve the process iteratively and measure the impact:
Iteration 1:
-
Establish CI/CD pipelines to deploy the latest code in all available environments (automated or, for higher environments, using a manual trigger)
-
Shift accessibility and mobile testing to weekly sprints to find defects during the development cycles (both accessibility and mobile testing should be added to the definition of “done” for each sprint)
Iteration 2:
-
Add automated integration test cases to test the end-to-end flow in the integrated environment
Note: This step assumes that the integration environment is ready and CI/CD pipelines can deploy the latest code before running the integration tests.
Iteration 3:
-
Add new CI/CD pipelines to deploy the minor and major versions of the product to the pre-prod environment
-
Shift security to the development and delivery cycles, automate the security processes, and streamline reporting to the security and compliance teams (a practice known as DevSecOps)
Iteration 4:
-
Integrate automated performance tests in the CI/CD pipelines to run every minor and major release
The overall process is now 17 percent more efficient and 50 working days shorter. Compared to the current state, the team can ship two releases in 98 days instead of one. There are more steps in the weekly sprints, but they’re all automated. Note that throughput will be impacted, as the team has to fix the defects found by the automated test steps. However, a predictable, high-quality product delivered in half the time is always more valuable, to both businesses and end users.
Path-to-production analysis allows IT leaders to identify opportunities for shipping better software, faster. It is best to optimize the process using an iterative approach, to both reduce any organizational resistance and allow the team to assess the impact before any further changes are made.
