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.

What is continuous performance improvement?

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 implementing this?

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.

Comments

There is a typo in this sentence, “Rapid delivery processes can certainly help, but only when continuous performance improvement it planned and implemented at each iteration.”

Also, I would have liked a more in-depth explanation about how continuous performance improvement would solve these problems:
“We don’t have time allotted for this.”
“We don’t have infrastructure.”
“There is no budget to hire skilled people.”

As the agile testing framework is widely used by the testing analysts so its important that it performs efficiently on continuous basis to so as to maintain software performance on continuous basis. Thanks for sharing this article; it really helps me to maintain desired results.