I've been thinking a lot lately about leadership development and asking software testing professionals who contribute to SearchSoftwareQuality what it takes to head a test organization that consistently delivers high quality software.
Here's what I have come up with based on recent conversations with test management experts: 1) The best test organization leaders are not afraid to break the rules, and they often take actions that fly in the face of conventional wisdom. 2) These test leaders have enough self-awareness -- and enough self-confidence -- to get out of their own way, solicit honest feedback and admit when they are wrong.
In this installment of "Quality Time," I share leadership development insights I've gained from interviewing test managers and editing the articles they write for SearchSoftwareQuality.
Breaking the rules
The tester's real job is to assume a leadership role in helping business people figure out the right things that the software under development should deliver.
Many software organization rules are unspoken, but test pros who are tuned in know what they are. Case in point, test pros don't get invited to early planning sessions at the outset of application projects. The rule breakers -- the real leaders -- invite themselves. They don't do it out of spite, or to make a point about their own importance. They do it because they know their presence at the table will result in requirements that are specific enough to be tested. They show up because they never lose sight of the big picture: Better requirements produce better software.
The right way to make your way into this meeting is to say you are there for test planning purposes. SearchSoftwareQuality expert Pete Walen said, once you're in, make sure your presence isn't a hindrance and that you add value to the discussion. He has shown up at plenty of meetings he wasn't invited to -- often with a box of donuts, just for good measure. Next week at the Software Test Professionals conference in San Diego, Walen will offer his tips on leadership development in a session called: "Stepping Up to Leadership: Test leadership lessons from Harry Potter."
Sometimes breaking the rules -- and stepping up to the leadership role -- is about delivering way more than what's expected. SearchSoftwareQuality expert Lisa Crispin offered a good example of this when I interviewed her for my year-end wrap-up article Software testing trends 2012: Business alignment, not bug fixes. The tester's real job, Crispin said, is to assume a leadership role in helping business people figure out the right things that the software under development should deliver. The days of the testers-as-bug-fixers -- people who simply test the requirements exactly as those requirements are specified -- are mercifully over, Crispin said.
Real leaders admit when they're wrong
Last month I worked with management expert Johanna Rothman to produce a SearchSoftwareQuality video. Our topic was engaging business leaders in Agile projects. Among other tips, Rothman offered advice on what to do when your project's business sponsor stops showing up for the demos that showcase project progress. Conventional wisdom goes something like this: "Business people do that all the time -- they don't pay enough attention to technology projects."
The unspoken implication is that the fault lies with the business sponsor, never with the technical leader or software project itself. Rothman doesn't buy that idea. She recommends asking the business sponsors why they don't show up, and listening carefully to their response. "You might learn something," Rothman said. Maybe the software under development is the wrong software; maybe it's not delivering what the business sponsors expect. Finding that out now is a lot better than finding it out later.
Her advice on dealing with this not uncommon occurrence struck me as an excellent example of real leadership: Leaders don't buy into long-held conventional wisdom. They are self-aware and confident enough to solicit honest feedback. They allow for the possibility that they, not the other party, are at fault. Most important, they understand that the earlier they can implement a course correction, the closer they are to meeting their ultimate goal: delivering high-quality software.
When I told Walen what Rothman said, he said that admitting failure is one of the hardest things leaders have to do. But the ability to do so is the mark of a good leader. As a test leader, he tries to follow in the footsteps of Civil War Gen. and U.S. President Ulysses Grant. Grant said that if his people failed, the fault was his for not giving adequate guidance. But when his people succeeded, the success was theirs alone.