Light Weight Change Approval Process

Lean software Management delivers early iterations of working code incorporating customer feedback along the way thus improving software delivery quality and effectiveness. The key to iteration is frequent small code releases. The change management processes are being implemented to ensure developers and IT professionals can easily manage system configurations, deploy new code quickly and fix incidents faster.

Why Change Management Process?

In the IT industry there are numerous people and processes interacting with technical systems on a day-to-day basis – constantly shipping new code, adjusting network configurations, running automated tests and much, much more. So, defining a change management plan ahead of time can help your team with the identification and installation of required changes to servers, networks and other computer systems.

Most IT organizations have defined change management processes to manage the life cycle of changes to IT services, both internal and customer-facing. These processes are often the primary controls to

    • Reduce risk of making changes

    • Satisfying Regulatory requirements

The common regulatory requirement is segregation of duties, which states that changes must be approved by someone other than the author, thus ensuring that no individual has end-to-end control over a process.

Change management processes often include approvals by external reviewers or change approval boards (CABs) to promote changes through the system. Compliance managers and security managers rely on change management processes to validate compliance requirements, which typically require evidence that all changes are appropriately authorized.

Why the light weight Change Management Process?

Traditionally, change management goals have been met through a heavyweight process involving approval by people external to the team proposing the change: a change advisory board (CAB) or a senior manager. However research shows that these approaches have a negative impact on software delivery performance.

Such heavyweight approaches tend to slow down the delivery process leading to the release of larger batches less frequently, with an accompanying higher impact on the production system that is likely to be associated with higher levels of risk and thus higher change fail rates.

In Lean Change Management, we have a loosely defined framework to design experiments. However, there is no overarching methodology for executing change.The key principle is to co-create change with the people affected, in whichever manner and sequence makes sense in context.

How to implement light weight Change Approvals?

The goal should be, to make a regular change management process fast and reliable enough that it can handle emergency changes too.

    • Use peer review to meet the goal of segregation of duties, with reviews, comments, and approvals captured in the team's development platform as part of the development process.

    • Employ continuous integration, continuous development, continuous delivery and comprehensive monitoring and observability to rapidly detect, prevent, and correct bad changes.

    • Treat your development platform as a product that makes it easy for developers to get fast feedback on the impact of their changes on multiple axes, including security, performance, and stability, as well as defects.

This new role for the CAB is strategic. By shifting detailed code review to practitioners and automated methods, the time and attention of those in leadership and management positions is freed up to focus on more strategic work. This transition, from gatekeeper to process architect and information beacon, is consistent with the practices of organizations that excel at software delivery performance.

Automated configuration management and automation of other tasks in IT operations can lead to a change management process that’s faster and more reliable. Then, if something does go wrong, the team has visibility into the problem, can fix the issue and will be able to quickly communicate with stakeholders.

Ways to improve your change approval process

To improve your change approval processes, focus on implementing the following:

    1. Moving to a peer-review based process for individual changes, enforced at code check-in time, and supported by automated tests.

    2. Finding ways to discover problems such as regressions, performance problems, and security issues in an automated fashion as soon as possible after changes are committed.

    3. Performing ongoing analysis to detect and flag high risk changes early on so that they can be subjected to additional scrutiny.

    4. Looking at the change process end-to-end, identifying bottlenecks, and experimenting with ways to shift validations into the development platform.

    5. Implementing information security controls at the platform and infrastructure layer and in the development tool chain, rather than reviewing them manually as part of the software delivery process.

How light weight change approvals help us?

The development team can perform the static code review by integrated code analyzers in their development environment as in software code is what is changing and delivered. There are security analyzers and test coverage analyzers that review the code and remind the developer of test coverage and security issues in the code piece. The code cleanup before checking it into the repository helps in improving code quality. The CICD tools perform regular builds and perform thorough code review after code integration, alerts and blocks the erring build. The associated visual dashboard displays the code quality and review reports. The automated devop tools further monitor the changes and alert the stakeholders.

Thus a level of automation ensures no weight time for review and common quality standards easily perceived by the team. When team members have a clear understanding of the process to get changes approved for implementation, this drives high performance. This means they are confident that they can get changes through the approval process in a timely manner and know the steps it takes to go from "submitted" to "accepted" every time for all the types of changes they typically make.

Common pitfalls in change approval processes

The following pitfalls are common to change approval processes:

    • Reliance on a centralized Change Approval Board (CAB) to catch errors and approve changes. This approach can introduce delay and often error. CABs are good at broadcasting change, but people that far removed from the change might not understand the implications of those changes.

    • Treating all changes equally. When all changes are subject to the same approval process, change review is inefficient, and people are unable to devote time and attention to those that require true concentration because of differences in risk profile or timing.

    • Failing to apply continuous improvement. As with all processes, key performance metrics such as lead time and change fail rate should be targeted with the goal of improving the performance of the change management process, including providing teams with tools and training to help them navigate it more effectively.

    • Responding to problems by adding more process. Often organizations use additional processes and more heavyweight approvals when faced with stability problems in production. Analysis suggests this approach will make things worse because this drives up lead times and batch sizes, creating a vicious cycle. Instead, invest in making it quicker and safer to make changes.

Ways to measure change approval in your systems

Now your teams can list possible ways to measure change approval:

While you consider your own environment, you will likely develop your own measures to understand and gain insight into your change approval processes. We suggest you use these to not only measure your process but also work to improve it.

In traditional change programmes, the central key is a change team. They interview those affected, create change readiness assessments, design new processes, construct communication plans and so on. When they take your views, they analyse, synthesise and consolidate these inputs into ‘programme documentation’. In conclusion, Lean Change is a co-creation-led, responsive and experimental approach to change. It sees change as a social movement.