Scrum. Where Do You Start?

Episode 28

September 07, 2011




The Agile Weekly Crew discuss where a good place to start for a team wanting to adopt Scrum might be.

Episode Notes

Jade Meskill, Roy van de Water, Derek Neighbors, Drew LeSueur and Clayton Lengel-Zigich discuss where might be a good place to start for a team wanting to adopt SCRUM.


Define the roles

Scrum Primer

Roles and Ceremonies

What is necessary to improve

Strict SCRUM

Without experience it’s difficult to know

It’s not about experts, it’s about learning

SCRUM in 10 minutes

It’s not a panacea

User Stories Applied, Agile Estimating and Planning, Succeeding with Agile

Don’t get discouraged, focus on improving


Jade Meskill:  Hello and welcome to another episode of “The Scrumcast”. I’m Jade Meskill.

Roy van de Water:  I’m Roy van de Water.

Derek Neighbors:  I’m Derek Neighbors.

Drew LeSueur:  I’m Drew LeSueur.

Clayton Lengel‑Zigich:  And I’m Clayton Lengel‑Zigich.

Jade:  This week I had somebody ask me…they had just formed a new team, they’re building a new product, and they heard about the Scrum thing, and they really want to implement it. Their question to me was, “Where do we start?” Let’s talk a little bit about starting Scrum from ground zero.

I’ve heard of Scrum. I think it’s cool, I think it’s the way to go, but I don’t know anything about it. What do I do?

Drew:  I think it make sense to start with retrospectives. I think we’ve talked in the past that with Agile…

Jade:  What’s a retrospective?

Drew:  We start with weekly meetings, in which we review the last week, and think of how we can do things better.

Jade:  Why every week?

Drew:  Why not every week?


Jade:  Who runs this meeting?

Drew:  Whoever is in charge of the new team.

Jade:  Who is in charge of the new team?

Drew:  I don’t know. I assume there’s somebody in charge. [indecipherable 1:14] asked here the question.

Jade:  Who’s the team?

Clayton:  I think one of the first things you can do is identify the roles. Who’s a product owner, who’s…

Jade:  What’s a product owner?


Drew:  This is the E‑Course.

Clayton:  I’m talking from ground zero. I’ve heard of Scrum. Where do I begin?

Drew:  That’s a problem. You have a lot of roles that need to be identified…

Clayton:  Where do I find Information about this?

Drew:  You are not going to be able to afford to go to a Scrum training class, if you’re a start‑up trying to figure this out for the first time.

Clayton:  OK. So?

Derek:  There’s the Scrum Primer. It’s a two‑page document, very simple basic, what is Scrum, what are the roles, the ceremonies, the artifacts. That’s where I would start.

Clayton:  Awesome.

Derek:  Have everybody read that.

Clayton:  That’s what I told them to do.

You’d start with the Primer and just learn the basic elements of what makes up a Scrum team, and what are the ceremonies involved.

Clayton:  I guess when I think about it I question, “Do we really want to be advocating Scrum to people, just because they’ve heard that Scrum is this cool new thing? How do we know that Scrum is or isn’t viable for their organization”?

I can think of at least one organization we’ve dealt with at one point, and we asked, “What’s your goal of doing Scrum and Agile”? The answer was, “I don’t know. That’s the project, we have to implement Scrum”.

Roy:  It was to implement the Agile.

Clayton:  Right. I guess what I mean by that is, are there things that you could take to an organization or suggest an organization that could get them to start thinking about some of the principles behind Scrum, before they necessarily jumped in and said, “We’re ditching whatever we’re currently doing and going full board into Scrum, doing absolutely everything Scrum‑based.” When we say just go look at the primer, somebody looks at that and thinks, “In order to do Scrum I have to do everything on here,” which is true.

But the question is, do you have to do Scrum in order to improve your team? Could you do just a retrospective and improve your team? Could you do just a stand‑up and improve your team? Could you do just a planning meeting and improve your team? At some point you would have to do more, but I’ve seen a lot of teams that they don’t even talk to each other. Just talking to each other would be an improvement to their team.

Roy:  I think those are really good points, but let’s just imagine that you don’t have hours and hours to coach and counsel them on what it is that they need to do. They’ve expressed an interest in going this particular direction, and it’s easy to say, from your perspective that, “Yes, maybe you don’t need all these pieces,” but they are not going to know that.

Unless they have someone that’s experienced working with them and helping them along, they’re not going to have that context to understand that, “Hey, we just really need to start by doing stand‑ups.” You’re not going to have that insight into what their team makeup is, and they’re not going to be able to share that with you, in passing.

Clayton:  My recommendation would be, “If you have decided to go Scrum, as your Agile framework, then you follow it strictly. Don’t take just pieces out of it, because, if you don’t have the experience to know which pieces, why they exist, and what impact they have, then you probably have not the experience to make that decision.

I think human nature will tend to avoid the difficult things, and there are some parts of Scrum, some of the ceremonies, that specifically expose those difficult things. It almost seems it’s those ceremonies that produce the problems, when really they’re uncovering the problems.

If you don’t have the experience to see that, “Oh, it’s actually an underlying problem, we need to solve this,” your natural reaction may be to shy away from doing that particular, “OK, we won’t deal with having just one product owner, because that just doesn’t work for us. We’re going to avoid that because that’s…” when really that’s a huge problem for your team and maybe you should be addressing the problem, not what exposed it.

Derek:  Yeah, I agree, but that’s different between saying, if you’re going to do the ceremony, follow the strict guidelines of the ceremony versus saying, do the ceremony or don’t do the ceremony.

I guess where I’ll play devil’s advocate is, I’ve seen teams do virtually every step of the Scrum and not do Scrumbut, and still completely fuck it up, meaning just because you have a planning meeting and you say, what we did yesterday, what we’re doing tomorrow, and any impediments, you can still totally screw that up.

I was in a planning meeting today and it was, we said what we did, said what we’re going to do, and then we said, here’s the impediment, and passed the token to the next person, and nobody talked about actually removing the impediment.

Jade:  That’s the Scrum master’s job.

Derek:  Yeah.

Jade:  [laughs]

Derek:  I’ll also go against a little bit of what you said, Roy. I think that different teams are at different levels, so when you say, do everything for Scrum if you’re going to do Scrum, don’t pick and choose which ones that you want…I don’t know if that’s what you said…

Roy:  Sure, I think I’m more saying that, if you’re in [indecipherable 6:33] , if you’re in the position where you don’t know anything about Scrum, and nobody on your team knows anything about Scrum, but you know you want to do it, I would say you’re in no position to pick and choose what works best for you. I’d say that’s a very dangerous choice to be making.

Drew:  I would agree with that.

Derek:  I’d also say that, maybe you want to experiment with one feature, and you can gain value…it’s true, like you said, at the beginning. Start with retrospectives. You can gain value over just one aspect or one ceremony or one artifact of Scrum as you transition into it.

Roy:  That’s true.

Derek:  It depends on what level the team’s at, and maybe how committed they are.

Roy:  I could definitely see that, doing one thing, adding one thing at a time and measuring what effect it has. I think that would get you a really good understanding of what that particular thing actually does.

Clayton:  I think to me, we put way too much emphasis on experts. I think that the whole premise of Agile or Scrum, if you look at it from an inspect and adapt method, is that there is no prescribed, real formula. It’s really all about saying, what are we doing? Is it working? How could we make it better?

Certainly, experience helps accelerate that, and to me, that’s the difference. If you’re not willing to invest in training, if you’re not willing to invest in doing a ton of reading, if you’re not willing to invest in hiring a company to come in and do coaching or hiring in somebody experienced to put them on your team, you’re going to have to go through some learning phase.

It doesn’t matter if you read every Agile book out there. At the end of the day, when you go to apply it to your team, you’re going to run into things and you’re going to make wrong choices. I see experts every day make wrong choices, and that’s OK. The thing is, how can you iterate over those choices as quickly as humanly possible to speed up an improvement.

I think when you’ve got more of an expert eye towards things, you can make that change happen quicker, just because you’ve see