Scrum for startups explained

Scrum for startups explained

Speakers: Wiktor Żołnowski, Darek Mozgowoj

Wiktor Żołnowski: Welcome to Pragmatic Talks, podcasts and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. I am Wiktor Żołnowski, a CEO of Pragmatic Coders, the first-choice software development partner for startup founders. Today, together with Darek Mozgowoj, one of our best product managers, we are going to discuss the Scrum framework. You will learn more about Scrum itself, but what is more important, we will help you understand how Scrum can help you build digital products in the startup environment. Welcome to Pragmatic Talks. Today we are going to discuss Scrum: what is Scrum, and how startups could use Scrum in their everyday work. For today’s episode, I invited Darek Mozgowoj, who is one of our Product Owners. So, welcome, Darek.

Darek Mozgowoj: Welcome.

Wiktor Żołnowski: It’s great that you joined me today. So Darek, you started as a software developer a couple of years ago, then you were a Scrum Master on the side of the software developer role.

Darek Mozgowoj: That’s correct.

Wiktor Żołnowski: And today you are a Product Owner.

Darek Mozgowoj: Yes, that’s correct.

Wiktor Żołnowski: So you had a chance to actually work in Scrum in different roles, in all of the roles, and take a look at it from various perspectives. So this is exactly why I invited you for this discussion, because I believe that your insights might be very, very valuable for everyone. The first question is if you could describe Scrum in a very short way for someone who never heard about it. So, what is Scrum in a very short form?

Darek Mozgowoj: Okay. To me, Scrum is a kind of mental model that allows teams and people to learn quickly in an environment which has a high risk. And it did these iterations, and Scrum itself helps to mitigate the risks and provide the value.

Wiktor Żołnowski: Okay, I believe we’ll talk about it more later. So, Scrum is a mental model for you. So how does it work? Are there any rules and principles?

Darek Mozgowoj: Scrum is based on something–this is the framework. The framework consists of important things which define the boundaries, and these things are the three pillars of Scrum and the five values of Scrum. And the base is most important to understand what the pillars mean and what the values actually mean in the context of building products. So that’s all.

Wiktor Żołnowski: So there are three pillars and how many values?

Darek Mozgowoj: And five. Five values.

Wiktor Żołnowski: Okay, let’s maybe start with them. So when I learned Scrum and when I am now teaching people using Scrum, the beginning is actually about the values. Because what I believe is when we understand the values, when we know what the values mean for product development, then the Scrum boundaries actually create themselves. So if you keep the values in your mind and you use the values and try to make these values alive in the teams, then everything else becomes very simple. So we just listed these values: commitment, courage, openness, respect, and focus. So if we think about those values…

Darek Mozgowoj: All of them are somehow committed to good team operation. And if we don’t have these values–so that’s the common problem actually in the market–people think that it’s enough to use kind of mechanical thinking, using mechanical Scrum, like doing some events and having some artifacts, but they don’t think about the values. And most of them, when they use it in this way, they end up complaining about Scrum, that it’s not working. And the root cause of this “not working Scrum” is because the values and the pillars are not there. So this is very important to understand and teach people to use it. And I believe that one of the main points of the work of the Scrum Master in the team is to understand the values and look for the misunderstanding of these values in the team and individual members of the team.

Wiktor Żołnowski: We will get back to the Scrum Master role as well, but you mentioned also something very, very important: that Scrum is for teams, yes? It’s not for a random group of people who are just developing something, but you need to have a team to actually work in Scrum. So what should be first, Scrum or the team? Or it doesn’t matter? Or maybe if you already have a team, it’s much easier to implement Scrum? And if you have a group of people, maybe Scrum may help you with turning them into a team?

Darek Mozgowoj: I believe both ways could be possible. When we start from Scrum, we know how the Scrum world works, and we are trying to invite people, and then we can teach them about the values and pillars and the methodology, then they can create a team. But if you already have a team, it’s also possible, I think, but the team could already have some principles which they discovered or implemented in their workday. Sometimes they are against Scrum, so they have some kind of team culture that they already have, and it may be okay. So then the role of the Scrum Master and the team is to explain to them how to fit into the new environment, because as the Scrum Guide teaches us, if we don’t do something that Scrum describes, it’s not Scrum anymore. So if people do not implement the values and believe the values, and have some different culture, it’s not Scrum anymore.

Wiktor Żołnowski: Just a short disclaimer that the Scrum Guide is a 16-page-long document. I don’t even want to call it a book. It is a document that actually describes what Scrum is. So everyone who wants to learn more about Scrum, I strongly recommend you to visit scrumguides.org, and you can download your copy of the Scrum Guide document. I believe it’s translated to more than 50 languages, so you can do this in whatever language you speak. But I strongly recommend downloading the English version because that was the original one, and there are a couple of words that have different meanings when translated, for example, commitment or responsibility or things like this. In different languages, those words have different meanings, and there are different words that they are translated to, and sometimes the correct meaning may be lost. So aside from reading this content in your language, please also try to read it in English, in the original version. That is the most correct one, I believe. Okay, so you mentioned already the values of Scrum. What are the three pillars?

Darek Mozgowoj: When teaching people, there is always like a picture of a house where the values are the fundaments and the pillars are the pillars that are keeping the roof up. And so the pillars are very important, and they are drawing or raising from the values. And the pillars are, first, transparency, inspection, and adaptation. So all these three things–we can discuss further what that means actually–they are building the cycles in Scrum which allow us to mitigate the risk and deliver value.

Wiktor Żołnowski: I remember when I was teaching people how to work in Scrum, I was always explaining inspection and adaptation through the air conditioner we have right here. Our air conditioner works in a way that you set a proper temperature, and it’s constantly measuring it and adjusting to achieve the goal that is the target temperature. But without transparency–like for example, here we have this lamp that is putting light on us, and it also generates heat. So actually our transparency is interrupted by that, and the air conditioner is working pretty hard right now and cooling much more than it should be because the lamp is increasing the temperature. So this is why transparency is very important to actually correctly inspect and adapt in Scrum. That’s great. Okay, so we already mentioned the Scrum Guide. Recently, I heard from some person who worked for one of our clients that for him, the Scrum Guide or Scrum at all is just a suggestion. What do you think about it?

Darek Mozgowoj: It’s kind of, but I’m very careful, I’d be very careful with this word “suggestion,” because I would not suggest to do a couple of things and not do a couple of other things which are in Scrum. We kind of have to implement everything to be sure that we are on correct Scrum. But Scrum does not explicitly show us what to do, like “do the refinement” or “do the management of the backlog,” but it’s not saying how to do it. And this gives a space for implementing the tools whatever we want. So it’s flexible, and that means that Scrum is not actually the same for different teams. They can develop some kind of tools and processes which fit the culture for these teams.

Wiktor Żołnowski: Exactly, but they are still working in some frames.

Darek Mozgowoj: In some frames, and those frames have to be fulfilled. They cannot be like, “we keep only a third part of this.” It has to be everything. And I will always try to help people to imagine how it works if you have a part of it. Then you probably don’t see the problems in other parts, and Scrum is a very sensitive framework. So if you don’t do the transparency well, it hits you in adaptation and inspection, and so on. So it’s not possible to do it as a suggestion; it’s like a guideline.

Wiktor Żołnowski: Yeah, maybe it might be a good idea to record another episode only about what will not work if you are not doing Scrum correctly and what could happen in that situation, because we’ve seen a lot in our history of working with our clients and working on inside projects that Scrum sometimes doesn’t work because it actually hasn’t been Scrum. Okay, so we have values, we have pillars, we know that Scrum is a framework. So what else, and how does it combine together?

Darek Mozgowoj: Okay. So in Scrum, we have periods in which we work and deliver and learn. And these cycles, we call Sprints. And in the Sprint, at the end, we deliver something which is valuable or can be released, or this piece of the product is very important for our end-users, for example, or our clients. But in every next cycle, we’re just learning more and more, so we are much better at delivering the product. So actually, for me, the entire cycle in Scrum is about learning; this is a learning process which has some special abilities to do it quickly. And this framework just allows us to position it in a very good manner. So you don’t need to actually remember; it helps you to remember things how to do it, but you have to just commit yourself to these values, to these processes, and then Scrum helps you to deliver it better each time. So this is the learning cycle for me.

Wiktor Żołnowski: So actually, Scrum is based on the empiric, or is an empirical approach, yes. And when we spoke before, you named it as an empirical decision-making process. Yes. Okay. So why does it matter, for example, for startups, but not only for startups, for any kind of product development, to actually use this kind of empirical decision-making process? Why shouldn’t we make a decision based on our assumptions, for example?

Darek Mozgowoj: Yeah, because it’s very easy to be misled in delivering the product because we see it here, delivering, so coding and thinking about the product. But there is a client, there is a user, which is a lot of users who have different perspectives. And there is a market on which these users are living and existing. So everything there is quite complicated, and at the beginning, we don’t understand; we have some hypothesis that it should work. So every time we do something, we are testing our assumptions. So this is a learning cycle. We deliver it to our clients, to the market, and we are looking for feedback. And this feedback allows us to improve the product or change the direction in which the product should go. And that’s the simple order for a startup, because startups are mostly based on that; they can do things quickly. And the quicker we learn in a startup, then I believe the higher the chance to succeed. So startups should be highly thinking about using Scrum. I believe that’s something that will support them, definitely, for sure.

Wiktor Żołnowski: So you actually described one of the two learning loops in Scrum. The first one is that you described that we have this learning about the product and how the product is evolving, and then we can increment it because it’s very important that you mentioned that every iteration, every cycle is called a Sprint in Scrum. We want to have something that is at least potentially releasable, some increment of a product. Scrum is also iterative and incremental. So at least one increment, or the increment is actually usually built with a couple of changes that could be released together or separately, so we can release a couple of times. It doesn’t mean that we have to release only once per Sprint, yes, but this cadence, this iteration, ends with the Sprint Review, where we can actually discuss together with stakeholders, with clients, with some places we can invite users of the product and learn what they think. What they think about the changes, the increment that we are going to release or we just released, because it could happen during the Sprint, and we can learn from that and learn what we could do or what we should do next, not even in the very next iteration but maybe next in the future, etc. So this is this one learning cycle, this one learning loop that we have. The second one is that the team can actually, based on this user’s feedback, based on some data from the market, from the product itself, and also the data, for example, about their velocity or capacity, how they worked, how much work they performed during the Sprint, how hard it was, what they discovered, if there were any surprises during the Sprint, something that they didn’t predict, the team can also adjust the process. And this is the second learning loop.

Darek Mozgowoj: When you look at it, when you’re trying to draw how the process looks like, it seems like this second loop is smaller, but for me, they’re equal in value. And the second loop, as you mentioned, is about the processes, actually. All the things we’re doing, delivering this product as this increment, it’s a kind of process. And here we can understand better, as we already discussed, we can understand better the product, the market, but on the way to delivering it, we can find that something is not working perfectly for us, so we can deliver it better, quicker, more efficiently. And the second loop is about how to improve our work so this other process will be much faster, smoother. And there is a famous graph: when Scrum is working well, each iteration we’re going better and better in both processes and what we deliver. So the accumulated value at the end is much higher than in all other methodologies which are used on the market. So those are those two main learning loops. There is a third one, the smallest one, the daily loop. Actually, the single question that we, maybe not the single one, but the question that we can ask thanks to this loop is, “Are we going in the right direction? Are we going to achieve our goal for this iteration?” And that happens during the Daily Scrum. Okay, so we have these three loops. Let’s get back to the first one, the product one. So, Sprint Review, this is an event at the end of every Sprint, not one of the very last, but one of the last events at the end of the Sprint. So what happens during the Sprint Review?

Darek Mozgowoj: So, the Sprint Review is the final event in Scrum. During this event, everyone–hopefully the team members, the client, and hopefully, it would be very nice to have the end-users–comes to see the increment, so the change, and they can decide at this meeting if the change is valuable, if this change helps the user achieve their goals in the way they want. That is one of the parts. So the team is looking for feedback, looking at how the users or clients are using the tool, so they can think about maybe improving something. So they can inspect what they did and they can adapt, so they can add some things to the backlog which can improve the product further. And also there is the other part of inspection and transparency where the team is discussing with the business actually the next steps, if something changed on the market. Sometimes the team doesn’t have this information; this information is on the business side, and then the business understands maybe closer to the strategy and changes on the market. So this is a good point and good time to ask if the next moves, the next steps which we are going to implement, are in line with the strategy, if something has changed. So this is kind of asking a question about agility, if we can do the change now, if something changed which pushes us to do some changes on our side as well. And that’s what the whole Sprint Review is about.

Wiktor Żołnowski: Okay. So one more thing here to add, or the way I always describe the review, is that I always try to show people that there is a difference between a demo and a review.

Darek Mozgowoj: Yeah, there is a common mistake.

Wiktor Żołnowski: Yeah, a common mistake. The demo is sometimes, I heard that the teams are showing a PowerPoint presentation. “Oh yeah, that’s very nice pictures, everyone, this data is fantastic.” There’s a difference from showing a Jira backlog or a Sprint Backlog in Jira. For me, if the team shows only Jira during the Sprint Review, it’s exactly like they could actually put it on a slide in PowerPoint. So it doesn’t make sense. Exactly. So how should it look like?

Darek Mozgowoj: It should be, as I said, when the business representatives come and the users come, we actually would like to show them, not just show them so they can see. They should be able to use it, and we can discuss it.

Wiktor Żołnowski: Like, what I always tell our teams is to send all the stakeholders who are invited some information before the Sprint Review, even send them some instructions so they could actually use the product, use the increments, notice on their own before the Sprint Review what has changed, and be prepared for this. So that during the Sprint Review, which is, for example, for a two-week-long Sprint, it’s just 45 minutes–sorry, we have only one and a half hours to actually make the most probably very important business decisions. The decisions about what we are going to do next, in the next iteration. So you can imagine that a two-week-long iteration of a team, let’s say of five developers, a Product Owner, and a Scrum Master, is a lot of money. So this is a point in time where we actually need to make a decision what they will be working on next, and we need to assure that they will not waste this time and waste this money. Every hour of a seven-person team or a six-person team is worth a lot of money, especially for startups who are usually short on money.

Darek Mozgowoj: Yeah, and that’s why it’s very important to discuss this. On the other side, one and a half hours, but there’s a lot of things to show. We have to look at the product, the increment, how it changed, how the people are using it. We have to discuss some kind of points, if we changed our strategy. So it’s a lot of things, and it’s a very good idea to send this information before, especially as you mentioned previously, that we can deliver not only at the end of the Sprint; we can deliver it continuously during the Sprint. And actually, each small increment, which follows to the entire increment at the end, can be tested, and we can receive feedback much easier. So it’s not a surprise at the end of the Sprint that something has to be changed.

Wiktor Żołnowski: Yeah, sometimes it’s even good to actually ask for feedback before we release something to production. It might be good to ask the stakeholders if this is something they actually wanted to be delivered before we deliver it. Because then, of course, with the current technology level and development methods, reversing all the changes is usually not very difficult, and we can do this, but still, sometimes it’s a waste. And especially from the user’s perspective, it might be considered some kind of problem if we release something and then revert it back. Okay, so Sprint Review is mainly about the product, about the increment. This is the discussion, and this is a decision-making point in time in the Sprint. We make this decision based on the data that we collected during the Sprint, based on the feedback that we have, etc. And we actually take a look at the Product Backlog, yes. We’ll discuss what the Product Backlog is in a moment. And then, what next? The very next meeting that is actually done by the–event, not the meeting–that is performed by the team itself without the stakeholders, is the Sprint Retrospective. What happens there?

Darek Mozgowoj: Yeah, the Sprint Retrospective is about the second loop, about processes and people. So when we receive the feedback, we already know that we are doing great or not. And maybe we have some clues about our work during the Sprint. So then there is a point in time before we begin the new loop of the Sprint. Then we can sit together, the team representatives sit together, and they discuss what can be improved, what was strong maybe, what was good, because it’s also good to maintain the good practices. And during this discussion, it’s a roundtable; everyone has a voice to say something. We decide what is the most important thing to change in our processes to be better in the next iteration. So at the end of this, the outcome from this retrospective is action points, very well-described and with an assignee already, what has to be done, who will do these things to improve the processes next time, and when.

Wiktor Żołnowski: And when, yeah.

Darek Mozgowoj: And so we know exactly what happened. We can measure it in the next iteration if the change happened and if the expected outcome is correct or not. So we can also then adapt to this situation. And that is very important. When I’m teaching people Scrum, we often reflect this into the education system. When people get, let’s say, the score at the end of an exam, the score means like A+ or whatever, but then there is no loop about how we can improve the learning process to deliver it.

Wiktor Żołnowski: Why would you like to improve from an A+? Yeah, or maybe a B+. But if someone gets a B, C, or D, or whatever, then what can we improve? What was wrong in the process that we received such a low score? And then usually, in the education system, we’re going further, and we have this lack of knowledge with us to the next level, so it’s not helping at all. Later it’s even worse. It’s pretty the same in the software development process. When we are not learning, or when we are not improving, these problems that we have from the very beginning, they accumulate, and then after some time, they are even worse, they’re even more costly. So learning about them–and that’s a bunch of different things that could happen and that we could learn, from starting with the communication within the team, the communication with the stakeholders, with people outside of the team, the tools that we are using that are problematic, the methods that we are using, maybe the quality that we are delivering is not correct. And maybe, for example, we are not testing enough, or we are collecting some kind of technological debt, decreasing the quality because we are moving too fast. And without monitoring it, without learning from the data, from everything what we observed during the Sprint, we are actually collecting all of these problems, and they are increasing with time. And later on, they might be very, very costly to solve or actually very, very costly to maintain because still, we’ll have to deal with them when trying to develop some value.

Darek Mozgowoj: And I see also that there is no direct relation between results. You observe some problem, and you actually don’t know what is the root cause of this problem. And at the beginning, you know that there are not many hypotheses, so you can test and you can find it. But when you accumulate all these problems, after a while, it’s so big, so you cannot track it at all, and you don’t know where to dig in to find the root cause. So that’s why Scrum gives us this tool, like the retrospective, to do it regularly. And we can regularly pick the problems and adapt ourselves to the process. Well, that’s the correct way, I believe.

Wiktor Żołnowski: Okay, so perfect. So we had the Sprint Review almost at the end of the Sprint. Then the very next was the Sprint Retrospective. For the Sprint Review, we discussed the product, the increment, we decided what we are going to work on next, maybe in the next iteration or in the very next iteration, or maybe in the next couple of iterations as well. Then we had the Sprint Retrospective where we discussed the process and we decided what we need to improve, what we want to improve, what we will improve in the next iteration. And that’s the end of the Sprint. And that’s the moment that the Sprint ends, and immediately after the Sprint ends, the next Sprint starts. And it starts with Sprint Planning. So how does this kind of event look like?

Darek Mozgowoj: This is very important because it’s the beginning. If we do not plan well, then it will hit us in the entire Sprint. So after all these ending meetings, like the review and the retrospective, we have accumulated some knowledge. We know we have action points which were delivered in the retrospective, and we have some feedback, and maybe we already adapted the backlog after the review when we got the feedback from the clients and from the users. So now we have a lot of knowledge which gives us an opportunity to adapt. And we know what we can do next because we discussed it with the business owner in the review. And then, of course, there is another meeting which is done during the Sprint–we’ll maybe discuss it later–which can improve our backlog. But assuming that our backlog is in a good state, we understand what we need to do. And then on planning, simply, the team and the Product Owner know what needs to be done in the next step. And so they know about the goal, the business goal. The Product Owner comes with this need which needs to be addressed to the team. And then together with the team, looking in the backlog, what is in the backlog, they can decide what we can pick from this backlog for the next Sprint which will help us to achieve the goal. Of course, sometimes, from a very general perspective, the goal is too big and has to be defined, has to be negotiated to adjust to the current state of the backlog and the knowledge of the team. But then this negotiation is going on, we decide what can be done, how we can do it. At the planning, we also think about all the blockers, all the things which can change the perspective during the Sprint. Let’s say someone says, “Sorry, I forgot to tell you that in the middle of the Sprint, I’m taking my holidays, so I’m off. My capacity is null at this time, so we cannot deliver everything what we thought at the beginning.” So all these insights are very important for the team to decide what to do. And simply, the entire team needs to understand what they want to achieve, how they want to achieve it. So everyone is on the same page, and they can help each other because they are a multi-functional team, cross-functional, let’s say cross-functionality, and they need to understand in the same way. If not, then if someone is missing, then things are blocked, they cannot deliver anything at all in the Sprint. That means that they are not cross-functional, simply.

Wiktor Żołnowski: So the team actually has to decide and actually prepare the plan for the Sprint. And the plan is what will be done and how we are going to perform it. And what I’ve seen many times is that teams usually stop on deciding, “Okay, we need to do this and that. Okay, we have Sprint planned.” Deciding what we are going to do is not the plan yet. We need to decide, “Okay, so how are we going to do it?” We need to discuss it more in detail and decide, “Okay, so for example, for implementing this feature or this increment, we will need to change the front end of the application, change the mobile apps, maybe add some API calls, maybe change the database. I will have to maybe do some research on that, maybe do some design, or something else.” So every aspect of this development of this feature needs to be planned. It will be perfect if we will already decide how much time it could take, who will perform the work. But still, I wouldn’t recommend over-planning here because we may get to the point where, like, we have a Sprint plan that’s, “Okay, you have a capacity of 80 hours, so 78 hours of your time is already planned until the end of the Sprint.” That’s not the point. But still, deciding who can do that, and then maybe even at the end of the planning or during the planning, we can, for example, see that we have one rockstar developer who is involved in every item that we are going to work on. And actually, this is something that is not good because at the end of the Sprint, it may occur that all of our work will need to be streamlined to this guy’s capacity, and it may occur that we are not going to make it, we will not deliver what we planned. So yes, so the team as a whole needs to plan how they want to deliver the scope, or actually how they want to achieve the goal that you have named. It has a name: it’s a Sprint Goal, a business objective for the next iteration that we want to achieve. It’s perfect if this goal is defined in a SMART way. I believe that everyone knows what a SMART goal is. If not, you can Google it, SMART. But it doesn’t have to be. It’s great if it’s SMART, but it doesn’t have to be. Okay, so we have this planning, then we run the Sprint. But maybe before the planning, there is something that we missed here. We haven’t mentioned, or we mentioned but we haven’t described in detail, what is the Product Backlog. All of these things are not happening in a void. It doesn’t work that way that ideas come from some clouds or some space, and people are just working on that. It’s also work that someone, usually the Product Owner, but perfectly if the Product Owner does it together with the team, has to perform: the work on the requirements that are described in that Product Backlog. So what is the Product Backlog?

Darek Mozgowoj: Yeah, the Product Backlog is, in the definition, the ordered list of things that need to be done, and it exists before the cycle starts. We can say that we feed the Sprint Backlog from the Product Backlog. We feed the Sprint Backlog, and we can begin to work. So the team, at maybe only one point in the entire Scrum cycle, is looking at the Product Backlog, but the cycle is about the Sprint Backlog. So this artifact, the Product Backlog, as I said, is an ordered list of things which needs to be done. The granularity is there, so when we think about it, if we know more about this kind of task or user story or Product Backlog item, it should be higher, so it gives you, “Okay, I’m able to deliver it because I know already a lot about this.” If not, then it’s in the bottom of the backlog. And of course, that’s not the way you should order the backlog. When you have an ordered list of items, it’s a product already. And besides the details that we have in each item, the order came from the business objective, and these are priorities, which are actually the work of the Product Owner to decide about. But of course, when you look at the priorities from a high-level perspective, looking down, the things we know more about are higher than the things we know less about. We try to add more details to the things that are on the top of the backlog, and that process of adding the details is called refinement.

Wiktor Żołnowski: Exactly. And this is the one event that the entire team is actually looking at the Product Backlog during the Sprint. And so there’s a kind of assumption or there is a strategic plan in which we know, with a very high probability, that these things which are at the top of the backlog will be the next things, and we need to discover everything about them before we go and deliver it. Because if not, then there will be a lot of risk, and maybe we missed something, and we will not be able to deliver that. So Backlog Refinement is usually the first thing that comes to my mind when I see that the team, for example, struggles during the Sprint Planning, or especially when I see that the team during the Sprint Review says that, “Okay, we delivered only 60-70% of what we planned.” That usually, or I would say even in most cases, means that they haven’t done enough backlog refinement. In an old version of the Scrum Guide, it was written that the team should use at most 10% of their capacity on backlog refinement. As far as I know, in the current version, there is no limit. They should do refinement as much as it’s needed for the process to work well. And this is something that, if you’re already working in Scrum and if you’re struggling with your Sprint Planning, Sprint Review, and you’re struggling with delivering what you promised or committed to during the Sprint Planning, most probably you are not doing enough backlog refinement or you are not doing it correctly. So maybe let’s talk a bit more about how to perform backlog refinement correctly. What does it mean? You said it’s an event; I would say it’s a process. It’s a process. Of course, sometimes people need some time to sit together, but of course, each individual member can sit with something and do it offline from the team and then share the knowledge with the team at some meeting. It’s actually like research, requirements analysis; those are the things that…

Darek Mozgowoj: Exactly. But at the end of the day, we need a Product Owner who gives us some context on the backlog item which we’re going to refine. So we need to understand why they need to do this, what’s at stake, actually. Because sometimes, we have to deliver, let’s say, some user interface, so we need some design. We need to know how it should be planned in front before we begin to decide how big it is, if we can deliver it, and what needs to be done to deliver it. So as I said, we need some input. This input comes from different things, like from technical research from the team, from the business perspective, so the Product Owner, from the user designer. Not necessarily the Product Owner is responsible for that, but is responsible.

Wiktor Żołnowski: But at the end of the day, it may be done by any team member who actually, for example, talks to the stakeholders or talks to some business domain experts in the organization or outside the organization, or does some desk research or something like this.

Darek Mozgowoj: Of course. And it can happen that during the process, the team members become the domain experts, and there’s also a learning process. They learn, they can learn the domain, and so…

Wiktor Żołnowski: Yeah, I mean, what you started from, that Scrum is about learning, yeah, I believe that’s completely true. The team, the people, can also learn the domain when they work on it in a more structured way, not in a chaotic way that, “Okay, we just…” There is some information, the group environment is also a process of learning or gaining information about what we are doing, why we’re doing it, and often it’s even discovering things that no one in the organization knew about before.

Darek Mozgowoj: Yeah, absolutely. But I believe that the Product Owner him or herself is actually needed during the refinement sometimes because the main reason the Product Owner, according to the Scrum Guide, is the person who has this role to maximize the value. And sometimes, there’s a problem, technically there are a lot of opportunities to deliver or solve this problem. But sometimes if teams don’t understand, because the developers mostly want to deliver very good quality things, and that’s fine. But of course, there is a kind of, if we need to do it with this cost, maybe we can deliver something which gives us a hint and maximizes the value of the product quickly, and we can learn quicker. So we can deliver it in three days, not in two weeks, something like that. We will discuss it in a moment. We are surely going there. I believe this refinement process itself is something Scrum teams like because they can autonomously decide and think. This is the process of critical thinking about a problem which nobody has solved yet, for example, and you have the ability to deliver it in a new way, and this is fantastic. The team learns, the team is discussing, so the culture is creating during this cooperation, and it improves the morale. And at the end, all of them, with all these inputs, they meet together, they find the solution, they understand the problem, and they understand better the business and the goal which they are going for actually. So it increases the motivation.

Wiktor Żołnowski: Absolutely. Anyone who is running a startup and if you’re struggling with your team’s motivation, there are no better perks like free food in the kitchen and other stuff. It never replaces the understanding of the business, of the product, and the motivation that came from being a part of something that I feel is important for me personally.

Darek Mozgowoj: So remember, I have a whiteboard with some pens, coffee, and discuss the problem. And usually it works. When you support the team, give them the problem, and they will pay off with committing themselves to solve this problem for you. So that’s important in startups, I believe.

Wiktor Żołnowski: Okay, so backlog refinement is a process where we are trying to add some details to the requirements that are on the Product Backlog. And usually, we are focusing on the Product Backlog items, which now are features that are on the top of the Product Backlog because the order of the priority came from the business objective and other stuff. The Product Backlog is actually a description of how we are going to achieve something that also should be defined in Scrum, which is a Product Goal. Maybe you can tell us more about the Product Goal.

Darek Mozgowoj: On top of what we said about the Product Backlog, this is also a list which, it’s very stressful for anyone who heard it the first time, this never ends. Because we believe our product never ends. Even when we deliver it to the market, the market evolves, and the product evolves with the market, so it will be continually having things in the backlog because we discover new ideas, new needs in our users, in our market. Maybe we will see an opportunity to move to another market, and it also opens the backlog for new items, and so on. And that’s difficult because if you don’t have the skills to manage it well, it will explode because your backlog will rise and rise and be too big to be manageable. And this is the role of the Product Owner or Product Manager to keep a hand on it and maximize the product. That for me means as well managing the new backlog well. So decide with the business what does not need to be done. So that is the opposite of what people say, “Oh, this business is about what we can do,” but in the backlog, what we don’t need to deliver to achieve what you actually promised to the market.

Wiktor Żołnowski: Yeah, to achieve this Product Goal, right? We define what we are going to, not what we are going to build, we define what our product is going to do for its users and what value we add to the user’s day-to-day life, whoever the users are, whatever the product is. You need to have a Product Goal, and then the Product Backlog is the list of potential functionalities that we have, some opportunities we can use, but we don’t have to do all of them to actually achieve this Product Goal or move us closer to this Product Goal. And increase the value that we deliver to our customers, to our users. We can define the Product Backlog as a description of this Product Goal, the decomposition of the Product Goal. As you mentioned, it never ends, it’s infinite, and we can always add some things to the Product Backlog. But actually, the role of a Product Owner or Product Manager is to cut down the number of requirements to the absolute minimum, or actually order it in a way that we will find the shortest path to achieve or move ourselves closer to achieving this Product Goal.

Darek Mozgowoj: There are always things which can be done, but that costs for the startups, for the clients. And the role of the Product Owner is also to minimize the risk that we run out of money before we deliver what we promised and we get the traction and we begin the entrepreneurship journey actually. So it’s like the maximization of the product value means also to me minimizing the risk that we will not deliver this product ever.

Wiktor Żołnowski: So this kind of idea is very important for everyone who is watching us today, that if you have some classical corporate project management background and you try to build your startup in the same way, that you have a well-defined scope, timeline, budget, some quality requirements, and you believe that that’s exactly what you need to build to surprise your users, most probably, I would say in 100%, but maybe in 98-ish percent, you’re wrong. You don’t know what your users actually need. You need to ask them, but not only ask them but actually show them, give them the next versions of your product, and that way you will learn what they actually need. If you want to spend all of your budget or the majority of your budget on your fixed-price, fixed-budget, fixed-scope project, most probably you will lose most of this money. Some part of that might be reusable later on, but you can, and most probably if you don’t want to waste some money, you have to make it in a different way. And Scrum is one of the flavors that helps us, that is much more actually cheaper, cheaper. So this is why we decided to use Scrum together with our clients. The entire topic of project management versus product management, the old waterfall approach to building, especially startups, and the product management approach, product-led companies using, for example, Scrum and other agile methods to build your products for startups, that deserves a totally different meeting, different episode. Or even a series, because that’s a very wide topic we can talk about for hours. We already mentioned what is the Product Backlog. You mentioned there is something that is a Sprint Backlog that is created during the Sprint Planning.

Darek Mozgowoj: Yeah, it emerges from the Product Backlog. So these are things which are picked up by the team, which they believe they can, when they deliver it, they will achieve the goal of the Sprint. So that is what we close in the Sprint Backlog. And we focus–this is one of the values of the current version, I believe, at the very beginning–this is like we focus now. The team is focused on delivering this small piece of the Product Backlog which they understand best, which they know how it is linked to the goal. So they can increase the engagement and deliver it much faster because they have no distraction from the outside. So that’s why we have the Sprints. We have this time when we can focus on the goal, we can focus on the plan, we can focus on the value. We continuously think and check, inspect it during the daily, as we discussed previously. So we are trying to find the optimum way to deliver it as soon as possible during this iteration.

Wiktor Żołnowski: I always try to describe a Sprint as a box. The team is inside of the box, and no one from the outside world is disturbing them. So there are plenty of processes that happen around the team, but no one should–of course, there may be some emergencies or other stuff–but no one should interrupt the team during the work so they could focus on that. And even in a very chaotic and very emerging environment, they could focus, and they could actually perform at the highest level and deliver value to the organization, to the users. Of course, the team could reach out to other people from this box to the real world, let’s call it that way, but the other way around, it shouldn’t be done or should be minimized if you want to have the team that is performing well. So this is also why Scrum is very good for startups, but not only for software, for most of the contemporary product development endeavors. Even in the very emerging, very fast-changing environment like startups, we can still perform, we can still have these inspect and adaptation loops inside of the team. Okay, you already mentioned another event that we haven’t described before in detail: the Daily Scrum.

Darek Mozgowoj: The Daily Scrum. You mentioned before that this is the third small loop that happens every day. From a generic perspective, when you look at these pillars I mentioned, like transparency, adaptation, inspection, it happens in all these events. Actually, in a different composition, but it happens everywhere, and it also happens during the Daily Scrum. And the Daily Scrum is just a continuous check if we’re on a good track to deliver the Sprint Goal. And this is the problem here because most of the time I’m discussing it with people, they don’t understand it. And I heard that people think, “Okay, during the daily, I am just saying what I did yesterday, what I am doing today, and that’s all.” I’m saying so this is a quick meeting. But it’s also about saying what I did and what I will do because I believe that all this information is already in the Sprint Backlog, so you can look at it and you don’t need to speak at all about this stuff. We have to meet there at this daily to quickly see if nothing happened which actually prevents us from delivering the Sprint Goal. Something will happen, some of the team members can feel sick and cannot deliver something. We learned something during the process which we missed during the refinement, it could happen, and we have to address it quickly. Or some other things change, or there was some emergency or some production issue that we needed to fix everything. All these things influence and can impact on delivering the goal on which the team committed at the Sprint Planning. So that should be the core of the discussion. “Okay, this is our Sprint Goal.” Let’s sit around the Sprint Goal and discuss what we can do to be there on time, or quicker if possible.

Wiktor Żołnowski: For me, it’s like a very micro-planning. At the planning, we’re planning the entire Sprint. On the daily, we’re planning the next 24 hours. But planning like, “Okay, I have to go today to do this stuff, I have to check this one. I have to call the DevOps to check something. And how do we do it efficiently to not block each other and deliver something and have progress?” Or even if we could cooperate on something, we can still look at some pair programming, or maybe there are some more complex features or items that we can work on together, not interrupting each other, but to achieve better results, make it faster, etc. So I really like when I see during the daily, if the team members are, as I mentioned, planning their work together. And if that happens, I am convinced that they are working as a team, not as a group of individuals where everyone is focused on their list of tasks. So that’s not my problem that someone will not perform well due to different reasons.

Darek Mozgowoj: So that’s actually, the daily is a very quick meeting. It should take like 15 minutes every day. But we don’t want to spend more because it’s to spot the problem. If we spot it and it requires another meeting, then we plan it. Not all of the team members are required for discussing it, so we also don’t want to waste the time of the people who can work efficiently with the tasks they have already. But if there’s someone who can help with some issues, for example, then we can say, “Okay, let’s discuss it after the daily.” But everyone knows what the situation is. So this is also the transparency which is showing up at this moment. So this daily and everything, actually, from the small event like the daily to the big one like planning, everything is important, as we mentioned at the beginning. It’s not like we can do proper Scrum without a daily. You can do it for a while, and after some time, things which are not addressed on the daily will kick you, and there will be a very big problem. I believe.

Wiktor Żołnowski: Okay, so we already described all of the Scrum meetings, like Sprint Planning, Sprint Review, Sprint Retrospective, Daily Scrum, the process of backlog refinement. We described the artifacts, like the Product Backlog, Sprint Backlog. We haven’t mentioned the Definition of Done. That is also pretty important, and I believe that this is something that also many teams forget about.

Darek Mozgowoj: And the Definition of Done is kind of, we can say it’s just a checklist sometimes, we can describe it like that, but it emerges from the experiences of good practices for the product and from the experiences of the team members. The Definition of Done can clearly, this is an abstract for every item in the backlog, so when we deliver anything from the Product Backlog or Sprint Backlog, it should pass the Definition of Done. And it’s like, if it doesn’t, it means that we haven’t delivered it. If we haven’t delivered it, it’s not there. I mean, it’s not a potentially releasable product, it’s just something we coded and nobody can use it for different reasons. And then this Definition of Done is like the check of the quality. For me, all the process which we’ve done assures that the end will be delivered and provides value. If not, if we forget to do, let’s say one of the parts of the Definition of Done will be “our code passes automation tests.” If not, then there’s a potential risk that when it will be deployed and the business will use it, it will be broken. And let’s say a client will pay for that, or there will be a potential miss in the business. All the things could happen. But that is the process, and the process is set at the beginning because the people have already some experience, they have some requirements, for example. So they define this together, the Scrum Team, but when they learn the process, when they learn how the pieces work, they can expand this Definition of Done, and it can happen anytime. But if it’s not very impactful, I would say that most people think about it during the retrospective because it’s a kind of process. We observe that normally, when we’re going through the process, the Definition of Done becomes more and more sophisticated because we think more and more about quality. Maybe, let’s say, there’s a more complex process, there are more users, we have to be more careful, so our Definition of Done is better, but as I said, more sophisticated. At the beginning, it is a normal process when we forget that we can fall very easily into the trap that we have to fix a lot of bugs and we will not deliver any value.

Wiktor Żołnowski: So, yeah, I always like to say that the Definition of Done is the definition of the quality of the things that we deliver, but also it’s some kind of like the gates on the airports that you go through during the checking. It’s like, if there are some bugs or some problems or some issues, you will not get into the airport; you’re not flying to production in this case. So this is very important. This is also actually the point where we add transparency to what we deliver and how much we are able to deliver during the Sprint. I’ve seen so many times that teams deliver like 60% or 50% of what they planned, and another 50% is “almost done.” I always ask them to show me their “definition of almost done,” and they say, “No, we have only a definition of done.” So maybe next time, try to take less for the iteration. First of all, go back to the refinement and try to do better refinement, more refinement. Even spend more time on that so you will have less capacity in the next iteration and you will take less. But let’s assume that, for example, they have 10 items. They delivered five that are done and five that are almost done. And I usually tell them, “Okay, so next iteration, try to take six and deliver six. In the next iteration, try to take seven and deliver seven.” And usually after three iterations, they are able to deliver 10 or 11, and then in the next iteration 12, 15, etc. So they are improving only because they understood how to make things “done” and how to better align the process to how they work and better cooperate with each other because they generate this little bit of slack time that they can actually think instead of doing, as we are actually teaching people here in Pragmatic Coders. But because everyone who does some coding or whatever work, if it’s not finished, this person feels that, “I spent a number of hours, but I haven’t finished, but let’s say 80% is finished,” and they feel that this is very valuable. But we have to think that we’re not doing it for ourselves, but for our clients, for our users, and if it is not delivered yet, there’s no value. If it’s not on production, there is no value. And of course, we can think, “Okay, that’s 80% done, we’ll do this last 20% next Sprint.” But discussing it during the review, for example, that, “Yeah, we delivered 50% done and 50% almost done,” this 50% almost done doesn’t have any value for the client. Actually, even discussing it during the Sprint Review is a waste of time, so please never, ever do that.

Darek Mozgowoj: Exactly. During a Sprint Review, we are discussing things that are only done, not almost done. That doesn’t make any point.

Wiktor Żołnowski: Okay, so we are talking about “them.” Who are “them”? The Scrum Team. And what are the three roles in the Scrum Team? Shortly, because we can run another episode for each of these roles, but shortly.

Darek Mozgowoj: So according to the Scrum Guide, there are three roles. There is a Product Owner, a Scrum Master, and, let’s say, Developers, but I prefer to say Makers, because not only developers deliver value during the Sprint. So, Makers, Scrum Master, and the Product Owner. So that’s three roles which actually cooperate together to provide value. Also recently, it’s called “accountabilities,” which may be even better describes the meaning of what it is actually doing. So we have to remember that Scrum Teams are autonomous teams, so there’s no hierarchy here. There could be some person that has some leadership skills, and these leadership skills help the team to achieve the goals. That’s fine. But there is no, “I can tell you you have to do this. I’m the technical manager.”

Wiktor Żołnowski: Inside of the team and assign the tasks to everyone. Maybe it works, but it might work to some extent, but I believe that cross-functional, autonomous teams usually are much better. And by much better, I mean a couple of times better in terms of performance than the teams that are micromanaged by managers. They are much more empowered, so they can think out of the box without any pressure. Well, like as we mentioned from the beginning, Scrum is a framework. There are some frames, and this autonomy happens only inside of these frames. It’s not like they are–this is not anarchy. It’s autonomy, it’s not anarchy where everyone does whatever they want. There are some strict rules that everyone is working according to, and that is how and why it works. It’s not anarchy.

Darek Mozgowoj: Yeah, and we’ll say that autonomy or freedom comes with responsibility. Sometimes people have to be responsible for what they decided to deliver during the Sprint Planning. So all these things are about the Scrum values which we discussed already. But if we think about the three roles: the Product Owner thinks about what is the right product, how to maximize this to deliver the best possible value. And on the other hand, the developers or makers think how to do these things right, how to deliver a proper quality, so the Definition of Done has to be fulfilled, and the good technology, whatever they use, all the skills to decide about that. And the third person is in between, talking, discussing with these two roles, makers and Product Owner, how to do it efficiently. Sometimes teaching the team or helping, supporting that kind of stuff.

Wiktor Żołnowski: I like the word “efficiency” because sometimes I heard that Scrum Masters work so that they do work faster. I don’t agree with that because fast is not agility. They have to do it efficiently. Of course, because we are efficient, sometimes we do things faster, but doing things faster is not the aim of being agile. We can deliver six times faster things that no one will use, for example. We focus on the outcome. We can deliver a lot, but with no value.

Darek Mozgowoj: So these three roles, they cooperate together. The Scrum Master is teaching, trying to support the team with problems and to establish good processes, for example, processes for the Product Owner, processes for the makers.

Wiktor Żołnowski: I always say that the Scrum Master is mainly a teacher, a person who’s only there to teach others how to use Scrum properly and to teach everything what is needed for that. Some teams will require other skills, other knowledge. For example, let’s say the Product Owner is not experienced, so the Scrum Master would have to focus more on teaching the Product Owner or helping her or him to learn the new product management skills, tools, whatever. Some teams will lack some technical knowledge, so the Scrum Master will have to assure that the correct learning process of the technicalities, technical skills, or quality, or whatever, will be there. Or the Scrum Master has to teach the team how to make a space, make a room for teaching, for learning. The example that I mentioned that the team takes 10 items to the Sprint and delivers only five, decreasing this amount to, let’s say, five or six in the Sprint, and forcing that, the Scrum Master teaching the team that, “Let’s try this experiment,” next iteration, that creates a space for accelerated learning, problem-solving, thinking. And this is the main role of a Scrum Master.

Darek Mozgowoj: Yeah, that’s why we call him a Scrum Master. Because sometimes, because we are focusing on the work, like technology only, or like the Product Owner, we tend to forget about some good practices. And the Scrum Master is like the guardian. “Okay, let’s do it more transparently. If you don’t do this transparently, your work will not provide value. It actually can work against you.” So this cooperation is crucial, I mean, and the team needs to respect–so this also respect to all of these Scrum values–and learn continuously. But that’s actually the most important thing for Scrum, to learn together, an empowered team.

Wiktor Żołnowski: An empowered team. I believe it’s worth mentioning that at Pragmatic Coders, we do things slightly differently. Since many organizations are hiring a Scrum Master as a full-time job, in our case, Scrum Masters are just developers who are trained in performing this role as a part of their daily duties. I believe it’s mainly possible because aside from a Scrum Master, we have a Scrum training process that everyone who is working for us in their first month goes through and is taught. That’s part of the teaching, the system solution that we have, that we implemented at Pragmatic Coders, so everyone is on the same page. Everyone read the Scrum Guide, 16 pages, so everybody’s on the same 16 pages in the same book. So that simplifies the role of the Scrum Master. But of course, in many organizations where this kind of system approach doesn’t exist, in organizations that do not have so skilled Product Owners, Product Managers as we do, this Scrum Master job might be a full-time job, and that cost might be the cost of a full-time person in this role. And usual experts are not cheap, and I wouldn’t recommend hiring a junior Scrum Master if you don’t have any senior Scrum Masters around who could work with such a person. So that cost could be justified in organizations that do not have this knowledge on board. In our case, it’s much simpler since Pragmatic Coders from the very first day was designed as an agile company, and Scrum was something that we came to as a main way of doing things in the entire company. Even right now, in the marketing and HR departments, we are using Scrum, and that works perfectly. Even for the management, we use, I wouldn’t say Scrum, but something that is pretty close to Scrum. Okay, so I believe we went through all of the Scrum aspects. We started with values and pillars. Then we explained that Scrum is a framework and that Scrum is an empirical decision-making approach. We went through all of the events, starting from Sprint Review, then Sprint Retrospective, then Sprint Planning, and that order of description, I believe, wasn’t a random order; we did this on purpose. And we also discussed Product Backlog Refinement, which is a process. We also discussed the Daily Scrum, the smallest learning loop in the Scrum cycle. We talked about what is the Product Backlog, we talked about what is a Sprint Backlog. We also went through all of the three roles: Scrum Master, Product Owner, and Developers or Makers, as you call it. We also spoke about the Definition of Done. And actually, I believe that’s it. That’s the entire Scrum framework. So let’s try to wrap all of the things together and try to describe once again why do we think that maybe not every, but most of the startups and startup founders should consider using Scrum as the way their team works. Maybe not startup founders, maybe CTOs, maybe Product Managers, or CPOs, certain VPs of Product, whatever you call it. Why should people who are responsible for the process, for the technology in the company, such as startups, consider using Scrum?

Darek Mozgowoj: Yeah. It’ll probably be a huge list of reasons, I believe, but let’s focus on the most important for me. Building startups is a very intensive experience. You have to give 100% or 200% of your time to deliver something, and this happens for a couple of months sometimes, and you don’t have guaranteed success. You could fail for a different reason; it’s not because of Scrum sometimes, just the market. During this process, there’s a lot of emotion and a lot of decisions which need to be made quickly. And because of this emotion and decision-making intensity, if you just decide from your head, let’s say, you could fail with the decisions which have no arguments behind them. So you just decide because of your feelings, your plans. Exactly. And then, as we discussed here, Scrum is based on an empirical approach. So everything that we learn and when we observe is documented in some behavioral data, metrics. It helps a lot for the founders to make very good decisions, much better than based only on feelings, good feelings, especially in situations that are very difficult. Let’s say you have to run quickly because you’re running out of money, or you have to decide something because something has changed on the market. The structure of Scrum helps you to focus on something. You see the metrics, you see the learning curve, you have support from your team, experts from different technologies, from the business, the Product Owner. All of this just gives you a lot of uplift in your decisions. So that for me is the most important aspect of why Scrum is good for a startup. Other things is that I believe that in startups, it’s also a kind of process of learning. If you learn, let’s say you use a tool which also allows you to learn efficiently. And as we already discussed it, and I believe that’s true, that Scrum is a framework which is based on the learning process. So it speaks to me; it seems like it fits correctly into this niche where you think about startups. Startups need to learn quickly, Scrum allows them to learn quickly, so let’s merge these two worlds, and they should empower each other and give some positive feedback. That’s my opinion.

Wiktor Żołnowski: Perfect. I believe that’s one thing that is worth mentioning here is that from my experience, from the experience of people whom I talk to, there is a huge risk in startups that people tend to burn out because of the chaotic environment, fast-paced working, etc. And so we haven’t spoken about it, but it’s this stable pace, this stable cadence, the iterations in Scrum, this framework, the structure that you call it. This is something that even in the very demanding startup environment, a very chaotic and fast-changing environment, this is something that is a good foundation for people to actually work in a stable pace, so they are not burning out, or at least not as fast as if they are not using Scrum. Because of course, usually people who are motivated–as we also mentioned before, Scrum also enforces or enhances the motivation of the team if it’s done correctly. If people are involved in the business decisions, if they are doing enough backlog refinement, if they have access to all the stakeholders, etc., they are way more motivated. And thanks to this framework, people are learning faster and they are working more and more efficiently with every iteration. They are learning about the product, about the business, the way, etc. They are way more motivated, way more satisfied by the job that they perform. And at the end of the day, they are less fatigued, or they are not burning out from the work as fast as people usually do in startups. I believe that concludes our discussion about Scrum. So thank you very much, Darek, for joining me today. And I’m pretty sure that we’ll record another episode about all of the things that we skipped today and that are worth mentioning. So please stay tuned and don’t forget to subscribe to our channels. Pragmatic Talks is delivered to you by Pragmatic Coders, the first-choice software development partner for startup founders. Be sure to catch all new episodes. Subscribe to our YouTube, Spotify, or Apple Podcast channels. And if you are thinking about building your own startup or struggling with product development, contact us and find out what we can do together.