Solving common dev problems by doing SCRUM right with Sohrab Salimi

Victor [00:21]: Sohrab welcome to the show.

Sohrab [00:35]: Thank you Victor for inviting me.
Victor [00:37]: Yeah. My pleasure. How did you get into scrum being a scrum professional?

Sohrab [00:43]: That’s going to be a long story, but I’ll try to cut it short. So initially I studied medicine. I’m the only medical doctor in this field that has achieved the highest credentials in the world of agility. And I actually finished medicine and I didn’t really know which specialization to do. I liked the intellectual challenges of being an internal medicine doctor, but that was just too slow. If you have a patient, you just give them a bit of drugs and then you have to wait until things come. And I like the action in surgery and there’s really no mix between these things.

[01:23] So I was in the middle of a debate internally in my head. And one of the ideas that I had was also to look into other fields. As my parents were both entrepreneurs I had this entrepreneurial neck in me and I was like, okay, let’s explore this. And let’s look at the world of business and let’s look at what kind of opportunities are out there. And ultimately I joined Bain & Company one of the three big strategy consulting firms. And I stayed at Bain for almost three years, then my wife said, as long as you’re working there, we’re not going to have any kids because you’re never at home. So I left Bain.

[01:57] I founded a company with a friend from school and I also consulted my parents’ IT consulting company on what could be like the next steps that they do. And as a startup founder, I obviously in 2010, 2011, read the book, Lean Startup. And for me it was always like, why wouldn’t you work this way? Because if you think about it, basically every scientist, every medical doctor is clear that anything that we have in our head is a hypothesis. And what do we have to do with hypothesis, is to validate them? We have to run experiments in order to understand to what extent this hypothesis is correct and to what extent it is not correct?

[02:38] So The Lean Startups really resonated with me. And at the same time, I was like, oh, this is very different to what most of the clients that I worked with during my time at Bain do. And it was also very different to what my parents IT consulting company was doing and consulting their clients on. So I looked into this whole space and identified that connected to the lean startup, there’s this upcoming topic of agile software development, particularly scrum. And together with my dad, we looked at this and said, maybe that’s like the next thing that the company should focus on. And as part of that, of course, we had to like train ourselves.

[03:16 ]We had to train our employees, our colleagues and then also look for clients that were looking into this particular thing. And as part of that this whole topic of agility, particularly scrum is one framework to get there. It resonated really well with me. And I just made it my decision to spend the rest of my career probably learning about this stuff, teaching people around this topic. And as part of this journey ultimately became a certified scrum trainer, agile leadership educator, and all of that.

[03:47] And today I spent around 50% of my time teaching classes, running trainings, building online courses, and the other 50% I spent with companies, small ones, but also pretty big ones on implementing these things in reality. And then learning from that. And in the past years, I’ve had a lot of work in the software space, but more importantly, maybe, or more interesting for me, I did a lot of work in the non-software space. So building a truck or medical devices participating in this COVID tests, et cetera. So it has been quite a journey and I’m still excited about the topic.

Victor [04:26]: Well, indeed is quite a journey. So you started right with the roots of agile and scrum as well. I remember those days when nobody heard of it. It’s like this big new thing. And so when you consult clients, or you see different projects, different companies, different maybe even goals or circumstances, is scrum always the right approach?

Sohrab [04:50 ]: Not necessarily, I mean, right is always relative. So for me, I mean, the topic that I try to drive is the overall concept of being adaptive to the situations that you’re in. And I think based on that, claiming that one framework be it scrum, be it something else, is always the right approach would be contradicting the overall philosophy that I try to teach people. And even within a framework like scrum, what I really like about is that there is this continuous improvement of the process as well. And as part of that, the framework.

[05:28] So to your question, no, it’s not always the right approach, but I think what is one of the most important things and what could be considered as on a meta-level, as a right approach is the concept of empirical process control, where you are aware that you have hypothesis in your mind, as I mentioned earlier. And where you start defining experiments or designing experiments that can help you uncover what the reality is and get better and better over time.

Victor [05:57]: That makes perfect sense. And so do you see that more and more people are taking this validation part outside of code and actual coding, rapid prototyping or things like that?

Sohrab [06:11]: To some extent, not enough unfortunately. There is this whole movement coming up about discovery. Because a lot of people associate agile ways of working primarily with delivery. The moment you know what you need, now you start to build it. Build it in small increments and in sprints, and then you get it out of the door faster. I never thought that this would be the intention of agile or scrum as one of the frameworks in that space. For me, the discovery piece. And as you mentioned on rapid prototyping helps you do that.

[06:45] Like defines smaller experiments to validate your hypothesis, everything that Alex O Valer and his company strategize and do around business model design and innovation. All of that for me is also part of the same philosophy, part of the same thinking, where with as low cost as possible, you try to get validation on certain assumptions that you have. But not enough organizations, especially not enough big organizations, startups do this quite well nowadays, because there’s so much literature out there in the startup community people really challenge each other as far as I can see, but not enough of the big organizations are aware of this whole discovery piece. They still believe that they know what their customers want. That’s the assumptions that they still hold. And based on that, they’re primarily looking at delivery options, not so much at discovery options.

Victor [07:40]: And so when we speak about discovery, then obviously the one hour session where you go over requirements, that’s not the kind of discovery that you mean.

Sohrab [07:50]: No, no. I mean, if you do that with clients, it could be, but still probably not enough, but just within your team, going over requirement and creating clarity around that requirement and align it. It’s an important process, but that’s not what we mean with discovery. With discovery we really mean being aware of the assumptions that you hold and the hypothesis that you have, and then designing experiments with code or without code. Usually without code, it’s cheaper to validate to what extent those assumptions are correct or not. And then inspect an adapt based on that.

Victor [08:25]: How would you then compare something like Shape Up to this model? Would you say it’s actually aligned in that philosophy? It seems like it from what you’re saying.

Sohrab [08:36]: Yeah. Shape up. You mean the one from Base camp? Victor [08:39]: Yeah.

Sohrab [08:41]: So I haven’t looked into Shape up in detail, so this as a disclaimer upfront, but I’ve read a bit about it. And based on what I’ve heard, both of Jason Fried and David [08:55 name] say and others, and based on the work that they do with their products. I think they follow a lot of these things or they do a lot of these things in a really good way. To my understanding, again, not too much into it is they do spend a fair amount of time on discovering the actual problem is, the needs, how that can be solved from both design and technology perspective. And then they implement it. And I think they give themselves like six weeks sprints. They don’t call it sprints, but it’s more or less the same concept.

[09:30] And within these six weeks where you try to solve a certain problem, you have a lot of autonomy on how to solve that problem. All of that resonates very, very well with my philosophy. And I think there’s a lot of overlap if you go beyond what a lot of the organizations have done with framework like scrum making it a mechanistic way of working. But if you really look at the essentials at the foundations of it, there’s a lot of overlap with what Shape up does again, I don’t know enough about it.

Victor [09:59]: Yeah, exactly. Thank you. Because that’s exactly what it seems like, that a lot of people when they think or hear scrum, they really only start from the moment you break down things into a billion tasks, try to sort them on a backlog and then throw them at the next sprint and just mechanically work on them, which almost sounds like waterfall to me at this moment. Not quite because you then get the flexibility, but just from a planning perspective and here’s my backlog and these are all the tasks that I need to do. Thank you. Planned upfront a lot of them are, is what I see.

[10:36] Versus show shape up where you have this shaping up phase of like, we’re putting back focus on this discovery thing. So this is very interesting. But now back to scrum, maybe. Why does everyone do scrum slightly differently? That’s what I see from a lot of development teams. They miss out a few of the ceremonies, or are they implement slightly different sprint lengths. Is that how it’s supposed to be?

Sohrab [11:04]: So scrum based on how I see it. And again, I don’t have the expectation that I have the one and only truth, but the way I see it, the way I also teach it, it’s intentionally a lightweight framework. So a lot of the criticism that I heard in the early days, especially from people coming from traditional project management, they were like, we need something similar to the project management body of knowledge PM book, which is like this thick. And I’m like, no, I think in the case of scrum, it is intentionally lightweight.

[11:38] Now the moment something is intentionally lightweight, it basically gives you a few constraints. But within those constraints, you have a lot of flexibility, a lot of autonomy. It basically gives you a canvas, but the type of picture you draw on it ultimately depends on you. And I think for me personally, I think this is a good thing. Now, with regards to sprint length, it is intentional that teams can choose their sprint lengths. And now one of the question that comes up is, so based on what should they choose, what their sprint length should be.

[12:10] And I always give them the two things. One is what is the minimum amount of time that you can spend, or that you need to spend in order to get a real product increment out? So something based on which you can gather feedback and learn that’s one. The other thing is how much time can you invest before you actually get customer feedback? If you can go six months without getting customer feedback, I don’t think anybody can really do that because worst case you might have spent this six month working on stuff that nobody wants.

[12:46] And finding the balance between these two things is really important for a team and whenever possible I try to go into one week sprint. It makes it easy. Monday to Friday. You don’t worry about anything over the weekend. Next Monday, you start with the next sprint. Most teams that I see work in two week sprints. And then there are a lot of frameworks around this if you think about like multiple teams working on the same product, like [13:09 inaudible] agile framework, et cetera. And let’s not go into the debate, which of these are good and which ones are not.

[13:16] But they basically tell every team they need to have a two week sprint, because then you have several of those two week sprints. You end up having a program increment, which is then ultimately three months. So the flexibility here I think is needed. The other reason is I think a lot of teams or people don’t understand the reason behind the individual events, or I think some people refer to them as ceremonies. Why do these things exist? Planning still clear.

[13:46] Everyone probably runs a planning. Daily that’s easy to do. Let’s do this one. The two things that are complicated and that a lot of teams don’t do are review and retrospective. And from my perspective, from my experience, both of those are actually the ones where you get the value of a framework like scrum. One is related to inspection and adaption on your product. So what are we building? And the most important thing about a review is that it’s not the team giving feedback to itself. It’s our stakeholders, ideally customers giving feedback to whatever we have delivered because that’s when we learn.

[14:29] And the intention of scrum, the intention of the review is to facilitate that learning process. And retrospective is about learning about how we collaborate. And if we don’t do that one, we probably won’t improve over time. And both of these things, especially the retrospective was also known as the Kaizen in the lean philosophy. Now think about how many organizations implemented lean, but they never implemented a true pattern or a true habit of running regular kaizens.

[15:04] But only then if you do this, you get the real benefits of lean and only then you get the real benefits of scrum. So I think in most cases, it’s not knowing why these events exist and why we should do them. And therefore they just skip them. And then it looks very different from team to team.

Victory [15:22]: That’s actually very interesting. And so what does a review usually look like? I have my customer sounding board that I invite, I demo them what we developed then we ask for feedback, is that ideally how it should look like?

Sohrab [15:35]: That’s one way to do it. You have your customers, you demo something to them, and then they give you feedback. Another way is you just tell your customers what you have developed, and then you let them demo it to you. Because in that scenario, you also see like, okay, how do they interact with my product? So one of the better examples from my own experience was when we were building a truck using agile ways of working primarily scrum, and we invited truck drivers.

[16:04] And one of the first increments that we had delivered was the cabin. And it was not like the developers or the product owner sitting in the cabin and telling everyone else how they can see things. We ask the truck drivers to sit in the cabin and share with us to what extent the experience sitting in this cabin is different from their regular truck cabin. So the more you can engage your customers, like a traditional product development, that will be a user acceptance test. But in the review, we’re not asking about acceptance. We just want to learn.

[16:37] And we also want to observe the customer in the environment that we put them into. And the better you can create an environment. Again, look at the review as an experiment. The better the experiment is designed, the more learning you can take from it. So customer being there crucial and then involving them as much as possible, even better.

Victor [16:59]: That makes a lot of sense. When you think about the truck cabin, I think it’s just natural to let people sit in it and say what they think about it. But in software, we kind of have this urge to do demos. We do demos. We show it to people, we screen share. So that’s actually a very fair point.

Sohrab [17:18]: And now think about it. We just have to give them one of these devices and tell them, okay, so try to book, I don’t know, try to book a hotel. If you are running Booking.com, ask your customer, try to book a hotel and then try to filter based on certain categories and try to do this. And then you see how they do it and how intuitive it is to them. And also you will see whether you run into a certain box that you have missed, et cetera. Get the customer engaged as much as possible.

Victor [17:45]: Oh boy, would they learn a lot from that? That’s great. And now to the retrospective, what questions should I ask my team here? Or how would that look like ideally?

Sohrab [17:58]: So again, going back to the intention, the intention is to continuously improve on how we as a group of people, as a team collaborate and deliver value. So there are a lot of things you can now focus on from how we communicate, be it like verbally or also in a written format with regards to requirements, or also other things. How do we engage in conflicts? How do we invite our customers in? How do we build the code? How do we write the code? Like the engineering piece of it.

[18:33] All of these different perspectives can come into a retrospective. Now the crucial thing here is A, providing a space. And that’s what a great scrum master or agile coach, or however you want to call this person does. Create the space where people safe to talk about problems and challenges that they’ve been facing? That’s number one. Secondly, prioritize those challenges and problems and then go into identifying the root causes. Some people use the five Y technique or whatever. And based on those root causes, come up with solutions to these problems.

[19:13] And within each of these steps always focus because ultimately you don’t want to get out of a retrospective with a long list of things that you could do. You want to leave the retrospective with one or two things that you will do, because if you don’t do those things, guess what the problems, the challenges won’t go away by themselves. They’re not just going to disappear. And if you don’t have this habit of identifying problems, identifying solutions, and then executing on those solutions, at some point, people won’t see any value in the retrospectives. Because they will say, oh, we do this every two weeks, we spent an hour or two, we just talk and nothing changes.

[20:00] So what you want is to make the change visible, because that results in improvement. And sometimes everything you try is an experiment. It doesn’t go the way you want. And then you can look in the next retrospective, but built this habit of continuous improvement. And from my perspective, if I have to pick one thing and one thing only, it’s always the retrospective.

Victor [20:25]: And I think you touched on a very, very good point here, which is the scrum master, whose job it is to give people that safe space who probably is, I don’t want to say the only person, but one of the few people who are actually motivated and whose job it is to think about this. And a lot of organizations, especially small, early stage startups, don’t have a scrum master. Actually the product manager equals the product owner equals maybe unintentionally the scrum master, the CEO, potentially the designer or the developer or all of it now. But now we’re getting into too small of a team. But now obviously how important is the scrum master?

Sohrab [21:08] It is important, but for example, in my own company, we’re not that big. We’re a total of nine people, and we are split across multiple initiatives, circles, teams, however you want to call them. Now in a team where I work with one of my colleagues producing content for our online courses, we’re just two people. Do we need also a scrum master, probably not? And we cannot afford it. And that’s the thing that I see in most startups.

[21:37] But what’s important is to understand that somehow we manage to create this space for continuous improvement. And part of that space is taking the time. Another part is to work on things that we as a collective of people become better at addressing these problems. Now, what we decided as a company is on a regular basis, engage with an external coach and work on us as a collective. Some organizations might go and say, actually, we do have the budget to get a scrum master for our whole organization. That’s also great, but not having a scrum master should never be an excuse for not pursuing this journey of continuous improvement.

Victor [22:23]: Now I would like to move on to a topic that I also see is very dear to a lot of people, which is estimations. And I think this is. I mean, this is obviously a can of worms and we could have probably five other shows on this topic alone. But agile comes with its own way of estimating, which is not an hours, even though a lot of people, most people actually still estimate in hours, but there’s the concept of points. Can you explain a bit about that?

Sohrab [22:58]: Yeah. So again, a few steps back, scrum is a framework, just says that items should be estimated. It doesn’t say how and the other agile framework, some of them are more prescriptive. Some of them are less prescriptive, but it’s not necessarily that one could say that agile always estimates in points compared to ours. Now getting into this conversation about points and ours. It’s an interesting one. I personally never understood why people would estimate anything in hours because I mean, I understand why they do it because they want to get some predictability.

[23:36] But the very first time that you do that, and then after a week or two, you look at how close those estimates were. You realize that they’re probably not that close. And you see this with every project and the bigger the projects get, the weirder or the bigger the gap between estimation and reality. So what we try to do is to fulfill the need for predictability. What is the problem that we want to solve? We want to predictably say how much work can be delivered in a certain period of time.

[24:13] Now, especially if you look at a team doing this and not individuals. So again, if you’re just an individual, probably you can estimate in hours, depending on how well you know the task at hand and how well you know your own capabilities. Based on that experience, you could probably estimate in hours, how long it will take you to write a text or whatever, an article. But the moment you think about a team where not everyone has the same skill set. Not everyone has the same seniority, but as a team, you’re now trying to make estimates. The whole concept of hours becomes irrelevant.

[24:53] Now, how do points help us? Points by themselves don’t help us because you still have the uncertainty, like how many points do we get into a sprint, which is a certain period of time, a time box. But once you start estimating in points, which is something that you can really do well as a team, you then built the experience over multiple sprints. How many points did we actually deliver sprint by sprint, by sprint, by sprint?

[25:23] And then based on that, that’s what we refer to as the velocity. You can make predictions into the future. Of course, every time your sprint length changes, those predictions become less reliable. Every time your team composition changes, those predictions become less reliable. So velocity, as a point of experience is only so reliable as the long as you keep things constant, the boundaries being the team and the sprint length, and more or less the type of tasks that they’re working on.

[25:57] So if you take a software team and now ask them to build hardware, the velocity is not going to be any indicator that can help you predict the future. So all of these things taken into consideration the velocity or the point system can help you get the predictability that you ultimately aim for without estimating in hours.

Victor [26:18]: This is great because what you’re essentially doing is taking the hour out of the hour. People are still estimating the very same way as they would with hours. This takes one hour as compared to three hours. So this is three times more complicated takes longer. But then what you can’t do with hours is say that I don’t know, we have a 40 hour week. What you do with velocity is you would say, Hey, we manage 30 hours in 40 hours. That’s essentially what you’re doing with velocity. We’re learning that our team can get an estimated 30 hours done in a week or an estimated 50 hours in a week. And you’re abstracting that away and saying, oh, we’re doing points so that it’s not confusing. Is that basically what it is?

Sohrab [27:04]: It is to some extent. So the example that I give is usually if you go back a hundred years from now and you would ask someone, so I sit in Cologne, the next bigger city is, Bon. How far is it from Cologne to Bon? Probably they would’ve told you. It’s like one day of walking or like half a day on a horse. So instead of like, the distance was measured in time until we came up with the concept of that’s a meter and then thousand meters are one kilometer.

[27:36] Now, does everyone take the same amount of time to go through like a one kilometer race? No, it depends on who that individual is. And it depends also what kind of tools they can use. If you have to run, it depends on who’s the fastest. If you have a car or a bike, the whole thing changes. And the story points to hours are the same thing as kilometers to hours. And velocity is basically how fast can you run within a certain period of time and that’s what we try to do. So take work as a concept and try to put an own dimension behind it that is not time. And then see how much of that dimension can you get into a certain time box?

Victor [28:19]: Yeah, it’s just like in physics, it makes a lot of sense. Obviously when we look back at the first agile software teams, that was most famous for these sticker boards and the posted notes. And that was kind of the new thing. Now, fast forward, a couple of years later, things changed a lot. Even before people started going remote, but now even local teams had to go remote. What tools, especially during maybe discovery, because everybody knows the standard duraboard and Issue tracker. But what tools do you really like that enable scrum in a remote first environment?

Sohrab [29:03]: So anything that fosters collaboration and transparency. So for collaboration, I mean our whole team runs on slack, our developers, they use, I think it’s called [29:13 topo] for pair programming remotely, fosters collaboration. We have mural boards in order to again, create collaboration. You can also take mural, whatever. All of them are essentially the same and we try to create as much transparency as possible. So having a process or a place that on a daily basis, you get together, maybe instead of 15 minutes, now you spend half an hour because you also want to replace the water cooler conversation, et cetera.

[29:42] So any tool that can help foster collaboration and create transparency is super helpful. And once you put those things into place, people can work really well also in a remote session and they can work really agile in a remote fashion, but always ask the people. So I had no idea that there was a tool for pair programming remotely, but when the developers came up with it, Hey, we would like to use it. Alright, go use it. Because the cost of those tools in most cases is really negligible to the overall cost that you have. And the productivity benefits that you get.

[30:16] And this is, I think most startups do this really well because they give people a lot of free around what kind of tools to use, et cetera. Most big corporations where you then have to go through procurement and data security and all of that. For them it’s really difficult to have everyone work remotely and still be productive and collaborative.

Victor [30:38]: And do you have also recommendation on issue trackers, everybody’s kind of in JIRA? Do you have anything else you like, I mean, personally, I think they’ve now gotten a lot better in the last years, but maybe you have something that you like.

Sohrab [30:54] Yeah. I think JIRA is great. For us many years ago we didn’t use JIRA because back then they didn’t have a cloud solution. And as a small company, we didn’t want to have one person being in charge of hosting JIRA. So we selected another tool it’s called pivotal tracker from pivotal apps. It’s super simple to use. It just works out of the box. I don’t know to what extent the functionality between pivotal tracker and JIRA is different or what additional things you would get from JIRA.

[31:23] We’re happy with pivotal tracker and my recommendation to people is always use whatever is already there. The tool is not going to make the difference, using the tool in a systematic and disciplined way and ultimately building on top of it, having the collaboration, that’s going to make the difference. So whatever tool is there, just start with it and don’t worry too much about it.

Victor [31:45]: And what are the most common mistakes people make apart from putting too much focus on the tool?

Sohrab [31:52]: I was just going to say putting too much focus on the tool. So that’s one thing. And the other things are putting too much focus on thinking about how to do things instead of doing things and then learning as you go, I cannot count how many and that again, not so much about startups, but mostly big organizations, how much time they spent on designing the agile initiative rather than just trying to do it with one or two teams and then learning from it.

[32:25] But that goes again, back to the mindset that the people have. They believe if they just spent enough time upfront, they can predict all the things that would come up and design a good solution, but that’s not the case. They hold a lot of assumptions that need to be validated. So moving into doing, into the actual doing, and then learning by doing that’s I think one of the most important thing that organizations need to do, and you can always obsess about like, oh, how should we call this role? And how do we do this?

[32:58] Get into doing Nobody cares about what this is called, but you will learn along the way, how you differentiate between the different roles. And who takes, which kind of decisions. That’s so much more important than all these initial stuff that you do.

Victor [33:15]: That makes a lot of sense. And continuing with maybe mistakes that people make, is a few pain points that I see some of the teams having. So for example when a team just has too many tasks in a given sprint and they’re never able to finish, there’s no way, what would you recommend to them?

Sohrab [33:37]: Take less. So independent from whether you’re working agile or not. This is a disease that we see anywhere and that’s the medical doctor in me speaking. And that disease is called multitasking. We still hold the assumption that we can multitask. None of us can, none of us can, even the ladies listening to this podcast of watching this video, you can’t do it either. We can run multiple things at the same time that we have habits on that drive basically on autopilot, like talking on the phone and cooking. And I mean, everyone’s had probably seen this picture and also vacuuming the carpet, that’s all happening on autopilot.

[34:20] But whenever we consciously want to do something and work is always consciously, especially creative work, which like engineering is part of creative work. We can’t do multiple things at the same time. And every time we switch between different things, we lose productivity due to context switching. One of the first advices that I give to people, recommendations that I give to them is take less, doesn’t mean that you don’t do all of these things over time. Just don’t do them at the same time and you can run so many simple exercises.

[34:58] And for those of you who are interested to see what kind of exercise to run, we have a free online course called agile fundamentals. And maybe Victor, you can take the link to that in your show notes. It’s module five of that course, it’s about Kaban and I run a very simple exercise. It doesn’t take you more than 5 to 10 minutes, and then suddenly you will get to the point where, oh man, what have I done all of these time, like really losing productivity individually as a team and as an organization by taking on too many things at the same time. So advice, number one, take less, focus, stop starting, start finishing. One of the credos of the people working in Kaban.

Victor [35:44]: That’s a very good one. And now when you have a team or let’s say distribute it and the product owner essentially trying to figure out what everybody’s actually working on and when they will actually finish with something certain and that information just isn’t there. What would you recommend or is that almost a disease in itself in wanting to know that very much detailed?

Sohrab [36:10]: I mean, if you really want to know what every single person is working on at any point in time that probably result, or is big based on not a lot of trust within the whole team. And I emphasize on within the whole team, because you cannot only put it on that one person on the product owner, but how do you deal with that? How do you create trust where there is no trust? One of the better things to do is to create transparency and the intention of, for example, a sprint backlog and the intention of the daily scrums is to exactly create that transparency.

[36:44] And based on that transparency that you create, you also create the space for impediments being raised and addressed, and you also create the space for alignment to be created. So really taking these two simple things, a sprint backlog, looking like a Kaban board, by the way, it can help us also with the previous disease that we talked about, like visualizing how many things are happening in parallel, and then reducing that. It can also help you create all of the transparency needed from the product owner side, but also from the side of every other person in that team to see how are we making progress? Where can I help and whom can I ask for help? And based on that become a better team and deliver better products.

Victor [37:32]: And how about when we have lots of bugs or urgent issues that just keep derailing a sprint, just keep coming up and got to put them in there. And here’s my sprint gone. And I probably can’t even finish the complete feature, the outcome that I actually wanted to finish in that sprint.

Sohrab [37:55]: Make it visible, in that sprint backlog, make it visible, like this has come up and this has come up and our servers are down and this. Make it all visible and then make also visible the impact that it has, which is as you mentioned, Victor, we cannot get the features done that we wanted to build in this sprint. And not getting the features done probably we are also not getting the outcomes that we wanted to have as a goal of this sprint.

[38:24] And then talk about it in the retrospective. Is this just a one time thing or have these issues come up over and over and over again? And that probably means that our legacy system is probably a big source of disruption. Now, what are we going to do about this? Are we going to take the time to refactor some of those pieces in that legacy system? Probably yes. It becomes a return on investment calculation. If it’s just a one off, alright, you dealt with it, move on. If it happens constantly, you either create a buffer or you start addressing the root cause of this disruption.

Victor [39:05]: And probably a somewhat similar question is, when I have to keep discussing mid sprint with people, how things should look like if the team is not certain about what is being developed and either discussions come up mid sprint and tasks just get bigger or they have to be just reopened because the product owner realizes this is not what they initially wanted to have developed. What would you tell a team like that

Sohrab [39:37]: To use common sense. We’re laughing but because a lot of teams, again, look at this whole thing as something mechanistic. But in the sprint planning, we said that we will deliver this. Alright, no, during the sprint, in the sprint planning, we have a certain level of visibility and depending on the product that you’re working on, the people that you’re working with, sometimes the weather is a bit more, sometimes a bit less foggy, but it is in general foggy.

That’s what uncertainty feels like. So now we are in the middle of the sprint and now we see that on our most important item, there are a few things that we initially forgot to mention, but without those things, it feels incomplete and it doesn’t really deliver value to our clients. So what do we do? Just because we forgot them initially, we just say, no, no, this is now done. And please open a new ticket so that I can move on to the next one. And then we can talk about this in our next sprint planning. It doesn’t make a lot of sense.

[40:40] That’s where we need to have these individuals and interactions over processes and tools. We talk about it, the product owner says, you know what it would be great if we could do this on top. And the developer says, you know what I can do it. But probably the one item that we have currently at the bottom of our sprint backlog that will fall into the next sprint. And the product owner says, okay, I can live with that. Thank you for letting me know. And that’s the kind of collaboration you want to see mid sprint, and you don’t want to have the debate about, do we open a new ticket or not.

[41:12] Now, depending on the context that you’re in, it is clear why these conversations might come up because you have a product owner, which is the company. Like trying to build a product and then you have a supplier supplying them with developers and they’re being paid based on, I don’t know what, the velocity or whatever. You can take out a lot of these debates if you just say, for example, we’re paying you per sprint. So mid sprint, we don’t have to debate whether this is an initial ticket or not. Because if you’re getting paid by the tickets, you would want this to be an initial ticket.

[41:51] So go back to what is incentivizing different types of behavior and whatever is not an incentive towards better collaboration try to take it out. Create the contract in a way that it fosters collaboration and doesn’t inhibit collaboration. That it fosters building trust to each other. It doesn’t inhibit building that trust, and I’m not a legal expert, but I’ve seen a fair amount of contracts in the past. And some of them really incentivize having these debates instead of delivering value. So that’s my two cents on this.

Victor [42:31]: And that makes a lot of sense. Obviously fixed prices, scrum or agile, don’t really mix well. Thank you so much for this very enlightening episode. It was very, very good to hear your thoughts on this. Where can we learn more about you personally, as well as the scrum academy?

Sohrab [42:49] Our company’s scrum academy is the host of a bigger platform, which is called Agile academy. Also easy to remember agile-academy.com, where you not only find the courses and offerings that me and my company offer, but also which a lot of our partners offer both live trainings, online trainings, a hybrid of those things. Because our mission is to make society more productive, more humane and more sustainable. And given the times that we are in, I think this is so much more important than we try to support this journey. That a lot of teams, a lot of organizations and whole societies are on with the knowledge and experience that we have. So just go to agile-academy.com and you will find more about us.

Victor [43:34 ]: Wow. Great. And you were speaking about the scrum master, coaching, training, the scrum master on demand. Is that something your company provides as well?

Sohrab [43:45]: Yes. So we provide the education piece around it. We can also help you with a few coaches that help you in the short run. But our intention with every company that we work with is to not give them our scrum masters for a long period of time, but help them build that capability internally because only that makes it sustainable.

Victor [44:06 ]: Amazing. Thanks for coming on. It was a great show. Sohrab [44:09]: Thank you Victor for hosting me. Great to meet you.