Continuous Performance Improvement in an Agile World

Modern organizations have moved from serial development of monolithic applications — assembling and releasing once or twice a year — to an agile, DevOps, and CI-CD motion, where applications are developed and deployed often and in smaller blocks.

We’ve all heard about the internal and external advantages of rapid software delivery. However, while pursuing the goal of rapid delivery in all points of the lifecycle; performance checks often take a back seat.

Where does software performance testing fit into the Agile and DevOps development process?

No matter how seasoned the development team is, less than 30% of software projects using the more traditional software development processes actually end on time.

Rapid delivery processes can certainly help, but only when continuous performance improvement is planned and implemented at each iteration.

What Is Continuous Performance Improvement?

Continuous performance improvement (CPI) normally takes the following structure, which is iterative and fits well with both Agile and DevOps software development methodologies.

It starts with defining the performance thresholds, both at the sprint level and at the project level.

Next step is setting up the right metrics to measure performance and setting up realistic methods to analyze the performance data.

Once you get data-driven actionable items, it’s time to improve the application performance. We know that what  gets measured gets improved, and what gets improved sticks with customers.

Finally, to close the loop, the last step is to control the levers that control the performance. For example, if an external API determines the majority of the overall performance of your application; controlling that API’s response time, setting up SLAs to hold your API provider accountable is done at the control stage.

What Are the Challenges of ImplementingThis?

Like any other process change, continuous performance improvement can come with challenges.

The common challenges related to budget or bandwidth are often viewed as blockers:

• “We don’t have time allotted for this.”
• “We don’t have infrastructure.”
• “There is no budget to hire skilled people.”

But once internal buy-in is achieved and continuous improvement is made a priority, these can be resolved with simple tactical steps.

Other Times, The Challenges Can Be Strategic.

These challenges can be a bit more difficult and time consuming to resolve — including cultural differences, misalignment, and buy-in to the performance goals.

Organizations can’t force collaboration and improvement just by implementing DevOps at the conceptual level, or making Dev and Ops work together on the same tools. The other strategic challenge is performance checks not being part of the process.

• “We haven’t done it traditionally, so why now?”
• “Whose responsibility is it?”

Strategic questions like these can be solved when performance becomes one of the major focal points in the organization, top to bottom.

Whose Responsibility Is It?

As projects get broken down into smaller, manageable pieces, development teams can concentrate on performance and quality at a granular level. Also frequent multiple iterations and integrations allow developers and testers multiple chances to validate and review the application – finding and fixing application issues as they come.

The responsibility of performance improvement is spread across the lifecycle. Developers write code that performs well, testers test application for high quality performance, and operations makes those tests continuous by monitoring the application in production for performance and quality.