How do I escaped the dreaded ‘Scrummerfall’ trap?
Duncan’s team has switched from waterfall to an iterative approach. Their iterations are 2 weeks in length, but it seems the team is just doing mini-waterfalls in the two-week timebox. I’ll share the 3 simple steps teams can take to extract themselves from this common agile antipattern.
Like the podcast? I’d love it if you’d take 60 seconds to rate it in iTunes.
Mentioned in the show:
Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin & Janet Gregory
More Agile Testing: Learning Journeys for the Whole Team by Janet Gregory & Lisa Crispin
Do you have a question for the show? Want the show notes or transcript? http://GetAgileAnswers.com
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.
How do we make sure we have cross-functional teams and why does it matter?
What agile practices can you recommend to our game development studio?
How do we remove silos when doing government contract work using Scrum?
How should we form new Scrum teams?
How can we have good retrospectives (about our Scrum Master)?
When’s the podcast coming back?
How do we self-organize if our boss is on our team?
How do we deal with constant interruptions to our Sprint?
Can a User Story be too long? Ours seem insane!
Can our Scrum Master and Product Owner be the same person?
What 1 simple thing can I do to improve my coaching & scrum mastering?
How do I get hired as a ScrumMaster if I’ve never been one before?
Our team wants to be more agile. What agile process is best?
How do we improve our giant, multi-team Sprint Review session (or Sprint Reviews in general)?
What are some creative & effective ways to make Retrospectives more engaging?
Will this hurt my Daily Scrum? And how do we deal with “non-dev” work?
How do you help PMs and Managers not fall back into their waterfall ways?
Our teams keep changing. How do I set guidelines that keep teams together?
How do you make sure your team has time to make the improvements they identify in their Retros?
When should the business stakeholders get help from the dev team to get items ready for work?
How do I energize a demotivated Scrum team?
Mic Check! 1…2…3…