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.

• Retrospectives
• 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

Transcript

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?

[laughter]

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?

[crosstalk]

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 seen the patterns before. But I think that we need to stop trying to circumvent learning in organizations.

Drew:  I feel like some of the stuff that you’re saying there, in terms of what the principles are and everything, are some kind of based on nuance or your experience. I think if you’re the average person that says, “OK, I’ve heard about Scrum, and I want to implement Scrum at my company,” they’re going to go on the Internet and they’re going to watch some videos and read some things and they’re going to say, “I have to do these 15 things, this list, and I have to follow this order. I think that’s what they’re going to do.

They’re not going to immediately jump to, “OK, I just need to inspect and adapt.” I don’t think anyone out there that’s selling Scrum…I think most of the stuff out there for Scrum is really promoting Scrum for a commercial reason. “Here’s how you do Scrum, and I know it’s very confusing, so come and talk to me.”

Because of that, no one’s saying, “Hey, you can get started with Scrum by doing this simple thing. Just inspect and adapt and just do a couple things and see what works and learn from that.” No one’s really talking about the nuance of it. It seems almost impossible, if you are not really part of that culture or part of that community, to understand that that was the case, and understand there’s a different way of doing it.

Jade:  Going off what you’re saying there, could you…and the situation that I’m faced with…could you come in and do Scrum in 10 minutes? What would that look like? You have 10 minutes to explain Scrum to a team that wants to implement it. Go.

Drew:  It seems like, if you had 10 minutes, you’re going to focus on more of the principle stuff, and then it’s not going to look like Scrum necessarily. I wonder, if you were to do that, then would you begin some kind of mixed messages? Then, where do you go from there?

Because, if you go seek out the next step, or, “OK, we’ve been doing this for a few weeks now. What do we do now? Now I’m going to look for Scrum stuff, and it’s not the same thing I have learned already.”

Clayton:  Yeah. I think some of it is we highlight Scrum as this panacea or this magic pill that, if you just do it, all your problems go away. I think that, if someone were to come directly to me, what I would probably tell them is, “Hey, here are some resources, here’s the primer, you might want to read my koans, user stories applied, [indecipherable 10:59] menu planning.

You might want to read a couple of different books that help you accelerate your learning. But, ultimately, it’s really, really simple, but it’s really, really hard. Don’t get discouraged. Just make sure that, every week, you’re improving. As long as you’re on the journey towards improving, don’t worry about whether your implementation of Scrum is perfect.”

I think maybe that’s the chicken’s way out, but I think that the problem that we do is we do this [indecipherable 11:30] . I think the community has this thing that, once you know Scrum, then you have to do exactly Scrum. You’re not allowed to do in Scrumbut, and, if you have any problems and you’re failing, it’s because you’re not doing the exact prescribed elements of Scrum.

If you would just do those, you would stop failing. I think that’s bullshit. Human beings are involved, and, even if you follow the process to a T, you are going to have failure sometimes. I think every human being is different, so every team is composed of multiple humans. You’re going to have a unique problem on every single team that no Scrum guide can solve for you.

Roy:  That’s definitely true, but I think the beginner’s approach, often, is the think that every problem you run into is your own unique problem, and it’s very difficult to get away from that. Without experience, it’s impossible, really, to see that this isn’t a unique problem. This is actually the problem that the ceremony or whatever was directly designed to address, and it’s exposing the problem.

That’s my concern. I think it’s important that you inspect and adapt. It’s also important that you start out with some kind of framework. If we’re going to go with Scrum, just going over a set of principles, like Agile in general, then it seems to me that you’re interested in having a starting‑off point.

You inspect and adapt, but you start off with something that you can inspect and adapt, so you don’t have the blank page problem, where you sit in front of that and you don’t know what to try first. At least, Scrum gives you something there, but it’s difficult to make a [indecipherable 13:03] to say, “This is working for us” or “This isn’t.”

Drew:  Yeah. I would imagine that it’s pretty easy to say…the person that came and talked to Jade says they want to do Scrum. Jade points them in the right direction. They start doing Scrum, and they get to a point where there are some psychological issue with people on the team, and that’s a totally separate thing that is not necessarily discussed in the primer.

I think, unless they are willing to go above and beyond, maybe they’ll go do some more reading and say, “This is a deeper issue.” Then that’s how you get into doing Scrumbut, where it’s like, “We had this problem on our team which I didn’t read anything in the book that says anything about this, so we’ll change it a little bit.”

We’re still doing Scrum, and then you get to the point where it’s like you’re not doing Scrum at all. You’re doing this weird bastardization of it.

Jade:  So it doesn’t matter?

Drew:  What?

Jade:  If, let’s just say, I end up going down that road. I learned the very basic principles of Scrum, and now I’m changing it to fit our situation, but maybe it’s not the “right way.” Does it matter?

Drew:  I guess it doesn’t matter in the sense that you would be doing maybe just as bad, and you’d be doing it in some other way.

Derek:  I think it doesn’t matter, the one thing being that you cannot accept stagnation. You cannot be willing to accept that you refuse to improve. Because I think I’ve seen that before, where people come up with their own derivative of Scrum, and they say, “This is our Scrum,” or, “This is our process,” or “our method” and then they start making changes, they start looking at anything that has changed around them, and they just stick with the exact same thing.

Clayton:  I think that is the problem. What we tell people right now is, “Go read this primer, and, if you implement Scrum, all your problems are solved.” So what they’ll do is they’ll go implement Scrum, and they’ll find little things here. Maybe I can have one product owner, so I have to, or maybe Scrum doesn’t really address velocity, hours, or something else, so we roll our own based on some anecdotal evidence.

Then, when somebody comes in and says, “We’re frustrated. We’re still not delivering on time. We stopped using Scrum, because Scrum doesn’t work for us.” Then you talk to them, and you say, “What you’re doing is not really Scrum, and you’ve got these other problems,” but what happens is people stop inspecting and adapting.

What they’ll do is they’ll say, “I implemented Scrum. It didn’t work for me, whatever part. I made this change, and that didn’t work either. Therefore, I’m going to just stop trying and go back to just whatever we were doing before that didn’t work either, because this Agile stuff just doesn’t work.”

I think the crime that we’re committing is we’re not telling people that making the first deviation is actually OK. But, when that deviation doesn’t work, you should be asking why didn’t that deviation work and trying something else. Maybe you’ll get two, three, or four deviations before you finally go “Ah! Light bulb moment! Now I understand the strict version is this. Maybe I need to back and try that based on what I’ve learned.”

I think we teach people that it’s not OK to make changes to Scrum, which isn’t novice. I think it is dangerous to do that. I really do. I’d recommend to try to implement a fairly strict version of Scrum before you make any changes. But, if you start to make changes, don’t give up if those changes don’t work. Keep making changes until you find what works for you.

Derek:  Right. I think, even if you implement the ideal version of Scrum, and if feels like it’s working good, still keep making changes, because it could be better.

Jade:  Still inspect and adapt. Maybe not necessarily make changes.

Derek:  That’s true. No. Actually, I want to take that back. That’s not true. I would say, even if you are happy with your results, still make changes, because, what if it could be better, and you are just on the other side of the hill and there’s an oasis on the other side. I would say, even if you feel everything is going great, still make changes and still take risks.

Jade:  Any last parting thoughts for new teams looking to implement Scrum or explore Scrum for the first time?

Roy:  Yeah. I like what Derek said about you’ve got to understand the underlying principles. I also like what you said, Jade, about if you had 10 minutes to describe it, what would you say? I think we can combine the both. Nobody is going to learn everything in one go around.

The principle of inspect and adapt is huge, but, if had 10 minutes to describe it to a team, I would talk about the basic principles: weekly iterations, a deliverable product after each iteration, teach them the Scrum primer, and then have them continue to learn and grow, and don’t reject it if it doesn’t work the first time around or if it exposes issues the first time around. That’s what Scrum’s all about.

Clayton:  I think the thing that kind of uncovered this conversation for me is I don’t think it’s realistic to say “How do I implement Scrum?” Then I’m going to tell you what to do, and then you’re going to go on Scrum. I’m going to tell you what to do now, and then we’re going to have to keep you talking about it. It’s going to have to be an ongoing relationship, and ongoing thing. As you go through the motions of implementing Scrum, and you get the growing pains and everything. You’re going to need someone to talk to, and discuss what’s happening. I think the only way you can say “How can I implement Scrum?”, is to have an ongoing conversation.

Drew:  I think one thing I would add too, is to try to get the entire team to be open and honest about their feelings regarding their teammates. Especially regarding how they are feeling about the current process. I think it’s going to be impossible to successfully implement a, or maybe at the very least extremely difficult to implement a successful version of Scrum. Unless you get buy‑in from the team. If you have an entire team of people that are against you, I think that that’s fighting an uphill battle, and at the very least you should know about it going into that.

I do think that you should promote the honesty. Just because they don’t agree with you it doesn’t make them wrong. It’s better to know how they feel than it is for them to hide it for fear of pissing you off.

Jade:  Thank you for listening to the Scrumcast. We’ll catch you next time.