31 Days of Testing - Day 4: Sustainable Pace, Sensible Flow

Updated: Index to all posts in this series is here!

Updated: Fixed some busted paragraph formatting. Sorry for the massive run-on post!

If you want to continually deliver great software in a rapid fashion at as low a cost as possible, then you need to step back and understand how critical sustainable pace and sensible flow are—especially as it relates to testing.

Sustainable pace is a critical rule that needs to be part of a team’s foundation. You work a sane amount of hours every day, then go home and come back the next day refreshed and ready to do great work. Yes, you may need to work occasional spurts of extended hours, but that needs to be the very, very rare exception. Environments without a fundamental belief in sustainable pace keep silly amounts of pressure on their teams to complete work in unreasonable periods. “No, we’re not cutting scope. We’re in this mess because you created too many bugs previously, and our marketing department has made too many promises. Work harder. Failure to meet the release date with the promised scope is not an option.” Such attitudes and environments will kill your team over time, and will end up driving the quality of the products/systems into the ground over time. Your developers speed through their work and throw everything over the fence to the separate QA group. The separate QA group is overwhelmed and ends up feeling like scapegoats for the release’s poor quality.

Sensible flow is a term I’ve been using, off and on, to describe how work items need to move through your development process and environment. I’m sure other smart folks in the industry have other terms, but it’s what I’m using to describe things like ensuring you have great collaboration, proper work item sizing, and honest measurements or standards for what “done” really means.

The notion that testing is a separate activity leads to testing being the last bit of work done in iterations/sprints/release cycles. This is madness, quite frankly. You’re putting an immense amount of unreasonable pressure on your testers, and it also creates additional stress when they inevitably reject work items with only a day or two to do the rework and revalidation.

I’ve worked in these environments in the past, and I continue to talk with a lot of folks in the community and clients who are in these environments now. My biggest, bestest suggestion to them: Take the mental step of throwing away the notion that testing is separate from development.

That may seem like a trivial thing to do, but it really helps you, your team, and your organization to start being honest about when a work item is really done. That item isn’t done until it’s been tested. (I could go a few steps farther and say it’s not really done until it’s released to production, but as with all these columns I’m trying to save you from too many of my wandering rants.)
Agreeing that an item has to be tested before it’s considered done means you have to be honest about including schedule time for testing. This discussion is a great positive factor when you’re deciding what you can accomplish during your iterations because your team will be more consistent about identifying possible bandwidth problems near the end of the iteration.

Once you get honest about having to include testing as a measure of an item being done, then you have to get honest about how you’re going to meet done for your work items in your iteration. Now we can start to look at how you’re sizing your work items.

If your work items are too big, then they get hung up in the development stage for too long. Testers don’t get their hands on the work items until late in the cycle, and there’s little time left for finishing up automation and doing exploratory testing. (Note I said “finishing up automation” because I believe your devs and testers should be pairing up on building automation as part of the development cycle!) These delays lead to pressure to get everything done in the few days at the end of the iteration. Folks work longer hours and/or work doesn’t get finished up within the iteration. Both are bad.

You need to figure out what size work items works well in your environment, but I’d encourage you to try to reach work items that can be completed in a day or two. Yes, by “completed” I mean done. That’s designed, discussed, developed, and tested.

Small-sized work items mean you’re able to start getting a great flow through your team’s process. There’s much more sense of progress, and there’s less impact when a work item fails the testing stage and has to be put back in for further rework. The team sees a lot more accomplishments, even if those items are at a smaller scale.

Now you’re open and clear about what done means, and now you’re working hard to properly size your work items. Ensuring sustainable pace and sensible flow means watching your processes stages to avoid pileups and bottlenecks. Maybe your development team is crushing their work and getting through the development portion of work items at a tremendous pace. The downside of this is you’re stacking up a huge amount of Ready-To-Test work items in the testers’ area. What do you do?

Look at this backlog pileup as a team problem. Solve it as a team problem. Have your developers roll up their sleeves and help work through those items. No, developers aren’t testers, but they’re quite smart and can do a great job helping work through this backlog. A couple ground rules do have to be in place for this to succeed, though. First, no dev can test a work item they did. Secondly, each dev has to meet with a tester for a few moments before they test to quickly discuss testing strategy for that work item. Lastly, the dev has to quickly review their actions and discoveries with the testers after they’ve done their work.
Once you get back to a good spot with your pipeline’s backlog then developers can go back to their primary tasks.

Focusing on keeping a sustainable pace, and a sensible flow ensures the software you’re building gets solid testing throughout the process. Be honest about what done means, size your work properly, and work as a team to avoid backlog pileups.