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 through using agile is cited more and more often.
Having conducted hundreds of agile optimization 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 help us realize one of the key benefits of agile.
Let’s start with perhaps one of the fundamental cornerstones of agile: Quality is the responsibility of the whole team. Sounds easy, right? But this is still one of the hardest agile mindset changes to make happen.
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 this risk
- Teams are often still doing their estimates in their siloed role—e.g., testers estimate how much testing is required and developers estimate how long to code
- There is still too much regression testing that is not targeted to the 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
- ScrumMasters 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 were like chalk and cheese; developers think, “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.
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 right when they occur and reducing or even eliminating waste.
Let me give you a few simple examples where you can easily change your teams’ way of working for the better. A lot of these shift-left ideas are common-sense quality assurance practices that include some good engineering principles.
When writing user stories and tracing requirements, let’s make sure that they are testable. If you cannot measure or test something, how do you know if it is doing what it is supposed to? After all, working software is one of the main tenets of the Agile Manifesto.
Include INVEST reviews or checklists as part of your definition of “ready,” making sure the review criteria are:
Independent
Negotiable
Valuable
Estimable
Small
Testable
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 with 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, 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 it is that 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 generally been expanded so that multiple roles can pair.
There are also several other processes that have emerged from TDD, such as behavior-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 allow customers to be able to converse in their own domain language.
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.
They have a common goal for each iteration. Skipping or shortening steps to get through the planning as quickly as possible and start coding is a false economy. 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 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, it is unexpected that quality is not increasing at the same rate as delivery. However, given that a lot of teams think that being agile only means having a daily standup, maybe it is not so surprising that quality is decreasing at the rate at which delivery is increasing. To get accelerated quality in your agile initiatives, you have to truly be agile.
