Quality in Agility

In a Agile Scrum world, the focus is on quicker & smaller deliverables in time-boxed durations, which inadvertently puts pressure on Quality of the sprint as well as release deliverables. To achieve the goals of the sprint, quality could get short circuited often postponing the defects to later sprints or later stage of product development. 

To deliver a product or feature quickly (although rarely the delivered content gets used quickly), teams often compromise on basic software development principles. A customer requirement or problem may need to be discussed, analysed & understood clearly before preparing for a solution. The solution needs to be designed for various use cases & conditions, whetted with potential customers, end users & soaked for a duration to remove pitfalls, before proceeding with implementation. Such a well soaked design solution is likely to have shorter implementation/test cycles & is likely to last longer at the customer's location. On the contrary, quick & dirty (poorly designed) solutions are likely to have a short lifetime with the customer.

Assuring Quality in a Agile Project

Given the challenges of completing the committed scope within the sprint schedule, how does one assure quality of deliverables and who is responsible for assuring quality. Below are some thoughts...

Scope freeze - Ring fence the scope of the sprint & the release to avoid scope creep. Most often, quality issues arise due to new scope being added constantly with the code being continuously churned while it is still being developed. To avoid quality issues arising due to scope creep, the team needs to freeze scope of sprint to ensure quality of what was committed at beginning of sprint. This does not mean requirements or scope cannot change (as agile methodology os based on ability to handle changing scope), but just that scope changes should be prioritised to be done in future sprints or in drastic situations, the sprint should be replanned to accomodate new changes. It is the responsibility of the Product owner to safeguard the quality of sprint output by preventing changes to committed sprint scope.

Test automation - Automated tests can ensure certain basic level of quality with each sprint, able to run tests quickly & repeatedly. Running tests as part of continuous Integration & deployment can support to find defects as soon as development is done. Automation comes at a price which the team should be prepared for and may not be exhaustive to achieve the expected quality. Getting tests automated also takes time which the team should plan for as part of a sprint.

Potentially Shippable Product (PSP) - One of the agile theme is to deliver increment of potentially shippable product with every sprint. That means to achieve the exit quality criteria of product with minimal feature content with every sprint. During sprint planning, only content that can be completed within the sprint with the expected level of quality criteria should be taken up. However, this requires practice & team discipline. In the intial sprints, typically, more content is taken which ends up in defects that don't meet exit criteria for the sprint. In such cases, Keep adding defects to the sprint backlog for subsequent sprints, until you reach the PSP quality criteria for the intial feature content planned. This way quality can be assured during the sprint duration at the sprint scope level. However, this requires discipline with the scrum team on strict adherence to the exit quality criteria.

Quality focused - Quality should be built in with every step of the product development. Quality is not just Tester's problem to deal with. Every line of code, every standup should discuss about quality, so that the focus is on defect prevention rather than to deal with cost of poor quality. Every member of scrum team should undertand the customer requirement & be cognizant of how his/her work is impacting the end deliverable. In other words, testing should be shifted as close to development as possible to reduce the cascading effect of defects.

Integrate across scrums - Typically, in agile scrum based model, the teams are structured as scrum teams & testers are part of the scrum team. Depending on how the work is split across scrums, there could be integration issues across the work done by each of the scrums. So, one approach to avoid quality issues falling out in between scrum deliberables, a Integration test scrum team can handle these outside of the regular development scrums. The Integration Test scrum can be responsible for dealing with testing of end to end use cases independent of the work done by the scrums. This is sort of double check the quality issues that could seep out of sprint deliverables, potentially, even arising out of lack of testers independent assessment within scrum teams. This approach could be followed where scrum deliverables are not directly consumed by end customers just after sprint completions.