How *NOT* to win the hearts of developers, part 1

So, I had this crazy idea that I would try to do this blog in some chronological order, since a lot of the early posts will be historical lessons.

I know it won't happen that way, but I will at least start pretty early.

I recently attended the STAREast conference, and during Janet Gregory's agile testing talk, I heard her talk about some qualities that an agile tester should NOT have that sounded eerily like me. The team got a kick out of my presentation to them after I got back, where I talked about how testers who acted like "quality police" did no good for an agile team. It was a big lesson for me, and very humbling.

So let me tell you one thing NOT TO DO when you are trying to help a team of developers transition to agile. Come to think of it, it reminds me of a Thomas Edison quote about being able to tell you 10,000 ways NOT to make an electric light bulb .... (I grew up just a few towns south of Edison, NJ).

In any case, in one of my first official testing assignments at Rainbow, I had very much a "quality police" mindset still. Their adoption of scrum had not yet quite kicked in, and they did a whole bunch of development and then gave me a final product to test.

And test I did. That night, working fervently from home, I sent an email out with 37 bugs in it (bugs over email? I will address this later). Though I was rather proud of myself at the time (37 bugs! YEAH!), it turned out the team was not quite ready for that. There were complaints of not being able to tell the status of the issues I had sent out, not knowing who was working on what issue, not knowing which issues they were required to fix ....

In short, I had created chaos. A testing and development nightmare. I had, unwittingly, pitted myself against the development team, thus splitting our budding agile team into dev vs. QA. I have a tendency to come on strong ... and the team learned it early and thoroughly.

Recently, I have suggested a few changes to the way we do things ... now, our testers are involved at the initial stages of user story development. We can run the web site locally and check on things the moment that a developer has finished some part of development (get latest, build, go to localhost website). I think most importantly, formal bugs are not submitted within the scope of a sprint's user story work ... if a tester sees an issue, he simply walks over to the developer (or IMs him or calls him) and says "hey, I see this thing, can we look at it together?"

I have watched these few changes bring our testers and developers closer. I have watched how much more comfortable they are talking to each other. I have learned how to become a more agile tester, and how much more effectively and efficiently a team can run when approached the right way.