QA and Dev: One Team

This is part 4 of my Lean and Agile, in Reverse series

To get an idea of how this Agile QA process is working, let’s first contrast it to our old friend Waterfall.  This is not in order to bag on Waterfall per se.  I hope by making this comparison that I’ll illustrate for you just how much leverage you can get from preventative measures, like sending frequent, working and installable builds to the QA team.  I’ve used this technique inside several ‘Waterfall’ teams to great effect.

Starting on the Wrong Foot

In the average case of a waterfall project, there is a long anxious period every release where QA has ‘nothing to do’.  There’s no new code to test yet, or very little. In fact if you’re doing any substantial rework to support new features, the app may not run at all for several weeks – or months.   Ultimately it’s a big game of Hurry Up and Wait.  Any reasonably conscientious human being in this situation will create work for themselves if management can’t provide direction.

Some will attend Requirements meetings.  The right QA person in those meetings can save you months of rework at the end of a release cycle, so this is very helpful.  But Requirements can be a slow process,  it can’t be a full time job for everybody.  It’s lots of short meetings intentionally spread out for logistic and psychological reasons. Often your worst decision was the last one you made in a long meeting, when you’re exhausted and not thinking straight.

Some others will look at the toolchain, upgrade things, try new techniques or tools.  But here too there are limits.  There’s a lot of risk in completely swapping out your test automation from one release to the next, so you have to be conservative.  Chaos and uncertainly are major stress points for many people.

The bulk of QA effort during this awkward in-between phase will go toward looking for bugs in old code, because finding bugs is what the boss is paying them to do, isn’t it?  And of course they will find them, because the waterfall process puts tremendous pressure on the QA team to sign off on a release that they haven’t had an opportunity to test thoroughly.  It doesn’t start out that way, but once the schedule slips, all eyes are on them to greenlight a build once the developers declare Feature Complete.

So now that the previous release is out the door they can go back and test the things they wanted to test but couldn’t finish under such intense scrutiny. The problem for the Dev teams is that now you have a flood of bug reports coming in for things that they haven’t been thinking about, possibly for a long time.  Even to categorize and confirm the bug requires a lot of attention, potentially reinstalling older versions of the software and tools.

If the news is bad enough, this can be demoralizing just at a moment when the team is trying to build momentum.  The huge spike in open tickets makes the dev team look like they are not good at their job, when the truth is that it’s just that QA is being more productive.  This tension, added to any anxiety the QA team has about appearing unproductive, can foster a feeling of antagonism between Dev and QA, and a sense that there are two teams instead of One Team – the people trying to build and deliver a product. It’s easy for this to turn into a problem that management has to deal with.

The Beginning of the End

Now we fast forward a bit, a month or two later when Dev tries to deliver the first working feature to QA so they can start exercising their muscles.  QA may already be grumbling about delays and risk to the schedule, so it’s Dev’s turn to feel the scrutiny.  They may expend a great deal of energy pushing to get a working build to QA.  Odds are that the first release to QA won’t work.  Some dependency doesn’t update or is missing.  The documentation for the system configuration is missing some critical piece.  Dev thought they had explained some things about the workflow changes that didn’t quite get explained to everyone. And it’s typical for at least one QA member not to follow the new instructions religiously, resulting in some hands-on tech support and a bunch of high profile tickets being marked as Not a Bug or User Error.

So we have a burst of energy expenditure from the Dev team to build a binary, then a whole lot more when the binary doesn’t quite work right for everyone in QA.  This push to QA often lines up at the worst possible time, the mystical highly productive period of the release cycle, which some call the ‘Steep part of the S-curve’.  Just when the developers are firing on all cylinders, now come the interruptions.  It can be very frustrating for them and this sometimes comes out in unhealthy interpersonal patterns.

The Way Out

By fast iterating with the QA team, a healthy rhythm gets established.  Much of the delivery lifecycle looks similar to the rest, allowing a sense of ‘routine’ to settle in. People can more easily predict when it’s appropriate to interrupt you, and generally have some capacity to ‘look out for each other’.  This allows space for a sense of camaraderie to develop, and cooperation leads to a happier, more productive and perhaps most importantly, a more resilient team.

Advertisements

About innerjason

Software Developer
This entry was posted in Uncategorized. Bookmark the permalink.