Posted by: MichaelDKelly
people management, performance, Project management, software project
How can software testers get development team members’ firm commitments for deliverables? That question came up while I recently hosted a panel on time management at a local software testing group meeting. As testers, we rely on a lot of people: developers for code; system administrators for environments; business managers for data and oracles and so on. A big part of testers’ day-to-day life can be spent waiting on getting what we need to start test execution.
“Sometimes I feel like I’m nagging other people to get things done,” said one tester in the audience. “Do you have any techniques to help get commitments out of people to help make this process less painful?”
Panel member Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, provided some ways to move from nagging and silence to empowerment.
“I think that all of us have the experience of nagging, and we all know that nagging does not work. It doesn’t work to be nagged; you don’t have any desire to do the task. In fact, if you’re nagged you’re less likely to do something. If somebody calls me three times in the course of a day and asks me to do a project, I’m not going to do it for them. Because I know they’re going to keep reminding me until the deadline comes up. They just created an expectation that I don’t have to remember any more. They’re now my human to-do list. So nagging is the worst thing you can do to get something done.”
Take away nagging, though and what persuasion option do you have?
“The opposite seems like silence,” said Slaughter. “Just hopping that it happens doesn’t really work either because you really haven’t communicated what it is you need. So, I think the most helpful strategy is to try to empower the person you’re work with. And to say, ‘Hey, if you can do this really great thing that I can’t do, that would be fantastic because then I can do my job, and make you look even better.’ So if you can find a way to empower them, they’re more likely to want to get the task done for you.”
Slaughter, wanted to be clear about the difference between empowering and enabling somebody, noting that:
“If you empower someone then you’re imbuing them with the authority and the responsibility to provide you with their work that you need to do your job. And that authority and responsibility translates into satisfaction, satisfaction translates into productivity, productivity translates into a sense of ‘I can know what I do.’ If you enable them, then what you’re doing is you’re allowing them to not complete their job. Empowering is more about ensuring they have tool and resources, ensuring they have information, ensuring you understand their challenges. Whereas enabling means I’m you actually say, ‘You know what, I’m going to come and do some work for you, or come and make your life easier directly by doing the things you’re suppose to do, so I can get the things I want.’ And if you do that, the danger is that you try to take work away from them. And you give yourself more work to do. And you establish a culture in which you doing people’s jobs for them.”
Francine Carter, founder of Action Coaching & Training, extended what Slaughter said, to include getting buy-in. “If they know why you need what you need,” said Carter, “and how it will move everything else along, then you’re going to have much more buy-in.” Buy-in, she said, isn’t always as simple as saying, “I need this because….”
Carter also pointed out that you need to consider where the other person is coming from.
“You never know what they’re thinking. They may be hesitating in getting it done because they’re afraid of doing it [or] they’ve never done it before. You don’t know what their story is, either. So the more that you can go at them and try to understand where they’re coming from and why they’re not doing it, [the more you can] maybe help them and empower them along. Think about where that other person’s story is. What are they thinking? Why are they hesitating and procrastinating on this?”
Brian Ball, a software engineer with Software Engineering Professionals, gave some advice on getting commitment:
“You want to put them on the hook for what it is that you’re trying to get them to commit to, and the easiest way to do that is to let them hook themselves. If you say, ‘Hey I need this as soon as possible.’ that’s one thing; but if you turn around and say, ‘So, I need this. Here’s why. When can you have that by?’ then they’re creating a commitment to you. And if they say, ‘I have no idea.’ then say, ‘I need to know, so I can plan my schedule.’”
“The other thing is that, if it is the case that they do start blowing you off, then you at least have something to go talk to somebody about. Say, ‘They said they were going to do this and have not given me a reason, and refuse to give me a reason, as to why it hasn’t happened.’ And I hate to bring out the big guns and bring somebody else involved into it, but usually it helps just to say I got them to commit to something.”
Ball also pointed out the other side of asking people to do something for you, which is thanking them. “Conversely, when they finally do actually get done what it is you ask for them, sit there and go ‘Sweet! That’s awesome!’!!” said Ball. “Pronounce it with three exclamation points even if you don’t feel like it, because you’re trying to make them feel good about what it is they did for you.”
Chris Wingate, a principal software engineer for Liberty Mutual, provided some of the easiest advice about managing commitments. In short, get the project manager to do it for you.
“Most of my performance test engagements [are situations where] you’re always waiting on somebody,” Wingate said. “Or, you’re trying to get another resource to get more information, or do more monitoring or track down this issue or that issue. The most effective thing I’ve found to get the team focused and moving forward on things is a 30-minute meeting twice a week. The project manager is there, the developer, the lead developer is there, the architect is there, the lead tester is there, so everybody knows what’s going on, everybody knows what the delays are. Let the project manager do that work for you.”
You can find the complete audio for the panel members response to this question on the Indianapolis Workshops for Software Testers website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.