One question an organization should ask when adopting agile is “what happens to our quality assurance function?” I’ve seen a lot of different implementations over the years – some good but most of them very, very bad. Part of the reason for bad implementations is because many companies are structured as functional silos. And part is a lack of understanding of what an agile team is. So let’s take a look at the role of quality assurance in the agile universe.
What’s an Agile Team?
If you look at the , you’ll see that a delivery team has these characteristics:
- Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
- Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
- Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis;
I prefer the term “delivery team” because the whole team is responsible for delivering a product. And that team may also include operations staff (especially for those organizations embracing DevOps). But the main idea here is that quality assurance should be an integral skill of the team. And that we don’t differentiate between “developers” and “testers” on a team. (There are other implications here that I described in a previous post).
That also means that developers on a team shouldn’t only focus on development and testers on testing. The entire team is responsible for everything required to deliver the product. This can be a bit of a surprise to individuals who are more used to their specific function. Coaches and Scrum Masters should prepare their teams for this change.
So When Should QA Begin?
Regardless of whether we have a mature agile team or not, when does QA start? The answer is “before the sprint begins”. When we’re looking at stories, either in backlog grooming or – at worst – during sprint planning, it should always be through the lens of testing. How are we going to validate and verify this?
During backlog refinement, the team asks questions to better understand the to meet the business need. They should understand the testing scope. When we use the , we help guarantee that we account for multiple variables but, in this context, especially “testable”.
So, while the short answer for “when should we start” is “as soon as possible”, the practical answer is “as soon as the sprint begins”. There is no reason why quality assurance should start only after development has ended for a story. Testing should start the moment we begin work on a story. We can always prepare our test environments and get automation and manual test scripts together at the beginning of the sprint. We need to change our mindset that quality assurance happens only after development “throws it over the wall” to the QA team.
@ Velocity
Many clients have their own quality assurance teams and staff. As a result, we try to merge them into our teams as full members. One challenge is that those QA people are often shared between multiple projects, so that’s where I sometimes push the client to make some changes. We want to have teams that are focused on a single product. And our QA specialists should be committed to that team as much as possible. It usually requires some changes on the client’s part, but I argue that we’ll see greater improvements if they can dedicate that person to our team. And our teams assume some quality assurance responsibilities regardless of the client’s staffing, so we’re always delivering a quality product. It takes time, but it’s important to “build quality in”. You can’t scale crappy code, so make sure it’s not.
Closing Thoughts
The changes required to make fully cross-functional delivery teams is substantial. It requires changing how we think about bringing work to teams, how we develop code, and how we verify and validate that code.
I often think about agile transformation in terms of a machine with a crank. Many people think that adopting agile means we’re changing the handle on the crank from an old wooden one to a nice, new mother-of-pearl one. And when they come back later, they find that the entire machine has been replaced with push button machinery like an elevator. It’s a drastic change to almost every function engaged in product development and the impacts are often unanticipated.
We need to carefully set expectations about what changes are needed. The biggest changes are likely to be in those areas that are most closely aligned with development – the business and testing. By helping our quality assurance engineers find the best way to participate in development we will find our way to better products.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)