The number one vision of every SCRUM Master out there is the one of the interdisciplinary team. That one miracle staff that can handle any problem, no matter the domain, the task at hand or the complexity. All of them are the ultimate experts and working together as a unit in order to deliver change to the software in the fastest possible way. The best part about it? If anyone in the team goes missing, all the others can just take over that one’s part and guarantee a stable and perfectly shippable product increment.
Bullshit.
Let’s switch over to real world for now. A typical agile development team consists of 5-7 people, usually 80% of them being developers (or engineers if you so please), one typically testing the crap they’re producing, and one documenting it. If you have a very UI-affine company, you might want to have a graphics artist swirling around as well.
Usually, those people have been taken out of a bigger pool of employees in your company, have been assigned a supercalifragilisticexpialidocious team name (you know, the one with the cojones). They are a bunch of people with different company background (and have been there for a different amount of time). And they are here for one thing: do their fucking job.
If one applies as a developer, he wants to code
Obvious, isn’t it? Well, not in the world of holy SCRUM it is. I can’t count the number of times I heard the SCRUM Master suggesting to test our stuff ourselves if our tester wasn’t there. Guess what genius, there’s a reason why you should never test your own code! But in the rainbow-cast world of SCRUM everyone’s a specialist, no? So why should the UI designer not code some backend? Well for the same reason as he was hired in the first place: because developers SUCK at doing GUI.
If you’re going to apply for a job as a software engineer, in most of the companies they make you endure some tedious acceptance and skill tests, checking if you understood OOP and the mechanics of the languages they use. This is already a sign for a shitty company anyway, as it doesn’t speak much of agile if you’re taking over the choice of the tools your specialists are going to use. Anyway, you’re doing that test for a reason, and that is to prove that you are good at what you’re doing. If you apply as a tester, you’re most likely good in finding details out of a big picture, and a UI designer better has got some great portfolio.
What I’m trying to say is, we apply to a position because in that moment we want to do exactly what that position is made for. Sitting in a team of “experts” all of a sudden and being forced to do the stuff others would like to do, does not enhance efficiency. And it certainly does not help to praise this twice a day, dear SCRUM Masters!
Let me do What I do best, please?
Yes, I get it. The tester is ill and we will most likely not make it this sprint. That doesn’t mean that I want to sit around like an idiot for the next 8 hours. I’m an engineer, give me some engineering or give me the rest of the day off! But for sure don’t make me test the stuff I made myself, because I guarantee you I won’t find any mistake.
If its the common goal to max out the efficiency of the whole team, it should be in the best interest to let people contribute in their role. Forcing them into other roles raises only one thing: aggression.
