The agile methodology focuses on building in quality from the very beginning of the software lifecycle. That is why we aim to find and fix defects early on: A defect found and fixed in an earlier lifecycle phase is a multitude cheaper than the same defect at a later stage.
But how can we more easily make it possible to prevent defects from percolating deeper in the software development lifecycle by fixing them in their nascent stages?
This is the main theme of my latest article for @Gurock TestRail blog – where I explore and explain ways to foresee, analyze and thwart defects in an agile context.
The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?
In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.
Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software
What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.
The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.
What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.
A hardening sprint is an additional sprint that some teams run to stabilize the code and ensure that everything is ready just before release. Agile teams vary in their opinions on using hardening sprints in Scrum, but if your team does agree on having one before your release, there may be a lot to be done and varied expectations from the product owner, testers and developers. It may also lead to other work being delayed, leading to accumulation of technical debt.