Stop Testing and Start Thinking

On a stand-up meeting recently one of the developers said that a story was going to take longer than expected because "it's really complex and is going to require a lot of testing". Nothing wrong with finding out a story is more complex than expected and that it's going to take longer than expected. What struck me was that so often, in current software development, testing is our first answer in addressing complex software problems. Testing is an important part of software development, but I'm afraid that one of the things that we've lost in the move to agile methodologies is the concept of design. One of the principles behind the Agile Manifesto is "Continuous attention to technical excellence and good design enhances agility." but too often design is considered non-agile.

I see this most often when working with teams that are relatively new to agile, or with more mature teams that are stuck at a low level of agile maturity. They have heard about the agile principle of simplicity (maximizing the amount of work not done) and YAGNI (You Aren't Going to Need It) and they have put all their focus on coding. This can get these teams into trouble, especially in areas like scalability and performance, because some problems need to be thought through and designed before coding starts. The team should understand the overall targets that they need hit (expected perceived response time for the user; processing loads per unit time; etc.) but these are usually high level goals and are often not translated into acceptance criteria at the individual story level.

To deal with this I like to introduce 2 practices that are not universally embraced in the agile community: Sprint Zero, and Research Spikes.

Sprint Zero

Sprint Zero occurs at the start of a Release Cycle. The team identifies stories that are either too big, or where they feel there is a lack of understanding and/or technical risk and "drill in". This may mean breaking large stories into several smaller ones, or doing just enough design to give the team confidence that they understand the work. A key is to keep this sprint as short as possible. I've heard of teams spending 3-6 weeks in Sprint Zero, but my rule of thumb is that it should never be longer than a normal sprint, and preferably less. If the team is doing 2 week sprints then a 1 week sprint zero is what I shoot for. You are preparing to deliver business value, but aren't actually delivering any in this cycle which clearly indicates it should be as short as possible.

Research Spikes

In the sprint planning that starts each sprint the team will occasionally have a story that they are having difficulty breaking into tasks and/or estimating. Or there may be a story that is too large and they are having trouble breaking it into smaller stories (my rule of thumb is that a story shouldn't take longer than 1/2 of a sprint). These may be candidates for a research spike. Also, in backlog grooming, stories may be identified that the team considers high risk. These may also be good candidates. A research spike is a story where the output is not working code, but is one or more of the following:

• A detailed task breakdown, with estimates, for the story


• A design for the story, captured in the story itself or on the team's wiki, depending on the standards established for the team


• An architecture for how to implement the story


• A detailed test plan for the story

Research Spikes should be used sparingly. If you have a good backlog that is periodically groomed almost all stories should be able to go through the normal sprint planning process without issue. If you're doing research spikes more frequently than once every half dozen or so sprints you might have a problem with the backlog or with the team.

You're not directly delivering business value during Sprint Zero or while working on a Research Spike, so these need to be used sparingly. But they can be valuable tools in helping teams reach the next level of performance by moving beyond writing code and then trying to test it to completeness. Test driven development (TDD), if done well, is a reasonable compromise, because it requires the developer to think through the different aspects of the solution, but in my experience too few teams have adopted TDD and if they have they practice it with insufficient rigor.

I guess I could have titled this post "Stop Using Testing as a Substitute for Thinking", but it wasn't as catchy. Don't design everything, but when faced with a complex problem think it through. Draw a sketch of the interactions in Visio, or LucidChart, or on a piece of paper. You'll throw it away later, so don't make it pretty. It's value is to get you thinking of the different aspects of the problem, which makes it more likely that it will be complete. Then, after coding it, do your testing. And if you find problems, maybe you didn't do enough thinking.