Forget Roles; Embrace “One”
Recently, I attended the Simple Design and Testing Conference in Pittsburgh, PA.
It was an excellent open space format conference. Naresh Jain and Andrew Chen are great men to organize such an enlightening conference. Also, thank you sponsors (Univ of Pittsburgh, Agile Alliance, Version One, Pillar, Open Information Foundation, Lean Dog, Foreopen, and Westinghouse.) for enabling us to attend the conference for free. You guys rock!
To get into the conference, you had to write a position paper on a topic you’re interested in discussing. My position paper was on “Do we, as software testers, really matter?” You can go read it if you want, but it’s one of the most depressing pieces I have ever written so you’ve been warned. Basically, the premise of the paper is does it make sense to have software testers anymore or is it a deprecated trade with the evolution of software development? When I talk about the evolution of software development, I’m talking about things like Test-Driven Development (TDD). Since developers are being to take a test first, proactive stance toward quality, are we as pure software testers still needed?
Roles? Where we’re going we don’t need roles:
One of the guys brought forth the position that “roles are evil”. Basically, his position was something like roles within a software team are damaging because it silos responsibility to one person. For example, if something breaks in production, then the tester is at fault for not testing that particular part. There were several people that agreed that the team should take responsibility for all aspects of the development of the software. Instead of concrete roles, teams should have “specializing generalists”. What that means is that you should hire exceptional people that are talented enough to fill many roles (writing code, testing, talking to the business, architecture) but maybe specialize in one or two things. I call this the “Commando Concept”. In commando teams, you might have a medic, a demolition expert, a linguist, a martial arts expert, but they are all commandos. Everyone should have should general knowledge in each area. If a man gets hurt, everyone on the team should be able to give him medical help. If they need to take down a bridge, everyone should be able to set up the charges and blow up the bridge. Of course, they all need to know how to handle a hand-to-hand combat situation. In the same way, software team members need to be able to cover all roles in order to get things done. I liked the concept. I thought it was great.
Reality:
All of this sounds good, but in reality, it never works that way. One woman named Audrey brought up the fact that when everyone is responsible for an item, no one is responsible. Things that no one wants to do just fall through the cracks and don’t get done. For instance, there’s many developers out there that really hate testing (I was surprised to find so many developers that love testing at the SDT Conference). Some loath testing because they could be writing more code instead of testing. So, instead of testing the code that needs to be tested, they might take another coding task, and the testing never gets done. Maybe it’s touch points with the business, where nobody wants to go talk to the business to hear about their technical pain points. Roles are in place to make sure that someone takes up the responsibility for what needs to be done. The tester position is in place so that someone on the team worries about quality control and quality assurance. Testers think differently, and it takes a little time to switch between a developer hat and a tester hat. Sure developers can write unit tests and check basic logic and functionality, but who’s going to find the strange bugs that can only be found through exploratory testing? (And yes, these bugs exist.) Can you find people that have the talent to fulfill all the roles and have enough motivation to do them well? Even if you have exceptional people that can be a tester, a developer, a business person, and a user, can you get enough of them to fill a whole team? In reality, most businesses can’t afford to retain that many exceptional people. It comes down to pure economics. For a business, it’s cheaper to have one rock star that can do anything and the rest of the people functional in their one role. If you have a team of rock stars, then the company will break up that team and put one rock star on every team. Or those exceptional people will leave the company in search of better opportunities. Or worse, the company sees their greatness and makes them into a manager, giving them a raise and throwing all their talent to the curb to be eaten by rats, birds, squirrels, ants, and raccoons.
Conclusion:
There may be enough exceptional people out there that can form a team, take on all roles, but trust me, the company will be unwilling to pay for those people. Even if they get them, they won’t be able to keep them. Since we may not be able to get the pure, roleless team, let’s look at what we can do. I think that you assemble teams, and you give them the expectation that everyone is responsible for everything, especially quality. To borrow from the band U2, I’ll call this the “One“ Philosophy. ”When it’s one need…We have to carry each other.” As a team you have ONE goal: release high quality software. It’s not your part and my part. It’s the summation of all our parts. It’s all or nothing! One! We have help each other out and fight through our collective short comings. ”We’re one but we’re not the same…We have to carry each other.” Your role is developer. My role is tester. We are not in the same role, but regardless we have to carry each other to reach our goal: release high quality software. As you embrace this philosophy of One, you will see the roles become fuzzy. A developer might do testing. A tester might gather additional requirements. And a business analyst might fix the code. OKAY, THE LAST ONE MIGHT BE A STRETCH! But the point is once you carry (care) for each other, those roles won’t matter. One will matter.
Marisa Roman
Daniel Brown
Josh Carroll
