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?


Too Many Chickens at the Stand Up

An important part of Agile projects are the daily stand up meetings or daily scrum where the team gets together to report three simple things: what they did yesterday, what they’re doing today and any impediments in their way. For my current project, only the team attends our daily meetings. They are my pigs—the committed team members. But for another Scrum Master here at work, he has a lot of chickens coming to his daily meetings. These chickens are interested people—only involved but not committed.

And by Scrum rules, only the pigs should be speaking at the daily scrum. The chickens are supposed to keep their yappers shut and simply listen.

The other team finds, though, that they can’t keep the chickens quiet. Two thumbs down to those chickens.

How would you handle these unruly fowl?

A discussion over on the Scrum Development group website had some interesting insight into this dilemma. For one team, they stated that they have 5-6 members and 4-5 managers attend their daily meetings, which makes the team uncomfortable and concerned.

Bring on the diplomatic skills of the Scrum Master!

Have you dealt with this situation? How have you handled it and what works best?