Fail fast, improve rapidly: Delivering innovation with simplified change

What is your initial thought when you hear the term “rollout”?

For some, it instills a sense of dread.

Rollout signifies there is change on the horizon. A new development project or software launch is coming soon. Many of us have a natural aversion to change. We dig in our heels and grasp for any objections that will prevent it from happening.

But change is a mandatory requirement if a company is to scale and grow. Change introduces innovation to an organization. It triggers rollouts that deliver more modern products that better align with customers’ current needs.

So, how does an enterprise get its teams onboard with change? It may seem a bit counter-intuitive, but organizations should increase the frequency of change – until it becomes unnoticeable.

Like the process of growing up, we need to bring a “where did the time go” mentality to the software delivery experience. This doesn’t mean delivering perfect releases every time, but it does mean a simplified change approach to software delivery that enables a fail fast and improve rapidly culture.

Balancing incremental changes

Parents tend to not notice the day-to-day growth of their child. But visiting relatives who may not see the child regularly often express disbelief at their growth spurts.

We can be oblivious to change when we are a regular, active participant.

Consider adopting this same thinking with teams who may be resistant to change. The faster you can confidently release, the less noticeable the journey to the larger initiative becomes.

Of course, there is a threshold at which a change becomes too cumbersome for end users. To avoid reaching the change tolerance point-of-no-return, break the delivery down into smaller increments of quarterly, monthly, weekly, or even daily, to ensure not too much is introduced in any one release.

This method requires metrics that judge the amount of change proposed within each release and gauges the impact to the production system. For example, faster release times will be required for applications undergoing more change.

There is a unique strategy you can use to find the correct balance between the incremental changes versus the cost of implementing to meet the appropriate milestones. The basic principle is the larger the scope and broader the impact, the more planning, communication, enablement, testing, etc. that will be required. It could cost more time to orchestrate these discreet activities.

The most risk lies within the test effort and the subsequent development activities to address the issues found. When rework extends past the targeted deliverable, it delays a release until the next deployment window, which increases the impact of the subsequent production change and magnifies user disruption. The success of hitting a target release date depends on the speed of these feedback loops.

Change that is not proportionally distributed across the software development lifecycle creates a major shift in a user’s daily experience. It adds to the cost of hypercare to support adoption, leads to more production support cases to investigate, inundates support resources with change management tickets, and draws out resolution times for technical issues.

While support of releases is still required, the volume of change can be greatly reduced through rate of delivery, reducing the resource requirements. The relative amount of change and continuous delivery lead to less disruption and thus fewer inquiries for hypercare.

When change goes wrong

Change becomes more difficult when associated with negative consequences.

Let’s take for example what happens when there are errors in code. The rule of thumb is about 15 to 50 errors per 1,000 lines of delivered code. The volume of code changes correlates to the number of potential defects.

Many of these defects will be caught in various stages of testing and addressed prior to a release. Depending on the amount and quality of the code, this undertaking can result in a substantial amount of rework and a never-ending rinse and repeat process of defect management. The disruption could prevent an end user from recognizing the value of new functionality.

The methodology shift from waterfall to Agile was supposed to reduce the impact of these disruptions. The short durations of development sprints limited the lines of code delivered. Theoretically, Agile methodology should have limited the scope of testing due to the reduction of change. However, the speed at which testing is performed is often inadequate in relation to the deadlines of Agile sprints.

Eventually, many Agile practices will adopt a hybrid model with several development sprints taking place prior to a single iteration of testing. This only moves the paradigm back to a higher level of defects due to the lines of code delivered prior to testing.

The bottom line is that the longer the development window, the more volume of change between quality reviews and thus more potential for defects – leading to heightened recognition of change by end users within the software delivery process.

Paying attention to defects

While it might not be possible to mitigate all defect seepage, the risk profile of testing should be adequate to avoid any significant impact on the business operations. But even non-critical defects can still have an adverse impact on users and the overall perception of the release. Although these defects may have work arounds, they tend to create an uncomfortable user experience or be particular to a small set of users.

When the change is simplified and delivered in rapid succession, defects are addressed quickly due to the higher release cadence. When change slows down so can the expected resolution times. The feature improvements will be minimum compared to the resolution time to a defect if release windows are spaced too far apart. Additionally, the number of defects released can have a direct impact on the release cadence.

Once the rework to accommodate defect seepage surpasses the in-sprint feature development the release plans may be forced into a stall. To re-establish application quality, all defects need to be addressed which results in a larger investment with minimum gain. That is why it is imperative to make sure your quality process is at the heart of the release cadence.

Empowering Agile leaders

Change starts at the top and trickles down to the teams. How these changes to a company’s initiatives are communicated makes a difference to how they are received.

It is critical to ensure there is collective alignment to the objective of the overall change. It helps to break down large software rollouts into a manageable set of specific deliverables rather than sharing broad initiatives. This gives managers and individual contributors a north star to manage their deliverables against and produces a process of small incremental changes.

Executives need to be able to connect the dots between the incremental changes and the larger picture. It is similar to how a picture on a jigsaw puzzle box is used to orient a location of a specific puzzle piece. The more quality around the picture, the fewer vague assumptions about the individual deliverables and a feeling of less inherent risk.

Aligning simplified change to effective technology objectives can bring about clarity for the organization. The ideas of driving competitive advantage, growing business engagement, and reimagining operations should be at the root of all IT outcomes. The executive initiatives are then aligned to the outcome, the directors orient the projects to the initiatives, and the managers create the action items.

To enable this vision of simplified change, begin with empowering resources to venture outside of strict directives. Let them discover and implement actions that align to the outcome they are responsible for delivering.

To achieve simplified change, develop the quality of your technology delivery while maintaining alignment to a core set of executive outcomes. These changes should be made quickly to minimize disruption to the end users and protect against the risk of a defect that could cause a business outage.

The acceptance of non-critical defects will be more tolerable when resolution times can be achieved in the subsequent release. Ensuring that workloads do not become overrun with defects is a must to protect the orchestration of simplified change.

By keeping quality at the heart and delivering change rapidly and incrementally, your users may have a more positive view of the word “rollout.”