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!

Don't Crap in the Product Backlog

I've got news for you, if your product backlog has so many items (stories, features, bugs, back log items, call them whatever you like) that you feel the need to create a web of dependencies that you then need to visualize in a chart or use some other huge time sink, then you're doing it wrong. There's too much crap in your backlog and you're drowning in it.

This is an astoundingly common problem and one I deal with on a daily basis as I interact with various Scrum teams. Here's what the problem looks like:

1. Change wording in system options from "Foo" to "Bar" in random context menu.
2. Move dropdown menu in system options from "Bar" tab to "Foo" tab.
3. Simplify security settings for "Foo" in system options menu.
4. Other random change to system options that is too small to ever make it into a real sprint

Multiply this by every feature in the product and you end up with a backlog spanning 100s if not 1000s of things to track. The problem here is that any tools you use to manage this behemoth product backlog is really just masking the problem bigger; you're getting lost in the details and missing the bigger picture.

Don't look for ways to manage everything, look for ways to make everything simpler and the problem will solve itself.

So what should those 4 backlog items look like?

1. Optimize the system options menu

That's it. Each of those 4 original backlog items are bullet points inside of the bigger one and I've effectively shrunk the amount of crap I have to manage by 75%. Do this with your entire backlog and you'll get something you can actually refer to in conversation with the team.

Product Owner: I'm thinking we should probably get around to the menu item in the backlog

Team: The whole thing or just parts? I took a peek at it last week during Sprint planning and it was getting pretty big, that's one of the reasons we didn't do it then. Has it changed much since then?

Product Owner: I've changed it a little since then, but I don't think we need the whole thing done by next sprint. I'll pick out the bits I like and send it to the top of the priorities, but we've been putting those changes off for too long already.

As opposed to:

Product Owner: There's a bunch of menu changes in the backlog I'd like to try to get some of them done in the next sprint.

Team: There's work for the menu in the backlog? We never got a chance to look at the whole thing during sprint planning. What kind of changes are we talking about? I haven't had time to even look at any of the menu changes yet.

In the first example, the Product Owner can refer to something in the backlog and the team knows exactly what he's talking about. In the second example, the conversation needs to refer back to an artifact, list or tool for even general conversations.

You'll notice by the way, in the first conversation, the Product Owner wasn't afraid to pick out the bits in the backlog item that should be implemented, in effect, he's splitting the product backlog item, but he's only doing it when he needs to. The same thing will happen with the estimation; the team will estimate the new backlog item that's high enough in the priority for them to do. The other will probably sink lower into the backlog and doesn't need to be estimated until it makes it to the top again. If the item needs to be split again to fit it into the sprint then it's usually handy to have the Product Owner around so he can help figure out which half needs to make it into the sprint.

So, what about when feedback comes in? After all, the backlog is filled directly (if possible) by the stakeholders and those ideas are likely to be fairly small compared to our new larger items. The product owner should look at each and every backlog item that comes in and if the item doesn't seems similar enough to other backlog items, it should be assimilated by another item.

More objects, more moving pieces means more administrative overhead for the Scrum Master and the Product Owner (they have enough going on as it is). Like most things in Scrum and for that matter like most things in life, make things as simple as possible (but not simpler) and only add complexity as the need arises.

Related Posts:
6 Things a Product Needs to Know
Should Your Scrum Team Stop Using Story Points?
5 Big Issues when Scaling Scrum

Implementing Scrum: Top Down and Bottom Up Approach Part 2

We've already discussed implementing Scrum from a top down approach and came to an interesting conclusion. Establishing trust between the Scrum Master and the Team is key in a top down implementation.

So what about implementing Scrum from the bottom up? This is sometimes referred to as the "grass roots" movement for Scrum where a development team decides to abandon some of the more traditional aspects of how they make software and move towards a more Agile environment.

This type of Scrum implementation can cause an entirely different class of ulcers for your average Scrum Master since the business employing everyone is not likely to be enthused about a large change in the way they interact with IT that they did not initiate.

In order to find a solution here we first need to understand the problem. Unfortunately, things aren't quite as clear cut as they would be with a top down implementation of Scrum. The reason here is that different businesses have different needs of their development teams and it might be difficult to communicate how Scrum fits into to all of that. So your first job is to find out what the business needs from the team, while there's no definitive list for this here's a few that I've seen as common:

• The business needs the product to be useful
• The business needs ALL of it's requirements met
• The business needs software quickly
• The business needs predictability

Understanding the businesses needs (which may or may not include "Being Agile" so much as "Making Software" or "Having Software") is the first step here. The second part is to actually give them what they want.

The Business needs the product to be useful

It's fair to say that somebody would eventually like to use this software. Since we're building software in iterations and we have either somebody from the business or somebody focused on the business's needs setting our priorities the end-product will be in a useful state much faster.

The business needs ALL of it's needs met

This also needs to be taken into account with two important caveats:

• The needs of the business at the start of a project rarely match up exactly with the needs of the business at the end of the project.
• It's impossible to gauge the usefulness of a tool until you have it in your hands.

Both of these problems are solved with one simple axiom: Ship software faster. Will the first release to production include all of the requirements laid out up front? No, but this release hits all of the primary concerns, you can begin using it almost immediately and we're working on the remainder of the requirements as we speak. This brings us to the next concern for the business.

The business needs software quickly

Very rarely are you going to get a project that needs to be shipped a year from now, usually it's a project that needs to be shipped today but will be shipped a year from now because that's how long it will take to create. So let's shorten that first ship date and satisfy the most important of the businesses needs now (or as soon as possible) and use their feedback to make the product better with the time we have remaining.

The business needs predictability

This last part can be a bit more difficult since we live in an unpredictable world but predictability can mean a lot of things. Instead of predicting "It will take us 13 months to finish this product", start with something like "I can have you something that works within 3 months and we can figure out where to go from there". While it may not be possible to predict with certainty everything that you can get done in 3 months you can probably guess that the team can get something that works done in that period of time.

I can go on about any of these topics way more but this is a blog post and not a thesis so I'll leave it brief for now. Here's the important part, you have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver. That's important so it'll get it's own paragraph.

You have to figure out what the business needs, tell them how you're going to deliver on those needs and then you have to deliver.

The reasoning behind this is simple, management, your customers and/or the business that supports you needs to embrace Scrum every bit almost as much as the team. This is especially true since you'll be bugging them much more often for collaboration than you did previously. If you do it right though, you'll be able to show them results and results are difficult to argue with.

By delivering results you'll have gone a long way towards earning trust and that trust allows you to ask for things that you'll need down the road such as a path into the backlog for every stakeholder, a strong product owner (which you may not actually get to start with) and a little bit of understanding as to how development actually works.

Like most relationships built on trust, you'll need to extend yourself (along with the team) first. That may mean starting your first sprint without a full-time product owner or without a lot of room for collaboration on the backlog items.

Luckily though, you have the team to back you up here and they're primarily what you need to ship software. The team's performance is what's going to earn that trust from the business so get out of their way, let them ship software, keep the business off their backs and deliver software. When you're asked why your performing so much better, tell the world "Were doing Scrum now and it's going really well, we could do better though. I need some help from the business side for that."

Related Posts:
Implementing Scrum: The Top Down and Bottom Up Approach Part 1
What Does a Scrum Master Do All Day?
Your First Scrum is Going to SUCK!