Curse the savior who works around the clock to save the project. Their inability to prioritize is only one flavor of IT project botheration.
Is your software testing group a finely oiled machine? No squeaky wheels, nobody burning the midnight oil, projects finished on schedule with no whining about a lack of time or requirements clarity?
If Yes ==> goody gumdrops for you ==> stop reading ==> go to kitchen ==> get cup of coffee.
If No ==> purchase rope/constraining devices/muzzles ==> practice hog-tying ==> continue reading.
Because let’s face it, the unfortunate aspect of software development is that it involves humans. Mewling, disorganized, miserably analog humans. Sometimes they smell bad.
In January, Software Quality Connection published an article by Brenda Kerton, I Think My Testing Group Could Be Better. Kerton listed some questions to help people pinpoint testing issues, such as, “Do you feel the time allocated for your job is too little, too much, about right?” For each of her questions, the specter of a particular type of team malcontent, each wailing about a given issue, rises out of the project miasma.
Regardless of the Pollyannas who cry out, “No, no, Agile takes care of all software testing team imperfection! Surely these malcontents of whom you speak belong to an alternate reality!” I reached out to testing experts for their take on how the human testing issues might look and how they might be remobilized, de-whinerized, and repurposed to once again promote team harmony and hygienic office conditions.
Because truth be told, you probably have problem children on your team. Here’s how testing guru Alan Page—one of Microsoft’s first Test Architects and current Microsoft Software Design Engineer in Test—puts it: “You’re going to have whiners in any organization. I don’t care if it’s software or making widgets for the auto company. You’re going to have people who want to be the victim, who want to have some drama, who want to whine about some things,” Page said. “I’m not saying it’s a good thing. But we work with humans. When we get to our robot society, we can have a different discussion.”
==> Proceed for non-robot identification and hog-tying strategies.
The Time Whiners (a.k.a. Armless Children)
For James Bach—principal consultant at software testing consultancy and training center Satisfice Inc.—whiners are top-of-mind problem miscreants. It’s just far too tempting to avoid complaining that you don’t have what you need to do your work.
Bach calls it the "not my job" theory of testing. “That's when testers criticize the designer for not delivering a good spec but don't do anything to independently interview and learn in order to discover what the spec should be,” Bach said. “Sometimes testers can behave as if they are children who can't feed themselves.”
Microsoft’s Page thinks that testers who don’t think they have enough time actually have plenty of time. What they really have is a prioritization problem.
“It’s not that you don’t have enough time,” Page said. “Testing is exhausting. You test until the tester is exhausted. And there’s always more testing you can do. If you have two weeks, you have two weeks. I say to them, ‛Here’s your time constraint. What are you going to do?’ Even if they’re thinking it’s not enough time, they have to be able to communicate: to say ‛I can do A and B, but not C, because there’s not enough time, and it’s not a big enough priority.’ And people in charge can say, ‛OK, we can take that risk,’ or they can say, ‛Your priorities are wrong.’”
After all, Page said, there’s always enough time—just not enough time to do everything. So they can do the top chunk in short sprints. Page’s Microsoft testers use the Scrum project management practice of agile software development, conducting short sprints, continually reprioritizing and choosing whatever they can get done in the next iteration or sprint.
Why, with great, popular methodologies and practices such as scrum and agile, are we still talking about things like time whining? Because, again, squishy humans are involved.
“There are no silver bullets,” Page said. “Methodology is nothing compared to culture, and it’s easy to do wrong. [Scrum and agile are] just guidelines or frameworks. But scrum is iterative. And iterative is good. Artists do the same thing: they add another layer, and another layer,” Page said. Projects need to change over time, and the methodologies have to address that.
How to hog-tie: In addition to coaching team members so they learn to reprioritize instead of whining, it’s advisable to keep their whines from leaking out. As a test manager, Bach says it’s his job to present his team as a powerful, creative force. He encourages the team to escalate problems to him if they get stuck so he can unstick them, but try not to ask for help outside the team.
“It's important for testers to know that they don't run the project,” Bach said. “We light the way, but we don't steer the ship. And it’s also important for them not to wait passively while events happen around them.”
This type creates solutions that are, shall we say, more complicated than is strictly necessary.
Jenson Crawford—director of engineering at Fetch Technologies, an online service that accesses and transforms Web data into actionable information for companies such as Dow Jones, ADP, and Shopzilla—says this team member “is very smart, enjoys solving difficult problems, and is uncomfortable with the ambiguity often present in business requirements.”
The over-complicator addresses ambiguity with sophisticated design that can handle all of the possible situations that could occur and enjoys solving this now supremely difficult problem, Crawford said.
Why? Because it’s fun. “I understand the motivation here. It's fun to solve hard problems, and that's why most of us got into this profession,” Crawford said. “But that's not necessarily the right solution for the project.”
How to hog-tie: Crawford suppresses the over-complicating tendency with two methods: 1) working with product management to address issues of requirement ambiguity, and 2) stressing to the team that their goal should be to find the simplest thing that can possibly work.
He credits the operative principle to this quote from Albert Einstein: "Everything should be made as simple as possible, but not simpler."
Closely related to the Over-Complicator, this type doesn’t really want the big picture at the start of the project. These people prefer the itsy-bitsy picture instead.
“When it comes to testing, sometimes people do want too much detail in the beginning,” says Joann Perahia, a semi-retired software developer and manager for over 20 years who is now director of Systems Solutions Inc. “You need the big picture in the beginning. Sometimes there’s too much detail at the conception stage,” she said, and there are people who just never get enough detail.
“I see individuals get dead-ended trying to get enough detail,” Page said. “It’s better to just dive right in.” Page credits the good communication that comes from his team members all sitting in the same hallway as developers, where “We work together, we talk together, and we don’t have a lot of problems. We can just ask somebody,” he said. “If we have a question about what happens to this function if we use a really long string, we can just ask the developer that. We don’t have to send mail, and we don’t have to clarify details in requirements.”
How to hog-tie: In addition to good communication, following the project plan can extricate a project from a detail glutton, Perahia says. That plan, of course, should outline specific roles, responsibilities and deliverables.
“Human beings need structure,” she said. “If we don’t follow something it’s going to go all over the place. The way you control that is having a project plan. … You stop it by getting everybody involved. From start to finish, everybody who’ll have a piece of this project needs to be involved upfront, with the technical people running it.”
Mr. Can't-Get-Stuff Finished
There are two types of this character, according to Crawford. Some no-finishers get distracted by something new and shiny before completing the task at hand, while others are perfectionists who always needs to fix "just one more thing," he said.
How to hog-tie: Both of these types need to have goals clearly defined, with required level of quality being key, Crawford said. “Good QA metrics are a key here, along with project management techniques to help these two get across the finish line,” he said.
The Hero is bad for the team, the project and the company, period. He or she is motivated by “making themselves indispensable to the project by becoming irreplaceable,” writes Zacharias Beckman in his post, “Why heroes are bad,” on Rational Scrum.
“Most often this takes the form of information hoarding,” Beckman continues. “The hero understands quite well that the established culture supports his role only while he and he alone can solve the project’s problems. One of the most effective ways to make sure this happens is to keep critical information away from the team. He’s the only expert in a few critical areas, and refuses to share his knowledge because it would be inefficient or too difficult to convey to someone else.”
In fact, heroes are so busy working round-the-clock to save the day that they make lousy mentors. In a healthy environment, information is shared. Management doesn’t run around solving every problem; instead, management draws solutions out of all the team members.
“The hero is more a product of bad management than anything else,” Crawford said. “It shouldn't be a surprise that when heroic efforts are lavishly praised and rewarded that people continue to try to be heroes.”
At Microsoft, they used to reward someone for being a hero once, for staying up all night to finish a feature in a miraculous amount of time, Page recalls. Then, “We’d reward them again for fixing bugs in that release,” he said.
“They’re a hero once to make the mess and once to try to clean up the mess,” Page said. “We eventually figured out, ‛Hey, maybe this hero stuff isn’t so good.’ If you have to do an 80-hour week to get the job done, there’s no reason to reward somebody for that. It could be that management is giving them too much work, or sometimes it’s that the person’s not really working all that time. They dug themselves into a hole because they don’t know how to ask for help. Sometimes they just like the adrenalin rush of being a hero.”
How to hog-tie: According to Crawford, the key is to change the culture so that heroic efforts aren’t rewarded. “One of my mentors taught me to tell the team that I'm not impressed with the number of hours they work, but the amount and quality of work accomplished,” he said. “If someone pulls a heroic all-nighter to get something done, instead of praising the effort, I ask, ‛How can we prevent getting into this situation in the future?’"
Page says good communication between all members on the entire team also takes away from the hero and last-minute mentality. “We have rapport in communication with other roles and people from the first day of the project,” he said. “Even on features that get approved and not approved. Especially on agile teams, it’s not that programmers create something and developers find all the bugs. That’s old testing mentality. Instead, everybody is involved in making the end product.”
Iterative development and the joy of going back to square one
When it comes to dealing with team problem members, efficiency coach Laura Rose, CTACC (Coach Training Alliance Certified Coach), believes in liberal use of the Reject button.
When managing a group of developers and testers in the software development industry, her team dealt with problems by using iterative development and agile for product lifecycle management. They’d keep track of defects found in developers’ work. If they received something that didn’t pass acceptance criteria, the testing came to a half, the code was returned, and the clock was reset to zero.
This method is both an efficient use of time and a way to revamp criteria that wasn’t panning out, all without embarrassing anybody, she said.
“If we found over five defects in the first hour of testing, we sent the code back immediately without completing the test round,” Rose said. “We logged it as a NON_START. It showed on our testing logs and tracking reports. If it could not pass our set of acceptance tests without failure or defects, we sent the code back. We did not waste time testing the entire package. We publicly reported our status and progress on our testing. Each phase had entrance and exit criteria to be met before officially handing off to the next team. If developers had consistent trouble meeting those criteria, we would revisit the criteria and/or devise training to assist successful completion. The goal was not to embarrass anyone. It was to clearly articulate quality expectations and reward the behavior that supported the team goals.”
In sum: Train away the pain
Regardless of what type of miscreant you have to deal with, Rose says the best way to handle problem team members is to ignore them and instead focus on the behavior you want to encourage.
That means rewarding team members who are properly scheduling their time, working effectively, calmly and with quality output, she said. Once you clearly articulate your expectations, encourage the miscreants to get extra training, coaching sessions or, in the case of the midnight-oil-burners, time management classes.
After all, at the end of the day, do we really want to compensate people who work late? Instead, let’s try rewarding them with time off, Rose suggests. That’s not so much time off playing golf or grocery shopping. More like, time off training themselves on how to prioritize, how to time-manage, and how to thereby avoid passing the buck and whining.
Like this article? You should follow us on Twitter and on Facebook.