What do you mean, don't submit bugs?

Of all of my "aha!" moments in transitioning from a waterfall-style QA person to an agile tester, the one I am about to talk about is *definitely* in the top 3. Top 5, most .... *Definitely* top 10. :)

I have to give my credit to Janet Gregory, yet again ... during her presentation at STAREast that I named in my last post. This one, in particular, hit me personally, rather than being a suggestion for the whole team.

Janet talked about how as an agile tester, the "Quality Police" mindset must be avoided. I have to admit, I am *really* guilty of playing "quality police". *REALLY* guilty .... However, I was *really shocked* when she said that one of the indicators that you may be playing "quality police" is that you insist that all bugs go into a bug tracking system.

"Well, DUUUUUUUH," I thought, "OF COURSE all bugs go into the bug tracking system!"

(pause)

Wait. What?

As this discussion went on, I learned that there was a practice that I not only had never thought of, but actually made sense! It went something like this: When testing in the scope of a user story inside a sprint, DON'T SUBMIT BUGS. Just go talk to the developer and have him fix it!

I brought this idea back to my team. It was easy to sell this one ... I was able to play the humble one, and show them Janet's slide that shows the indicators for "quality police". We all had a big laugh while the list was read ... describing me, just about to a tee.

The amazing part, however, was that within hours, I could hear testers going to developers and talking about things they found, and I could hear developers yelling, "Hey Sally! I checked in that change. Get latest and let me know." It was almost like this team was waiting for exactly this kind of idea.

What we decided follows roughly this pattern: If a tester is testing a user story card within the scope of a sprint and finds a small problem that can be fixed easily, they just go talk to the developer (maybe send an email ... ). Bugs are submitted if issues are found relating to work done in a previous sprint, or if an issue is so big that it can't easily be fixed within the scope of the current sprint, or if we hear about issues from our customers (our product owners or beta users, for example).

I monitor the bug list and watch for developer activity during a sprint that relates to issues in the bug list. If I see that a developer is working in a certain section of code, I ask if he can look into the related issue. In this way, I still get to play quality police *a little* ....

Benefits that we see from this process:

• fewer bugs (which means less of everyone's time reviewing bugs) !!
• more developer/tester interaction ... better relationships
• better tester insight into developer processes (they talk about where problems are in the code)
• less email traffic
• cards marked as 'done' earlier

Pitfalls:

• ? I haven't yet seen any direct pitfalls .... the one concern I have is not being able to analyze issues for patterns. I have in the past, seen a bug crop up several times, and being able to review previous discussions and/or fixes can help reduce troubleshooting/fixing time. Instinct tells me that I can look through checkin comments just as easily ..... but this is an edge case, nonetheless ......

Personally, I was amazed at how willing I was to give up the "quality police" mindset. I simply had not realized how much that mindset was interfering with the team integration, and just how much closer testers and developers were when this barrier was removed. I realized that in order to be a better agile tester, I had to remove my own barriers. This was a big one, and I have been watching, first-hand, just how much better the team operates with this one removed.

Give it a name, and they will follow ....

Ok, well, my idea of going chronologically is blown ... I have to say, I learned the most from my recent trip to STAREast, and I think that those are the most valuable lessons I can share.

Part of my problem with this agile transition has always been that I am a "details girl" (that's what they say here). I can read LOTS of Schwaber and Cohn and get lots of concepts and ideas, but I really need the details ... exactly *how* do I follow the procedures outlined therein?

I got LOTS of those ideas at STAREast, so I will talk about one of them now.

This one came from Janet Gregory's track talk, called "Perils and Pitfalls of the New Agile Tester". The concept was called "The Power of 3". I brought this idea back to work ...

Here is the problem it solved for me, and helped the team with: lack of everyone being on the same page. The problem plays out in many ways, and I know it happens whether you do waterfall or agile or whatever. There exists some requirement/user story/work piece, and over time, someone comes up with a question and asks someone else. Perhaps it's the tester who asks the developer, and they make a decision and move on ... to the surprise of the product owner, who then looks at it and says "That's not what I wanted it to do!"

For me, the frustration has been when a developer asks product owner questions and they hash out some details, but I don't know about them. Then when it comes time to test, I feel like I start over from the beginning. I ask questions, and someone says "Oh yeah, I talked to Joe about that and we decided x" (for privacy reason, names of coworkers have been changed :) ).

GRR.

I have suggested many ways to try to alleviate this ... and as I think about it now, I don't think my suggestions hit the problem early enough (the Power of 3 does!). I had asked for a group email list, and we required that all questions were sent out to the list, so that everyone would know the answer. Several people complained that this filled their inbox with too many emails. I made it worse by suggesting that verbal conversations (since they were bound to happen), be followed up with an email to the list with the info discussed in the conversation. Do you think anyone followed through with this? Of course not (I don't think I even did that one!).

How the Power of 3 works for us: The basic idea is that for any discussion on a user story card, all 3 stakeholders must be involved. The 3 stakeholders on our cards are the product owner, the developer, and the tester. All of these are assigned (if not obvious, like product owner), during the planning meeting. So, if the developer wants to ask a question of the product owner, one of them just needs to remember to grab the tester as well.

To my surprise,the team took to this really well!!! We all still forget once in a while, but if I just poke with a little "power of 3", they realize it should have included someone else, and then laugh at me :) I love this concept, and since I had not yet come up with it on my own, was *so happy* to hear it at the conference.

I have been totally excited to see little meeting requests go out that say "power of 3 discussion about x group of cards" .... (we have MANY meetings, so I cannot escape that yet). It seems, that if you just put a catchy phrase on a concept, it's more fun to implement.