There was an interesting note I at a developer conference retrospective workshop on the topic of team dynamics. With a room full of developers, a bit of frustration to someone identified as tester was expressed.
The frustration was described as pigeonholing. You know, learning the parts of agile that you choose to enforce your message. Like as a tester, you would learn that "everyone tests", but you'd fail on learning that it would mean that you'd also need to do other things than testing. Everyone pitching in means *everyone*, not just the programmers.
The whole mention of this sounded very familiar expression of not understanding what the other party sees as the whole scope of tasks that need to be done combined with a bit of bitterness on unfairness of how we end up being treated.
I believe the core of the problem is in not understanding how to break down programming and testing into activities, perspectives and needed skills within them.
I find that it's fair to ask of everyone in the team that they grow their skills. I find that the umbrella term of testing (or programming, take your pick) includes a lot of width and depth, and gives a team endless possibilities of mixing up individual's focuses on what stretches them best next.
I don't find it fair to ask that when there is e.g. 1 testing specialist amongst 10 programmers to say that since programmers need to test, the testing specialist must do programming. In particular, if the "doing programming" means doing it alone in a corner, trying to pick up skills.
It seems to me that a lot of times these discussions are hard because we don't share an understanding of what the umbrella terms actually include. The tester saying "everyone tests" could easily mean that there's a lot of that work and people need to pitch in and that she won't be feeling available to leave the post for learning stuff outside her usual stuff.
I find that the container "testing a change" is easily a 10 minute task for a programmer and a 100 minute task (or more) for a tester. The results also vary.
Making the actual work more visible is one of the main reasons I love mob testing. All of a sudden the 10 minute task, with an expert in the room, grows into its full length, often extending even the original idea.
My main concern with the remark is that the honest discussion about how people feel might not happen at the workplace - instead we go to our own peers to complain and the work at office continues to annoy us just as much as before.
Feelings need to be talked about. I'm sure the only reason for testers to stick with their turf is not pigeonholing. It's often the feeling that someone needs to take real responsibility of that turf no other really really understands.
The frustration was described as pigeonholing. You know, learning the parts of agile that you choose to enforce your message. Like as a tester, you would learn that "everyone tests", but you'd fail on learning that it would mean that you'd also need to do other things than testing. Everyone pitching in means *everyone*, not just the programmers.
The whole mention of this sounded very familiar expression of not understanding what the other party sees as the whole scope of tasks that need to be done combined with a bit of bitterness on unfairness of how we end up being treated.
I believe the core of the problem is in not understanding how to break down programming and testing into activities, perspectives and needed skills within them.
I find that it's fair to ask of everyone in the team that they grow their skills. I find that the umbrella term of testing (or programming, take your pick) includes a lot of width and depth, and gives a team endless possibilities of mixing up individual's focuses on what stretches them best next.
I don't find it fair to ask that when there is e.g. 1 testing specialist amongst 10 programmers to say that since programmers need to test, the testing specialist must do programming. In particular, if the "doing programming" means doing it alone in a corner, trying to pick up skills.
It seems to me that a lot of times these discussions are hard because we don't share an understanding of what the umbrella terms actually include. The tester saying "everyone tests" could easily mean that there's a lot of that work and people need to pitch in and that she won't be feeling available to leave the post for learning stuff outside her usual stuff.
I find that the container "testing a change" is easily a 10 minute task for a programmer and a 100 minute task (or more) for a tester. The results also vary.
Making the actual work more visible is one of the main reasons I love mob testing. All of a sudden the 10 minute task, with an expert in the room, grows into its full length, often extending even the original idea.
My main concern with the remark is that the honest discussion about how people feel might not happen at the workplace - instead we go to our own peers to complain and the work at office continues to annoy us just as much as before.
Feelings need to be talked about. I'm sure the only reason for testers to stick with their turf is not pigeonholing. It's often the feeling that someone needs to take real responsibility of that turf no other really really understands.
