News Stay informed about the latest enterprise technology news and product updates.

How testers can handle switching to Agile's short iterations

Software testers today are under a lot of deadline pressure due to Agile development’s shorter iterations. I recently hosted a panel on time management for a local software testing group, and attendees asked for advice on how to handle the frustrations associated with moving to short development iterations. While the theme of “making sure you have team buy-in” underlay the entire discussion, there were some particularly insightful nuggets related to making sure people understand why the work is structured the way it is in short iterations.

Robby Slaughter, founder of Slaughter Development, a workflow and productivity consulting company, set up the problem this way: Most software professionals in highly-tactical roles — whether they are authors, developers or marketers — are used to the idea that their work is a representation of professional capacity. So, the pro has this self-concept, and then their deadlines are changed to weeks from the traditional span of three-to-six months. Instead of working on one larger task, the task is broken up into 20 smaller pieces.

“All of a sudden that way in which you represent your own professional capacity, your expertise, is now violated. Now it’s being divided up.”

Slaughter’s main point is that the work is no longer yours. It’s the team’s. The individual parts that you work on or someone else works on are not as important as the overall result. Many times people working in iterations are dealing with that frustration. They no longer have the same level of ownership of the piece that they’re working on.

Brian Ball, software engineer with Software Engineering Professionals, had a slightly different take on how you might illustrate the same point.

“There are principles to why you do things in Scrum,” said Ball. “So if they’re uncomfortable with why we’re only doing a short section of work here, why we’re breaking this up and I’m not doing the entirety of the feature, [or] why I’m only dong this little unimportant subset; then when you start throwing stuff out of the backlog because the customer changed their mind…celebrate that. Say this is work we didn’t do and we no longer have to do. Just throw it out…So they see a concrete result of why the principle was there in the first place. They get the payoff of, ‘Oh yeah, we delayed it and we didn’t have to do it.’ [That’s] because it wasn’t important — really important — at the time. It just left us with this uncomfortable and unfinished feeling at the time. “

If buy-in might be part of your problem, the panel offered a question checklist for helping understand what might be blocking buy-in.

“How do you set it up to provide it to them?” asked Francine Carter, founder of Action Coaching & Training. “How do you roll it out? Because the rollout’s the important piece to get people to begin to think about how they’re going to approach it. And if you’re thinking I can’t, then you’re not going to. What about it don’t you feel good about?”

Brian Ball recommends looking at your planning meetings and making sure all the work is being accounted for in the estimates — something that takes practice and measurement. Make sure everyone understands why the work was broken up the way it was, he said. In other words, paint the big picture.

Cory Mausolf, a career coach with Authentic Business and Career Coaching, pointed out that it can be important to make sure people are separating their feelings about the work itself from how the work is being done. Are they uncomfortable about the work? Or are they uncomfortable, he asked, “because that’s not how you did it before?”

You can find the complete audio for the panel members response to this question on the IWST website. There you can also find more information about the speakers along with additional audio from the meeting broken out by topic.

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.