About this podcast episode

Whether you are delivering products or projects, agile delivery with Scrum can work. But how do you do it successfully?

Today’s podcast is the second of a 2-part series with Nader K Rad, who shares the core concepts of Scrum.

Bill and Nader share ideas and stories to help you learn:

✅ A recap of the primary Scrum roles, artifacts, and meetings ✅ How to know if Scrum will work for your organization ✅ The importance of leadership in the change process ✅ Common challenges you will face ✅ Important takeaways if you want to start your Scrum journey

Transcript

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

Introductions

Bill Raymond: Hi, and welcome to the podcast. Today, I’m joined again by Nader K. Rad, author, speaker and trainer.

Bill Raymond: Hi Nader, how are you today?

Nader K Rad: Hi, Bill. I’m fine, thanks. How are you?

I’m doing great, thank you. We’re actually on part two of a two-part series with you, and the first one was an introduction to SCRUM where you shared the difference between predictive and adaptive systems and shared the concepts around SCRUM.

Bill Raymond: So if you really want to get the best value out of this podcast, go back and listen to part one. It’s titled An Introduction to SCRUM: Predictive vs Adaptive Systems.

In today’s episode

Bill Raymond: Today, we’re going to talk about implementing SCRUM and agility, and I think those go hand in hand.

Bill Raymond: But before we get started, it would be good, just in case you are listening to this podcast right now and you’d like to get a quick overview because you want to listen to this and you’ll go back later to part one, Nader, could you just share a quick overview of SCRUM and predictive versus adaptive systems?

Quick overview of SCRUM and predictive vs adaptive systems

Nader K Rad: Yeah, sure. SCRUM is a simple framework. It’s a minimalist, simple, non-proprietary one. And it’s a very interesting one. There’s a reason it’s been so successful. It’s probably the most popular one. And most of the other things that we have nowadays are heavily inspired by SCRUM. What happens inside a SCRUM project is that we go on with our work one sprint at a time.

Nader K Rad: Each sprint is a fixed duration partition of time, one month, for example, or two weeks. It shouldn’t be longer than one month, and it gives us a cadence on what we do. Makes everything more routine. And inside that one month partition, we have certain things we have to do. We don’t have to think about what is needed every time. We will just follow a simple cycle over and over again, and instead of thinking about how to do the work, we will focus on the technical part, on the more creative part, if you will.

Planning

At the beginning of each of those sprints we’ll have a short planning meeting. And it’s important, some people think that in agile we don’t have planning, which is not correct. We always have planning, but the type of planning we have is different. It has to be compatible with agile approach.

Nader K Rad: So in our planning, what we do is that we go and review the list of things we have considered for our product. We want to create a product, we come up with different types of ideas. Most of them come from the customer, but sometimes we also come up with things that compliment them.

The product backlog

Nader K Rad: They all go into a really long list, it can be long. And that list in a SCRUM is called product backlog. And What we do is that there’s one person who’s responsible for taking care of that list. It’s a person who’s focused on the business aspects of the product we create. That’s the person who talks to the customer a lot and also is in touch with the developers, explains what each of those items mean, and that person is called product owner in a SCRUM.

Nader K Rad: There are similar roles in other methodologies and frameworks, they may have different names.

Nader K Rad: So the product owner makes sure that we have a good enough product backlog. It doesn’t have to be perfect and it doesn’t have to have every possible item. It’s adaptive. We go on and we will discover more items.

Nader K Rad: So we never want to stop for a long time at the beginning and try to discover all the possible things we are going to need in the product. We will just go on, start with a simple product backlog, and when we create the product on a step by step basis, what we create helps us and the customer to come up with new features, which will go to the product backlog again.

Spring planning meeting

Nader K Rad: Now, what happens in the sprint planning meeting, which is the first thing we do in a sprint, is that all of them together will check the product backlog, the top of the product backlog, and that’s because the product owner always orders the items in the product backlog. The more important items, those that create more value will go on the top.

Nader K Rad: So instead of going through the whole product backlog, we will focus on top of the product backlog. We make sure that we havea correct understanding of what those items are. And then the developers check to see how many of those items they can deliver until the end of the sprint.

Nader K Rad: And now, there’s something special in SCRUM, which is actually very interesting, and it’s that if you have a really huge list of items, think of your to-do list, it becomes really frustrating. Each time you take a look at it, it’s just scary. So instead of using the product backlog all the time, we take out those items from the top of the product backlog and put them in a smaller list.

Sprint backlog

Nader K Rad: And that’s the list we’re going to work on during the sprints. And the name of that list in a SCRUM is sprint backlog. Very simple. It creates more focus, it makes it easier for the developers. They create that, and there are a few other things they do, and that’s basically our planning for the sprints.

Bill Raymond: So for the planning piece, I just want to recap what I think I heard here is that first we have this product owner who has a really tight connection with the end customer. To make sure that they understand what they’re looking for. There’s a sprint planning meeting and all those things that they’re looking for rather is, it’s a giant list.

Bill Raymond: It’s called the product backlog. And then when you go into a sprint planning meeting, you find the highest value items, I think you said the top of the list, the highest value items that the team believes they can complete in a sprint, and you start implementing those as part of your sprint backlog.

Bill Raymond: So there’s a giant list of things that everyone wants, and then there’s the smaller list of what can get delivered for that period of time.

Nader K Rad: And having that list really helps, that creates focus. And there are certain things here. For example, ordering the product backlog it’s only the responsibility of the product owner, no one else. Other people can give suggestions, but it’s ultimately the product owner who makes a decision.

Nader K Rad: But deciding on the number of items that developers want to pick for the sprint backlog is completely up to the developers. Not someone else telling them, Oh, come on, that’s only 10 items, you can do more, pick more. But they can give suggestions or anything, but they have to respect what the developers say.

Nader K Rad: So yeah, that’s planning, very simple, but still we need it.

Start working on the project

Nader K Rad: And then they start working on the project. They go on for the duration that they’ve set for the sprints, and we don’t change that duration all the time. We can see, for example, maybe they start with one week of sprints and then they realize that it’s too short, they cannot finish bigger items. So after a while, they may decide to turn it into two week sprints, and that’s okay, that’s absolutely fine, but we don’t decide about it each time.

Nader K Rad: We prefer to have fixed duration sprints that are all the same, because if you want to decide about it every time, it’ll be extra cognitive load. And why do we want to do that? We want to spend our energy on the product.

Nader K Rad: So we go on working on the items, preferably one at a time. Well, depending on the number of items. Maybe each one or two developers want to start working on one item. But we don’t work on all of them in parallel, we try to limit it and focus on finishing things instead of starting things.

Daily SCRUM meetings

Nader K Rad: And in that normal work during the sprint, one extra thing we have in a SCRUM is a daily meeting.

Nader K Rad: It’s a very common thing in all agile systems. The general term for it is daily standup, and in a SCRUM we call it daily SCRUM. It’s a 15-minute meeting and we prefer to stand up, because when you stand up, you keep it brief and we really have to make it brief. And each developer, traditionally, they answer three questions.

Nader K Rad: What I’ve been doing since yesterday, what I’m going to do until tomorrow, and what problems I may have.

Nader K Rad: And when someone mentions problems, we don’t come up with answers at that point because if we want to do, the meeting we’ll never end in 15 minutes. So we’ll just listen and if you have solutions for that problem, we can do it after the meeting.

Nader K Rad: This is a special meeting that helps people be aware of what’s going on in the project, to align their work with others, to be synchronized. So we go on like that, and when we reach the end of the sprint, it doesn’t matter how many items we’ve finished, we always end the sprints on time. That’s extremely important.

Nader K Rad: We will end it with any number of items we finished. If something is not finished, even if it’s 90% done, we will return it to the product backlog. And those that are finished will be part of the latest version of the product.

Sprint review

Nader K Rad: Now, we will have two other meetings at the end of the sprint. One is a sprint’s review.

Nader K Rad: That’s where we also call the customer. We will review the product together. We will show them what the product is, how it works, talk about different things about the future features and so on, and we receive feedback from the customer. And that feedback will be a lot of times translated into new items for the product backlog or changes into the existing items in the product backlog.

Nader K Rad: Although it’s important to say that the sprint review is not the only time where we receive feedback from the customer. We prefer to do it continuously, to do it all the time.

Sprint retrospective

Nader K Rad: After sprint review, we have one other review, one other meeting, which is also very interesting, it’s a sprint retrospective. That’s where the team members get together and check to see how they can work better the next sprint. can we do differently in order to work better, to be more efficient, to have higher quality, or be happier at work?

Nader K Rad: And they try to come up with one or two items. And that’s what they will try to realize in the next sprint.

Nader K Rad: So that’s basically what the sprint is in a SCRUM. I mentioned the events, the sprint itself is like an event, which is time-boxed and it’s maximum one month. And I mentioned four other events and they are also time-boxed. I didn’t mention the time boxes before, but they are. The sprint planning at the beginning is maximum eight hours, daily SCRUMs 15 minutes, sprint review and a sprint retrospective at the end. Together, they are also about eight hours.

Nader K Rad: I also mentioned a few artifacts, there’s the product backlog, which is the big list of everything we want to have in the product, which gradually grows and we add more items to it. And there’s the small list we have for the sprints, for the current sprints, which is called the sprints backlog.

Nader K Rad: And maybe I should mention it here. I’ve seen some people who sit down at the beginning of the project and create the sprint backlogs for all the sprints. That’s not right. That’s not adaptive. We have to do it one sprint at a time because we want to collect feedback and use that feedback to see what we have to do next. So one sprint at a time. That’s really the nature of SCRUM.

Nader K Rad: So the first artifact is product backlog. The second one is a sprint backlog, and also the product that we create, the increments of the product. That’s also some type of artifact. There’s also the concept of definition of done because we really want everything that we create to be done, to be completely presentable, releasable. Because that’s the only way we can collect proper feedback from the customer and end user representatives. So we define what we mean by being done. For example, do you also include documentation or is it only the functionalities? And for the functionalities, what type of tests do you have and so on.

Roles in SCRUM

Nader K Rad: last concept in a SCRUM is the roles. And we have three roles, I’ve mentioned two of them. One of them is the product owner. That’s the person responsible for the product backlog, for ordering the product backlog based on value, and in general, the product owner’s responsibility is to help maximize value.

Nader K Rad: The other role is developers. We have a number of developers in the team. Programmers, UI designers, maybe architects, maybe anything else. Anyone who contributes to the actual product will be called a developer. And there’s a third role, and that’s a role which has a different responsibility. Now think about everything we talked about right now.

Nader K Rad: There’s a certain way of working. There’s a certain process, and we also need different types of techniques to work properly here. If we leave it to people who are involved in that process, there’s a chance that they may forget something. They may be too busy with the work, with the deadlines or something, and forget about a few important things.

Nader K Rad: So it’s always a good idea to have someone who’s experts in the way of working, in the way SCRUM works, to be there and make sure that people are doing it properly, and if they have a problem help them solve that problem and so on. So there is a role for that, and it’s called a SCRUM master. All right, so I think I covered everything. Did I? Because I don’t have notes. I’m just improvising.

How do you implement SCRUM?

Bill Raymond: I think you’ve covered it very well. Really, what we’re talking about here, when we talk about this framework, as you can see, it’s actually pretty straightforward. There’s a few specific roles. You’re working with a small team and you are delivering on a regular basis. You’re doing your planning on small cycles, iterative cycles, and the team is responsible for making most of the decisions that go into the product.

Bill Raymond: And so from there, that’s kind of what it is. I think what’s interesting, and one of the key topics for this podcast is now, how do you go about implementing this?

Bill Raymond: Because I think there’s sometimes this concept that, Oh, all we need to do is just say, we’re going to do SCRUM now, and actually you can do that. I’ve seen organizations just start by saying, Okay, we’re going to time box our work into two week sprints, and we’re going to have standup meetings 15 minutes every day, and we’re going to do this planning thing, and it starts off that way.

Bill Raymond: However, one of the challenges there is very often we get lost in doing SCRUM, and we’re not necessarily thinking about how it’s going to improve our overall standing as an organization. I think it would be useful if someone says, you know what? I haven’t done SCRUM in my organization, I am interested in implementing SCRUM. What are some of the thoughts that you need to go through in order to do this effectively?

Simple is not always easy

Nader K Rad: Yeah, well, SCRUM is simple, but it’s not easy. Simple is not always easy. Starting to use SCRUM and implementing it in an organization, it’s a big change, it’s a really big change because it involves a shift in culture in the way people work. It’s not the common way of working, to be honest. It’s a creative, innovative way of working, which is different from the way many companies are used to.

Nader K Rad: And as you said, we have this huge problem. There are many companies who think that or claim that they are using SCRUM. But all they do is they just use the labels and have the rituals. That doesn’t work. You can have certain meetings and give them names and give certain labels to people, it doesn’t make a real change.

Nader K Rad: The real change is to have adaptation in the project, to be responsive to the environment and understand what SCRUM really is about. To understand what happens behind the scenes. The problem is that people just look at what some successful company is doing and they try to imitate it,

Is SCRUM a good solution for everyone?

Nader K Rad: I think the first step is to decide whether or not SCRUM is the right solution for them. And it’s an important step. We cannot assume that it’s the right solution because many people are talking about SCRUM. First of all, we have to be careful about the product we are creating.

Nader K Rad: Some people would say that SCRUM and agile can be used for creating any type of product. I personally don’t agree with that. Some products require a predictive approach, but some products, like most of the IT development products are really, really good options for having adaptive projects. So that’s the first thing. Check to see if they can use SCRUM.

Nader K Rad: And the other thing, SCRUM is for one small team, about 10 people or so. If you have projects with a lot of people, with 50 developers or so, SCRUM is not for that type of project. There are frameworks that scales SCRUM up for bigger projects, but they are different frameworks.

Nader K Rad: So instead of using SCRUM, you have to use one of those scaling frameworks. And in order to use them, you still need to understand SCRUM, but what you implement won’t be SCRUM. This would be that other framework.

Nader K Rad: And this scaling, doesn’t happen automatically. There are lots of challenges that people have to overcome in order to use that in a bigger project, and those frameworks are trying to solve those problems.

Nader K Rad: So if you have bigger projects, instead of trying to reinvent the wheel and find how to use a SCRUM in a bigger project, just go and use one of those scaling frameworks.

Nader K Rad: Now, if you have a small enough project, your projects are small enough for SCRUM and the product is suitable to it, well, you can go on with it, but there are still a few other things.

Nader K Rad: For example, is your whole company okay with it? Are the managers going to accept it because the management layers in the company should support the way SCRUM works.

Nader K Rad: For example, we want to give the product owner the authority to order the items, meaning that we don’t want any higher manager to go and change it.

Nader K Rad: We also want to give the developers authority to make certain decisions. We don’t want anyone else to go and override those decisions. If they do, it won’t work properly. So, are they okay with it? Do you need to train those people? Do you need to talk to them?

Nader K Rad: And there’s also something else that I find to be important. It’s about the developers that you have. Some people may not be comfortable in the SCRUM setup. It’s an interesting setup, but it expects more from developers. It expects them to have a role in the management of the project, and not everyone is okay with that. They don’t want to take responsibility in that type of thing.

Nader K Rad: They just want to focus on their specialist activities. That’s okay, but that’s a different thing. But if most of your developers or all of them are like that, then you will have problems using your SCRUM, I think. I believe that’s the first step, if you will, to examine what the environment looks like.

Nader K Rad: Would you like to add something here, Bill? I know that you have experience in this area a lot and you probably have a lot of things in mind.

one of the biggest struggles that I had when I started looking at this shift towards agility, and of course SCRUM always comes up, which is why we’re doing this season of SCRUM in this following Winter season. This is a framework that comes up frequently, and it’s so easy, we talked about this already, there’s just a few roles, a few artifacts, a few meetings, and you’re kind of up and running.

Bill Raymond: But really, what’s said in the background it should be said in the foreground, it should say, is the role of the manager.

Bill Raymond: And this is something that took me a long time to kind of get, and it does take change in an organization.

You sort of said it already, which is that, you know, the product owner and the product team, they get to decide what happens. **If you’re in an organization right now, where you basically have a team and they’re coming to you saying, Okay, what do I do next? And or you are one of those types of managers like me that loves to just say, here’s what I’d like you to do next. And you start giving them that backlog, then they don’t have ownership of it. **

Bill Raymond: And one of the key tenets I think, of having a successful SCRUM implementation or agile implementation is that you’re giving the power to the team to make these decisions. And the product owner, for example, is part of that team.

Bill Raymond: So you shouldn’t be, if you will, and I’m going to use this word, it might be a little bit of a strong word, but you don’t want to corrupt that team by inserting yourself as a leader, as a manager, into that team and telling them what your expectations are. It really needs to be coming from the customer, working directly with the product owner, and working directly with the team.

Bill Raymond: And if you think that’s something that is counter to your organization, then you’re really going to want to have to focus on that in a very significant way because these roles are going to change.

Bill Raymond: I would also say that there’s no formal project manager in here.

Bill Raymond: You know, we talked about the SCRUM master concept. The SCRUM master is there to help with the team, align the team, help them improve. But there is no such thing as a project manager in this role. There can be project management, and we talked about that in part one.

Bill Raymond: So one of the things that you might be thinking right now is, well, we’ll just do SCRUM, but actually, we have to think about that from a management perspective first, what are our expectations?

Bill Raymond: And then what are also, the thing that you need to think about as a manager, as a leader is something different, which is how are we going to get a competitive advantage out of this?

Bill Raymond: Okay. Sure. We do that SCRUM thing, we do these meetings, we do this iterative development. What do I expect out of this to be different? And that’s where you start to think a lot more differently, a lot differently about what it is you’re trying to do in your organization. You start thinking about a product-focused organization.

and I’ll give you a moment to share your thoughts Nader, but we’ve been talking about developers, but I do want to highlight, you know, throughout this podcast, we’ve had successful implementations of this concept of agility and using SCRUM methods and ideas in HR, in manufacturing and research and development, where it’s not developers, it is small teams of people working together, that constantly are producing for the organization. And when we think about that, that really makes us think about, do we have the right roles in our organization? And what is the definition of those roles?

Bill Raymond: If you’re thinking, well, I’m just going to take this project manager and make them a product owner. I’m going to just take this software developer and say, now you’re a SCRUM master. That may or may not work, so you really need to think about what the titles are for those roles. So I said a lot, but what I’m getting at here is that from a management and an executive level, you need to be thinking internally just how much change needs to happen.

Bill Raymond: And also you need to be thinking about, do I need to reorganize? Do I need to think about the teams in a different way? And do I have the right people? Before you jump too quickly into this.

Nader K Rad: Yeah, that’s correct. And also something important is that we are talking about what happens inside the boundaries of projects, but those projects are within the whole context of an organization and there are other layers of management, and all of them have to be working there. So for example, sometimes you see that there’s a company with 100 developers working on 50 projects at the same time.

Nader K Rad: So it doesn’t matter how you run your projects, they will never work well. And that’s not a problem with the way you work inside your project. It’s a problem with your portfolio management system. That’s where we select projects and run them. You have to target that problem in that layer and fix it there instead of trying to fix it inside the project.

Nader K Rad: Many people say, Okay, that’s a problem, let me fix it in my project management system. And then they introduce really complicated time management systems where people are tracked by hours and so, and it never works because the problem has roots in a different layer. So that’s an important thing.

Nader K Rad: And for the roles?

Distributed project management

Nader K Rad: Yes. As you mentioned, I forgot to say, that that’s usually a question people have. There is no project manager in SCRUM, we always have the concept of project management, but in a SCRUM we have distributed project management instead of centralized project management. A centralized project management system has someone in the center who’s called a project manager.

Nader K Rad: These are two different systems. SCRUM has decided to use decentralized, and the whole framework is created in a way that needs it and supports it. So people should not add project managers when they use SCRUM. I know that some people do, but they really shouldn’t. It won’t be a SCRUM anymore.

Nader K Rad: And also it doesn’t mean that having a project manager is against being agile. That’s not the case. Many of the agile systems have project managers. Many of our regional first generation agile systems such as Dsdm. There’s no problem with having centralized project management. But that’s a different concept. The other thing that you mentioned, which is important is, managers in the organization causing problems. And one common problem is they go to the team members and ask them to stop what they do and start working on something else. It’s a big problem because, when people keep switching tasks, they lose their focus, they lose a lot of efficiency and we really don’t want to have that.

Nader K Rad: We want to create a safe environment, where people can really focus on a small set of items, which is the sprints backlog. And we have really short iterations. There are two or three weeks, so everyone can wait. Everyone should wait. Unless it’s really, really essential, in which case, in SCRUM actually we have this concept where we can cancel a sprint where things change so much that it doesn’t make sense anymore to continue it and start a new sprint.

Nader K Rad: But yes, they have to understand how SCRUM works and support it.

Now, something else that we have here, which is important for implementing your SCRUM is that it’s a really different way of working. And for example, as a developer, how do you create the product? How do you work when your whole database is not designed? You’re not supposed to plan and design everything upfront, right?

Nader K Rad: So your whole database is not designed, and many developers have this question, How should I work in this situation? There are answers for these things. There are different techniques, there are different ways of working, and there are people who are expert at it.

Nader K Rad: Normally, we expect the SCRUM master to be able to help.

Nader K Rad: So if a developer comes and says, it’s my first time working in a SCRUM project, I don’t know how to work when I don’t have a full design for the database, we expect the SCRUM master to be able to answer that question, or at least tell them how to find the answer. And that’s only one example.

Nader K Rad: There are many of these things. A common problem is that many companies just send someone to a one day or two day training course and give them the title of SCRUM master, and expect that person to implement SCRUM. Chances of that working well is really low. It’s really risky. It’s always better to bring, really experienced SCRUM master and use that person for the first project, and then they can appoint a few people to become future SCRUM masters and let those people learn from this person.

Nader K Rad: And in parallel, we have to also teach managers, many different managers on how SCRUM works. Yeah, these are a few other things I could think of, do you have something related to it?

SCRUM should be easy

Bill Raymond: One of the things that I definitely hear very frequently is that, Well, SCRUM didn’t work for us, and I’m going to go back to this team structure.

Bill Raymond: I have worked with a good number of companies that have implemented SCRUM and they’ve done so successfully, and then I’ve worked with companies that said, Well, it did not work. And while there’s differences all over the place as to why it did or did not work, the one thing that I noticed where it worked the best was, not only was it embraced fully by the teams, but the management team, but more importantly, the teams were really thought of in a holistic way.

Bill Raymond: And when I say change management and roles are so important, one of the things that we talked about here, and we’ve been using this example of software developers. What we didn’t say necessarily was that those teams usually have what we call a shift-left team. So there’s software developers, there’s quality assurance people, there’s testers, there’s database people.

Bill Raymond: The whole point of this team is that they are going to deliver something and they don’t need to rely on another team. They can’t say, well, we can’t get this done because we have to hand this off to this other team before it’s really done. You want to have the team be able to build everything that they need to.

Bill Raymond: And so this is kind of an organizational structure issue now that gets lost. And this is why I think a lot of SCRUM efforts fail. Is because we say, Oh yeah, let’s just take all these people and put them into a team. Yet each one of those people has a different manager and they come from a different business unit, and they’re not really part of a team.

Bill Raymond: They need to be part of this SCRUM team. There is no longer necessarily a QA department. There’s QA in the team. There might be some leader who thinks about QA, quality assurance, and thinks about some of the best practices that need to happen. There might be a leader of software development that thinks about the tools and technologies that need to happen, but it is the team that is going to be making these decisions.

Bill Raymond: And so we can’t have them just kind of coming together from a bunch of business units and hope that they all just get along and don’t have other priorities that their managers are focusing on.

Bill Raymond: I’d like to hear your thoughts on this Nader, but that’s where I’ve seen SCRUM fail is that we don’t really think about not just who is on the team, but how your organization supports that team and gets them into a place where their priorities are only those of the customer and the product owner.

I think the biggest problem in my opinion, but maybe that’s just my experience, what I’ve seen,is that in some organizations people have millions of responsibilities and working in a certain project is only one of them. In that case, it won’t be as good as we expect it to be.

Nader K Rad: It works really well when people are really dedicated to the project, their main responsibility, maybe 80% or 90% of their whole energy is spent on the project. Then they can really feel like they belong to the team. Then it becomes a real team and it can work well.

What else can you think of?

There will be failures

if you are implementing something like this, we have to expect there to be failure. And we should celebrate that. Because one of the things that will happen along the way, it’s pretty much a guarantee, as you’re looking at implementing a framework or even just changing the way your organization is structured.

These things are hard and there will be failures. And so, identify those for sure, recognize them, don’t overlook them, but celebrate them and find a way to sit back and say, this was a failure, so how do we fix it? And everyone will be very interested in fixing it because they want their lives to be focused on the great work that they do, not trying to deal with problems.

Bill Raymond: And so if you just recognize that there’s an issue and work on it together as a team, you’ll work through it. I also think that, you know, we’ve been talking about, and I know I mentioned this, you are going to really, ultimately think about how your organization is structured to support these teams.

Bill Raymond: But that doesn’t mean you have to do it all at once. And so I like this idea of gradually finding your way into working with these frameworks. SCRUM being one of them, I think you could easily start adopting some of the basic concepts, but you may not get the full value out of what your team can do right away.

Bill Raymond: This is a long term strategy that you’re thinking about. So I would say that if there’s any kind of takeaway, my last takeaway here is that if you’re thinking about implementing this, it is going to be long term. If you are any kind of a large organization where there’s a lot of red tape, a lot of people that you need to align with this can be a 1, 2, 3 year change and just like agile, things will change all of the time.

Bill Raymond: So, you will find that the things that you thought you were going to do won’t happen. The things that you thought were not important, will be very important.

Implement gradually

Nader K Rad: So just like agile and just like SCRUM, rethink your backlog, rethink how you’re going to implement and plan on this being a long term strategy, Yeah, it really has to be done gradually, and that’s not only about implementing SCRUM. It’s really about every organizational change. If you want to go with a big bang, it’s very unlikely for you to succeed because there are lots of things to work with. The culture of the organization it’s not something you can change overnight.

Nader K Rad: You have to let it absorb the change gradually and build it and train people, listen to their problems, find solutions. And also, something that is important, I think, yeah, not only about the SCRUM again, for any framework or methodology that people want to implement, implement it exactly the way it was intended without extra things.

Don’t add crazy extra techniques

Nader K Rad: Don’t keep adding crazy techniques and practices and tools and so on. Keep it as simple as possible. First, go on with it, let it take off, and then based on the feedback you received from your own environment, as you said it, it’s also adaptive. Then in response to that, make changes, not based on what you expect from the beginning.

Don’t use complicated tools

Nader K Rad: Also, about tools. I see people using really complicated tools. That’s usually a problem, even in bigger projects, even in complicated projects, usually simpler tools work better.

Nader K Rad: For SCRUM, which is simple itself, you don’t even really need a tool. You can just have a board and use sticky notes and so on.

Bill Raymond: Yeah, sure. I actually appreciate that. I think there’s lots of tools out there that allow you to manage your backlog and manage the track that work during a sprint. And it’s, you know, certainly there’s JIRA out there, there’s kanban board tools, there’s all these different things, but yeah, I’ve seen it just be just as successful up on a virtual whiteboard or some shared note list. You know, really what works for you and try not to overcomplicate it and build all these reports and creating databases to track all of this. I like your approach of just something simple to start. As the team starts to work, they’ll probably find, maybe they don’t need a daily standup, Maybe there’s a once a week standup, and maybe you’ll identify the fact that you need some tools to help the team.

Bill Raymond: But let the team drive that, you know, let the team start to realize where there’s failings in the process and adapt to it, and I think you’ll find that it is much more successful that way.

Bill Raymond: I guess the one last thing that I would say, Nader, is also that very often we do see multiple SCRUM teams. Sometimes they have very different challenges, so they might need their own tool sets and their own quirky way of doing things within their team that works for them because of the work that they do.

Bill Raymond: And so they’ll adjust and create their own extensions to whatever this SCRUM framework is that they’re using as well. But it’s something interesting to watch and it’s not something you probably want to solve for day one.

Nader K Rad: That’s the important thing. Don’t do it at the beginning and have a purpose for everything you do. That’s the most important thing, really. There’s this concept NUPP, Nearly Universal Principles of Projects, and one of the principles there is that you shouldn’t do anything unless you have a proper purpose for it.

Nader K Rad: So, for example, let’s say daily SCRUM. What’s the purpose of daily SCRUM? If the team doesn’t have a good answer for it, it doesn’t make sense, what they do won’t satisfy anything. It’ll be just a ritual.In SCRUM and every other framework and methodology, people have taught a lot about those things, and they really have purposes for those in the PMBOK Guide, Prince2, DSDM, XP, SCRUM. But if people don’t understand the purpose and only do the ritual, they won’t succeed.

Bill Raymond: I think those are some great words to wrap up this podcast. If people want to reach out to you, how might they be able to do that?

Nader K Rad: Well, my website is Nader.pm and there they can find the links for my LinkedIn accounts, my email address and everything else.

Bill Raymond: Wonderful, and I will make sure that it is on the agileinaction.com website, and also if you’re in a podcast app right now, just scroll down to the show notes, the description, and you’ll see those links there.

Bill Raymond: Nader, thank you again for a great conversation. I really appreciate it.

Nader K Rad: Thanks, Bill. I really enjoyed that as well. Thanks a lot.