Performance Engineering in an Agile Project

Posted by Vikas Hazrati on Mar 25, 2009

Sections

Process & Practices,

Architecture & Design

Topics

Performance Evaluation ,

Agile in the Enterprise ,

Scrum ,

Agile ,

Performance & Scalability

Share |

RELATED Research

Performance Engineering is an important software development discipline that ensures that applications are architect-ed, designed, built and tested for performance. However, mostly in traditional projects, the scope of performance engineering is limited to performance testing where instead of identifying the workload patterns and improving the process leading to better performance, the focus is on beating the clock under tested conditions. Balasubramanian,P shares an interesting perspective on building performance engineering practice in Scrum.

Balasubramanian provided the following overview of performance engineering activties,

• Collecting and validating the non functional requirements
• Developing the required models for analysis
• Developing a performance test strategy
• Reviewing the architecture and application code to ensure compliance to performance best practices.
• Reviewing the deployment of the application, and
• For pre-existing applications, reviewing the design and code to suggest appropriate tuning activities

According to him, performance engineering should be an essential activity in Agile because

• It provides immediate feedback about the system in each sprint
• It is easy to develop a false impression about performance – This is particularly true in Agile projects where a lot of focus is on delivering business value in each iteration. This usually results in  diminished focus on the system quality attributes.
• Refactoring may introduce code that performs poorly.
• The goal is shippable, production quality code - Performance engineering helps in ensuring that the system is designed, built and validated against the required 'Quality of Service' requirements.

Balasubramanian suggested focusing on the following four phases for introducing performance engineering in Scrum.

I. Planning Stage

Understanding requirements and planning for performance engineering activities.

• Use cases and Performance – Understanding the system qualities associated with every use case.
• Performance Test Strategy – Detailing out scope of performance testing, infrastructure needs, tools, licensing cost, metrics and results format.
• Identify Performance engineering activities in product backlog - Activities like workload modeling, performance testing, performance assessment etc should be a part of the baklog so that they are not missed.

II. System Architecture Phase

Validating the architecture in terms of system qualities apart from functional and business requirements.

• Architecture Assessment – The Performance viewpoint – Keeping a focus on quality, the architecture must be assessed using either of
  • Architecture Tradeoff Analysis Method
  • Cost Benefit Analysis Method
  • Active Reviews for Intermediate Design

III. Sprints

Building blocks for producing shippable, production quality software.

• Code right – Apart from regular coding guidelines there should be guidelines about achieving good performance.
• Create Performance Unit tests - Developers should write unit tests that tests the performance of the application developed in a sprint. Though, initially the benefit would be minimal because the system is evolving. However, as the maturity of the system grows the performance unit tests become more useful.
• Review Design and Code – Automated code reviews using tools like JProbe, FxCop to test for performance issues related to code.
• Identify and Automate Performance Tests – Performance test should be identified and automated if possible for the 'Sprint n' in 'Sprint n-1'.
• Identify bottlenecks and fix performance issues – Performance issues identified in 'Sprint n' should be fixed in 'Sprint n+1'.
• Performance Engineering Sprint – Finally, the teams should consider having a parallel performance engineering sprint for every 2-3 normal sprints. Activities like performance testing, performance assessment, capacity projection can be carried out in this sprint

IV. Closure Phase

Deploying the complete application in the production environment.

• Setup Performance Monitoring Systems – The production system should be monitored using tools like JAMon to report performance issues in real time.

In order to make the adoption process easier, Scott Barber provided a detailed collection of tips to the performance specialist on how to engage and be productive in an Agile project.

Balasubramanian does acknowledge that there are multiple challenges in building a performance engineering culture in any project. The biggest challenge being the mindset change to focus on system quality attributes just like the system functionality. However, the rewards for building performance engineering practice right from the start far outweigh the investment and the benefits start multiplying with every sprint.

RelatedVendorContent

Agile Maturity Model Applied to Building and Releasing Software

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Agile Practices to Improve Project Management Organization (PMO) Effectiveness

Visual Studio vNext: ALM features for Agile Planning, Team Collaboration

The Agile Tester

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   Agile no more vulnerable

   by Jim Leonardo

   If you aren't paying attention to performance, methodology doesn't help at all. Plenty of waterfall projects have run into performance problems at the end. The difference is that it's a LOT more obvious in an agile project because of the nature of time boxing iterations used in most agile methodologies. With the inevitable delays you run into in waterfall, performance ends up being just one more reason you are slipping. Regardless of methodology, you need to build in the time and resources to include performance analysis/testing/fixing etc. If you don't, it will bite you more often than not.
   
   All the best analysis, design, and coding practices simply won't help you with some of the hardest performance problems. The hardest performance problems often arise out of something that's being done that is subtly different this time around than the last 200 times you did it. What worked in the past isn't working in this situation, the only way to reveal that is with the code.
   
   The good news is that if you are planning on frequent performance checks, those iterative time boxes actually work in your favor. You are testing and using the system a lot more and so you have more opportunities to see problems early, and therefore fix them before people forget about the code in question. Granted, that won't always help, but it will in at least some cases.

   Reply

2. Back to top

   Re: Agile no more vulnerable

   by ganesan pandurana

   I do agree, no matter which methodology you adopt you will have to allocate adequate time to fix the problem. Agile or waterfall, performance problems will be caught and can be resolved only by testing more frequently. In essence, test driven approach is recommended to catch performance issues early on the dev cycles.
   
   
   regards

   Reply

3. Back to top

   No Performance Specifications?

   by Ryan Shriver

   While I think the method the article presents overall makes sense, I think its ironic that in this article all that's said about "defining non-functional requirements" is:
   
   "This is an area everyone would agree is important and critical, but is the one often missed or partly
   done due to various constraints. Efforts spent here will help the team to validate the performance requirements and be realistic about it."
   
   Really? Important but often partly done? Sort of like the coverage this gets in the article!
   
   It's a shame the article skips right over what's arguably the most important part of performance testing, clearly defined expectations of performance, and instead give it two sentences about being "important" while not providing examples, best practices, tips on how to clearly define performance levels, resources levels, etc.
   
   Perhaps adding something like Planguage for defining Non-Functional Requirements would be an improvement to this method? More details here:
   
   theagileengineer.com/public/Home/Entries/2009/1...
   
   -ryan

   Reply

4. Back to top

   Ok with the activities, not ok with the methodology

   by Fernando Poblete Arrau

   I agree with the activities but I think the way you propose is not the right way to achieve performance engineering. I think that instead of having performance-related items on your backlog or having a performance engineering sprint, all this issues should be part of your definition of done. This way, during the sprint planning, the team will have focus on performance engineering and related tasks will be implemented within the sprint.
   
   The product owner often don't have the knowledge to prioritize performance engineering items.

   Reply