Wednesday 7 January 2009

Filling in the holes in the Agile process

Today one of the testers has been asked to spend hours and hours updating their test cases for a project that's going out at the end of the month so that they can be used as the documentation for training the team that's going to use this product.

This bothers me for a few reasons. First, I don't think test cases should be used for training. We write them quickly and with the assumption of considerable area expertise - and to use them as training material requires considerable rework (as in what's happening now) and is likely to lead in holes in training coverage based in the differing needs of QA people and end users. Second, we actually need this person to do other, higher priority work - but as the team that's doing this project "owns" his time, I can't take him off of it. I mean, maybe I could, but it doesn't seem like the right fight for today.

Third, this points out to me a potential hole in Agile. If we're producing pretty much no documentation at all, how is this kind of need supposed to be handled? For this particular project, what I see is that there wasn't proper business analyst support put onto this task, but for the future, I don't see this being done at all. QA won't really have much of anything written down at all and certainly not enough to form the basis for a training program. Who's responsibility is it to get this done going forward?

Finally, in a meeting yesterday to deal with the scheduling problems caused by all of the last waterfall projects trying to make it out at the same time, I was dressed down for being negative "here at the start of the year, and really bringing down the attitude as we move into our new Agile workplace." It's really horrible for a QA person to be told to not be negative lest morale be affected; it's our job to point out when things aren't going right, and I'd say calling attention to a project being understaffed during the time of its release is a pretty valid thing to do and exactly what my job requires I do so that our product development work can continue without snags. To me, hearing "don't be negative" is pretty much like hearing someone tell me to just keep my mouth shut in general, which means I lose my effectiveness as a QA person and as a team leader. We haven't made the transition to Agile yet and the QA team is being seriously squeezed during this time; isn't it right to try to get this work done, and is it unreasonable that the team at the end of this process is the one that's under pressure? I guess in development land it all looks like the Land of Oz, and for us, we're still at the Wicked Witch's castle trying to get out - but pointing out the gaping chasm we're about to step into "is bad for morale."

Sigh. I hate feeling unappreciated.

No comments:

Post a Comment