When Doing Scrum, Don't Do Scrum: Focus on Problems, Not Frameworks
The Meridian Point Podcast
Host: Kumar Dattatreyan
Guest: Sven de Koning
Kumar Dattatreyan: Hi, everyone. Kumar Dattatreyan here with the Meridian Point. Thank you for joining us. Welcome to another episode of our podcast. And today we are talking to Sven de Koning. I don't know if that's the way you say it. I'm hoping I didn't mispronounce it. And he's one of the Netherlands' most experienced transformation practitioners with over twelve years in the Scrum and Agile space. After building his reputation coaching teams across pan-European organizations, he recently made a bold pivot from Agile coach to Product Owner, bringing a unique perspective on what it really takes to create customer value. Today, we're exploring how frameworks fail organizations, why the Agile coaching market is saturating, and what it means to solve problems without the methodology baggage. Sven, welcome to the show. And let me pull you back in. It's really, really nice to have you on.
Sven de Koning: Happy to be here. And you said my name perfectly.
Kumar: Okay. That's good to know. Thank you. All right. So you spent a decade as a Scrum Master, right? And coach. And then you transitioned to Product Owner. This to me is like the essence of this show, the disruptions that we all go through in life and how we respond to those either individually or the organization does so. Let's talk about yours. Walk us through your decision to move into that area. What made you move?
Sven: Okay. It's because of my background. At the university, my education was to be a UX designer. I have done some UX design, functional design. I've always been the bridge between one side IT and the other side users and customers. And that transition after a while, it was fun, but I wanted to look more at the process. I had the chance to become a Scrum Master because there was a gap at the current organization and I jumped into it. I've learned a lot through those years, but after about eleven years there was this itch again of looking more towards delivering value instead of creating the optimal process. Yeah. Once again, the universe has strange ways of showing its existence, but there came in another vacancy at my current company for a Product Owner. So I made a switch.
Kumar: And how's that going?
Sven: It's fun. It's really great. I've now I'm doing it a while. I know now how much I've missed it. But also the experience I gained during my time as an Agile coach and Scrum Master, they also come in handy now. I learned to appreciate the process and I know where the bottlenecks are and I can use that knowledge to improve some stakeholder management. I can explain easier to my stakeholders, "You have a great idea, yes it delivers value, but at the moment, I'm giving priority to X, Y, Z because of these reasons. And so, sorry, not at this moment, I'm going to do this, but I'm going to put it on the backlog and looking at it, I think I can have next quarter or the quarter after that, we have the conversation again about why this is important for you."
Kumar: Yeah. I think it makes a lot of sense. So with your experiences as Scrum Master and coach, do you find that the company said, "Oh, you've done both. Maybe you can just do both roles for this team"?
Sven: Yes, and when I made the switch there wasn't a replacement for me as a Scrum Master. I became a Product Owner in the team where I was the Scrum Master. And they were looking for a new one and I've done both roles, Scrum Master and Product Owner for a little while together. And all the years I've been yelling why that isn't a good idea, they all came up, why that isn't a good idea. It's the conflict of interest. As a Scrum Master, you want to have an optimal flow, but you also think about the team, the interactions between the team members, between the team and the rest of the organization. And as a Product Owner, one of your main goals is delivering value. So you're tempted to push a little bit more on your developers. "Okay, you said this would be done yesterday but it still isn't ready, why not? It needs to be ready now." And your Scrum Master at that moment is your conscience. "Yeah, okay, we understand but these are the circumstances that disrupted our process at the moment, so yes, at the daily yesterday we thought we would be finishing this but this is the reason why it isn't done yet." So you're missing your conscience.
Kumar: Yeah, it is a hard thing to do. I remember early in my career I was the project manager, the Scrum Master and the Product Owner for a couple of teams because it was new for this organization. I was sort of the evangelist saying, "Hey, we should do Agile," and so I ended up wearing all these different hats and it was really hard for me to keep it all separate. And so I actually went to make it fun and make light of my predicament. I actually had hats made, literally baseball hats with PM, SM, PO on them. And when I talked to the team I would always take my hats and I would put the hat on that I was speaking from so they knew where I was coming from and I knew where I was coming from. So it was a little easier for me to be schizophrenic that way. And it's not that I'm recommending that in any way, shape or form. It was hard to do. But it was something that came to mind when you were describing your conundrum.
Sven: Yeah. The hat thing also provides transparency in what your mindset is at the moment.
Kumar: That's right. That's right. Yeah. The team thought it was funny, but it was helpful, I think for them and for me. So I, luckily I didn't have to do that too long, but it's still something I remember. You said something in our prep conversation that stuck with me. "Transitioning to Scrum isn't the goal," but organizations everywhere are obsessed with framework adoption. What's wrong with this picture?
Sven: For me, what's wrong with it is they see transitioning to Scrum as a goal instead of looking at what's the problem we are trying to solve here. There is a famous book written in the beginning of Scrum, "Doing Twice the Work in Half the Time." It's a terrible, terrible title. And it for me gives a bad idea of what Scrum is about. It's about delivering value and it's about delivering the right thing and it's not about going faster and delivering more. It is not a magic turbo boost you put on your conveyor belt for software development.
Kumar: Yeah, I totally agree with that. I've been reading a lot about SpaceX and how they do their development. And they're very agile as a company. Tesla as well. It's all these Elon Musk companies. And whether you like him or you hate him, he's a very polarizing figure for sure. But one of the things that I think I admire about him and the companies that he's created is he's imbued the sense of agility and empowerment in the people that do the work. And so it's not about Scrum or frameworks. It's more about what are the problems to solve and how can we together as a team solve them? It's not about epics and features and stories and breaking things down. It's more about what are the problems and what are the solutions to those problems? And that really kind of resonates with me that we have gotten away a little bit and we are maybe a little too prescriptive in our frameworks. And we could learn to be more adaptable by really focusing on the problems to solve. What do you think?
Sven: I couldn't agree with you more. When I started at this company, there was one small team that was working, let's say traditional with planning and planning weeks and months ahead and stuff like that. And the manager at the moment said, "They need to go. They need to go and use Scrum." But why? "Yeah, everyone, every team is working with Scrum. So they also need to work with Scrum." Yeah. But what are we going to solve with it? Yeah. And he couldn't explain that to me. And it was just an order given. They need to use Scrum, period. So I just looked at what were the problems they were having at the time? And it was a lot about team communication and things like that. So what I introduced was the daily Scrum. And there was a problem with stakeholder communication. So I introduced the review and I could say to the manager, "Okay, they're working Scrum now. Look, they got the dailies, they got the review, they are working Scrum." And the team at that moment, the planning ahead of looking, "Okay, this is what we are going to do the next sprint" and things like that, that didn't work for them. They were a small team and there were so many bugs and fixes they also needed to do. Planning was just a disaster. So I just gave them the tools they needed to solve their problems. I could say to the manager, "Hey, they are working Scrum," and everybody was happy.
Kumar: Yeah, sometimes it's the words you use, right?
Sven: Yeah.
Kumar: I had a similar experience recently with a team. I won't go into the details, but basically the same kind of thing. And so it's really understanding that work, how work flows to the team and then designing a system that fits the way that work, and not trying to impose things that are not going to work for them. You know, they're definitely not a Scrum team because their work is so variable that they couldn't possibly plan something that they could deliver in two weeks or even four weeks for that matter. So I think that's the key is being more adaptable to the situation on the ground and using what we know about Agile and value delivery to create ways of working that fit how the team is set up, how they're designed in a way. Go ahead.
Sven: The goal of Scrum isn't having all those, having a daily and having a review and having a retrospective and things like that. The goal is delivering value and having the products that the user needed.
Kumar: That's right. That's right. Exactly. I'm going to switch here a little bit. The certification economy. And this, the Netherlands has the largest certified Agile group per capita. You have the most certified Scrum Masters and coaches and things like that. Yet traditional coaching work is drying up. What do you think is creating this paradox of more certifications but less opportunity?
Sven: I think it has everything to do with the quality of the people. Some companies view, for instance, the role of Scrum Master as a beginner role. People come fresh out of university, they take a two-day course of getting their PSM-I. "Congratulations, you're a Scrum Master now and you can go to a company now and we can bill a hundred euros an hour." Being a Scrum Master isn't an entry-level job. You need to have experience. You need to be in the trenches. You can have to be a developer or a tester or you need to have had experience within the field of being a software developer or at least close to it, having also some people skills with you and knowing how to handle political situations and things like that. And I think, yes, the Netherlands has a lot of certified people, a lot of certified Scrum Masters, a lot of certified Product Owners. Well, the number of Product Owners, even worldwide, are less than Scrum Masters. And it's all about some companies seeing a market. "Oh, they're asking for Scrum Masters. So we take some people who come fresh out of university or have one or two years experience. We give them a Scrum Master training and they can become a Scrum Master." The problem with those people is they are too young to be able to explain what their added value is. Right. And the moment companies need to cut back, the first thing they're looking at, "Okay, what doesn't add immediate value for me?" And if you as a Scrum Master or an Agile coach, you cannot explain what your added value is, you're out of the door. Yeah. And also, once that company decides to cut away their young Scrum Master, they aren't really eager to hire a new one, maybe an older one, maybe a more experienced one, but most of the time, perhaps a little bit more expensive. Yeah. So that's where the value is because they have that experience and they can actually help the team deliver more value. So yeah, why wouldn't you invest in that?
Kumar: No, it makes sense. And I totally see that here in the U.S. as well. We have lots of people that are certified saturating the market, but it's what has resulted in rates going down, you know, what people pay coaches because there's a glut. There's lots of supply and not enough demand. So what happens to rates? They go down, salaries go down. Speaking of which, in the Netherlands, you and I talked about regulations around independent workers having major unintended consequences. What's happening there? Why does it matter beyond the Netherlands, in your view?
Sven: Well, at the moment there is a new law. That law has been here a while, but it mainly focuses on independent workers. And that law is all about, for instance, in construction, the situation you could have there is that the carpenter was laid off today and rehired as an independent contractor tomorrow for an hourly rate of thirty-seven euros. Well, thirty-seven euros an hour isn't enough for someone to pay all their bills, pay all their social costs like health benefits and also have a solid retirement plan. So the Dutch government wanted to stop that and introduce this law. What they totally skipped on was there are a lot of professions like coach, like Scrum Master, like Product Owner, like software developer, et cetera, but also outside IT work that have an hourly rate that is sufficient for having all those things. So being able to have some savings for the rainy days, having savings for your retirement plan, also your health benefits and things like that. But it also affects them, this law, because companies are saying, "Okay, we are hesitant with hiring independent contractors because of this new law. Our IRS can fine a company if they think you've broken the law." And those are really hefty fines. So companies are really hesitant with hiring independent contractors.
Kumar: Oh, wow. Interesting. I don't, I certainly the move here in the U.S. is away from contractors but it's, I don't think there's any law that prohibits it here at least not yet. So we'll see. Knock on wood, I hope for you it stays that way. I'm not sure how it's going in other countries in Europe, but the one of the downsides of the European Union is if one country implemented a law successfully, other countries will copy it. And after a while, it even becomes a European law. So I really, really hope that doesn't happen with this one.
Sven: Yeah, that would be unfortunate for sure.
Kumar: Yeah, because we cannot work without a flexible workforce. For instance, this year in my company, I have some larger projects and I need a flexible workforce for those projects. And it would be a shame that I need to go to the higher rate companies, "Okay, deliver me some software developer or something," and I need to get them from those companies instead of getting the best.
Sven: Yeah. Because it limits your ability to be flexible and get the best talent because of this law.
Kumar: Yeah. I guess the intention of the law is to level the playing field, but it's having unintended consequences in the process.
Sven: Yeah. That's unfortunate.
Kumar: I wanted to switch topics. So I know this is going to be a disruptor. Hopefully it won't spread across the EU, but something that you have to deal with now. When someone brings you in, are you a contractor now or are you not?
Sven: No, no, no. I'm employed by the company I'm working at.
Kumar: Okay. And you just made the switch from coach to Product Owner within the same company.
Sven: Okay. Yes.
Kumar: So when you made that switch, how did you approach your new role? What was your first question to try to figure out where the problems were?
Sven: I didn't ask questions. My first move of action was keeping my mouth shut and just sitting at the office floor. We have a lot of large office spaces. Yeah. And just sitting there and listening what's happening around me. The second step was looking at the work my predecessor did and after that just talking to users. "Okay, how do you use our products? What does it do for you? How do you use it in your daily work? Where does it irritate you? What do you love about it?" Things like that.
Kumar: Yeah, no, that makes a lot of sense, especially in the product space. I would think it would make sense for anyone on the team to have that kind of curiosity, right? So have more of a product mindset. If you're on a team developing the products, usually what you see is, and maybe it's not the case in your team, but what you see is that the team has really a bunch of order takers, you know, like they're almost like cooks in a restaurant. They get the order, they go prepare it and off it goes. They don't really have the time to ask why or who it's for or get to really know the customer. That's one of the benefits we have. A lot of the software we develop we are using in-house, so there's a short distance between developer and user. And sometimes I intentionally keep the question vague, and there come a lot of questions from the developers, and I'll say, "Okay, go talk to the user. They know best. I can tell you, but go talk to the user."
Sven: That's great. I mean, it's great that you have that luxury, that you're developing solutions that are being used within the company, and you can actually go talk to people that are using it to get what they need, right, and how it should work.
Kumar: Yeah. What would you say where there's many layers that separate the user from the developer, from the team?
Sven: If the distance is longer between user and the developers, the end result is suboptimal at best.
Kumar: Sure, but how do you simulate the conversations that your team members have with users?
Sven: There are different options. One of the things is we can invite our end users at the office or we go to the end user at their office. "Show us, how do you use it? This is what we have made. This is our first prototype. Do you like it? What do you like about it? What don't you like about it?" From my background as a UX designer, I do a lot of graphical stuff. So we make some UI design and then we test the UI design if that solves the problem or if that resonates with the users. And if that resonates with them, then we build the backend instead of completely creating the full product and then finding out, "Okay, this is great, but it wasn't what they were looking for."
Kumar: Yeah, that makes sense. Makes a lot of sense. I mean, certainly there's user research and user design and human-centered design and all of these things that help teams get closer to the user. I'm just wondering, you know, I think all these things have helped me as a coach because I primarily I'm a coach, but they've helped me coach better in the teams that I coach, the organizations that I coach, because I feel that I have more of a product orientation, like what are the products and services that we're providing and how should we organize ourselves as teams to deliver value? Do you think that's, as a coach, what are your feelings about that?
Sven: That's how I've operated throughout my career. For me, if you are in a product environment, you are in the business of making users happy. If that's the way you can make your users happy, it works. Your end goal is making something for that user. It isn't delivering something and your product isn't ones and zeros. It's a solution for your end user. So in any way that you achieve that goal, that works. And there are a lot of different ways of achieving that, like A/B testing, like UI testing, things like that. But having an end user-centric mindset is really important here.
Kumar: Yeah, and I guess my point is for all the people that are certified in Scrum and coaching and stuff like that, and with not that many jobs available, it might be good to sort of examine what you do as a coach, right? To really focus more on the value that you're providing. And part of that value is helping the team develop a product mindset so that they're closer to the customer or the services that they provide because if you don't do that then what value are you really providing as a Scrum Master or coach?
Sven: I totally agree.
Kumar: Yeah. All right. We're going to wrap up with a few fun questions. These are lightning round questions so quick answers. Biggest waste of time in most Scrum implementations?
Sven: Focusing on Scrum.
Kumar: Yeah.
Sven: And not focusing on the problem you want to solve.
Kumar: Okay. I love that. All right. When you're doing Scrum, don't focus on Scrum. Focus on the problems. I love it. Yeah. One certification every Agile practitioner should get or skip.
Sven: For me, the most value I got from the PSK, so Professional Scrum with Kanban.
Kumar: Okay.
Sven: And it shows the gap Scrum has that optimizing your flow. Yeah. And it shows that combining those two frameworks is really powerful.
Kumar: Okay. I love that. Yeah. I often coach that way. So maybe that's something I need to look at. If you could eliminate one Scrum ceremony, which one would it be?
Sven: For me it would be the review.
Kumar: And why the review?
Sven: Because a lot of teams focus, "Okay, we have a sprint of three weeks, so at the end of three weeks it's the first time we need to have contact with our stakeholders." Hey, you need to have constant contact with your stakeholders. So have those conversations about your backlog, about the product, about what you are delivering, have that throughout the whole sprint. And everything during the review you tell there and show there shouldn't be a surprise for the stakeholders.
Kumar: Yeah, that's great. I love it. You blog as Scrum Ronin, Samurai without a master. What is your current mission?
Sven: My current mission is a happy solution for every problem.
Kumar: Oh, okay. I love that. That's very, that's something that people can get behind. I love it. All right. I'm out of questions. Anything you want to share that I didn't ask you?
Sven: Well, what I would like to talk to you and would like to pick your brain about is I was telling about that Scrum Master isn't an entry role. My background, I used to be a software developer. I started my career as a software developer. I used to do functional design. I was a software tester for a short while, and that all helps me with my role as a Scrum Master and also my growth as a Scrum Master. What are your thoughts about it? Do you, is it a good idea to have a technical background or do you think it's more people-centric or?
Kumar: I mean, in my view, you definitely have to have more experience as a Scrum Master or coach. I don't think it's, I mean, one of the best Scrum Masters I ever worked with did not have a technical background at all, but he had the ability to ask the right questions at the right time, the powerful questions so that the team was, you know, they had to sit back and think about the answer. They didn't have a ready answer. And so he was amazing at that, to be able to ask those powerful, those wicked questions. And I think in some ways, when you don't have a technical background, you're working with a team that is technical, that they're developing software, you almost, you have to be more curious, not less, because you can't assume anything. You don't know. You don't know how these things work. And so you can be completely, you can ask those open-ended, dumb questions, if you will, that maybe those developers and testers and so on aren't really thinking about because they have come to a certain assumption about how things should work, look, feel, whatever. So I'm not saying that people that are technical make poor Scrum Masters, no. But I think there's a little bit of a barrier for them to get over so they can adopt this curiosity-based mindset as a team coach or a multi-team coach that they cannot rely on their knowledge and make assumptions about how something should work or is working. They have to ask the team, they have to take it to the team. So I think I agree with you in that Scrum Masters, that role has been bastardized like to no end. They are really meant to be strong, experienced coaches that can coach at all levels in an organization. And that's not the case. That's not what we're seeing today with Scrum Masters.
Sven: Right, I agree with you that I sometimes have the discussions or the question is, what's the difference between an Agile coach and a Scrum Master? And for me, the difference between those two is an Agile coach is a Scrum Master without a team. And with that, I mean, a Scrum Master isn't only about the team. A Scrum Master should be comfortable at the team level, but also at the C level within the company.
Kumar: Yeah, absolutely. I agree one hundred percent. And I just don't see that in the industry right now. Scrum Masters are more junior and they're treated that way and they're paid that way. And they're more administrators and coordinators than they are team coaches. You know, and so not to say this is a blanket statement. There are some amazing Scrum Masters out there that take pride in what they do. But the majority of the people I see, I'd say seven out of ten are pretty green. You know, they're pretty new to the role. And so they end up doing what they can and not really adding a whole lot of value to the team. So if there's a parting thought for me, for people that are Scrum Masters is really invest in your craft, you know, coaching, not just knowing Scrum, because as Sven mentioned earlier, if you're doing Scrum, don't do Scrum, meaning it's not about Scrum, it's about solving problems. And so if you're a Scrum Master, learn how to solve problems for your team. Not that you should be doing it, but you should be challenging them to solve their problems. Would you agree?
Sven: Yeah, totally, totally. And also try to get across what software development is. For a lot of my experience with a lot of managers is managers think software development is more like creating a car, so as long as we give you the parts you can build that car. But software development is more like writing a book or creating a painting. It's a, you should be creative. It's a creative skill being a software developer.
Kumar: Very complex endeavor.
Sven: Yeah, it's not a complicated endeavor. Like building a car is complicated. You got all these parts, you got to put them together in the right order, torque all the bolts to the right specifications. It's complex, but not complicated. Once a car's been designed, it's complicated, but not complex to put together, where software building or anything creative building is complex. And so, yeah, you're right, for sure.
Kumar: So that's one thing I would like to give with the Scrum Masters out there. Make sure everyone within the organizations understand what the process of software development is. It's not you make a wish list and it's built that way. There are so many creative decisions that need to be made and also be, if you as a user, if you ask something, be ready to be involved in the development process. Be there when developers have questions. Be there to do some acceptance testing. Be there to do some functional testing with the tester of the team, things like that.
Sven: Yeah, no, I'm with you. I, you know, this spurred another thought in my head and I know this is going long but I think users, viewers may appreciate it. Do you think the Scrum Master is a role or a title?
Kumar: I think it's a full-time role.
Sven: Okay.
Kumar: Because it requires a dedication.
Sven: Yeah. I have been a Scrum Master part-time, like being a part Scrum Master, part tester, that collides with interest. The moment you need the Scrum Master the most is when you have a, when stuff hits the fan situation. That's also the moment you need everyone on the team to play their A game. So at that moment, if you are a developer and Scrum Master or a tester and Scrum Master or whatever, you need to be two persons at the same time because you need your Scrum Master to kind of be the guard dog at the door of the office. If everyone wants to try in, "Okay, I hear your problem, but not now. We are busy. We're trying to solve, we're trying to put out this forest fire." But also that developer needs to be there at their A-game. So you cannot be a part-time Scrum Master, in my opinion.
Kumar: Yeah, that's a fair argument. I've seen where it does work, where the Scrum Master rotates through the team. Everyone is playing that role one iteration at a time, it rotates. And I've seen that working reasonably well, but you're right. When stuff hits the fan and you need to have your A game, then it can be a little challenging. That company still had some coaches that helped coach the teams, but to coach the teams to really be self-sufficient. And I thought that was really elegant the way they did it. But it doesn't work everywhere. I think the culture has to be supportive of that sort of autonomy. And I think it can work, but I love your argument that, no, it's a full-time role, that there needs to be someone with focus and dedication to it.
Sven: Yeah, also the rotating can work, but my experience with that is when the role of the Scrum Master rotates within the team, the focus is also on the team. And the moment you are a full-time Scrum Master, you have room to go outside the team to go to the organization. Also, have that talk with that one stakeholder who's constantly knocking at the door. "Okay, is it done yet? Is it done yet? Is it done yet?" You have the time to explain the process, but you also have time to sit down with the CTO about the new implementation of the new Oracle version, why that could be a danger for your development process and what you need from the rest of the organization about implementing that new version and things like that. And the moment you start with the rotation of the Scrum Master role, the connection outside the team is the first thing that gets lost.
Kumar: No, that's a very valid point and a good argument that supports the idea of it's a role, not a title. Right. Even if maybe people are rotating through it, it's still a role. It needs to be a full-time role, even if it's one sprint at a time, which means that everyone has to be proficient at that and have the social skills, the people skills, the emotional intelligence and the knowledge and the gravitas to be able to speak to people up the chain. Right. So good points, but we are a little long. I'd love to keep talking to you because this is fun, but I'm going to respect our time box. We're a little over our time box, but that's fine. We had a great discussion. Thank you again for coming on the show, and I'd love to have you back on. Maybe we can take this conversation further in another direction, perhaps, in the future.
Sven: I'd love to come back and love talking with you, Kumar. Thank you very much.
Kumar: Yeah, thank you so much. All right. Thanks, everyone. Thanks for watching, and we'll see you next week.
