Development and Testing in Agile Shouldn’t Start the Butter Battle

I have heard the word “silo” used to describe the cultures on each side of the invisible wall that sometimes exists between our development and our testing teams here at work—even after we’ve implemented Agile at our company five years ago. You would think by now, we would have learned that can’t exist in a successful Agile environment, but there are still individuals, on both sides of the wall, that continue to enforce the separation.

I wish they would stop it.

It reminds me of Dr. Seuss’s The Butter Battle Book, where you have two hostile cultures, living on the opposite sides of a wall, separated by their bread-and-butter differences. Their hostilities very nearly result in mutual destruction.

As a Scrum Master, I dread the start of a project when I’m waiting for the software tester to be assigned because I don’t want it to be one of those “Silo-ers” or “Butter Side Up” citizens. Because my boss is the supervisor of the software developers that will be on my team, I can use him to push back on any “Silo-ers” or “Butter Side Down” citizens coming from the development side of the wall and force them to STOP IT.

But my influence on the software tester is limited.

One of the approaches I have taken for breaking down their invisible wall is to ENFORCE team testing.

Here’s how it goes.

  1. Tell Them. I inform the team that we are going to be doing team testing and the software tester will lead this. They seem surprised.
  2. Explain Testing’s Role. I remind the team that testing is not a SEPARATE activity removed from the rest of software development. From experience, the developers all agree on this as they are constantly testing their own code through numerous methods. But sometimes, the software tester is surprised with this mentality.
  3. Plan Testing Time. Set it up as a time box and put it on team members’ calendars. If you have access to a computer lab where you can all work in the same room, do that. Unfortunately, at my company, our software testers don’t sit with the rest of our agile team. We schedule virtual meetings instead where everyone’s at their own computer with their headsets on and we connect through Microsoft Communicator.
  4. Write a Testing Plan. Ideally, this would be completed by the software tester, but in some cases, I find that they are still pushing back because they are intense “Silo-ers” so I may take this piece on. I ALWAYS communicate everything I’m doing about this with the software tester and do my best to let them know that they are really the one driving this. This is where they need to lead the team because they’re the EXPERT. It’s always good to play up somebody’s ego, right?
  5. Execute. Give the team the plan and have them go at it during their scheduled testing time. I’ve always made myself a member of the team as well with assignments in the plan. This helps me to understand the software better and brings the team together as well.
  6. Document. Document EVERY part of what each individual does for the testing plan. This will require each team member to be as exact and detailed as they can, but you know the software tester wants every little piece they can get. If you’re going to do it, do it right.
  7. Give the Results to the Software Tester. At this point, I step back and let them do with the results as they please, but usually, they start to realize, “hey this works!” And, the entire team OFTEN tells them they now have more respect for what they do as a software tester and how detailed they need to be in their tasks.

You are part of our TEAM and your piece is just as important to the team as the development is when it comes to actually getting stories to DONE.

What do you think? Is that an appropriate job for the scrum master to do? Does it work?

Advertisements