Current Episode

Adam: Welcome to Agile Answers. I’m Adam Weisbart, your Certified Scrum Trainer and agile coach. Each week, I get your questions about Scrum and agility, and I answer them, here on Agile Answers.

Today, I was teaching a Certified Scrum Master course here in Silicon Valley. Today was Day 1. And I got a question that comes up relatively often. The interesting thing is that I also got this question via the GetAgileAnswers.com website, from Duncan. And Duncan’s all the way around the world, in Australia. So since it seems like this issue is sweeping the planet, I thought I would answer it here on the show. I’m going to give you three actionable tips for improving the situation that Duncan has fallen into and a couple of people in my class have fallen into. Heck, maybe even you have fallen into it as well. Let’s have a listen to his question, and I’ll give you the three actionable tips for solving this super common pitfall of switching from waterfall to Scrum, or any iterative approach, really. Let’s take a listen.

Hi Adam. This is Duncan. I’m a Scrum Master for an insurance company based out in Australia. We have recently transitioned from waterfall methodologies to agile and we’re starting our journey towards iterative development. The question I have is how do we stop our sprints turning into mini-waterfalls where over the course of a week or two weeks, we do all the design, all the build, and finish with all the testing , dropping from our maximum velocity to zero at the last day or two of the sprint?

Adam: Duncan, first off, congratulations for taking the big step of going from waterfall to a more iterative approach. That step is no small task. Getting folks on board to agree to try this crazy agile thing is not simple. So congratulations on taking the first step.

The issue that you’re running into is not at all uncommon, as I mentioned. It came up in class today, and it comes up in almost every one of my classes. So I have three tips for helping you make some steps towards a more iterative approach. Now you didn’t say that you were doing Scrum. In fact, I suspect that you’re doing something other than Scrum, but nevertheless, I call the situation you’re currently in “Scrummerfall.” I call it that because, as you outlined, you’re doing all the steps you would in waterfall, you’re just doing it compressed into a two-week iteration. Now, I don’t think that this is a huge problem in that you’re going in the right direction. You’ve taken steps to at least shorten your feedback loop to a two-week iteration. Now, it can be a bit painful, so I have three tips that will help you hopefully ease the pain.

The first of the tips is that I recommend having smaller product backlog items. I’m guessing that you have maybe four or five of these things for a two-week sprint, if you are like most teams that I see in the situation. I would work really hard in a backlog refinement session and just ongoing to get product backlog items small, such that a team could pull, I don’t know, 10 or 15 of these things into a two-week sprint. If you have small product backlog items, that means the team, if a few people on the team swarm one product backlog item, that you can actually get that item fully done in a day or two. You can then move on to the next time in the product backlog. In this way, you won’t be saving up all the testing for right at the end. You’ll be doing this ongoing in smaller chunks.

The first and probably lowest-hanging fruit, the easiest way to get a win here is to start working on smaller product backlog items. And initially, this can seem difficult. If you’re previously doing waterfall, you’re probably used to some pretty big items to work on. Well, break those down into smaller items. So that’s my first tip.

My second tip is to spread the knowledge and expertise across the team. Usually, in waterfall approaches in teams, there is a UI specialist, and there’s a database specialist, then there’s the testing specialist, and people really stick to those roles often because of the way we set up organizations. We set up organizations with a UI team, a database team. The trouble here is that you’re leaving stuff for just one person to work on.

Now if you have an agile team working together, team members will swarm on items together. That might mean initially, that things are slower because the expert who picks up this item will get it done probably more quickly than if he or she was mentoring somebody who is more junior to them or didn’t know as much about say UI design or database development or whatnot. The plus here is when people work together, you start sharing knowledge across the team, which means, after a number of iterations, everyone on the team is getting a little bit better at everybody else’s job, which means everybody can pitch in and help out where help is needed to get particular product backlog items done.

Now it doesn’t mean that people on the team won’t still have their specialties. They certainly will, but they’ll be helping mentor and share knowledge across the team with their teammates. And this can help you get out of that Scrummerfall mentality that you’re currently struck in or pattern that you’re currently stuck in. So the second tip, spread knowledge and expertise across the team. I do this by working together. Do this by not being  concerned about being slower at first, so that you can go faster later.

My third tip is that often one of the bottlenecks that I find here is in testing. So I would focus on transforming the way my team does testing. Traditionally, we do a bunch of development work. We say, “Asa developer, it works on my machine,” And then we pitch if over the wall to QA. Now, of course, when we have a cross-functional agile team, maybe we’re not pitching it over a wall that’s quite as big, but in the scenario that you’re talking about, all that testing was left right towards the end. And if you’re like most teams, that’s still quite painful. And if you’re like most QA people, they know how painful it is, because it gets thrown to them at the last minute, and then stuff doesn’t get finished, and the tem is unhappy, because well, looks like testing just didn’t happen fast enough. Those poor QA folks.

So the first thing I would do is grab a copy of Lisa Crispin’s book, Agile Testing. She also came out with a new book called More Agile Testing. Lisa Crispin is @lisacrispin on Twitter, that’s L-I-S-A C-R-I-S-P-I-N. She’s a great person to follow on Twitter. If you haven’t done that, go ahead and do that. But grab her book, because her book really helps you figure out how to test in an agile method or in an agile approach. It gets everybody on the team involved in testing. In fact, there’s a bunch of testing that can happen before anything’s every written.

Testers and developers talking about how something’s going to be built and how they’re going to go about testing it before any code is written will, in most cases, make your product and your software even better, makes it better. And there’s a ton of testing that can happen from anybody on the team, and you could leave the hard-edge cases, the stuff where you have to be a QA professional to the QA professionals on a team. So just like a UI person might mentor a database person in terms of how to get some of the UI work done if they needed some help on it, a QA person can help mentor the rest of the team about good QA practices, about good ways to test your software. And since this is one of the huge places I see teams falling into the Scrummerfall mentality or workflow, I would grab that book. I would grab Lisa’s book. In fact, I’ll put a link to it in the show notes, if you want to grab a copy. If your team is like most, it will help phenomenally. Also following her on Twitter is great, because she’s quite active on there, and there’s tons of useful nuggets that she tweets about.

In closing, the three things I would do to help move you forward, and there’s probably things to do after this, but this is where I would start. I would make sure I had small product backlog items, such that I could pull 10 or 15 of these into a two-week sprint. If you’re currently doing that, and you’re still running into the situation, add five more. Just make smaller product backlog items. Sorry, don’t add them. Break down your larger items into smaller items so that you have more product backlog items in your sprint. Number two, spread knowledge and expertise across the team by working together, by transferring knowledge, by making sure you don’t have just one expert in some segment in your workflow. And three, transform how you’re doing testing. Get everybody involved. Take a look at Lisa Crispin’s book.

So Duncan, thank you so much for your question. I hope that’s helpful. If you would like to grab the show notes for this episode, you could do one of two things. You can go to GetAgileAnswers.com and the show notes along with the transcript is available there on the home page. Or if you’re listening to me in iTunes, or rather, on your iPhone, you can tap on the graphic for this episode, my face there, you just tap on my face, it will bring up the show notes that links to all of this. On that same screen, there’s a button or link for rating this episode. I would love for you to rate this episode on iTunes so more people will hear about it, and I hear feedback from you about if this was useful or not. Hopefully it’s useful, because I’m going to be back next week answering another question. Maybe it’s your question. If you go to GetAgileAnswers.com, there on the home page, there’s a widget where you can record a message just like Duncan did which I’ll answer on a future show. If I choose your question to answer on a future show, you’ll get a deck of Agile Antipattern Cards, which, Duncan, I’ve got a deck coming your way for submitting a question.

Until next time, stay agile. Never change.