Scrum

So both of them are lightweight approaches to software development, kind of a reaction to the 1990s era when people were writing huge documents describing what they needed in a software development project. And so Scrum was the first response to that, of getting people to go lighterweight, not having to think one and two years ahead on their project.

And Agile then came about as a broadening of Scrum and included a few other methodologies that are similar to Scrum.

Rachel Salaman: The word Scrum suggests a huddle, which is a quick standing meeting that some organizations like to do. But it's a lot more than that, isn't it.

Mike Cohn: It is. Scrum is an overall process framework. It's not really a methodology. I know we're calling it one – I call it one a lot as well – but Scrum is deliberately incomplete, so it's not a full-on methodology. And one of the elements of the framework is something called a daily scrum and that's gotten to be very popular. People have taken that beyond Scrum and just started to use that, even if they're doing nothing related to Scrum.

And so a daily scrum is a very short meeting, we normally limit it to about 15 minutes, where team members just get together and talk about how things are going on the project.

So it's much more than that daily scrum, but that's one of the most visible things and it's been picked up way beyond people doing Scrum the framework, Scrum the methodology, and way beyond just software development as well.

Rachel Salaman: So what are the main characteristics of Scrum?

Mike Cohn: The main characteristic is to do things incrementally, build a little bit, see how people like what you've built, and then use the feedback from that to figure out the next thing that you're going to do.

I had a conversation with my dentist a couple of weeks ago and it was actually a new dental hygienist and she said, "What do you do?" and I am trying to answer the question while she was cleaning my teeth. I said, "It's basically if you wanted to start a new software product for your dental practice."

The traditional way would be to have somebody write a 100- or 200-page document describing everything you need and then people would go away and build that software, come back in a year, and probably give the dentist something that didn't really match your needs. In an Agile or Scrum approach, what we do is go to that dentist and say not what do you need, but what do you need most, what do you need next, and then we build one thing. Now we have a vision of where we're headed, we want to know what the whole product is going to be, but we build one thing and then we show it to the dentist and then she can say, "No, that's not what I want" or, "Yes, it is." And then, based on that, we build the second thing and then the third thing.

So it's about having teams working together with their customer collaboratively and building just a little bit, rather than trying to get the whole thing specified out up front, which is just a huge mistake.

Rachel Salaman: As we've been saying, Scrum and Agile are both associated with software development. How much are they being used outside the world of software development, in your experience?

Mike Cohn: I think quite a bit. In fact, I think the coming wave is for organizations to use Scrum outside of software development. It definitely has its home territory in not even software development but general product development, so building tangible, real-world things. The Sony Walkman, for example, back in the Eighties was considered an early Scrum project and wasn't necessarily a software project. So it started in product development, moved to software because it's so perfect for software, but very broadly used beyond there.

My attorney, who just does things like file copyright notices and things for me, he's learned about Scrum. They started using Scrum in the law firm, where he and paralegals and partners on his team will meet in the morning, do that daily Scrum we discussed, and so they use Scrum. One of my favorite examples is that people are using Scrum to organize and plan their weddings. There's a website that I enjoy called scrumyourwedding.com – I'm not associated with it at all, I just enjoy it because I've used that example for 10 or 15 years and Scrum is perfect for projects where there's a lot of uncertainty, where you haven't done the thing before, so it's a great methodology for things like that. There's marketing initiatives that are being done with Agile, and so people will run their entire marketing campaign. Instead of lining up a "here's what we're going to do for the next three months," they'll do a little bit of the campaign, see how it goes, and plan the next part of their campaign. And that's one of the Agile principles, so very broadly beyond software development.

Rachel Salaman: So does the whole organization have to move to Scrum for it to be most effective or does it work just as well with one or two Scrum teams within the organization?

Mike Cohn: I'd be reluctant to say it works just as well. It's certainly going to be better if you can get a pretty broad adoption but, really, what I look for is trying to get a project at a time moved over to Scrum. So it's kind of difficult if you have, say, two teams on a project and one is doing Scrum and one is doing more of a traditional plan-driven approach. That makes it very difficult. One team is trying to do things incrementally, the other team is saying, "Don't worry about it, we'll have the whole thing done in six months," and so it's a kind of impedance mismatch. They just think about their projects in different ways.

So I don't need the whole organization to adopt Scrum, but I do try to get a project at a time or an ecosystem at a time. One element of the organization converted, one subset of the company, at a time.

Rachel Salaman: And do those Scrum teams usually operate like that all day, every day, or is it something they can dip in and out of depending on which project they're focusing on?

Mike Cohn: It actually is something that is pretty fundamental to how they work, so I would want them to be consistently operating in a Scrum or Agile manner on the project they're on. If you have people who are on two different projects, one project might be Agile, one might not be, so they could be half of the day on Scrum and half of the day on the traditional model. But most of the time, once people start working this way it becomes something that they want to stick with.

I want to give you one other example, because it kind of ties in with this and it was back with your question about where else is Scrum being used. There are a couple of organizations who are using Scrum to go into primary education, young kids, and one of the examples I'm familiar with is a bunch of nine-year-olds in a school and the teachers are using Scrum to educate them, to help them through their schoolwork.

So they're not teaching them Scrum but they're using Scrum, and the example would be, I remember when I was nine years old, I think we had to do a project on the pyramids, study the Egyptian pyramids. And so the way these nine-year-old kids are doing this is they'll work as a team, one of them will perhaps draw pictures of the pyramids, the other one will prepare a little oral report that they'll give, and things like that. And so the nine-year-olds are using Scrum to work as a team to deliver their project on the pyramids. And the feedback from the teachers, and this is where this relates to your question, is the kids love working that way so much that they want to work that way all the time. They want to do their math homework, their spelling homework, whatever else they have. They enjoy Scrum and they want to stick with it.

One of the teachers refers to her students as her little Scrum monsters because they are so interested in working that way!

Rachel Salaman: So how much of an upheaval is it for companies to implement?

Mike Cohn: In one sense it is a big upheaval and it doesn't have to be in a bad way, but it is fundamental to how people work. We want them to be more collaborative. We want them to be talking with their customers, building smaller things, and it isn't always the way that software developers in particular have worked.

So it can be a fundamental change in how people work. It doesn't necessarily have to be a big upheaval, but it's a fundamental change and that makes it challenging at times.

Rachel Salaman: So what levels of resistance should a leader expect if they're introducing Scrum, and what are some ways to overcome them?

Mike Cohn: That's a tough one. I have seen organizations where we've introduced Scrum and the developers rebelled against it. They just did not want to work that way, largely because they didn't understand what it meant for them, and this is going back a few years when it was a little less known. And then there are other organizations where they totally embraced Scrum and have no issue with it.

I think it's one of those things where the leader has to somewhat sell why the change is being made, and this is where past success can be a big enemy. If you had a company that was very successful and they go to make a change, people are going to say, "Well why do we have to do this? We are Company XYZ, we're successful, we're this, we're that. Why do we have to change?" It's like, "Because our competition has started to get faster. Our competition is putting out good products, we are still the leader, but we want to stay the leader and just because something worked for you 10 years ago doesn't mean it's the right process today."

So there does have to be some salesmanship from a leader in terms of why the change is being made. When people do resist, there's an interesting change management model called ADKAR and one of the things I really like about that change management process is they talk about looking at people's awareness, desire and ability to change.

And when you have a group that's resistant, I want to find out are they resistant because they're not aware that the new way is better? And, if they are, then you can do things like educate them and expose them. If they're aware, do they have the desire? They may not have the desire to change, they may think it's not a big deal that there's better approaches out there – our approach is good enough – so I look to see if they have the desire and, if they don't, you have to increase their desire. Often you can do that by doing things like creating some urgency, letting people understand, "If we don't do this, here's what's going to happen," so you create some urgency around the problem.

And then the last one is ability. If people have awareness and desire and are still resistant, it may be because they don't have the ability to do the thing at this time and then it's a matter of getting them training, education, exposure, getting a really good pilot project and then moving people off that pilot project onto other projects so there's some experienced guides in the organization, things like that.

So I really do look at awareness, desire and ability as often being the impediments when people are resistant.

Rachel Salaman: You've suggested that it's worth starting with a pilot project, not so much to test Scrum but rather to learn how to do it well. What are your tips for choosing a pilot project?

Mike Cohn: This goes back to what I said about Scrum being a framework rather than a full-on methodology. And the difference I mean there is a full-on methodology would be fully defined. We would say exactly how things work. We would define all the inputs and outputs in great detail. And Scrum doesn't go to that extent – it leaves a lot of that up to the organization.

And so, by running a pilot project, what we're trying to do is figure out what should Scrum look like in this company. So, in terms of the attributes of a pilot project for me, I want to look for something that is probably in trouble and probably not going to be successful on its current path. If I put Scrum in place on a very simple project, a project that's already set up for success, it's not going to matter if it succeeds. People are going to say, "Well, it was already going to be successful, no big deal." So I like to find things that are challenging in the organization and make those successful with Scrum.

One of the ways I like to make that successful is I certainly would like to stack the deck in terms of the people on the project, I don't want to pick people to be on that project who are openly resistant or aggressively fighting Scrum. Occasionally people afterwards will say, "You were only successful because we had the good people," and it's like, "Well yes, but now we know what it looks like, we can start to make it work with our average people in the company." But use your good people to figure it out.

I also like to pick a project that's critical. If I don't pick something that's critical, if I pick something that's just unimportant, we'd like to get it done, background project, low risk, but the problem there is people won't do the hard things that change requires.

So, whether we're changing the Scrum or changing anything, I want to have people on the project who are experienced, I want to have a challenging project, and I want to have a project that was probably headed towards a failure or you sensed danger before the change.

Rachel Salaman: Now, you've touched on this a bit already, but what kind of planning should go into a Scrum project, pilot or otherwise?

Mike Cohn: I think planning is always going to be vital. We have to know what we're building. I don't want to start a project and not know if we're building a video game or a word processor. We have to know what we're building. But the thing is, we don't have to lock down every last detail about the project.

There was a great author named E L Doctorow who wrote books like, "World Fair," "Billy Bathgate," and, when he was writing, he used this great explanation of what he said writing a novel was like. He said, "Writing a novel is like driving a car at night. You can only see as far as your headlights, but you can make the whole trip that way." And I think that's what software development or any sort of product development is like, or, going back to our earlier example, even planning a wedding is like. But you don't have to lock down everything. The things that are near-term are illuminated more brightly by your headlights. The things that are further out are not. You can still possibly see them but they're not as well illuminated.

If you do have something where you need to have a little bit more insight into something that's further out on a project, maybe three or six months out, you do a little bit more planning on those things. It's not always necessary but, every now and then, we can plan a little bit further out to know what we're going to deliver and exactly what it's going to be. To me, the analogy still fits there because that's like driving on that highway and flashing on my bright headlights for five seconds just to see what's out there.

So I really like that idea of a project is like driving with your headlights and you can only see a certain distance, but, as you make the journey, things that are further out start to get illuminated better as you approach them. So planning is still important, but we just don't want to overdo it.

Rachel Salaman: What does a Scrum team look like? What's the size, roles, structure, and so forth?

Mike Cohn: The typical Scrum team is described as being about five to nine people. We can certainly work with smaller teams, but a lot of Scrum is oriented around solving communication problems and things like that. Communication problems are probably not your biggest issues on a one- or two-person team. They can certainly be relevant, and Scrum is going to benefit smaller teams, but part of Scrum is about solving these communication issues and focus issues, things like that. So kind of a five-person team but, above nine, there are studies that show that we don't interact with people the same way as the team starts to be 10 or 11 people. There will be days where you don't even talk to some of your team members. So the standard size, five to nine, is the advice.

I like how Amazon talks about it. Jeff Bezos from Amazon describes the goal being to create what he calls a "two-pizza team." And a two-pizza team would be a team you can feed with two pizzas. You don't want to have a team that's too big. A team that's too small is, again, not going to get all the benefits. So I like that model of a two-pizza team. If I go to 10 or 11 people, it's getting pretty big. But I don't want to feel like I'm breaking a rule, it's just a guideline of five to nine. So that's the size.

There are two special roles on a Scrum project and they're called Scrum Master and Product Owner. Scrum Master is kind of there as a coach, keeping things moving. They're the one who would normally know Scrum the best and moves it along. The Product Owner, I call them the key stakeholder, they're the one who knows what we're going to build and they prioritize work for the team, answer questions about should it do this or this.

So there are those two special roles, Product Owner and Scrum Master, and apart from that it's really just a team.

Rachel Salaman: Let's talk a little bit more about those two roles then and, starting with the Scrum Master, can you tell us a bit more about what someone in that role does and what attributes does this person need to have?

Mike Cohn: The main way to think about a Scrum Master is they're there as a coach. And I'm not a big fan of sports analogies, because everybody likes different sports and won't know as much, but, if you're familiar with any sport, a coach is there to help people perform better, help the team work together. And so that's what the Scrum Master does. They are there to facilitate meetings, they are there to resolve problems for the team, they are there to do anything they can do to help the team work better together. So they will notice things. If a team member needs to improve at a skill or anything like that, they can have conversations with them like that.

So, to me, a Scrum Master is kind of like that good type of project manager who is there helping the team, figuring out what needs to be done, but not being directive. Scrum Masters really have no authority – they can't say you do this task. Teams are meant to figure task assignments out for themselves. Scrum Masters normally do not have the ability to hire or fire team members. So they are really just there to facilitate, help the team in any way they can be a better team.

In terms of the attributes of a Scrum Master, I like to find Scrum Masters who are willing to take on the responsibility for a project. They have to be people who will not shy away from that. I look for Scrum Masters who are humble. I don't want some sort of Scrum Master who is going to be talking about what the team accomplished and saying, "Look what I did." I want them to talk about what the team did – collaborative Scrum Masters. And that's another good attribute.

I need people who are not in it for their own sake, they're there to help others. They have to be able to influence people. Because they don't have direct authority, they can't say, "Do this or I'll fire you." They have to be influential. They have to be able to get the right things done on a project without that authority to say, "Do it because I say so."

Rachel Salaman: What about the Product Owner?

Mike Cohn: The Product Owner's main job is to figure out what to build, the order in which to build it. Priority is important – what should we do next. They are often thought of a little bit as outside the team. I really do want to think of them as a team member but their personalities and their backgrounds are often a little bit different. They're not the core developers. Scrum Master is sometimes a former developer and so Product Owners are often a little bit outside of that. They may be coming more from the business side of an organization or from the marketing side.

And the attributes I look for from them. I really look for them to be business savvy. They have to understand what we're building. They have to be able to make the right call of, "This feature is more important than that feature." They have to be able to figure that out, so domain knowledge is extremely important in the Product Owner. I want Product Owners who are available. As a consultant, I go into companies and explain Scrum to them, and then I'll talk about the Product Owner being the key stakeholder who can make business decisions. And occasionally some great big VP will say, "Well that's me. I'm the Product Owner. I have an hour a year to devote to this project." Well, that's not a Product Owner. That's an important stakeholder, but that's not the Product Owner. We need more availability than that.

I want Product Owners who can be decisive. Teams are going very quickly when they do Scrum and if a Product Owner says, "I don't know. I'd better go run that by the user committee," and if they say that too often, that can be a problem for teams.

Rachel Salaman: And the Product Owner should not be the same person as the Scrum Master?

Mike Cohn: That's a very good comment. We really don't want to combine these two roles. It ends up being a little too much power all in one person when we do that, and I think there's something fundamental to their personalities.

A good Product Owner by nature just wants more. They want more features, more functionality, and they want that because they are there to service their customers, build great stuff for their customers, and so it's their nature. That's what I want in a Product Owner.

A Scrum Master certainly wants to deliver more and more functionality as well, but is a little bit removed and watching the team develop. Again, think about a coach watching the team. And so, the Scrum Master is able to say, "We're pushing the team too hard. They're getting sloppy. This is not the time to push for more," or, "Now is the time to push for more."

And so we lose too much of that when we combine the two roles.

Rachel Salaman: You said that, other than these two roles, the team is just a team. But are there any particular pitfalls to look out for when you're putting a Scrum team together?

Mike Cohn: The things I look for in putting together a Scrum team are not very different from the pre-Scrum days. You don't want to have personalities who are going to overly fight with one another and things like that. You want people who, I don't want to say get along together because it's not just that, and sometimes I want a little bit of tension between team members because then, through that tension, they can perhaps get the right answers. But it's the same issues as with a pre-Agile team.

Rachel Salaman: And the idea of teams self-organizing is fundamental to all Agile methodologies, including Scrum. What does that mean?

Mike Cohn: That's a great question. Self-organization is about the team figuring out how they will solve a problem.

The Product Owner role that we discussed, that's the key stakeholder, the business person. The Product Owner defines what needs to be done and then the team figures out how to achieve that goal. So a Product Owner might say, "I need this big thing done. I need it in six months. it has to achieve these three initiatives," and then the team figures out how they're going to do that.

So the team itself organizes in response to a challenge. The challenge is given by the Product Owner, the team figures out how to do that, meaning there's no designated technical lead on a project who gets to assign tasks. The Scrum Master doesn't do a task breakdown, a work breakdown structure, and then assign tasks – that's done collectively by the team.

Now, to make that easier, they tend to work in what are called Sprints, which are short two-week time boxes. They might be two to four weeks, but the team will get together every couple of weeks and say, "OK, how are we going to achieve the big goal? What is the stepping stone in this next two weeks?" and then they'll make a list of tasks, divvy up the tasks among themselves, perhaps in that meeting or during the two weeks. But it's up to the team. It's not up to the traditional approach of the one smartest person in the room.

Rachel Salaman: What are the challenges of leading a self-organizing team?

Mike Cohn: This can be a big change for the people who come into a Scrum Master role. They're really the ones who are guiding the self-organization. The Scrum Masters, if they come from something like a project manager background, very common, it will be hard because they'll want to fall back a little bit too much into some of their more directive aspects of being a project manager. People who have traditionally assigned tasks, people who have traditionally stepped up and owned a tremendous amount of responsibility to make decisions on the project, if they become Scrum Masters they have to back away from some of that and let the team decide those things.

Now, self-organization is not something that just occurs in a vacuum. Leaders in an organization, whether that's executives or Product Owners or Scrum Masters or a senior architect in the company who is outside the team, people like that can exert influence over how the team self-organizes. So, if you have the beginnings of a team and you think they rush to make decisions too quickly, you might want to, as a leader in that organization, put somebody else on that team who has a different decision making style, perhaps a more deliberate, slower-paced, fact-gathering decision making style. Well, that will influence how that team self-organizes.

So it doesn't just occur in a vacuum. Leaders can influence how it occurs and that's an important part of the leadership role in a Scrum or Agile organization.

Rachel Salaman: Another characteristic of Scrum teams is whole-team responsibility. Could you explain this and perhaps give an example of what it looks like?

Mike Cohn: Whole-team responsibility is where we say that the whole team is responsible rather than one person.

We may have one person on our team who is our go-to person for the database and, whenever we have a hard database question, we go to her. We ask her how to solve this. She may write some SQL code to solve that problem. So she's our go-to person for the database. But that doesn't let the rest of the team absolve themselves for all responsibility of the database. If there are things they can do to make the database better, clean things up, whatever it might be, they do that.

And so, when we give a challenge to a team, the team is expected to embrace that as a whole or perhaps say, "No, we can't do that." The Product Owner says, "I need this in six months." The team goes away for a day or two and thinks about it, and says, "That's impossible. There is just no way. But if you left this feature out or something, we could do it," but I want the team to embrace that responsibility as a whole.

Rachel Salaman: We should probably talk a little bit more about some of these other specialized terms. Sprint is one you used earlier, and Product Backlog is another term associated with Scrum.

Mike Cohn: A Sprint is really just a short period of time during which the team has picked something to deliver and will deliver it. And so a Sprint is just this short time box. It starts out with the team getting together and very loosely, briefly planning what are they going to do. "What do we have to do to achieve that goal on the product?" And then we run the Sprint, typically two to four weeks for a Sprint.

An example there, going back to the wedding planner, would be something like, "During the next two weeks, let's visit venues and we're going to pick the venue in which we're going to get married," and that would be a Sprint. Now, we're not going to worry about who the DJ is going to be, we're not going to worry about the guest list, during those two weeks. We're going to pick one or two things, focus on that, and get it done. So that would be a Sprint.

The Product Backlog is the list of everything that is desired to be done on a project. So again, sticking with the wedding as an example, we have to pick a venue, we have to pick a caterer, we've got to pick a photographer, a videographer, a DJ. All of those types of things would be your Product Backlog. On a software project, it might be things like add a spellchecker to our word processor, or improve the table design, or upgrade the Linux server. It would be things like that. So it's anything that needs to be done on the project.

Rachel Salaman: Could you talk a little bit more about quality in the context of Scrum, and tell us some ways to ensure high quality in any Scrum project?

Mike Cohn: One of the things that Agile has really trained the software development world on is that the best way to go fast is to go well. We want to keep the product at a high-quality level all the time and so it would be very unlike traditional software projects where we'd get to near the end and then we would start a two- or three-month testing phase where we try to build quality in. Building quality in doesn't work – car manufacturers learned that back in the Seventies – and so we need to be taking quality seriously throughout the project.

One of the things that is a bit of a hallmark of a good Agile team would be a heavy emphasis on automation for testing. So they will find ways to automate all of their tests. Some of the best ones you will see things happen like somebody checks in code to a version control system and they'll see thousands of tests run within minutes of the code being checked in. It just happens automatically, and that's the type of focus that has been put on quality with Scrum.

There is a another aspect to quality, which is also, "Are we building the right thing?" Because we could build a very high quality product, go away for a year and build that super high quality thing, no bugs, and then hand it over to our customer and the customer says, "That's not what I want."

So quality is also about building the right thing, and we get that in Scrum through this idea of Sprints that you raised a moment ago, where, every couple of weeks, we're talking to our customer, showing them what we built, and saying, "What do you want next?" And that helps us make sure that we build the right thing. So quality in that sense as well is very important.

Rachel Salaman: So let's say someone introduces Scrum into their organization. What are some ways for them to measure how effective that has been?

Mike Cohn: I like to look at the outputs of the development process, that is the things that we're building or the products that come out of the process – the right things. So I'd be looking at what do users think about what we've built. I do a lot with quality metrics so I'd be looking at things like defect rates, defects in the first 30 days post-release. So, "Have we seen a change in quality on our product from a pre-Scrum to a post-Scrum world?"

I also start to look at what's called cycle time, which is how fast we can go from an idea to an implemented feature. You really want to reduce cycle time as much as you can so it's very short. You'd like to be able to come up with an idea and, a week or two later, have that idea in people's hands. In a traditional world that wasn't possible because we might be doing three- or six-month development projects and things would be locked down. You couldn't introduce change. So, with Scrum, we really want to look at this idea of cycle time and, "Are we able to more quickly introduce new ideas?" And if we are, we will be able to beat our competition.

That is the goal – just be a little better in a competition and you win. And if we can reduce cycle time, the time from idea to implementation, that's going to be a key measure of success for me.

Rachel Salaman: So, standing back a little now, what would you say to a leader who is thinking about introducing Scrum into their non-software organization?

Mike Cohn: I would tell them to just absolutely go for it. The worst that you could lose is a Sprint. Again, a Sprint being something like two weeks. And do a one-week Sprint if you think that is more appropriate, depending on what you're working on, but the most you could lose would be a week or two. That would be a complete disaster and I don't know that I've ever seen that happen, but that is the absolute downside. You go in, you want to try this thing, and absolutely nothing comes out of it. It's horrible. OK, you write off the last two weeks. But that's not going to happen. You're probably going to find out, "Hey, this is an interesting approach. I'm not sold yet, I only did it once, but this was interesting. We saw people talking more. I got something out of it. Let's give it a try."

So it doesn't have to be this lifetime commitment. You don't have to say, "I'm doing this forever." You start out, you do it a Sprint or two at a time, and then you can evaluate. "Do I want to keep moving forward?" A hallmark of Scrum is continuous improvement so somebody who starts this, a leader who introduces this into their organization, they're not going to get it right because there is no right. There is just better and better. So they're going to try it, hopefully see that it worked reasonably well, do it again, make a couple of changes to make it better, and we improve over time.

Rachel Salaman: Mike Cohn, thanks very much for joining us today.

Mike Cohn: You're welcome. Thank you for having me here.

Rachel Salaman: Mike has put together a page of free resources on Agile and Scrum for any listeners who would like more information and help. You can find this at www.mountaingoatsoftware.com/mindtools.

I'll be back in a few weeks with another Expert Interview. Until then, goodbye.