Should a Product Owner be asking developers to do QA to meet deadlines?

Question

When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline.

• What should the developers do when this happens?
• What's the right thing to do from a Scrum perspective?

Answer 1

They should absolutely be doing QA. In fact, in the ideal agile team there are no specific roles.

Agile development is quite the opposite of the "throw it over the wall" mentality of development vs. QA.

Clearly the problem is: if a feature is not Done, should people get off the story and do something else? And if QA is not irrelevant (in other words, it actually finds bugs), who is going to fix them and when? Clearly if QA is part of the development team, stories need to be "bug-free" before they are Done. On the other hand, realistically, this means that some development must happen necessarily after QA, but within the same sprint.

This is why I've often advocated pairing between QA and developers. A story should be developed and QA'ed at the same time. This can be achieved when there's coordination, and development introduces QA features in code (e.g. tests), which removes work from QA, and when QA codes automated features and avoids manual testing. In this way it's much easier to get everything done at the same time.

Answer 2

Should developers do QA?

I guess it depends on what's more important to you: sticking to your job description to the letter (and interpreting being a developer as "I ain't do testing stuff, only write code"), or delivering working software as part of a team (which would imply that everyone is helping out each other as needed, even by doing unpleasant or boring stuff when it has to be done).

Even though you may be employed as a "software developer", in Scrum job titles are not that important.

A Scrum team in a Scrum environment does not include any of the traditional software engineering roles such as programmer, designer, tester or architect. Everyone on the project works together to complete the set of work they have collectively committed to complete within a sprint. Because of this, Scrum teams develop a deep form of camaraderie and a feeling that "we're all in this together."

(Quoted from here.)

In other words, if Joe is held back with his task and can't complete it till the end of the sprint, it is of no use to the team if Jim is fully done with "his tasks" and sitting idle, or is working on something less valuable rather than helping Joe.

So yes, in a well functioning Scrum team, even though members may have different primary expertise areas, still developers occasionally (or even often) do testing, testers may help out writing SQL scripts, DBAs sometimes jump in to configure a development server etc. etc. It is often said that Scrum teams need T-shaped people.

In case you are worried how this affects your marketability and long term prospects as a developer, Geoff Watts has good news for you:

growing evidence suggests (unsurprisingly) that the rates for developers with good testing/quality skills are much higher than those without.

(From Scrum Mastery, p. 149)

Note also that emerging best practices in this industry include developers writing unit tests and doing at least some integration testing to ensure that their changes work as intended before commit. From this, it is not a huge leap to assist in other types of testing as needed. In fact, I used to work in a Scrum team where we had no dedicated QA personnel at all; only four developers. And we did all the testing ourselves. It included building an automated, shell script based testing framework alongside developing the product and writing our unit tests. And actually it was much more fun than you might expect. But of course, the most fun was actually to see the project succeed :-)

Why is there too much QA work for your team to handle?

Looking at the larger context, your question raises some general concerns though. Sounds like your team may not be actually producing a potentially shippable product increment at the end of each sprint, instead you have one or more integration/testing sprints before the planned release. This does create an imbalance and slows down your team in the long run, so depending on the circumstances it may be worth raising the question how your team can move towards more frequent deliveries. The answer may include test automation, involving the testers earlier, slicing up your backlog items into smaller chunks... But these are just shots in the dark, without knowing more details about your actual situation.

Answer 3

What's Wrong with Your Team's Processes

When the deadline is tight and when there are not enough QA people, the Product Owner asks developers to join in with QA to meet the deadline.

Your process problems are legion. Let me count at least some of the ways:

1. Your Product Owner should never, ever be assigning work to the team.
2. Your "developers" and "QA people" are not on the same team, or not working closely enough together within the same team to meet Scrum's definition of a Development Team. A good Scrum team should contain all the skills needed to meet each Sprint Goal within the Definition of Done.
3. Quality assurance doesn't sound like it's part of your Definition of Done.
4. You have deadlines instead of iterations with potentially-shippable increments.
5. The team has accepted stories it may not have the bandwidth to complete according to the Definition of Done.
6. Your team (or teams) are not on schedule for successful completion of accepted work, but no one has identified a root cause or actionable impediment, or asked the Product Owner to consider an Early Termination and a return to Sprint Planning.
7. A team with chronic resource constraints is either not following the Scrum methodology properly, is consistently mis-estimating tasks, or treating velocity as a management target. Fix the process!

You may have other process problems, too. However, these are the ones that really stand out for me, and I generally recommend teams start with the low-hanging fruit.

How to Fix Your Team's Processes

Here are some suggestions for improving your processes. Feel free to adapt or refine the suggestions to fit your specific team and organization.

1. Enforce the Scrum framework rigorously.
2. Ensure that Product Backlog stories are properly refined, and granular enough to fit within a single Sprint.
3. Ensure the team uses Sprint Retrospectives to inspect-and-adapt its estimating practices and its Sprint Planning Process.
4. Ensure the team only accepts work into each Sprint that fits within the established velocity range, while still providing enough slack for unforeseen events. Don't fall prey to the %100 utilization fallacy!
5. Ensure unit tests and acceptance tests are part of your Definition of Done, and make sure the whole Development Team shares responsibility for swarming over stories that need additional resources.
6. Whenever the Sprint Goal may not be met, meet with the Product Owner to refine scope or request an Early Termination.

You may certainly find other ways to improve the process, too. Don't stop there; Scrum (and agile practices in general) are all about continuous process improvement!

Answer 4

In my teams all developers would cross-check their developments/bugfixes:

• Review their code using a GIT pull request,
• Validate the behaviour by testing it in the browser,
• Validate the functional behaviour too - if it's illogical, it's the role of the peer to go to the functional expert/PM and check the development still makes sense.

It's a great way to spread and exchange knowledge so both developers have knowledge on the ins and outs of the software. Since it's a peer review, all developers put their issues in QA at the same time of the sprint and test their colleagues' issues, so it doesn't add lag and it rather empowers them to discuss and fix issues.

In your situation, it seems QA hasn't been done during the development process and you're doing it altogether at the end of a cycle.

Answer 5

I don't know the specifics of agile, but having the same individual checking his/her own work is like having an inmate holding the keys to his cell.

The incentives are different. The QA / QC person is incented to find as many defects as possible while the builder of product is incented to boast what a great job was done first time around.

Now let's get to the human factors, the biases that affect ALL of us. We don't see what we don't want to see. If we think we did a great job building something, then we intuitively look for evidence that shows that and ignore, dismiss, minimize, justify the evidence that contradicts it.

If you have developers do their own QC, then you are essentially degrading the QC capability to the point where you could be better off cost wise to just deliver without it and go at risk. Conduct QC is expensive, paying for lousy work is very expensive. Delivering a product with defects is also expensive...but you didn't do anything to minimize that cost so you might as well just pay once.

Answer 6

No.

I think that QA is completely different kind of work than development is, that it requires a completely different skillset, that it is repetitive and therefore quite annoying for a developer, and as such - I think - unnaceptable to be transfered to developers just becuse they are capable of doing it. Why is QA team never asked to do development? Why are DBA never asked to do development? Devs are on top of a pyramid and POs are taking advantage of this to fill in their organizational mistakes and miscalculations?

Answer 7

An agile team is a cross functional team. Their ultimate aim is to complete User stories committed for current sprint. Thus it is absolutely fine for developers to do QA when time permits and to meet deadline. However, the Product Owner asking for this change is against the rules. A product owner is there to define the product requirement, furnish details, clarify queries, participate in product demos, and in the end accept/reject a sprint. The Scrum master can make this decision to deploy the resources more efficiently.

Answer 8

First and foremost, the project manager should be setting the direction for the team and assigning work. Product Owners should not be doing this. It sounds like there is either no PM or there is one "in title only", and their influence is weak. You should seek to correct that situation first, so everyone understands their role on the team.

Agile team principles would say that developers should be able to help with QA. But I would add these qualifications:

1. A developer should only do QA for someone else's development, not their own.
2. It would be preferred for the more senior developers to do QA, not the junior members.
3. If at all possible, a brief review of what was tested and the results should be held with a member of the QA group.

Answer 9

What should developers do and what is right within scrum: If you are truly following scrum you should find out what the priority of the request is, discuss the request and come to an agreement about what you will do and estimate it, commit to doing the things you agree to do and then follow through and get them done.

Some things to consider:

When talking about QA you are describing many possible things. For example, QA might be manual testing of the software in a production-like environment (we don't all get to do full CI/CD with 100% automated testing even if some of our peers are doing that). It might also mean something as close to the development effort itself as writing good unit tests. The place where programmers can work most effectively is nearer the code. We often do not feel as comfortable testing "the whole system" for any number of reasons. Those reasons might even include that we can get caught up in the process of trying to perfect the overall product when we should be focused on the change we are making. Sometimes this is a good thing and sometimes it is disastrous. Consider the case where you are a developer on a small team within an organization that has hundreds of developers working on a really large system for example. Getting your developers' hands dirty sounds like a good idea and might be, but it might also mean getting no code written during an iteration because they are spending time trying to reproduce scenarios they are unfamiliar with or configuring environments that they don't fully understand or even just trying to obtain needed credentials for parts of your system that they do not normally have access to.

Working closer to the implementation is a more likely success as far as good use of developer time. Your developers can easily (very possibly MOST easily) build automated tests of small units of the code. They understand the individual classes, functions or modules in your codebase and the details of how an individual part that they are working on SHOULD be well understood by them. Small-scale automated tests like unit tests probably don't require special permissions or access and should be something your build can include so that the smaller parts of the code are know to be high quality already. I would recommend that automated testing be something your developers work on from the inception of any enhancement to the codebase. They are useful even when fixing bugs.

I never want my developers working on manual testing of the UI or even running batch jobs manually for that matter. I certainly don't want them testing their own work if they are the "last line of defense" before the customer finds a problem. QA experts are much better at that and a good QA team member will be more focused on the right kinds of details and simple know how to build a good test plan and execute it. So in cases where we mean those kinds of testing it is my opinion that developers are a bad choice for the work.

We almost all take pride in producing high quality software but we should take advantage of the skills of different experts in ways that make sense. The scrum guidelines say you should have a cross functional team, but they do not generally say that a developer is a tester. They generally say that everyone on the team should be skilled enough to do any of the jobs that the team does. Maybe it would be better if you considered one of two obvious ways of composing a team to fit that description. You could either make all testers and developers the same (and require a person with the skill and interesting in doing all of it). You could also make two different teams, one that focuses on writing code and another team that makes sure the code works. The second option sounds "bad" to many managers but in the few cases where I have seen this done it works WAY better than the first option. I think of it like this: if you were building a car you would probably not have the same guy welding the frame together as the guy connecting the wiring or the guy doing painting. They all work together. If they don't the car sucks. It has nothing to do with throwing things over the wall because they are on different teams or not and everything to do with realizing that everyone on the line is building a car and if they do a bad job the car will suck. That also means they have to care about it. If your team doesn't care then no amount of togetherness or team building or co-location or open work areas will help you build a better car.

Final point: Even if they find some bugs and even if you manage to check the QA boxes, you still run the risk of losing a talented developer by pushing them into a manual QA position. I'm not saying I would ever quit a job for that but I will say this: I know many highly skilled developers who have left over just this issue and I know that my teams have regretted every one of those losses.