Complex integration projects in software development are often time-consuming. Seven best practices that companies can use to accelerate change management processes in software integration projects.
The most critical measurement indicator for successful change management processes in software development is the Lead Time for Changes (LTC). It describes the length of time required to use a source code change successfully in productive operation after a new commit. Automated test and installation routines, for example, can often reduce the LTC to 15 minutes. With additional consideration of human interactions such as coordination, review, or quality assurance processes, LTC of less than 60 minutes can be achieved. Based on experience from numerous software integration projects, we have identified seven best practices that significantly promote successful change management processes.
Unrestricted Access To The Infrastructure
Delays in the lead time for changes are often due to infrastructural reasons: For example, one team is responsible for the application operation in the production environment, while another group is responsible for the operating system and network issues such as firewall settings. Shared responsibilities are also often found in test environments or the CI and CD platform. In the event of problems or planned changes, it is always necessary to fall back on the resources provided by other teams – and to maintain them.
Best Practice: The test environments must be easy to use for all team members. Employees with operational responsibility should have the fullest possible root access to the test and productive environment: from the hardware to the operating system and third-party software to the application itself.
Change Management Processes: Cloud-Native Architecture
Large server applications take a long time to compile, package, and install. Automated regression tests often take hours and are therefore only carried out at night in many projects. If a company wants to bring software updates into production frequently – several times a day and quickly, e.g., within 15 minutes – the architecture must also support this. On the one hand, the risk of side effects must be as low as possible. On the other hand, the build, test, deployment, startup, and, if necessary, the fallback process must also run quickly. And users of the application should, if possible, not notice any interruption effects such as downtime.
Best Practice: A microservice architecture with small-scale and mutually independent cloud-native applications enables fundamental acceleration. The technical part of the lead time for changes can be shortened from several hours to a few minutes by switching from complete installations to incremental mini-updates.
Functioning DevOps Organization
The saying “Many cooks spoil the broth” also applies to change management. Regarding the lead time for changes, the following applies above all: You slow down the change management processes.
Best Practice: DevOps teams, in which all competencies from software engineering to quality assurance and installation and configuration management to application operation are bundled, can carry out all changes and optimizations independently and without waiting for supplies. Conflicts of interest or capacity can be avoided through the permanent exchange of knowledge.
Successful Change Management Processes Need An Agile Mindset
If not every team member can carry out almost any activity, delays in the lead time for changes cannot be ruled out.
Best Practice: With agile concepts, collaboration within teams and the skills of employees are strengthened. The essential methods from the agile world include a task board, refactorings, heartbeat retrospectives, pair programming, or peer reviews.
Zero Defect Tolerance
Existing errors or even the suspicion that there are potential errors slows down the willingness to update the software frequently and quickly – according to the motto “Never change a running system.” Conversely, permanently proven freedom from defects and reliability promotes trust in software updates, namely for all those involved, from the user to the software developer to the project sponsor.
Best Practice: Every company should give zero-defect tolerance a high priority. All existing errors must be eliminated, and the correct functioning must be ensured through automated tests with maximum coverage. Code generation, reviews, and refactorings can avoid redundant, incorrect, or extra code. This significantly accelerates the error-free implementation of changes.
Automation Of Interactions In The Lead-Time Interval
In the entire process chain of lead time for changes, human interactions, in particular, are the biggest time wasters: It often begins with the merging of source code changes. In addition, manual steps are frequently encountered during installation and test execution or configuration changes. Manual activities cause delays and include the risk of human errors, which can result in unnecessary repair work.
Best Practice: Using a trunk-based development method, all changes are ready and available at the time of the release decision. This means that they do not have to be manually transferred to a release branch, for example, and checked. A CI / CD pipeline can also carry out all steps such as release packaging, test installations, or effective commissioning fully automated. Every mechanical and human interaction avoids unnecessary waiting times within the lead time for changes.
Lean Change Management Processes
In some cases, human interactions are indispensable and cannot be automated, for example, in the technical review and quality assurance of an implemented change. However, there are also possibilities here to support and accelerate manual steps through automation.
Best Practice: All change management processes are streamlined, so that manual steps are only required for controlling or exploratory activities, if possible. Test results can be automatically processed so that all changes since the last test run are highlighted and can be checked quickly.
