Scrum Facilitators Community podcast

Is the Scrum Framework too hard to understand? Discussed with trainers Magda, Kate, & Pawel

• Scrum Facilitators • Season 3 • Episode 3

Share episode

Recorded in Paris, at the Scrum.org Face to Face event for Professional Scrum Trainers (PST). Scrum Facilitators own PST Sjoerd hosts Magdalena Kucharska, Kate Hobler and Pawel Mysliwiec. 

In this episode of the Scrum Facilitators Community Podcast, the participants discuss the topic of understanding Scrum and the challenges associated with it. They address the perception that if people don't understand Scrum, the problem may lie within the framework itself. They emphasize that Scrum can be difficult to understand due to its complex nature and the presence of numerous myths surrounding it. The participants also highlight the importance of experienced coaches and facilitators who can guide individuals and organizations in adopting Scrum effectively. They suggest that the Scrum Guide, while deceptively simple, requires a specific mindset to fully comprehend its principles and apply them in practice. The podcast participants offer suggestions for potential improvements to the Scrum Guide, such as rephrasing certain terms and clarifying misconceptions. Overall, the conversation revolves around enhancing the understanding and application of Scrum to achieve better value delivery and collaboration.


A big thanks goes out to my guests and colleagues for their courage to discuss this topic that came out of a ‘controversial statements’ brainstorm. I really wanted to discuss this topic, because Scrum experts can have a tendency to downplay or straight up strawman people’s struggles or grievances with Scrum,  by responding ”you are doing it wrong” and/or “you don’t really understand Scrum”. It was an interesting and insightful experience to discuss this topic with a group of Trainers whose job it is to guide and teach Scrum to improve teams and organizations effectiveness , by helping people understand Scrum and benefit from the framework. 


Links:

Are you working with Scrum/Agile and have similar stories and tips to share? Or do you know someone that you want to voluntell to be a guest? Reach out! podcast@scrumfacilitators.com

Also check out our website, LinkedIn and Meetup


Welcome to the Scrum Facilitators Community Podcast. The place for real conversations around scrum time. Hi and welcome in the scrum. So that is podcast where I'm joined today by my dad, Bill and Kate actually three Polish speaking deceased who are not going to speak Polish unless they're going to curse. And we had a face to face summit in Paris. And we have a small audience who will cheer us or who we say stupid or cool things. So before we start, I just want to shout out the topic we're going to talk about. And then I'm going to ask you all to briefly introduce yourselves and keep it up. So the topic we'll be talking about is if people don't understand Scrum, maybe the problem lies within the framework itself. So hold onto your seats. We are going to discuss this, but first give you a bit of insight whose side this piece. Tell me a short thing about yourself. Thanks. And Kate Helper and I am a Polish PC. I've been working with companies and agility and stuff like this for some more close to 14 years now, and I really enjoy that community. I'm based in Poland, but I work all over the world and I Google a company that does its own thing, things that my name is the first color on the piece. You train their and they also work as a as a square muscle, and that includes whatever the company needs to call me to feel better about optimizing the work. So currently I'm a mum, so it takes a lot of time also to be a trainer and a mum of the full day job. My name is Bubble when she gets you right to use it as a friend. So okay, they don't because this is polish, this is quality. Definitely so focuses on failure for the past seven years or so. Come on trainer. And I've been using Scrum consciously for 11 years and I'm consciously for additional three unconsciously because I was a product manager and my team was using Scrum. I never knew they were coming. I was the product owner for at least a year. In my previous experience, so that was a fun discovering and the training that we've been using. Scrum and I do note anyway, it would be interesting to have a discussion with you about this if you have some time. Yes, maybe for another. So but it also ties in a bit. Maybe. Thank you. Go into the the topic we have because you didn't understand Scrum at that time that you were doing stuff that transformed the scrum. And we're going to talk now about okay, there's a sentiment that we can finally align with your audience and that sometimes is also put out there by us or our fellow beasties. Like if people don't understand trauma, they can't get it to work failing. They just misunderstand, you know, and this can give off the sentiment of these people just going to people stupid, basically, for not care, which is not what we want to do. We want to achieve better flow, better value delivery, and better collaboration with Scrum. That's the goal. Scrum, right? So how can we change this narrative and really inspect and adapt our own position on this? And I'm really excited that you discussed this with So who wants to kick off? So okay, let me rephrase the question because that's became to start. Is Scrum hard to understand that? Hell yes. Why? It's like, you know, there is this old saying that scrum is like chess. And I think it's very relevant because the instruction manual for chess is less than half a page. It's it's very, very easy to kind of grasp, but to be able to move around, to remember all of the rules and understand how these rules work with each other, That's something very different. On top of that, if it comes to chess, there are myths, but it comes to Scrum. There is a boatload of myths. And so in every single place I have been working with, I'm debunking in one of my professional Scrum products or classes. We have spent almost all day debunking myths that have been introduced by tools for like so-called agility, like backward management and stuff like this. So in that given that environment, understanding what is Scrum and what is not, even though there actually is a guide for it, it's not easy to ask. That's interesting. So maybe one of you wants to respond as to what role the guide plays in this understanding or misunderstanding. It's just people not reading it properly or is made it from problem also b with the phrasing, the wording, etc.. So what's your take on this? So I think from my perspective, Scrum introduces a totally new category that we're not used to working on the day to day basis. So the idea of having the resources give a straight or straight came up with accountabilities for us to work on all of the product development, all the wording that we see happens for us for the first time, we're not really sure. We haven't even seen that before. Who's actually the scrum most was the product that we tried to fit into roles. So we we've already seen the workplace before and tried to fit them into the new idea that just come across. And I think that might be one of the issues that we tackle. We try to get tried to fit in what we know to the new instead of trying to open up and see. Maybe the new is actually the new right. So maybe try to approach how it is. And that's not to try to fit in the work that we already see, to try to we set what we know come come up as a new idea. But so are you basically saying that people and organizations starting to work with Scrum from Scrum should like really be coach and facilitators in a way that they can first endure and then learn a new or I think from my perspective, a couple of approaches we can try to learn from their approach. We can start with the approach. Let's start what we have right now and try to optimize for value, to bring the best product product that we can for the customer needs and wants. However, the approach is only to get us to the goal. So whatever the company needs of the company needs at the moment, we can try to get the best that. However, the constraints constraints with history because the company is already existing for some amount of time or with the greatest value and trying to, to be honest, to destroy everything they did so far by saying what you did before is wrong might be the approach actually to not make them want to work anymore. One of the issues is the way we try to phrase it. Yeah. So the problem maybe is not understanding scrum, but understanding how to go from where you are at to the place of value delivering a flow and how strong can help in that. So it's not about strong, strong scrum just to. However this discussion is about how we are teaching scrum and how we are putting trying in the world and a lot of books. But as one guy, so I didn't know if this was going to be what you wanted to talk about, but let me just put this out there and you want to waltz around it. We're not. So where in the guide are the problematic parts? Like what? What is are the parts of the guide that needs in most problems to get is deceptively simple. I mean, when you when you read when you read this from Guide, it's deceptively simple and maybe it will get you in trouble in terms of my license. But all of us where this is, let me put it this way, I've had five years of what I consider a solid scrum experience in the company coached by people who I consider professionals. And when I attended Training the Trainer event, when I was already passed the vetting process, I realized how much what I knew was wrong. Even though it's deceptively simple. And then not only I didn't realize a lot of things I knew was wrong during the training. The trainer. Later the same year I was with a client and and by seeing the work with Scrum, I was like, So that's what Scrum needs. Five years of a half into my scrum experience. Yes, it's it takes a while, I think, for anyone who had the chance to see a true agility occur in the real life, to make the connection between what the scrum guide says and the true agility. And if you have never experienced true agility because you come from an organization that pastes vocabulary and calls it agility without changing anything, you may spend the whole life without knowing what it means. Yes, it's only when you see it working properly for the first time, you're like, Oh my God. So that's what that's what it means. And I like belief finally. And and now I can see how it's working so easy to value. And I don't want, on the other hand, to go the completely opposite way and make a framework of 200 pages because it becomes too complex and the space for misinterpretation even higher than 40 pages. It's still not being a framework. So I don't know. I think we we try to capture it in a nice. Carlos, you made the problem of game of chess, which rules are simple, but to master it is really complex and I don't know if it's having the the right people to help you. And yet how do you vet these are the right people Because if you have blind people helping other people cross the road, they may not get there. Even if they trust each other. So yeah, so it's this is this is one of the difficulties. I find that the guide is deceptively simple, but the complexity lies in this in the frame of mind that you need to approach the guide with. And if you don't understand, is the different mind mindframe that you're playing with the mindset, it's it's very difficult to grasp the what's behind Scrum. Yes. And I get that and this would be hard to add to the guide because you would like because language is difficult. Right. And we do have to acknowledge that the guide has seen iterations. So it is not static. It's it's grown and it's been brought back to a few pages. As you said. So there's still work it and it's not ideal, I think. So just as a thought experiment, could each of you think of a thing that could be added to the guide to help improve it in terms of this basic mindset that you obviously need to approach the interpretation and practical application of Scrum with to not wander off into a zombie scrum or mechanical scrum or make the scrum colorful or whatever. Those things out there are. Quote right. So what could we add in those to the phrase first? Firstly, even just enchantments to to, to help here, because I think some guidance could be beneficial. Honestly, I would not be listening to the scrum and I'm very happy that the scrum guide over the years has mainly been shrinking. In was really growing. Of course it was kind of it was made clearer, but there are very few things that have been added to the scrum guide. It was mainly subtractive, like those second three questions I really hate with my whole self. They used to be their status questions, and that is questions for the and for the team scrum. Even though they weren't really questioned since 2014, everybody still read it that way. But I would change one thing in the scrum, which I think is one of the biggest impediments in a personally, I really don't like it, but I understand why it's there. The word developer and the word developer. I would love to change it to a creator or an expert of some sort. I'm not sure which one would be the best, but I would love to have something that's disconnected a little more from a programmer because that confusion is in many, many languages and that stops Scrum from going outside. It's being used in all types of complex environments because people think that it's only programmers that can be on some team and it's not true. It's very, very true. So I would love that to change. So I wouldn't add anything that I would want to change that one. One thing that I am, it's and again, it's vocabulary. Vocabulary statistics may be difficult to change it. I hate personally the word spread. It's it provokes an unsustainable base type of thinking. And every time I see this being applied spread, it created the sense of urgency that make people work faster, work care less about quality and if you sprint every sprint, then you will be very tired very soon. So for me, for me focusing on, well, removing the word sprint and replacing it with a more generic iteration would be already a more one step towards a more sustainable pace in terms of in terms of development. And we know that we've unsustainable pace. We hurt ourself, we hurt our teams. We have to organization for people and products also are taking the toll when people are working at unsustainable pace. We don't want to create anymore sense of urgency that it already is in the world right now. Mean to stress the hell out of people. So that's my number one. If we iterate for a number two or three or four, you both of you make some excellent point. Simple changes in the scrum. And the only thing that comes up to me right now is that scrum, right? Is supposed to give us frames. However, some things are given upfront. Let's say scrum values. We are given up to five values that we should have, should have as a team, a shared understanding to. However, if we do it in the framework, is like we should say that a team could come up with their own five values or six out of whatever values that they have and they have a discussion about them, how they want to interact according to those values, according to the events that we have, are the facts. How do they understand them? And then live up to them and also treat them as a living artifact. So whenever something happens in the team, there is a change and somebody comes in whatever the product changes, whatever happens, they can also inspect and adapt or values. What do did they change throughout the time? How did we work according to those values? And again, if we take our value out of the system, because I, the person who mostly interacted, who does value is gone, how does the product development? So that's the one issue that I have in terms of value. Cool. So do you actually mean like taking it out completely or would you replace what's there with the suggestion to make your own values and maybe also some guidance to make sure the values don't go contrary to the basic principles of Scrum? Like in here was, for instance, the question of the perfect person, perfect phrasing. We should have some values. This might be the values that you were using and have a discussion, but however you are free to replace them as long as it gives a value to you and your customers, then you can respect and adapt. So some frames, but not exactly a step by step method. Yes, that's good. Right? So let me circle back to the topic that there is a sentiment that people who are not getting benefits from Scrum are being wrong, that when you're judging type of view that the problem may not be with those people. But in Scrum or what we've done to this discussion, the descriptions of the scrum by so do you feel that the things we discussed now will be actually helpful in better understanding and getting more value from Scrum? The truth that what we just discussed right now would get us there. However, I think people need to make a step right and the small step in, right? Yes. I think one thing that people are forgetting and that brought a great point is why you use Scrum. What are you trying to achieve that most of the places where people focus on implementing the framework for the framework sake, they don't see the benefit. It's simply I like I like to make it parallel strongest like scaffolding. It's like a scaffolding. It helps you build a house and helps you build something and helps you create something. At the end of the day, no one cares how great your scaffolding looks for as long as it respects a couple of security rules so that you don't break your neck or break whatever you're trying to build with the scaffolding. And if you care so much about how great the framework is for the framework, say you're trying to make it perfect scaffolding that you forget what you're trying to achieve with this. And for me, this is maybe the biggest disconnect where I see the people that care so much about the framework they are applying that they forget to be agile and flexible. Well, they try to achieve a goal that they've brought the scaffolding for in the first place. Yes. And this is something that may be helping. Go back to what you're trying to achieve and be flexible in how you achieve it. But with this framework within the framework or outside of the framework, even though there's nothing much wrong with Scrum itself as a framework, there are small things that could be improved, but the framework itself barely changed for years and years. It has, and it is adapt based on what people are actually doing with it. But I'm going to point to an entity. Scrum is still believed to be a form of a remedy or a silver bullet, and it's just crammed everywhere. And it's that's not the way to do that because there are justifiable and sensible and valuable places. We're actually a waterfall type of approach makes much more sense than using Scrum because still scrum is heavy, it is expensive. The whole process and having a scrum master and product owner, it is expensive. So it is justifiable in a situation where we do have a complex environment but it's not justifiable in our environment is simple or clear or we are able to predict what is going to happen and so Scrum might not be a tool for you. It is just a tool. It is a pretty good tool. It is really well-suited and working is kind of like open free markets. So for smaller and bigger companies that want to innovate and experiment with the market, that's a great tool to use. But it's not for everybody. It's not for anybody is absolutely not to use Scrum. And honestly, one of the things when I'm, for example, interviewing Scrum Masters and we're checking for Agile coach knowledge, I am asking them whether they would use Scrum in a situation that I describe that clearly kind of should lead them to saying, No, no, no, this not scrum and people who know what they're talking with, they're talking about they wouldn't fall for the trap and I think one of the issues also, maybe this scrum for me is binary. Either you do all of that or you do none of it to get the value. And that might be sometimes an issue because scrum does not work in the bubble. We need to have a whole company, a whole area around us on board with what we're trying to build because there are so many constraints around the Scrum team that we need to face that will be very difficult to have this working scrum if you don't have all of this organization on board. Yes, I agree. However, we should also acknowledge, in my opinion, that Scrum is able to start where you're at. You said it yourself at the beginning, so that and it is a smart thing to get supports and maybe I'm not sure. I think the maybe the thing that's most missing in the scrum that it is, is it's like that the clarity of basic principles that you would, by the way, find in the scrum. But today is like the focus of teamwork on value and those things and cross-functional teams and self management that is hidden in the language in scrum guides but they are not put forward as being the basic principles next to the empiricism, the transparency. And that is very, very put forward as like a basic principle. But I think those are essential for Scrum or or not scrum, but achieving goals in a complex part. So that would make it maybe easier to have those conversations with like management or other people that need to support potential that interface and help remove that organizational structure or into the team structures or in the hiring process or wherever you encounter problems for moving your disgruntlement towards more upside mean better quality, they better flow, etc.. So the value of these is I see what I, what I what I thought and when you were when you were going through through the the principles. It's it's funny how it's one of the things that I'm passionate about is how our brain works and it's often we are we're creatures that we are conditioned to take the path of least resistance. And it is a there is an evolutionary perspective from this. I mean, when you needed to save energy because you never know when the tiger will attack you and when you need to run, you need to save energy in order to be in good shape to answer that imminent danger. Now, we no longer encounter frequency, as in my experience, tigers industry. So we don't need to save energy. However, our brains still works this way. And when you have a set of guidelines and some of them are simpler to understand and to process and to implement, like the three questions that finally got out of the Scrum Guide, our brain is happy to see simple recipes that it can implement. Now there are some fancy words like and I have no clue what it means. And my brain doesn't want to invest mental energy into understanding what that means. So I'll stop. And culture. Those simple things like pre-planning is for us is 8 hours and we ask why? What? How? It's even better recipe. Why what? How? One, two, three. And that implemented. Give me a template. Give me, give me a template. Give me, give me a zero for forehead. It's we like simple solutions. And when you have something more complex that is hidden in the text, it often gets overlooked. Definitely. If it's just one word that also changes over time, like cell phones or even self management, what does it actually mean? Right? And this stuff, we can actually sometimes get very nerdy about spaces. It's what we do in these days when we get together with a bunch of trainers and discuss all these kind of topics. But thank you for raising it and also making me feel a bit silly for for bringing up the word self management is obviously very was very fancy of you. Yes. So any closing remarks? It's fine if you don't and it's just one of if you get see it, then maybe I will go with a little bit of trivia that is not known to many, but it's interesting and it feeds back to what we were saying before about introducing Scrum as kind of step at a time. You might have heard the term scrum, but we're not talking about the the the, the piece of body that's kind of behind. It's the birds with one T, but some people also call it with a double T that you have in the scrum. It's very yeah that's right but scrum but it is right now it's used to describe a situation where we are not using a piece of scrum because we just don't want it. Yeah. Or we are justifying that, Yeah, we have a problem but we don't do something. Yes. But it originated actually as a very valuable process because Scrum but was actually a transparent physical, huge card that you would put on the wall of a team that was attempting Scrum that would create a backlog of things we still need to work on. So to really get the value of Scrum. Yeah. So to make sure that we have the full framework, we understand everything we would put, we have Scrum, but we don't do this, this and that because we did not learn. Yes, but we want to. So as long as you were done, but you did have a whole framework. So maybe we should go back to something like this because scrum is going to consist of things that do bring some value when they're used separately. But all together there is a synergy, and I know that this word is very overused in the corporate world, but there really is something like a synergy and this research and it is confirmed to to be and Scrum does work with synergy or the two elements and that's why it's all happening. So thanks. And the other closing remarks, I did like your scrum scrum, but backlog is going going a little bit the other way around it. So I don't want to misquote, but I think Kinch Weber was the one who said that scrum is like like your stepmother, and he did. And it's if you apply it, if you apply it every time you quote you elements that are not working in your organization and you have a couple of choices, of course, but we are human creatures. We have choices. And one choice is let's let's make a boat out of it. So we have we don't want to tackle this right now, so let's make it transparent. We are not doing because we are we are not feeling like it's the right moment that will be in the spirit of Scrum. It would be in the spirit of Scott because we have great transparency of the other hand, your other choice. When you have a step other coming in is listen to what she's trying to tell you and figure out whether in law, the stepmother or the mother itself. So you didn't can be faithful. It is now your clients. So yeah. So when you come in at second choice, so the second choice the second choice would be instead of doing limited and then keep talking, we will not change anything. You may listen what your mother in law tries to say behind all the acidity that you that transpires. Often this transpires and then maybe be a good way would be let's let's try to listen what she's trying to bring this mother in law, in this strength to change something so that we correct the problem. Yeah. So so actually this patient curiosity maybe or something there see as this might create the different backlog, the backlog of impediments to us being successful in a complex environment that we could prioritize and remove progressively using the framework as as a way for us to get ourselves out of misery and maybe be more successful. Yeah. And silence that mother in law because she had nothing to complain about. Yes. Or stepmother, depending of who's the most complaining of your family and your India. It is pay your into that space. It also could be your father or grandad or your sibling or your best friend. Quite a waste. Someone always complaining going to be your best friend. I don't know. I think the family analogy is because you don't teach your family, right? So for me the closing remark would be to you that as you well remember, why are we doing this in the first place? Don't focus on optimizing, just spend and focus on having the perfect scrum framework, or if you call it process, whatever. It's just focus on the why you're doing this in the first place are what you're doing brings value. Do you get feedback from that value? Can you inspect that? Can you learn from what you're building? So don't focus on having everything like 15 minutes daily. It has to be 50 minutes, 60 minutes. That's absolutely over the clock. You're not going to Scrum, right? But focus on why you're doing this in the first place. And I guess that's the goal for me. Thanks. So thank you all for joining us. Thanks. My by, I'm sure I wish your host we had this great conversation. If you have any opinions on this, please feel free to connect with us on LinkedIn and yes, or react to our posts or whatever. And I'm sure everyone happy to help find more value in Scrum. Right? We're not going to date useless stuff that can help make it more useful. And that's, I think, the goal for us is professional scrum famous as a scrum community and I hope we contribute to that with this conversation. So thank you. Thank you. Thank you. Thank you for listening to the Scrum Facilitators Community podcast. The place for real conversations around Scrum. Do you have a story to share in this podcast? Get in touch with us at podcast at Scrum Facilitators dot com.