One of the huge benefits of Agile is improved or increased quality. However, if you read Agile blogs and industry surveys, that does not appear to be the case. In fact, a reduction of quality due to Agile is cited more and more often.
Having conducted hundreds of Agile optimisation reviews across a range of different sectors and countries, I wanted to share my views about why this is happening, and what we, as an industry and as IT professionals, can do to fully realise one of the key benefits of Agile.
Let’s start with perhaps one of the fundamental cornerstones of Agile, namely that “quality is the responsibility of the whole team.” Sounds easy, right? But this is still one of the hardest Agile mindset changes to realise.
I believe that there are a number of reasons for this:
- Testers, particularly test managers from a traditional background, do not want to let go of their “quality police” ways of working.
- Team estimates are still factoring the incorrect coverage required to mitigate sufficient product risk, usually because the team does not understand the risk.
- Teams are often still doing their estimates in their siloed role - e.g., testers estimate how much testing is required while developers estimate how long to code.
- There is still too much regression testing that is not targeted at potentially impacted areas because teams are not having these conversations.
- Teams see automation as a silver bullet that can replace other quality activities or all testing.
- Testing techniques are not used enough, when they should be used to justify the creation of every test.
- Teams have too much reliance on the creation of upfront, manual test cases instead of session-based testing.
- Developers throw their share of the testing “over the fence” to testers and expect them to do it all.
- Some teams have no test professionals, even for high-risk projects, and the team members doing the testing tend to only test positively, leaving gaps in coverage.
- Scrum Masters do not have enough depth of knowledge in testing or quality assurance to coach the team.
To me, there is a direct correlation between these reasons and teams increasing the ratio of developers to testers, or even thinking that they do not need testers at all.
While I am not saying all developers aren’t cut out for testing, it is a fact that developers generally have a very different mindset from testers. You could almost say that they are like chalk and cheese.
Typically, developers think in terms of “how can I get this to work?” while testers think, “how can I get this to break?” To get a good balance on a team and increase product quality, you need a combination of both mindsets.
Shift to the left
Another common issue that I see all too often is teams not embracing a shift-left mentality. Shifting left is a cost-effective way to increase productivity with minimum effort, addressing issues, faults, and defects almost when they occur, thus reducing or even eliminating waste.
Let me give you a few simple examples. A lot of shift-left ideas are common-sense quality assurance practices that include some good engineering principles. When implemented correctly, your teams’ way of working can be changed for the better.
When writing user stories and requirements, make sure they are testable. This is one of the main tenets of the Agile Manifesto, namely working software. After all, if you cannot measure or test something, how do you know if it is doing what it is supposed to?
Include INVEST reviews or checklists as part of your definition of “ready,” making sure the review criteria are:
This is commonly known as a static review.
Of course, if you are going to use the INVEST mnemonic, make sure the whole team knows what it means and how to use it. I have been enthused to see numerous teams using this checklist as part of their definition of “ready,” posted right next to their task board, only to find out, when I ask them what types of defects they are finding, that they do not actually know what it stands for.
Another great technique, which comes from Extreme Programming (XP), is the discipline of thinking and writing automated tests before writing a single line of code. If you cannot think about how you are going to test it first, it often means that you have not fully understood what you need to code. That means you could have coded something that is functionally working but is not fit for purpose.
This is known as test-driven development (TDD). In this practice, the developer, business analyst, and tester all collaborate to ensure that the right tests are identified and produce a product that adds real business value. There are a couple of techniques that can be used for TDD, such as the Three Amigos strategy or pair programming, which has been expanded to enable pairing of multiple roles.
There are also several other processes that have emerged from TDD, such as behaviour-driven development (BDD) and acceptance test-driven development (ATDD). BDD directs the team to collaborate and focus on how the user wants the system to behave, while ATDD encompasses many of the same practices as specification by example, BDD, and story testing.
All of these processes aid developers and testers in understanding the customer's needs prior to designing a solution, and enables customers to converse in their own domain language.
Truly being Agile
Doing the right planning, and the correct amount of it, are also contributing factors to producing a great product right the first time. Agile is not about being ad hoc, but instead having the right discipline to plan so that team members all have the same understanding of what they are going to deliver and how.
Skipping or shortening steps to get through the planning as quickly as possible and start coding is a false economy. That’s why it is important to have a common goal for each iteration.
The team needs to understand the product risks and how they are going to mitigate them with the right level of coverage for testing. They need to decide who is going to do what testing and ensure that there are no overlaps or waste, but also no gaps. Test execution also needs to take place on at least day two of the iteration as a minimum, even if it is part of the user story.
With all these great techniques to reduce feedback loops to the shortest possible time, quality should increase at the same rate as delivery, or at least be maintained at a good standard. However, given that a lot of teams think that being Agile only means having a daily stand-up or doing the ceremonies, maybe it is not so surprising that quality is instead decreasing at the rate which delivery is increasing.
The moral of the story? To get accelerated quality in your Agile initiatives, you have to truly be Agile. This requires both commitment and perseverance, something that Agile training can help with.
If you are starting on your Agile journey, or feel that you are not getting the value from implementing Agile that you thought, contact us today to find out how we can assist.
This article was originally published by AgileConnection.