I'm a product owner on a 10 people Scrum team (too big of a team already) and last week Management came to us stating that developers can no longer participate in testing from the next sprint on, and that they need to focus on development activities or automation only (which they have never done before).

Our team consists of 8 devs, 1 tester and 1 business analyst, so it's easy to tell that there is no human capacity to keep up with such code output rate.

The point is, we had been working for weeks on moving from timeboxed mini waterfalls to actual Scrum. Given that the team cannot change its structure in the short term, having developers actively participating on testing meant a great advantage for the whole team and we were actually being able to have shippable versions at the end of each sprint.

I'm thinking about how to reorganize the user stories on the next sprint with the help of the Scrum Master to try to find a workaround out. But the underlying message is terrible in my opinion: it doesn't matter if we had a balanced number of specialists, if dev team cannot involve on testing and vice versa when needed, there is going to be waste and the velocity will suffer, not to mention the product itself.

Management's proposals included intercalating sprints by switching between coding and testing, so you can tell they are not getting the idea at all.

What would you do next if being in my shoes?

  • 2
    Why not just reassign some Developers to become Testers? Scrum doesn't care about those titles, anyway. Does it come with a pay raise or something?
    – nick012000
    Commented Oct 25, 2020 at 9:35
  • 4
    @BlastDV, if the organisation cares that much about job titles, there are probably also different career paths and salary scales attached to those titles. That means a developer is probably willing to do the testing work for the team, but they might not be willing to change their career path. Commented Oct 25, 2020 at 12:38
  • 12
    Repeat after me: Velocity is a capacity planning tool, not a management target!
    – Todd A. Jacobs
    Commented Oct 25, 2020 at 13:45
  • 2
    @BlastDV, then I can also guess where the edict comes from: The false economics that those "highly paid" developers shouldn't be doing that lesser paid, less worthy testing work because they are being paid too much for that. Commented Oct 25, 2020 at 15:33
  • 2
    Have you asked management how they want you to deal with not having enough testers to deal with the amount of testing that needs to be done to deliver at a reasonable pace? When given unreasonable requests, you should take every opportunity to raise concerns and highlight problems (and propose solutions, like "we'll need 2 more testers") with the person giving said requests. You should very much expect them to not give you a satisfactory answer, but raising concerns is still important for the eventual "I told you so" (which should only be implied, not said, obviously).
    – NotThatGuy
    Commented Oct 26, 2020 at 1:46

9 Answers 9


Any Agile practice, Scrum included, relies on collaboration and transparency for it to work properly. Your management failed at both these things. They are imposing a certain way of working on the Scrum team (in fact, forbidding to work a certain way, which is even worse) without asking input from the team, and without even providing an explanation for the reason.

So before deciding on doing anything, you first need to understand the reason behind it. It's obvious that they lack an understanding on what Agile and Scrum are, and given the way they acted, it is a clear sign of a traditional management thinking, of telling people what to do, without considering for a second that they might be clueless. This might also be the Y solution from an XY problem. So first, find out what's going on, what they are trying to do, and why do they think this arrangement will do it.

I see in comments on other answers that this is a company transitioning to an Agile approach? The main impediment of Agile adoption is often lack of support from management. They are usually the ones deciding on an Agile transformation, and then they are the ones that don't help, or even worse, cause problems. So beware. People often like the status quo, have ingrained habits for things to happen a certain way (their way), like their fancy job titles and their corner offices, and will not be very open minded when it comes to changing things (consciously or unconsciously), especially to Scrum, who doesn't even mention managers.

Obviously, whatever solution you eventually chose to organize your work within the team, it must also be accompanied by a large effort in training management to understand the new mindset. Without it, you will be fighting an uphill battle and this will be just the beginning in a long series of "orders" the Scrum team will receive while trying to self-organize.

Your Scrum Master needs to step up (as part of their service to the organization) and try to explain why the team swarming clears obstructions and increases the flow of work and the team's throughput on delivering, while keeping the work bound by silly job titles only creates bottlenecks on testing (a 1 to 8 testing/dev ratio is a lot) and slows down the work of everyone. Depending on how management receives this communication, you will know if things will get easier or harder as you go ahead with your Agile transition.

  • I think I'm picking your answer for this question, I took my time to check every link you shared and found them to be useful, so thank you for that! Just one side question, the study about reasons for failing at Agile mentions percentages that don't add up (46%+41%+38%+38%+...). Am I reading it wrong?
    – BlastDV
    Commented Oct 25, 2020 at 15:33
  • 3
    @BlastDV, one failure can probably be attributed to multiple causes. It is fairly typical in such graphs that the categories are not mutually exclusive and for that reason don't add up to 100% but exceed it. Commented Oct 25, 2020 at 15:36
  • Thank you @BartvanIngenSchenau, it makes sense now!
    – BlastDV
    Commented Oct 25, 2020 at 18:10
  • Why do you think the failure is on management's side?
    – fectin
    Commented Oct 26, 2020 at 13:08
  • 2
    @fectin: because (from the question and comments details) the symptoms match. In general, management is one or more levels distanced from the actual work, so for their decisions to be good, they should contain the input from those doing the work. This wasn't the case here. A manager telling people what to do might work for workers on the factory floor putting sardines in cans, but it doesn't work for knowledge workers whose main job is thinking and solving problems.
    – Bogdan
    Commented Oct 26, 2020 at 17:44

There are two things I would do in this situation.

Firstly, ask the management who made the decision what impact they are trying to achieve. Also ask them how they plan to measure if the change is successful. Assuming there is a reason behind their decision then you can start to track one or more metrics to 'validate' the approach. This should allow you to demonstrate the damage that is being done to the team's effectiveness.

Secondly there is a clear need for coaching of the management team. In Scrum this is typically part of the role of the Scrum Master, but as Product Owner you can contribute as well. I would be looking to detail the thinking behind agile concepts like self-organising teams. The more evidence-based you can make this, the better. Sadly, management teams are often more likely to be influenced by outsiders with a strong reputation than by their own teams.

  • 1
    Reading your reply makes me think how improvise-first our management is, because there is no focus on experiment & evaluate but on extinguishing fires. In this case our Scrum Master (SM) did not step in, so I went ahead and raised a few projections on what to expect after this decision. I will take your suggestion on keeping my speech fact-based and work with the SM to make the problems this will bring noticeable. Thank you!
    – BlastDV
    Commented Oct 25, 2020 at 12:07

You've had some good answers already but let me pick up the topic of test automation. The best way to use testers is not for them to execute tests but to have them work on designing, developing and curating automated tests, analysing defects and working with developers to resolve defects. Efficient testing and defect fixing of course has to involve continuous close collaboration between developers and testers - no way to avoid that.

I expect your management are concerned about having sufficient oversight and control of product quality. Test automation ought to be one way to achieve that. I mention it because you say your dev team haven't previously been doing automation so this may be an opportunity to improve on that.

  • I find the automation path to be an interest step and one that is also totally new for me, as I have never seen it in action before. I will give it a look and bring up this idea to the team to see how we could start.
    – BlastDV
    Commented Oct 25, 2020 at 15:30
  • I agree with the gist, but the value of skilled exploratory testers should not be understated. Any scripted testing can and should be automated (and if you have developers who get testing, they are well placed to do this), which frees up your testers to handle exploratory work.
    – James_pic
    Commented Oct 27, 2020 at 9:59

Ask management what the problem is

Not 'what bugs, defects, missed deadlines, etc has we missed. But rather the awkward and hard to ask

What is the specific problem with what we are currently doing to address issues?
Who has observed it and decided that it is inefficient.
Why, specifically is it considered inefficient?
What, specifically is "inefficient" about it.
Without details like this you can't know what's behind the initiative.

Be poilte but insistent - what is the problem we are trying to solve? Reduce bugs?Meet deadlines? Improved customer satisfaction? Or following management order because they know best, have experience and are well paid.

Management will not seek out these answers based on what you posted. You will need to be creative and take initiative - for example, setting up a meeting with management to discuss, in order to address these issues.

You decide

  • Thanks for your input! I learned from this experience that sometimes management needs help being educated and we as first hand experienced workers can support that process on specific scenarios. Of course I still believe it's their job to review these situations in detail and gather as much information as possible to reach sensible conclusions.
    – BlastDV
    Commented Oct 26, 2020 at 21:26
  • This is the most important place to start. Management probably does not care what the Agile/Scrum stones say, so starting with their perspective and their problems is paramount.
    – Seth
    Commented Oct 28, 2020 at 11:28

Ok, let's get the misnomers out of the way.

You may very well be practicing all the scrum events, and holding true to those, but let's be clear:

Your team isn't agile at all. I'd dare say that your organization is not practicing the tenets of scrum, and that impedance mismatch (your dev team practicing scrum but the organization not respective the values) is what's causing your consternation (and the organization's, but one thing at a time).

Let's start with the softball:

last week Management came to us stating that developers can no longer participate in testing from the next sprint on, and that they need to focus on development activities or automation only (which they have never done before).

And let's see what the Scrum guide says about that, under the heading "The Scrum Team":

Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. (emphasis mine)

Later, under the subheading "The Development Team", the authors expand this principle:

They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and, (again, emphasis mine)

Your next paragraph sheds further light on the issue:

Our team consists of 8 devs, 1 tester and 1 business analyst, so it's easy to tell that there is no human capacity to keep up with such code output rate.

If I told you that more code was worse for you than less code; what would you say? You'd probably look at me like I'm crazy, but there are two theses that support what I'm saying:

  1. Does the 'code output' directly correlate into 'value that the customer needs right now'? Probably not, because even if it did; if the code doesn't work well and doesn't address all the ways in which it's used, it's not value, it's just a feature that's out there to tick a box. That may present value to sales; but in reality it's a liability built up for your development team over time.

  2. There is an idea called "The theory of constraints", basically your whole team only moves as fast as its slowest link; and to improve that, you have to reduce the amount of work to whatever the slowest part of the process is. There's more to it than that, but that's the first step. Eli goldrait's "The Goal" as well as "The Phoenix Project" go deep into detail about this, and the Phoenix Project has the added bonus of being "The Goal" for technology teams.

Management's proposals included intercalating sprints by switching between coding and testing, so you can tell they are not getting the idea at all.

What would you do next if being in my shoes?

If I were in your shoes; I'd do the following:

  1. Figure out what's actually bothering management. No, not getting code out is not bothering management -- they may think it is, but they're very likely wrong (see "The Goal" above as to an understanding why that is.

  2. After finding out what really is bothering management (we need to make X widget sales this quarter; and the code is our first step to being able to make those sales), the team needs to reduce its workload (there are four types of work, Business Projects, unplanned work, Changes, and Operations projects (keep the lights on work, like updating a database, or upgrading a framework, or fixing auditing or logging, or improving observability) to match its constraints. Ultimately you need to identify the types of work the team does and ascertain what sort of work has the priority depending on the needs of the company (hint, unplanned work has a way of disrupting all the other types of work), and then the team can only take on as much work as they have the capacity to handle -- and that capacity is dictated by the constraint. In effect, you can only do as much work as you can test, or that your business analyst can analyze.

Overall though, I'd take a step back and ask why the organization thinks Scrum is the answer? It's clear management doesn't like the principles of scrum, so why do they think operating with a scrum team is the way to go?

Anyway, if you haven't already read those books, you should read them. They're good reads, and they'll change the way you think about work and give you actionable advice on how to solve the problems your team is facing; but they won't fix the culture of the company; that's up to you and the scrum master and your political capital to fix.


Did management give a specific reason, for example regulatory constraints stating that code must not be tested by the person who developed it? Then the team might need to find a way to somehow satisfy these constraints, and yes, this may reduce productivity, so management should be made aware of the effect on project schedule.

Otherwise they are trying to interfere with the team's responsibility to self-organize, which is an impediment that the SM needs to tackle. Have a look at https://www.scrum.org/forum/scrum-forum/27831/management-interference-scrum-team for a somewhat similar situation. Of course, this highly depends on the SM's standing within the organization; if management doesn't want to listen to him/her this probably won't work.

  • The organization is in the middle of the transition to Agile, so it has years of stiff rules and policies behind, including one referred to the segregation of duties. The only explanation given was one related to the latter, but I honestly have a feeling that they are trying to keep their development metrics up towards the end of year review. This is because we have come across obsolete constraints in the past and management did make an effort to remove them.
    – BlastDV
    Commented Oct 25, 2020 at 12:16
  • And also because there are controls in place like cross testing and sign-off provided by the business analyst only after checking testing evidences. I guess this whole situation took me by surprise just when the team were starting to take off.
    – BlastDV
    Commented Oct 25, 2020 at 12:22

One problem I've heard about is that test engineers feel there is no place for them in Scrum, and/or that the various test suites and expertise they've built up are being discarded in place of automation. "Apparently we don't need test engineers anymore, Scrum wants everyone to be a developer and that's not the job I signed up for and spent years getting better at!"

It's possible that management is responding to either direct or indirect communication of such concerns -- although, if their proposal is to switch between dev & test sprints (I have also encountered that proposal), maybe not. But I thought I'd mention it just in case.

In terms of trying to persuade against the "dev sprint, test sprint" model, I might actually point to a more traditional PM technique like EVM, in which items are either "done" or "not done" and the project only earns value for things that are "done". "In testing" is the same as "not started."

If they're thinking that the team's productivity has declined because it's taking longer for work to be complete (ie, for coding to be complete so it can go to the next step), maybe point out that previously, you would report work as complete from the development POV, but really, neither you nor they knew whether it was complete until it passed testing.

A relatable analogy for this one might be an auto mechanic. "Would you take your car to Mechanic A, who gives it back to you when they've done the work but haven't done a test drive, so there's a chance the wheel falls off on your way home? or Mechanic B, who will take longer but that's because they did the test drive, found the loose wheel, and fixed it?"

  • Fair point, in our case testing is under a complete different LoB and luckily they are pretty much independent, in the sense that this management decision came from elsewhere so they are totally open to any approach we might want to take next. I just find it really hard to call ourselves an "agile team" having that sort of intercalated model, it feels like the team now needs to put its effort on "handling it the best way it can" rather than learning and deepening its knowledge and experience on something designed to excel.
    – BlastDV
    Commented Oct 25, 2020 at 18:17
  • Guess you mean't "not done" where you mentioned "not started"?
    – Tiago Cardoso
    Commented Oct 25, 2020 at 22:49
  • I meant "you earn just as much value from a thing that is not started as you do from a thing that is not done", so from that perspective, "in testing" is worth as much as "not started". "Done or Not Done, there is no started/in progress/in testing", to mangle Yoda. ;) Commented Oct 26, 2020 at 0:07

What would you do next if being in my shoes?

It might be too late, but generally speaking, drop the notion that "coding" and "testing" are two separate stages of development that follow different rules. A product gets build by software developers and it's nobody's business what they do between getting the requirements and turning over a product. Testing is not a separate step. You code some, you test some, rinse repeat, you think it's good, you let a colleague look over the code, you let another colleague do the tests again...

Once you tell someone who has no clue the actual details of how you work, they will try to "manage" them.

I kid you not I had the following conversation with more than one boss of mine:

PHB: Why does testing take so much time?

Me: We are going through the whole app and make sure it works.

PHB: But we could just save all that time if you were better at coding, then you would not need to test it.

Me: We are already pretty good, but nobody is perfect, we make mistakes sometimes.

PHB: Well, then you need to double check your work! Get a colleague to look over it, like we do it in other departments.

So... the person is absolutely aware that you need to "double check" something (could call it testing, but hey...), but if you separate it into a unit and put a price tag (or hours) to it, they will want to manage and optimize it, because it does not directly produce value.

The only way out is to not let people that are not involved in the job decide how you do your job. Two valuable variables of your work (and every other job basically) are speed and quality (third is cost, normally a fixed size due to a contract).

If your bosses are happy with those, it really does not matter whether you coded, tested, wrote unit tests, followed patterns or just meditated and came up with great ideas to do without the former. It's none of their business.

Matter of fact, that is exactly what Scrum tells you:

The Development Team
Development Teams have the following characteristics:

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;

Emphasis mine.


You got many good short term answers, my long term answer to not get into such a situation again is do not tell them how the sausage gets made.

  • Interesting approach, however I think that would work better when actually being fully empowered to be self-organized (both at resource & organization level). As of today we are still to dependent of the classic management structure where bosses are looking over everyone's shoulders. On the other hand, how does transparency fit in what you say? Isn't that an antipattern on itself?
    – BlastDV
    Commented Oct 27, 2020 at 9:26
  • To the contrary, it works excellent in non-empowered situations. The point is that software development is coding and testing mixed. Do not artificially separate the two. If the boss asks "how long does it take", say "5 days". Do not say "3 days coding, two days testing". That makes it seem as if testing is optional and can be negotiated away. It's not. There is no problem with transparency, it's the truth. It will take 5 days.
    – nvoigt
    Commented Oct 27, 2020 at 9:51
  • I am assuming that "testing" actually means testing for no other reason than to make sure you did a good job. If there is a QA department that needs to validate the software for external reasons (certificates, regulation compliance etc...), then that's their problem. The software will be done in 5 days, QA is extra and on an extra schedule of their own making.
    – nvoigt
    Commented Oct 27, 2020 at 9:56
  • I get your point, in our case by testing I meant the whole set of activities to give it the shippable/not shippable tag. Our testing is entirely technology managed, so end users are seldom involved on it due to business constraints.
    – BlastDV
    Commented Oct 27, 2020 at 11:43

This is a little bit of a nuclear option, but... Take them at their word.

Developers can only do development or automation, OK. So you can only include as much development in one sprint as can be signed off on by one person. It won't be very much, but it will be the most you can do with the rules in place. You need to be careful that your tester doesn't start skipping corners and/or working too much overtime, but maintains a steady rate of high-quality testing.

The rest of the time, developers work on automation. It doesn't matter that they've never done it before, they will have plenty of time to learn. In fact, they are going to be in automation boot camp.

Three potential outcomes:

  1. Someone in management decides that they preferred the old way after all and tells you to go back to it.
  2. Your team produces so much automation that they can reduce manual testing needs and can re-increase output.
  3. Someone in management decides that you are the problem (instead of ridiculous rules) and fires you (this is not without risks).

To minimize risk you need to let your management come to the conclusion that this is the natural outcome of their rules, rather than something you came up with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.