Performance By Design – an Agile Approach

I recently attended a Test Managers Forum in London and sat in on a presentation entitled ‘Performance By Design’ (TODO: Insert Credit). The presentation didn’t deliver any earth shattering content and I felt that a lot of the audience hadn’t quite grasped the concept (as I had not).  There was something there – but the details weren’t specific.  I like theories but without placement, context and concreate examples they remain abstract.  As the week progressed and concept simmered, I came up with a few thoughts. Here is my take:

The premise of the presentation was as the IT world moves to the Agile methodology, performance doesn’t easily fit in.   Stakeholders are often so busy getting ‘something’ out, that quite often performance isn’t thought about until it’s too late. Performance drops off the radar because it is an invisible deliverable and stakeholders naturally focus on the tangible.  The problem with finding performance issues late in the lifecycle of a product is that they are extremely expensive to fix – and can result in major architectural reworking.  Performance by design, in this context, means that performance is designed into the product from the onset and becomes a secondary Agile central pillar. To do this you need a role that that will carry the performance flag e.g. Dropping a Performance Consultant into team.  This doesn’t have to be a full time role; this consultant would pick up the banner of ‘performance’ and ensure that it isn’t forgotten. The role would ensure:

  1. Collation and firming  up of existing performance requirements (a requirements article here)
  2. Architectural performance and scalability integrity checks
  3. Prioritization of Performance Requirements
  4. Performance objectives are an active and measurable part of an Agile teams workflow
  5. Ensure that the Agile team are confirming the release against impotence propecia the agreed set of performance requirements
  6. Advise on practical ways in which the AUT can be performance tested
  7. Report on ongoing risks for the performance aspect of the project (Results and reporting stage )
  8. …. and more

What continues to surprise me is that the above considerations aren’t naturally thought about and embedded into a Scrum teams’ mentality.  On reflection its easy to see how they are forgotten in the flurry of the Agile activity and pressure to deliver.

The benefits of this approach is the avoidance of costly reworking, successful high profile launches, and mitigation of performance and load testing risks. Performance by design, if done correctly, should relegate the distinct and separate performance testing phase to a tick box activity.  Not a phase that is in place and solely relied on to discover performance issues.

Key Takeaways:

  • Design performance into the product from the onset
  • Make it a central pillar of the Agile process – allocate a role dedicated to performance
  • Ensure performance is tracked and reported against, not forgotten or dropped in the scrum rush

For me, Performance by Design is a thought process.  A good Performance Consultant will guide and educate a team.  They will leave a set of enabling tools and processes which allow the scrum team to design in and test performance as second nature. You can fish for a man or teach them how to fish – A good performance consultant will essentially seek to make themselves redundant.

In part two I will outline some good practices for building scalability and speed into a system. Link here – Performance by Design II

*If the project was a building, we could imagine a significant performance issue akin to replacing the foundations. Performance issues are almost always high profile, high impact and high priority.


2 thoughts on “Performance By Design – an Agile Approach

  1. Comment left on behalf of John Jeremiah from HP >>

    Bravo, great insight and recommendations. Having a performance SME/consultant on the team can help ensure that performance is included in their requirements (user stories). When performance and other ‘non-functional’ requirements are clearly stated, then the project team can architect and design the solution to deliver what the business expects.

    Early in my consulting career, I was responsible for gathering the UAT criteria for an imaging solution we were about to deliver. (yes, that should have been done much earlier in the process..) The client said…” we want sub-second response time to load an image in the viewer” Guess what – that was never a stated requirement, and the system, as designed, was never going to be that snappy.

    I believe what you are saying about performance by design applies to all project approaches agile and more traditional. What do you think?


Leave a Reply

Your email address will not be published. Required fields are marked *