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.

On today’s show, I’m going to try two new things. That’s right, two new things on one show. Usually I just answer one question, but Jamie Smith submitted two, and since both of them, I think, are relatively short, I thought I’d answer them both. That means you get twice the value in the same amount of time. It’s almost like you’re practicing agility or something.

The second thing I’m going to try that I’ve never done before is give you the link to a really brief survey. The survey will help me adjust the show, maybe inspect and adapt it. I want to get feedback from people who are actually listening to the show, that would be you, so that I can deliver more value in future shows. And of course, the best possible way to improve your product moving forward is to get feedback from real live users. It only takes a couple of minutes. I’ll give you the link to it here at the end of the show.

So with that said, let’s give a listen to Jamie’s question. Let’s see what Jamie’s got to say.

Jamie: First question, is it acceptable to have the team write down the answers to the three daily Scrum questions before the daily Scrum? What are the potential ups and downs to such an approach?

Adam: Jamie, thanks for your question. All right, so you ask if it’s acceptable to write these things down. Well, I guess it’s acceptable. I wouldn’t stop anybody from doing it. But let me talk about maybe what the pitfalls might be to doing this. And to do that, let’s take a step back even further and look at why we have a daily Scrum.

Now for a lot of people, the daily Scrum just looks like a standard status report or some such, and while we answer the three questions of what we did yesterday, what we plan to do today, and if have an impediment as a team member, it’s not as a status report. We’re not doing it to just report to our teammates and we’re certainly not doing it just to report to the Scrum master, right? The Scrum master’s just there to help facilitate, but not be reported to. The reason we do it is to synchronize our work at least every 24 hours with our teammates, and hopefully, we’re doing that more often, but we’re doing it at least every 24 work hours with our teammates.

So I would say that if it’s useful for somebody to jot these things down, maybe someone gets a little anxious speaking in front of their team, for example, then I guess to collect your thoughts, that seems fine. But if you’re doing it to write them down and then you’re going to read them, looking at your paper, not making eye contact with your team, I could see that being a bit of an impediment. So I think there’s no harm in using it to collect your thoughts, but what I would look for in this meeting really, in the daily Scrum, is for my team to be interacting with each other at a high level. And I would want them to be making connections with each other on a high level. Otherwise, it just becomes very rote.

So to answer your question, I think it is useful to collect your thoughts. If writing it down on paper is good for you, go for it. But don’t rely on that as your sole means to talk with each other. Otherwise, getting together for daily Scrum wouldn’t be necessary. You could just shoot each other a message over instant message or an email, and we certainly shouldn’t be doing that. We should be talking with each other face to face.

So that’s your first question. Let’s get a listen to what your second questions was.

Jamie: Second question. If the next sprint begins immediately following the conclusion of the previous sprint, how do accommodate time for non-sprint activities like trainings, extended holidays or any time large groups of people are focused on activities not related to product development?

Adam: This question comes up pretty often, so I’m glad you asked it. How do we deal with stuff that is not directly related to product development? Well the first question I would have about work not directly related to product development is do we need to do it? Often, when organizations switch from doing waterfall or something else to Scrum, they keep in place all these other meetings and events that they don’t really need anymore. They’re not adding a lot of value.

So the first question I would ask is does this other thing add value? If not, you can take the opportunity to have some conversations about that, to figure out maybe if you could remove that impediment for your team. Man, they would love you if you could.

Secondly, what happens if it’s a vacation? What happens if it’s something that doesn’t relate to product development, but it’s really useful for your teams? What about that other stuff? Well, yeah, you’re right that there’s no time between iterations or sprints, no problem. You just plan less work for that sprint. Not a problem at all.

The best way I like doing this is not doing a crazy spreadsheet that does capacity planning. I just like to go on a sprint planning and ask my team, “Hey team, do we have any big events happening in this sprint? Do we have a company offsite? Do we have holidays? Or is anyone planning on being sick on Friday?” I would just ask those questions. People will raise their hands or they’ll explain when they’re going to be out or if we all are going to be out for something, and the, just go on a sprint planning as usual, and plan your sprint based on the collective gut feel as to how much work they can do this sprint. Don’t leave it to, “Last time, we did 30 story points, this time, we’ll do 30 story points.” Don’t worry about the points. Just plan your sprint based on the collective gut feel as to how much work they can do in the sprint.

And you can do that pretty simply, just by reading the first product backlog item, and having your team give a thumbs up or a thumbs down as to if they think they can do that. If they say yes, move on to the next item. And rinse and repeat until you have filled up your sprint. Once you have filled up your sprint based on your team’s collective understanding about their availability for this sprint, you will be good to go.

So there you go. Two questions answered in one podcast. As I promised, I want to get everybody involved here, anybody who is willing to take about two minutes to fill out a very brief survey. They can do that by going to GetAgileAnswers.com, that’s GetAgileAnswers.com, and there at the top of the home page, I’ve added a new button that says “Take the survey.” You’ll take the survey, answer just a few questions, I think it’s six, most of them are multiple choice, and your feedback will be super useful in helping form future episodes. Again, the best way I know how to do that is to get feedback from actual users. As it turns out, actual users are you. If you’re listening to this on the iPhone, in iTunes, you can just tap on my face, and there on the show notes, they’ll magically appear, and there’ll be a link to the survey. You can do it from there.

So Jamie, thanks so much for submitting your questions. I’m happy to answer both of them. I hope it’s useful to you. Anybody else who’s listening that might have a question they would like answered on the podcast, you can do that at GetAgileAnswers.com as well. There’s a survey, but there’s also a little widget where you can record a question just like Jamie did, which I might answer on a future episode. If I answer it on a future episode, you will also get a deck of my Agile Antipattern Cards for free, for helping out, for leaving your message on the website and getting it answered on a podcast episode.

Well, I look forward to talking with you next week. Every Tuesday, a new show comes out, and I look forward to talking to you then. Until then, stay agile. Never change.