About this podcast episode

Scrum and project management are not at odds with each other. Today, Nader K Rad introduces Scrum and the differences between predictive and adaptive systems on the Agile in Action with Bill Raymond podcast.

While sharing these concepts, Bill and Nader share stories and examples that will help you learn:

✅ The basic concepts of Scrum

✅ How Scrum compares to predictive systems

✅ Scrum ceremonies

✅ Scrum roles

✅ How to choose between predictive and adaptive systems

Transcript

(transcripts are auto-generated, so please excuse the brevity)

Introductions

Bill Raymond: Hi and welcome to the podcast. Today, I’m joined by Nader K Rad. Author, speaker, and trainer. Hi, Nader, how are you today?

Nader K Rad: Hi Bill. Thanks, I’m fine. Thanks for having me here.

Today’s topic

Bill Raymond: Great. And we’re going to be talking about what is SCRUM and creating an environment to support SCRUM. And this is actually a two part series, and this is the first part of that series. Before we get into that conversation, could you talk a little bit about yourself and what you do?

About Nader

Nader K Rad: Ah, well, so I work in the project management field. I try to help people have better projects in many different ways. I actually started as a project planner in construction projects. Then I entered bigger projects, process plan projects, and in parallel, I also had software development projects. So yeah, I gradually moved from a project planner into someone who’s mainly focused on whole idea of how projects are run.

Nader K Rad: Nowadays, I’m mainly focused on helping, contributing to different systems. I’ve worked with The PMBOK Guide, The Seventh Edition, I was part of the team. I was a reviewer for Prince2 What I really love is to think about systems, the methods of working.

Bill Raymond: That’s great.

Bill Raymond: And I think one of the interesting things, and one of the reasons for why I wanted you to come on the podcast is because there are a lot of project managers in that traditional sense. You mentioned that PMBOK, The Project Management Body of Knowledge. That’s from the Project Management institute or PMI.

A lot of us grew up on that, you know, us folks that, you know, kind of grew up in the nineties, dealing with large scale projects or in construction projects, as you said, where there’s these traditional, what we might also term, waterfall methods of working.

Bill Raymond: And there are some standards and practice around that, some concepts of a project management lifecycle. But then there’s also Agile. And one of the things that I was excited about having you on here for, was to talk about the sort of differences between SCRUM, which is a very Agile-focused way of working and project management.

Bill Raymond: So as we go through this, even though we’re going to be focusing on what SCRUM is, there’s I’m sure some good differentiators that people might be interested in if you do come from that project management world.

Bill Raymond: But what I can guarantee is that there’s going to be lots of shortened words that mean bigger things. Yeah, we’ve already gotten into it. PMBOK was one, PMI was another, and SCRUM, and so we’ll get into these as we go through.

What is SCRUM?

Bill Raymond: Before we dig into this, let’s start at the very beginning and just talk a little bit about at a high level, what is SCRUM and the problem that it is trying to solve?

Nader K Rad: SCRUM is one framework that is agile. It’s one way of being agile. So, before talking about what a SCRUM is, I really strongly believe that we should talk about the concept of agility. What it really is.

Nader K Rad: There are two main ways of creating a product. One of them is, maybe I can give examples. Imagine you want to create a piece of software that will be used on a Mars rover. You want to send a rover to Mars and you need to have a piece of software, okay? It must be really challenging. I was not part of the team and I’ve never read anything about the way they worked, but it must be really challenging because, think about all the things that can go wrong in an environment you don’t know at all, you cannot have any assumptions. It’s really crazy.

Nader K Rad: So you also don’t have any opportunities with trial and error. You have to build it perfectly. If you make a mistake, the rover will be there, will be sent there, it’ll land there, and it won’t be able to work. So you’ve lost a lot of money and time. So what do you do?

Predictive Approach

Nader K Rad: You just sit down, think about every possibility, think about every aspect of the work and design something that can really satisfy all of those things.

Nader K Rad: That’s what we call a predictive approach. In a predictive approach, you try to predict everything. And based on that, you will design your products. And based on the design, you will plan the product and then you go on with your project and build that product.

Adaptive Approach

Nader K Rad: So in practice, we’ve been trying to use predictive methods for these, thinking about every possibility, but we’ve realized that it doesn’t really work because we cannot predict people. What can we do instead of that? We can have an adaptive approach, meaning that instead of designing everything upfront and then building that product, which we hope is perfect, we just go on, create a small subset of the product, show it to the real end users or representatives of end users. And then we collect feedback. And when I say, collect feedback, it’s not limited to asking people what they think about it. That is a part of it, but that’s not the most important part. The most important part is to observe people and see how they are using the product.

Nader K Rad: **That’s the best type of feedback. And then we use that feedback to guess what can be the best next step. **

Nader K Rad: So again, this is important. If you build something and generate feedback and use that feedback to improve what you’ve already built, that’s not adaptive. That’s just what you have to do, and that happens in every project.

Nader K Rad: In an adaptive system, the main thing we do is use that feedback to think about the future, and find our way. We will use that to let the product gradually form. Instead of using the prediction, we will use the feedback we collect from our environment and adapt to our environment.

Nader K Rad: Think about what happens with life on earth, the evolution of different animals. It’s more or less like that. They’re living, they have different actions and reactions with their environment, and based on that, they change. That’s really what happens in an adaptive method.

Agile is an Adaptive Approach

So basically, Agile is a different name for an adaptive approach. When we say, Agile, we mean an approach that is adaptive. It’s using adaptation and feedback instead of prediction. And those other terms that many people use, you also use them, traditional or waterfall. They are names for a predictive matters. I never use those terms because they have a negative connotation.

Nader K Rad: When we say "traditional," it’s a little bit biased. And we really like to think of both of them as valid and useful approaches. We really have to take a look at the product we are creating. They’re not all the same and some of them need a predictive approach and some of them can really benefit from an adaptive approach.

Bill Raymond: I was talking to a person in the construction industry, and she said, you know, there’s some good ideas here, right? Because this concept of iteratively designing, but that these iterations you’re usually actually building something. And she said, you know, you can’t go from three floors to eight floors and just expect that to happen just because you had a meeting and everyone said, yeah, let’s do that.

But you know what she did say is, where these types of ideas can come in handy is when you are putting people in the building, right? So think about, you know, building an office building, you know, every single company that comes into those offices will have their own unique set of requirements. They might want the large office spaces to be closed in, so that the executives have their own spaces, where it used to just be open space, and things like that.

Bill Raymond: So you get to play in that more iterative space,or adaptive space, when you’re filling people into the building, where you have to remain much more predictive while you’re putting the building up.

Nader K Rad: Actually, I’ve seen one project. It was for really large office building and they actually used an adaptive approach for that phase of forming different sections of that building and moving people there. And it was perfect, it was amazing. It was a textbook example of how you can do that.

Nader K Rad: For the construction itself, no, we just cannot do that. But I should mention something. We should not confuse two different concepts. One, is implementing a method and using that for running the project, and the other thing is being inspired by something. So nothing stops a project manager who works in construction project to go read about agile methods and come up with three or four great ideas to be inspired for a few changes that can really help in their predictive method. That’s amazing, that’s really great, it should happen. But that’s different from implementation.

Different Methods for Being Agile

Nader K Rad: There are different methods for being agile. What I described about adaptive methods, that’s the overall idea, right? That’s not something you can use in your project. That’s the idea, and now you have to see, what should I do in order to be adaptive? And the answer to that is a method, or if you want to call it, the framework. And there are different methods for that, and they are not all the same.

Nader K Rad: Yeah, so do you want to talk about the SCRUM?

The Core Elements of SCRUM

Bill Raymond: Yeah. I think what would be useful is, to kind of just go through the major elements of SCRUM. So if someone says that they want to implement SCRUM, we won’t get into the change management aspect of it, but what are some of the elements, that you need to learn, the core elements of SCRUM so that you get a general understanding as to what it is?

Nader K Rad: Yeah. Or maybe we can say, how does it look like after you’ve successfully implemented it?

Bill Raymond: Sure. Yeah, that sounds good.

Nader K Rad: Yeah. So, you remember I mentioned that in adaptive systems, you want to repeat everything. You create a subset of the product, you show it to a few people, representatives of users, end users or real end users, and collect feedback, the feedback that you can use for the future of the product.

Nader K Rad: So we keep repeating again and again and again.

Iteration and Cycles

Nader K Rad: The way we are creating the product is iterative. We have cycles, and that’s why all agile methods have cycles in every layer of them. That’s the fundamental part of these methods, although it’s not limited to agile methods, and for example, Prince2 is also based on cycles.

Nader K Rad: For P three express is based on cycles, the PMBOK Guide can have cycles if you really, really push it. But by default, it doesn’t have cycles.

Nader K Rad: But anyway, so in a SCRUM, you repeat those cycles and they are usually a few weeks. It shouldn’t be more than one month. So you decide what it has to be, one week, two weeks, three weeks, but we prefer to keep it fixed because we don’t want to keep thinking about it every time. We want to create a routine. We don’t want to spend time thinking about the way we run the project, but we want to spend our mental energy and our creativity and creating the product. So cycles are really good ways of doing that, making everything a routine.

Sprints

Nader K Rad: And those cycles in a SCRUM are called the "sprints." So we create the product one sprint at a time.

Nader K Rad: At the beginning, we spent some time thinking about the subset of the product that we want to create. Based on all the feedback that we collected before, what seems to be the best next step for us? You spend, for example, one day or half a day for the whole team together. You think about that and you define it for yourself. And in case names are important, you put it in an artifact that is called " sprint backlog ."

Nader K Rad: But because I’m going to keep it short, I won’t go through all the artifactsSo, you plan your sprint and then you start working, and you go on until the end of the sprint. When you reach the end of the sprint, you have one meeting to go through everything you’ve created, with your customer, if you have external customer or the customer side of your company. Because even if it’s an internal project, you still have some people, for example in, I don’t know, sales and marketing, who have the customer nature. So you get together and you will review the product that you have created, the new version of your software.

Nader K Rad: You stay together, you let them work with it a little bit and you collect some feedback. That is only one official way of collecting feedback, but not the only one. You keep collecting feedback all the time. And when you are done with that, you will have another meeting, which is very useful I believe, that’s called the "sprint retrospective."

Nader K Rad: We get together with the team members, think about everything you’ve done during the sprints and the ways you can improve your way of work for the next sprint. It’s a really good idea. Each time in each cycle you have, you pause for a moment, you think about everything that happened and you think, okay, what’s the one thing I can do differently next time to be better?

Nader K Rad: then you do that in the next sprint. One or two things. Yeah, so that’s how it works. You go to the next sprint, create the next version of the product. There are details, there are sometimes variations depending on the source that you have in mind for a SCRUM and so on. There are also a few roles that may be interesting for people.

Feedback Will Become Features

Nader K Rad: So when you collect feedback, think of a piece of software. That feedback will be converted into features that you can have in your product. For example, you’re watching people, you’re watching 20 different users who are using the application and you see that there’s a common difficulty for them.

Nader K Rad: And then you see that if I add this one simple feature, all those users will be more comfortable using my application. So they will be happier, they will buy more of this application and so on. So that feedback which you’ve collected will be converted into a feature.

SCRUM Product Backlog

Nader K Rad: What are you going to do with that feature? In a SCRUM, we have a list of features and whenever we can come up with a new idea, we will add it there. And its name is "product backlog." It’s a backlog of the features we have considered for the product. Everything I’m saying here about this SCRUM, I don’t want to go through the details, so it’s not 100% precise, but it’s good enough for someone who doesn’t know a lot about this SCRUM. It’s about having an awareness of what the SCRUM is, okay?

Nader K Rad: So that’s the concept of product backlog.

Choosing Product Backlog Items for a Sprint

Nader K Rad: It can become a really long list of different features, and at the end you may decide to cancel many of them. It’s like the to-do list that many of us have. And each time at the beginning of each sprint, when you want to create your sprints backlog, which is the list of things you want to do in the upcoming sprint, you actually bring them from your product backlog. The question is how, which one do you pick?

Nader K Rad: Normally, naturally, you would sort the items in your product backlog based on how important they are, how difficult or easy they are. You can think of it as return on investment. Something that is more or less useful but on the other hand, it’s really easy to implement can go really up, because the return on investment is high. But something that is very useful, but extremely difficult to build, may go in the middle, because the return on investment is not so high.

The Product Owner

Nader K Rad: Now, when you have a list like this, and the idea that you need to be in touch with some of the people in the client side who have expectations, because even though most of the useful feedback comes from the end users or end user representatives, we still have a customer in most projects, either internal or external, and they have their own expectations.

Nader K Rad: And any person who has worked in projects knows that when there’s more than one person in the customer side with expectations, there will be lots of inconsistencies. So it becomes a challenge to talk to all those people, removing the inconsistencies, keeping all of them, happy, collecting the information and so on.

Nader K Rad: So in a SCRUM, there’s this one role who’s responsible for most of these things. And the role is called "product owner." So the product owner is like a hub of communication between the team and the outside world, not as a gate, but as a facilitator. The product owner goes to the customer, talks to them, may talk to end user representatives and many more.

Nader K Rad: And it’s the product owner who’s responsible for creating, updating and sorting the product backlog. But when it comes to creating the sprint backlog, the best plan depends on what we can do during the sprint, and therefore the developers must be involved. So it’s not like the product owner telling developers, this is what you have to do in this is sprint. No, they all do it together, they decide about all of that.

Nader K Rad: And then something else here is that we have a process here for working SCRUM, our framework, and in order to make sure that we are using it properly, we have another person who’s expert in a SCRUM, and that person can tell everyone, okay, you seem to be missing that thing or this thing, it’s time to do this, or don’t you think it would be better to do it in this way in order to be really adaptive? For example, you are blocking your adaptation by doing this thing upfront. That person is called a "SCRUM master."

Nader K Rad: And the SCRUM masters have a few extra responsibilities as well. They are for example, responsible for facilitation in many cases. And that’s mainly because the type of person who’s process oriented is usually a good candidate for being a facilitator. These things usually come in the same type of person.

Nader K Rad: Yeah, so that’s it. Those are the people, and that was the lifecycle of the SCRUM project. And at the end of each sprint, we have one new version of the application with a lot of opportunities for collecting feedback and using that feedback to see what we can do the next.

Summary

Bill Raymond: It’s a wonderful overview, I appreciate it. I appreciate the conversation around this being a adaptive framework where, I think you use the term lifecycle, but it’s adaptive. And we understand the difference between that sort of predictive, where you’re doing all the planning upfront versus adaptive, where you’re doing all of this work in iterations. Those iterations are called sprints.

Bill Raymond: In order to define what you want to do on those sprints, you have a product owner who helps facilitate the collection and prioritization of the requirements. And then the team can work on those, hopefully with a lot less interruption over the course of an iteration.

Bill Raymond: And then just to make sure that we’re all on track and that we’re all making sure that we’re closing out issues and keeping things going, we have a SCRUM master to support that.

As we talked about in a SCRUM, we have only the developers, the product owner and the SCRUM master and we don’t have a

###

Nader K Rad: project manager.

Nader K Rad: And what happens here, doesn’t mean that we don’t have project management, it means that there’s no single person who’s responsible for project management. But the project management’s responsibilities are distributed among those three roles. And a SCRUM doesn’t want to have a project manager. But that’s only SCRUM, that’s not agile. And many people mistake it.

Nader K Rad: When people think that when you are agile, you should not have a project manager, which is absolutely wrong. That’s because the only thing people know about that agile is SCRUM. There is nothing wrong with having a project manager in an agile method. And for example, DSDM has a project manager, There are different methods and for people who are interested, I really recommend learning about more than one of them.

Bill Raymond: that makes sense. I think that’s really important, you know, the roles and the purpose of the roles sometimes change dramatically, depending on the type of work that you’re doing, but it does not say, well, this is some new way of doing things, so therefore your role is now obsolete. That doesn’t happen in this agile space.

Bill Raymond: However, the what you do, the actions that you take, the expectations that are on you, could change quite a bit.

Nader K Rad: Yeah, that depends on the metric that’s being used. What a project manager is, we have an overall idea, but what it really is, depends on the project management method that we are using.

Bill Raymond: I really appreciate that, thank you. That was time well-spent on that one. And maybe we can even get into that in the conversation around implementing SCRUM within your organization, because that does introduce new and changed roles. As we wrap up Nader, is there some way people might be able to reach you if they want to talk to you about this further?

Nader K Rad: Yeah, sure. I’m relatively active on LinkedIn, and that’s probably the best way of contacting me. I’m not active in Twitter or other places like that or Facebook. Just LinkedIn for me. And there’s also my website. People who prefer to send an email or something like that, they can find it in my website.

Bill Raymond: Yeah, and we found out about you, of course, I’m almost going to call you a serial author. I think you have written 40 or 50 books or something like that, but actually we found out about you by your book. It’s called Agile SCRUM Handbook an excellent book, and it’s a great introduction to all of the concepts that we’re talking about here today.

Bill Raymond: So we’ll provide a link to your LinkedIn account, your book and of course your website, and I’ll make sure that those are on the AgileInAction.com website. Just look up the conversation with Nader K Rad, and it will also be right there in your podcast app that you’re using right now. Just scroll down to the show notes or the description, and you’ll see those links there. Nader, thank you, and until the next podcast, have a great great day. day

Nader K Rad: Thanks Bill, it was great talking to you