Pages

Friday, September 6, 2013

Play Your Position: 99 Ways Workshop #78

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 


Suggestion #78: When you say, you're a tester, play your position, that position could involve much more than just testing in a start-up. It might even involve giving an opinion on the go/no-go decision. - Matt Archer


As I have been come back from CAST, and in the process participated in not just one, but three testing conferences (TestRetreat and Test Leadership Camp, along with CAST; yes, it was a very busy week), I proposed an idea that seems to fit well with this suggestion. I had originally hoped to make this into its own series of posts, but the more I think about it, the more I think the advice I would give for this lines up with one of the important ideas we discussed at Test Leadership Camp. 


"Play your position" feels so much like baseball slang, and it feels right. There's things you focus on at first base that are not the same as if you were at third base, the catcher behind home plate, the shortstop, an outfielder (pick your favorite) or the pitcher. Each thinks of different things, but each has a singular focus. Win the game. Score more runs than the opposing team. As the team in the field, the players have to communicate and work as one to put up a solid defense. The pitcher has the most immediate control, but when a ball gets hit, every one of the on-field team members springs into action, looking to make plays, create outs, or to take on double or triple plays. Ultimately, it comes down to being ready to react to the situation, and making the best of it.


Workshop #78: Learn and understand the specialties you have, and see where they overlap other team members. See what unique attributes and skills you have, and see if they can be duplicated. If they can, teach others how to do what you do. Spread the knowledge and the focus of what you want and intend to do, so you can increase your field advantage.


As was pointed out to me in a team meeting today, specialization is the rule, not the exception. No matter how well we try, no matter how much we train others, we will not be able to make purely transferable skills. There are going to be some things that we are just better at doing than other people will be able to do. That knife cuts both ways, I should also say. There will be things someone else can do that you will probably not be so good at. Some people are exceptional at writing automation code. Some people like to work on the actual frameworks. Some people just want to explore and see what they can find, and how quickly they can find it. While it might be easy to say "we have star players in each position, know your roles and just get on with it", the team plays better when they can understand what each other needs to do and can help each other do it. 


The process of becoming too much of a specialist, or being too frequently that "go-to" person, the what I and others refer to as "siloing". For those not familiar with the term, a silo is typically a pit or tower that is used to store grain or other items in a large area. To keep the materials clean, fresh and usable, they are also kept sealed or otherwise separated from other materials. It's this "separation" that makes the metaphor of the "information silo". 


If we want to take the literal interpretation of "play your position", then a shortstop would only do the actions a shortstop does, or an outfielder doing what an outfielder does. Sure, they specialize in their tasks (catching fly balls as an outfielder, picking up ground balls with the goal of throwing the runners out at various bases if you are a shortstop), but the ball team analogy also requires that the team members work together and read off the situations and the readiness of their team mates. In short, they cannot act as information silos. They have to interact with each other.


The same holds true for testers. It is common during times of stress or intense focus to go where we feel safe or comfortable, or have a strong affinity or natural inclination. For some, that may be into platforms and architecture, for others, it may be mobile devices, for others, it may be security or stress testing. There's nothing wrong with that, but if we spend too much time in our niches, we rob ourselves of the opportunity to do more and better work. Plus, we miss the opportunity of sharing what is fun about what we do with our fellow testers.


Bottom Line:


Play your position is good advice, and understand where you can best contribute is likewise also good advice. At the end of the day, though, it's not enough to just "play your position", but to understand what the team can do as a whole and focus on ways that the team as a whole can be better at what they do. Cross train, shuffle assignments, pair on projects, teach liberally. 


At the end of the day, there will still be specialties, you will be better at some things than others, and those others will be better at some things than you. that's to be expected, but by concentrating on developing a whole team, we have a better chance of building everyone up to achieve and play to the best of their abilities (not to mention the fact that someone else can "play our position" if sickness, travel, or something else prevents us from taking the field that day.

No comments:

Post a Comment