Learn to “get traction” in your team. A guide for professional testers.
Software development is a fast paced world. We are constantly trying to work to the rhythms of “web time.” Professional software testers have valuable input for the team. The problem is that it can be hard to break free of the daily concerns to make that big impact.
Ideally testers are empowered to make positive changes in the organization and the product. The term empowerment is lampooned in Dilbert for good reasons. It’s a great management buzzword but companies rarely do a good job of putting it into practice. The reason is simple. No one can empower you like you.
You can empower yourself when you know how to get traction. Empowerment can trickle weakly from the top down, but it doesn’t have to. When you know the tricks you can empower yourself.
A tester’s job is to look at things and perceive where they might be deficient. A good tester may have a habit of breaking everything they get their hands on. Be careful that you don’t break the people you are working the closest with. Turn that critical eye inward and ask yourself how you can strengthen your work relationships with the people you work with. The best way to do that is by having a strong vision of what your ideal world looks like. Hold on to that and “show” it to your peers when the going is rough.
In the software world all of the power is really in the hands of the worker bees. Think about it. The developer you work with writes 100% of the code for his or her features. The developer’s boss doesn’t write a line of code. The product designer’s boss doesn’t write the specification or make the day to day design decisions that come up. Your boss doesn’t write the test specs, the test automation or run more than a handful of test cases at best. The further you go up the chain, the less direct impact a manager has on the actual code. The Product Unit Manager has almost zero influence on the actual technical work that happens in the product. Wow. You and your “feature crew” have all the power. Even in a non-feature crew model. All you have to do to change the product is convince one developer to do something different.
If you want to make a change in your area, product or organization you must start by getting the people doing the real work excited about it. If you convince one developer to do less and do it better there is nothing his boss can really do about. If you convince the product designer to make a feature a better fit for customer goals, the VP of your product can’t stop them. Start your great ideas right in your own feature. Get your peers excited about the cool ideas you have. Sell them to the people you work with every day. It doesn’t get easier than that.
“Always with you it cannot be done.” - Yoda chastising Luke on Dagoba. Don’t be a whiner like Luke. Stop thinking about what you can’t accomplish. It’s probably true you can’t get your entire company to change to a better process tomorrow. That’s not important. Find something you can make a little bit better today and do that. Go talk to a developer and ask them to help you think of ways to make a part of the program easier to test via automation. Have a passionate discussion about the benefits doing less and doing it better. Passion and enthusiasm are contagious. Concentrate on the things you are enthused about. Save the gripe sessions for later or never. Always frame your criticisms as “we can do better and here is my idea how.” It’s easy to complain about things that are wrong, but not usually effective. It’s surprising how often people will adopt your plan if you have one.
If you have some code and you want to factor out all the common stuff you don’t do it all in the same instant. It’s a process of iteration. Move a line here, a function there, a helper object over here. Then test each time you make a change. Think of your process the same way. Don’t try to overhaul it overnight. Pick one thing and move it to a better home. See how that goes. Then move on.
Test specifications are a perfect example of where over planning happens a lot. A tester reads the specs and other materials then spends days locked in their office creating a test spec. Then in the review certain sections get ripped to shreds. The tester fixes those and soon the test spec is closed. Later in the product cycle you realize you left out something basic and important. A better pattern is to start with the outline and short explanations. Run this by a peer, your boss, the developer and/or the pm informally. See what feedback stems out of this embryonic document. People will be less constrained by a deep level of detail and give you good big picture feedback. Go back and add some details. Get more feedback. Rinse and repeat. Both techniques will take you a week or two of calendar time. The iterative model will create better documents in same number of person hours and less “work” for you. Look for other places where you can replace planning with iteration. Iteration is very powerful.
Look for places where there is feedback in the software process. A prime one is logging bugs. How long is it on average between the time a developer writes code and you log the majority of the bugs? If you measure this time in weeks you have a feedback loop that needs closing badly. If the developer isn’t getting timely feedback, how can they improve their skills? What if the build process pointed out common coding mistakes? Some development environments have build in code analysis tools. Using them closes the code review feedback loop from days to minutes. Those kinds of tools have improve my coding substantially more and faster than traditional code reviews. This is a good example of doing less and doing it better.
Look for these loops and be ruthless about making them shorter and more meaningful.
Every software development effort has an official document set with The Process. I don’t know a single place that is following that exact process. Don’t worry about that. Concentrate on the actual traditions and workflow that is happening. You can get work done in any framework. Thinking too much about the big picture process will blind you to the major improvements you can make locally today. Just find one thing we can do better now. Can you find a way to do less and do it better today? Go do that. Then tell people how you did it and get them excited about it. The Process will mutate on its own for good or ill. Be an agent for positive change.
There isn’t a manager at any level in any company that wants to do worse today than they did yesterday. If you can show a clear path to improvement, management will embrace it. The trick can be showing the path in a way that management is compatible with. If you are reading this article you probably believe that one or more managers you deal with is obstructing progress. I am sure they don’t see it that way. You can still open their eyes if they won’t listen. Here are some tricks you can use to show your managers how to do things better.
The first time you say something like “I read on the web we should do less and do it better,” you may get a lot of resistance. That’s fine. That’s human nature. We aren’t entirely rational creatures. Keep at it. If you are genuinely passionate about doing less and doing it better it should be easy to keep discussing it. Don’t be shy about speaking up. Keep talking about it with anyone who will converse with you on the subject. Bring it up in the hallways and at lunch. It may take months, but your message will sink in. Pretty soon you will overhear people say things like “We need to do less and do it better. How can we accomplish that today?”
There are many clichés that come to mind about how to do something big. The journey of a thousand miles starts with a single step, and so on. It’s a true cliché. Try not to get frustrated because you didn’t scale Everest today. If you make one thing a tiny bit better every day, at the end of the year your impact will be huge. Break your tasks down, then break them down again. Just make sure you are going the right direction a little each day. Other people may seem to want to sabotage your efforts. Don’t worry about that either. Their distractions and setbacks are likely to be random. If you are committed to making just one thing better and work on it all the time you will win.
Remember that all the “real” work happens in the roots of the organization. If every worker bee in your organization is talking about doing less and doing it better, management will naturally fall in line. They won’t have a choice because the real work force will already be doing it. When you have an “aha moment” and realize how things could be better shop it around. Encourage the people you work with to think about it. Ask them if they think it’s a good idea. Ask them how they would go about doing it. Ask them what’s wrong with it. Infect them with your enthusiasm and be willing to be infected with theirs. Try to reach out to people who are your peers but you don’t talk to very often. Have lunch with someone from a different part of your company and discuss your good ideas with them. Get your meme out there. You will know you have won when it mutates, takes on a life of its own and runs away. Time to get started on your next great plan.
Testers feel like everything is out of their power. It can really feel like we are at the bottom of the hill and all the crap is rolling down to us. Don’t just whine about it. You can empower yourself when you know how to get traction. If you can do that you move from just running tests to improving the company. That’s a really big change in role, for the better. Don’t forget to put that on your evaluation this year. You can make any project you work on better.
Getting traction can be a subtle art. Think about ways to get traction and go make your product, your company and the world better.