We have a scrum team where there are 5 developers, 2 automated testers, 1 manual tester. Our tasks are completely independent.

Shouldn't there be 8 people, every one should be able to do every task: write code, write tests for it, sometimes manually test something?

  • 1
    Are you paying the testers the same than the developers? Do all of them have the same profile (studies, experience)? Also, even if the answer is yes, then every member of your team will need to know more things, which means more time to build proficiency/expertise.
    – SJuan76
    Sep 9, 2014 at 13:38

4 Answers 4


Aiming for a universal team is nice, but it might be easier (and more feasible) to aim for a team whose members are simply not too specialized. For example, among the programmers, you could try to ensure that you don't end up with one person who only does back-end coding, one person who only does JavaScript, and one person who only maintains the database. Try to ensure that all developers get some exposure to everything else. This ensures that if the UI needs a ton of work, and all is quiet on the database front, the DB guy can step in and lends a hand.

Similarly, you might want to get your automated testers and manual testers to cross-train on each other's work, so they can help each other when necessary.

Of course, there may be times where you need a large testing effort (and not so much programming) and you can try to press your programmers into helping with the testing and generally, they should be able to do it. In my experience, asking testers to write code (if there's a huge code push) is more difficult unless they have prior experience.

  • There's also the possibility of "pairing" a tester and a developer and asking them to finish at the same time. There's a lot of testing that can be avoided with good code and a lot of bad code that can be avoided with good testing...
    – Sklivvz
    Sep 10, 2014 at 14:03

They should be cross-functional, but not universal.

Understanding something of the domain of the person to whom you deliver artifacts or from whom you receive them is very helpful, but understanding it as well as they do is almost always far too difficult; if one person could easily master both domains (or all three), then they wouldn't have developed into different domains in the first place! Therefore, understanding enough to conduct a meaningful conversation about issues in it is what you should aim for.

A helpful metaphor is the evolution of human handedness. Wouldn't it be better if both our hands were as dexterous as the dominant hand is? Sure, but it would require more cognitive effort to control twice as many nerve connections at the same level of detail. Nothing is free, so something else would have to give. Since most tasks are very well doable with one dominant hand and one ancillary hand (e.g. holding something steady + carving intricate designs on it), we have to assume that overall the handed paradigm delivers more value for effort, so that's what mother nature went for.


I wouldn't get too extreme (pardon the pun) in either direction.

If manual testing can only be done by one person, you have a problem. There could be parts of the app that don't require manual testing, but chances are you're going to delay a release eventually.

You need experts. Don't risk not having any experts in anything because they get spread too thin trying to learn everything or hopping from one cool framework to the other without getting anything shipped. Some people can get away with knowing just enough to work with and coordinate efforts with the person doing a different job. Not all devs are going to be experts at all the automated testing tools, but there are probably some coding practices to avoid because they make testing a living hell.

With Scrum, you're trying to create working software that is going to probably change often. Do what it takes to avoid any bottleneck in the process. If that means some people become more proficient at some things or someone else has to take-over when someone else is not available, then you have to do what it takes. Going too far in ether direction has its own set of problems.


Universal is a great concept, and certainly the gap between testers and developers is narrowing. However...... Nobody is going to be an expert in everything, so it does make sense to push user stories to someone who can move them through reasonably quickly. I had a team where everyone was supposed to be able to do everything, and it was really slow. Turns out my team members were spending the first two days in every user story refactoring the code to suit their personal style.

It's a balance. If you have loads of areas that only one person can deal with, you've got a big problem. But you probably aren't going to get to the stage where everyone can deal with everything.

  • 2
    "spending the first two days in every user story refactoring the code to suit their personal style" has nothing to do with the question asked, about abilities to write code, write tests for it, manually test
    – gnat
    Sep 9, 2014 at 16:33

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .