Scrum: The Test Heavy Backend of a Sprint

You might hear me mention at some point that as a Scrum Master, I don't really care about the technical details that make a product backlog item done. I only really care about some form of measurable daily progress and the fact that these backlog items actually get done.

So, does that mean that the method for building said software is unimportant? If all you care about is Scrum and that which Scrum defines for you, then yes, it's unimportant. If you care about actually making working software (which is the real goal), then it's not just important, it's vital.

Ask yourself this, why do you always hear about test driven development, pair programming, code coverage and other software engineering techniques when talking about Scrum if Scrum, as a framework, doesn't define these things at all? Because, they solve problems that Scrum teams will likely run into. When a team builds software with traditional project management, there are certain problems that tend to hide themselves (or at least make themselves easy to ignore). Scrum brings these things right up to the front and forces these problems to be solved.  Most of the time these problems are technical in nature and should therefore be resolved by the Scrum Team (not the Scrum Master).

This is one of the reasons why eXtreme Programming (or XP) is often paired with Scrum. Many of the techniques found in eXtreme Programming tend to solve problems that a Scrum Team is likely to uncover.

Let's talk about only one of these problems/solutions for now.

When a team first starts developing in short iterations (which Scrum has you do), they will probably fall into a very common trap. They will finish writing the code during the first part of the sprint with the assumption that the latter half will be spent testing. Here's the thing, this could actually work if you didn't find any bugs in testing, but you will. So in reality, you'll have the latter half of the sprint to find bugs, fix them, retest them, and fix any new bugs that the fixes introduced. It's a confounding problem because individual bugs can't be anticipated and therefore make estimation a nightmare. What we need is some way to normalize the time we spend on quality in the software, so we spend less time chasing bugs.

Let's try this again; let's say I'm a developer in the middle of a sprint and I pull a backlog item from the sprint backlog, but instead of immediately writing code, I take a second to chat with a tester about how we'd like to test this when the item is done. While we don't know what the code will look like yet we do know what the finished code should do so we create a test case together and I go about writing code to make that test case pass. Once I'm done writing my code, I know that it'll pass the test we wrote but I pass it off to the tester just to get another set of eyes on. He confirms what I already know, which is that the backlog item is Done and we're that much closer to finishing up the sprint.

In both cases, we still tested, but by writing the test up front, we can gain some insight right away on how the code should be constructed.

Notice that I'm not telling you what tests to run, only that you should define the tests before development. The tests themselves may be anything from writing an actual unit test before writing the actual code or it may be as simple as a conversation of "I'm going to do X, Y and Z when I test it" before you sit down to make X, Y and Z possible in the product. The more detailed the test plan is up front, the less likely that you'll run into last minute surprises and that makes everyone's life easier.

Related Posts:
Your First Scrum is Going to Suck
What does a Scrum Master Do all Day?
What is the Deal with Story Points when Estimating?

No New Post Today: Go watch the OnTime v11 Launch Live

Hi Everyone, I normally try to have an article up and written at least every Tuesday but I decided that just this once you might be better served by watching the OnTime v11 (The Scrum tool that we make at Axosoft) launch on Axosoft.com. Our CEO Hamid will be demonstrating the tool and talking about everything that went into making it our biggest and most ambitious project ever. Starts at 11:30am Pacific Time tomorrow, see you there!

Organizations Against Scrum: Iterations First

"Scrum doesn't work here"

"We tried Scrum and it introduced a bunch of problems"

"We failed a big project because of Scrum and management doesn't want to try it again"

I hear these things every now and then and they stick in my brain. My first thought when somebody says something like this is that Scrum didn't cause any problems, so much as it exposed problems that were probably already there. As you can guess, this can cause some mild discomfort in any development team.

For instance, you say, "We never had enough time for testing at the end of the sprint"

And I hear, "We trade quality for speed in development and we immediately see the effects of that decision within a sprint". Essentially, you're seeing that you actually do not gain any time by hurrying development in the beginning, you just push it off until later and that's uncomfortable for your PMO to hear (although your developers have probably been telling you this for years).

That isn't a problem with Scrum, but it is a bad habit your organization has developed over the years and Scrum will pull that out into the open for you to fix. This is not a failure of Scrum, in fact some would argue that it's the whole point of doing Scrum to begin with. If you fail to fix your testing problem, then it's likely that you'll feel the effects when testing comes around anyways. This would be true in a waterfall project as well, the only difference is that the time between the issue and the consequence is longer in a waterfall environment.

I could go on with at least a dozen or so more examples, but at least with this post, I'm not going to go into the myriad of different ways that you can force a development project to fail using Scrum (that's a very long post for a future date). I'd like to talk about how to reintroduce Scrum to a wary audience.

Don't call it Scrum.

Yup, it's that simple. Start with something basic like building in iterations. You can even grab work from the schedule based on due dates to decide on your sprint backlog if you can't get a product owner to provide priorities. Start building in iterations and inspect and adapt after every single one of them.

The iteration (or sprint) is the cornerstone of Scrum and also the hardest part to do because it exposes problems and this can cause some discomfort. You'll discover things like how poorly your team estimates or how bugs really affect the productivity of the team (this often hides in the latter part of a waterfall project and is quickly forgotten by the time the next project rolls around).

Solve these problems over your first iterations, earn some credibility and then start implementing more Scrum and Agile concepts. Remember that when attempting to convert a skeptic, the best way to start is to show them something concrete rather than asking them to take a leap of faith.

*Disclaimer* I'm not suggesting that you introduce Scrum to your team like this, if you're new to Scrum then try to do things close to the correct way as possible. The iterations first method should really only be used if your organization is specifically entrenched against Scrum to begin with and you need to establish Agile. *Disclaimer*

Related Posts:
Implementing Scrum - The Top Down Approach
Implementing Scrum - The Bottom Up Approach
Your First Scrum is going to SUCK!