 This is, I've done about six talks, this is my last one, with this voice the whole week. It started like this. So I'm Henrik and welcome to this one hour dose of Scrum blasphemy. We're going to talk about what to do when Scrum doesn't work. A bit of a sensitive topic for Scrum trainers and actually I'm a Scrum trainer which gives me the excuse to make fun of Scrum trainers. So quick background, I'm a coach, I help companies improve and Scrum is one of the toolkits that I use but sometimes things don't turn out as planned. So I'm going to talk a little bit about pretty much typical things that you might, or how you might think if you're noticing that Scrum is not working. This is the one minute summary of Scrum. I'm assuming most of you know but I'm just going to give you the one minute summary which is pretty much Scrum in a nutshell, split your organization into teams. Split the thing you're going to build into pieces so you don't build it all at once. Split time into sections, sprints, iterations, and then order these pieces by some kind of notion of business value and then implement, take a cross-functional self-organizing team and have them pull one little piece at a time, work on that for this specific time period and then release something, look at it, learn from it and do it again. So inspect and adapt, do one piece at a time, learn as we go, improve as we go, adapt to this and most importantly do retrospectives and improve our process as well. So we're adapting the product, we're adapting the process. So in summary, instead of having a large group spending a long time building a huge thing, Scrum is really about having a small team, spending a little time building a small thing but integrating regularly to see the whole. This is the thinking behind Scrum, right, regardless of all the roles and artifacts and details. Okay, so how many here have been involved in a Scrum project? Which is just about everybody, keep your hands up. Everybody except one, okay, two. Have you seen cases where the general opinion was Scrum isn't working for us? Hands up. That would be about half, that's interesting, about half the group. Scrum isn't working for us. So there's like a doctor, you don't want to just start the treatment without doing a diagnosis, right? So I'm going to give you a guideline, a set of five different things you might check for in order, just like a good doctor, right? And we're going to go through each one. Using the process wrong, blaming the messenger, being impatient, not adapting the process or using the wrong process. These are possible things. Now if you don't get your diagnosis right, you're probably going to get the solution wrong as well. So this is important. So let's start here, using the process wrong, right? Some of you were at my Kanban talk yesterday, or was it today before, I don't remember, and I showed this picture. But for those who didn't see that, what is this person thinking right now, do you think? He's bought his new chainsaw and he's chopping down a tree with it. What is he thinking? The ax was a better tool, obviously. This is not a good tool. The old tool is better, right? Any tool can be misused. If you don't realize that a new tool typically implies a different behavior, right? And maybe a learning curve. So don't blame the tool. That's really step number one, right? And in this case, Scrum is a tool to me, right? So here's an example. Scrum misuse example. Where's your burn down chart, right? Says, oh, by the way, these are all real life examples. So these are actual dialogues I've had. Oh, we stopped using those, right? Okay, why? Well, they were demotivating to the team, right? Because it looked like this, showing that we're always behind, right? So they stopped using burn down charts because they're demotivating, right? So the purpose of a burn down chart is not to demotivate the team. The purpose of a burn down chart is to show when we're in trouble so we can do something about it. This is kind of using the process wrong. You don't have to use burn down charts in Scrum. But if you're going to use them, use them for the right reason. Scrum misuse example, too. Scrum didn't work for us, says somebody. And then I asked, why? And they said, too much time in meetings, right? For example, sprint planning meetings. Anybody had the feeling, darn it, all these meetings. We didn't have them before. So I asked, how long did, for example, a sprint planning meeting take? And he said, days, right? So which part of Scrum did he miss? Time boxing, right? And a time box does not have to be eight hours. In fact, I haven't met any team that enjoys having eight hour meeting. It just doesn't work. So you choose the length of your meeting, but do choose, right? And set a limit. So if you think one hour is a decent amount of time to invest for planning a two week cycle, then maybe that's the right trade off, right? So yeah, Scrum missed his example. Missing the point that in Scrum, time boxing is quite essential in everything. All right, so I'm going to have seen these kind of things happen. Scrum being misused. Wow, it's about half, right? About half, okay. So that's one possibility, but it's not the only possibility, right? It may be a case of blaming the messenger. So suppose I'm wandering around in the dark with a flashlight, right? Which is kind of what happens with Scrum. It's like turning on the lights. You see things that you maybe didn't see before. So you're wandering around in the dark with a flashlight and suddenly, oh, there's a tiger in there, right? Damn, you know, turn off the flashlight quickly. This tool is broken. This is a dangerous tool. Don't use this tool, right? That sometimes happens with Scrum, right? I'll show you some examples in a moment. So yeah, this is an example. We had to cancel the project, said one of the companies I worked with and I asked why. You know that most common coach question, why? After two sprints, it was evident that the project would take way too long, right? So, you know, Scrum is bad. Actually, that's not what he said, but I've seen cases where they think, it's like, yeah, Scrum showed us that the project is going to fail. Therefore, we shouldn't use Scrum, right? It sounds a bit silly, but it does actually happen and it's a little bit interesting. Here's an example I showed on one of my other talks. It was a company that had a fixed scope. This was the number of features or the number of story points they were supposed to deliver, right? That was a fixed scope. And this was a date where they promised to deliver it based on some contract, right? So fixed scope, fixed date, which is typically not the best idea. But this was the fact and that was the big date and the project started about a year earlier. And we started doing Scrum and we measured how much stuff we get done every sprint, how much of all this stuff, right? And after two sprints, we got this high. So doing a little bit of geometry here, wait a sec, this is wishful thinking. They believe that they were suddenly going to get this much faster and get done in time is wishful thinking. The more realistic case would be that we're probably going to get done somewhere over here in April next year, not this year. So this is a typical example of what I think is the value of Scrum when it helps you show how we're doing, right? And this showed us that we're in deep trouble. And it's important then to not actually blame the messenger and then put our head back into the sand. This can be done without graphics. You can do it using just numbers and math as well. All right. And by the way, these tools you can use them without Scrum as well. It's not really something owned by Scrum. So here's a poll. Any of your failures were they actually really just existing problems that were exposed by Scrum, rather than caused by Scrum? Curious. Right. That's about a third of the group. That's interesting. And was Scrum blamed for this? Have you ever seen that happen? Oh, that was more than I thought. Yeah, that's about a fifth of the room. I've seen Scrum being blamed for the failure that it exposed. All right. So when a problem is exposed by Scrum, focus on the problem, right? Not the flashlight, really. At least start with that, right? Okay. But this is just one possibility. It could be that the problem has nothing to do with using the process wrong or blaming the messenger. It could be just being impatient. So any musicians here and play instruments, ends up, yeah. Guitarists have been playing guitar, right? So what happens when you start playing guitar? Well, I already gave the answer here. Duff, right? You get blisters, right? This is like my fingers when I start learning to play guitar. It hurts, right? And it doesn't sound very good either. Damn guitar is broken, right? No. You just keep at it, right? And after a while you get tough fingers and you don't have blisters anymore. So then I started playing bass. I had to go through the whole damn thing again. New blisters, sticker strings. So I went through the whole thing again, learned to play bass. And then I wanted to learn to play a stand-up acoustic bass. Damn blisters again. So I gave up, but it wasn't worth the effort. It wasn't that important for me to play upright bass. But yeah, sometimes you just have to keep at it. Altitude sickness, right? You want to climb a mountain. Sometimes you have to stop for a little while to acclimatize, get used to that height, right? So you don't just go back down again just as soon as you have altitude sickness. There is an explanation for this in something called the satyr model. I don't think you're supposed to say satyr model, but... But basically if you have a stable system, such as you have a way of working today and it's not scrum, right? It's maybe not working very well, but it's working. It's stable, right? You optimize it. You optimize your current way of working. And then you have this idea, let's start doing something. Let's start doing scrum or let's change something, right? And you have this idea that that's going to make us better in however you measure performance. I don't know, but I think it's going to make us better. So we tend to think that the path from A to B looks like that, right? But satyr model basically illustrates that no, the path almost always looks like that. Things get worse before they get better, which basically means the middle kind of always looks like failure, right? So if you have a stable system, like a waterfall model or something and you start to scrum suddenly and somebody comes in in the middle of sprint two, they're probably going to say, oh, this is not working very well, right? Let's try to go back to that structure thing we had before. So yes, you have to be a little bit patient and be willing to kind of wait it out to a certain extent. But there's a limit, right? So you might want to decide how long, how much time we're willing to wait for this thing to work before we conclude that maybe there's another problem. So I'm curious, were any of your so-called failures caused by not sticking with scrum long enough to see that it actually works? Hands up. That was only a few, only three or four. Okay, we've got more coming up. Let's say one-fifth of the room is saying that this was happening in your case. So yeah, keep going. Don't give up after the first sprint. If you're going to do scrum, do it properly to see if it works and then start tweaking, right? So you don't give up too quickly. The first sprint is almost always chaos, right? And scrum is built that way. You start within a certain way and then you gradually improve the process instead of trying to design it perfectly from the beginning. Now here's one of my kind of pet peeves. Bad rhetoric. How do you say that? Rhetoric? Is that the pronunciation? Rhetoric? Bad rhetoric. I've invented a term called scrumdimentalism. The mistaken belief that pure scrum is always the right solution. Anyone have any scrumdimentalists in your building? Anybody here is a scrumdimentalist? Used to be one. You're a recovered scrumdimentalist. That's great. Example, our project failed. Our scrum project failed, right? Says somebody. So coach says, you must have been doing scrum wrong. Wait a second. What does this mean? So bringing out your old logic for dummies book or whatever you had and you learned in high school or college, logic, right? If A implies B, then what does that mean? If I turn that upside down. If A implies B, that's actually true. Then not B implies not A. Give me an example of that. Project failure means you must have been doing scrum wrong. A implies B, right? So doing scrum right means project success. That's logical transposition. This is logic for dummies. So sometimes you hear scrum trainers called scrum is not a silver bullet. But if your project failed, you must have been doing scrum wrong. That means you take the logic for dummies book and you throw it at them. Yeah, this is scrum to mentalism and it is basically nonsense. Phrases like this. Another example of this is what I call, maybe there's a term for that, a rain dance rhetoric, right? Rain dance works. Try it. You do the rain dance, right? And you go outside, next day check, does it rain? It rained. Good, it worked, right? Try it again next time. Rain dance, go out, next day, did it rain? No. Oh, you were doing it wrong. Try again. Do it differently, right? You go out, now it worked. Good, you did it right. It's rain dance rhetoric. Yeah, another example. When should I use scrum, somebody says. In which context should I use scrum? And I hear people say this sometimes. Only use scrum if you want to succeed. Otherwise don't bother. Nonsense, really. It's a silver bullet thinking again. There's another tendency which I call waterfallitis, which is waterfall obsession syndrome. The mistaken assumption that everything that is in scrum is waterfall. And that waterfall always fails, right? Has anybody here been in what you consider to be a waterfall project? Has anybody been in what you consider to be a failed waterfall project? Things did not work out. Anybody been in a waterfall project that you consider to be pretty successful? Yeah, look at that. That's a lot of hands. Wow, that's more than I actually thought. It's almost half. Wow, that's interesting. Gotta think about that. Well, then this won't come as a surprise to you, but we were in Japan, me and Tom and Mary and a few other people, and we visited Yoba and we talked to this guy, Satoshi Ishii, who's the general manager of one of the embedded software divisions, and we were very surprised when we asked him, we were expecting to be impressed by their agile lean kind of software process, but then he pulled up this picture and showed us what essentially was a waterfall process. And we're like stunned. We just went to the Holy Temple of Lean and he's telling us they're using waterfall for software. Of course, he said that it's not working very well for them and they're trying to change it. They're trying to get out of it. But the fact is, you know, if you get into a Toyota and your life is in the hands of waterfall software, right? Pretty much. This was a while ago. I don't know what happened since then. Maybe they have managed to wiggle out of it somehow. But yeah. So, sure, waterfall has its problems, but don't always assume that not scrum means waterfall, and don't always assume that waterfall always fails, right? Here's another one, sadoscrumism. What is sadoscrumism? That's sadoscrumism. It's the mistaken assumption that pain triggered by scrum is always a good kind of pain. Has anybody heard that? It's a good kind of pain, right? Example. Two-week sprints are too short for us, right? Well, try. One-week sprints, then. After that, two weeks will feel long, right? Right? Why not just do one-day sprints, then? You know? There is some sense to this, right? Maybe, you know, maybe it's right. Maybe if I try one-week sprints, it'll... But be careful of assuming that there's always... pain is always a good type of pain, right? It may be that we shouldn't be doing sprints at all in this context, for example, right? Or maybe it's that we should just better break your things down. I don't know. It's good to think this thought, but don't always assume that it's true. So, I'm going to introduce a new framework. This is mine, right? You can use it for free. There's going to be a certification program coming later, right? But you can... It's called Schlum, okay? So, you got ready to take notes, right? And you're going to be the first Schlum master walking out of this room, so... Um... Actually, I can't use that word. They'll sue me from some scum alliance. So, you're going to be the first Schlum bags. That's true, going to be, yeah. Yeah. The values of this framework... So, the values here are success and glory, right? So, only use this framework if you want success and glory, otherwise use something else, okay? We have two practices. There's only two. Do the right thing, and don't do the wrong thing, right? Um, it always works. It always works, because if it didn't work, you obviously did not follow the process, right? Clearly, you didn't... Maybe you mixed these two up or something, right? Something's happened, right? Any questions about the Schlum framework? Yeah? Go out there and change the world. Yeah. Pull. Have you ever been subjected to bad rhetoric about Scrum? Hands up. Anybody? That wasn't as bad as I thought. It was only maybe, you know, 20% of the room. Less even. Wow. We're getting better at this. If I'd asked you four years ago, I'd have at least half the hands up. Have you ever subjected others to bad rhetoric about Scrum? It's okay. You know, you're among friends, right? There is a way out. Yeah. I mean, it's sometimes tempting. I mean, I've said these things too sometimes. You don't think about it. It just comes out. Wait. What did I just say? Okay. So avoid bad rhetoric and challenge it when you hear it, right? Challenge it. Um, okay. Root calls analysis is useful when diagnosing problems, especially if they're not obvious. Sometimes it's quite simple. But whenever it's like, this is a recurring problem. We can't seem to get rid of it. Root calls analysis is a good trick. I'm going to give an example and this is a real life example. A company that was saying to me, our problem is that we're failing to do XP practices like TDD and pair programming. We know we should be doing it, but we're not help us, right? So, and I was like, uh, really? Is that really the problem? It's very useful to start asking a series of why questions, not to get the root cause but to get to the actual consequence of the problem, right? What is the real problem? So, no pair programming, lack of test automation. Why is that a problem for you? Why do you care, right? What is the pain all about? Well, because that gives us bad code quality. So, so what? I keep asking, so what? This is the five so what's by the way, right? Not the five why's. If it's the five so what's. And it finally gets you up to for them, this was a research organization. So, so their, their kind of output was demos and not commercial products like demos, right? Um, so, but their demos would crash sometimes, then they would lose clients. So, okay, this, this is a problem. This is a real problem. Maybe we could get further, say, lost revenue, etc. But, this is more of a real problem than lack of test automation, right? But we're not done yet. Now we've done the five or in this case, the two so what's. Now we want to do the five why's. Why? Right? Why are we not pair programming if we think it's a good idea. So, identify the real problem, right? So, in this case we had people divide up into groups and ask this question and draw this diagram. It turned out that most of them came up with the same, same same idea that, well, we're not pair programming because there's no proof that pair programming works. And why is there no proof? Oh, and because there's fear of failure. So, we don't want to do it unless there's proof because there's fear of failure. Might be wrong, right? Okay, and why is no proof because we have no experience of pair programming? Uh, wait a second. Ah, we just found a loop. Loops are great to find, right? We have no experience because we're not trying it. There's a loop. And, no experience of pair programming because we have no time to experiment. Why don't we have time to experiment? Well, because we have no slack. All of our hours are billable kind of thing. And why is all of our time filled up because we have push instead of pull? What does that mean? Well, clients from outside are pushing in work instead of the team pulling in work when they have capacity. And when there's push going on, slack gets really hard to get. Why is stuff being pushed in? Why can't we let the teams pull in work? Well, lack of trust. Because maybe those lazy bastards will pull in too little. Right? That was their diagnosis. And lack of trust, by the way, causes fear of failure. So now we're starting to see a picture. This is very amateurish. I mean, it's very high level, right? We did this in maybe an hour. But four different groups came up with this pretty much the same picture. So there must be some truth to it. And the root cause seems to be lack of trust. Right? So that's the problem we got to solve. So we spent the whole rest of the workshop talking about what can we do to improve trust between the developers and the stakeholders, right? Meet more often, get to know each other, et cetera. And all this in the middle about no pair programming. That's just symptoms. That's not really interesting. That makes sense? Root cause analysis? I call this cause effect diagrams. I think I wrote... Wait, okay, we'll get back to that. Anyway, putting the whole picture together, we see this big vicious cycle. Crashing demos causes lack of trust. Right? So it's a vicious cycle. Really got to get out of it. Right. So solve root causes, not symptoms. Right? What's happening here? Bailing water, right? So I ask, what are you doing? Oh, duh, I'm bailing water, right? Okay, why are you bailing water? Well, duh, because there's water in the boat. And I don't want to have water in the boat because it moves slowly and I get my feet wet. Okay, so there's water in the boat. Okay, so we don't want water in the boat. No, we don't. So I'll help out. Let me get a bucket. I'll hire some certified water bailers to come in and help us and empty the water, right? Of course, that's the wrong problem to solve, right? The real problem, if we take a little deeper, is there's a hole in the boat, right? And that's the problem we should be solving, right? If we solve that problem, this problem goes away and doesn't come back. Of course, if you're afraid for job security, then you might stay with this, right? You're scared of losing your water bailing job. Right, what would be a real-life example of water bailing just to get away from the metaphor? Connect this to real IT-type work. Fixing bugs, right? Yeah, we're fixing all these bugs. So if we put too much effort into fixing and managing bugs, we might forget to go look at where is the hole in the boat? How are the bugs coming in? What is making us add bugs and find them way late? And then back to reality. All right, so have you seen examples of organizations focusing on bailing water rather than fixing the hole? Hands up. That was a lot. That was almost two-thirds of the room. Oh, interesting, yeah. So this is a so-called high-leverage improvement area. You can really make a difference there, right? If nothing else but taking out your flashlight and shining it on the hole, right? Just to show that it's there. Sometimes even that just helps. So there are tools for this, or thinking tools. One is cause-effect diagrams. There are more details about that. You can just Google it and find it. A3 problem-solving is pretty much what I'm talking about here. The lean thing. Tom and Mary and I have this template. You can download with some concrete examples. So these are just ways to guide this effort, right? Okay, so using the process wrong, blaming the messenger, being impatient, not adapting the process could be part of it too. Here's an example. Ditching scrum for the wrong reason. We stopped using scrum. Why? This guy asks why a lot, doesn't he? If you're a coach, you don't know what to say, just say why. We stopped using scrum because there was too much estimating. Who cares if this or that task has four, six hours left? That's micromanagement, right? So we stopped using scrum. What's wrong with this picture? You think it's a good idea to ditch scrum because you don't like task estimation? Before you ditch scrum, think about what is it you don't like, right? Maybe you can address that instead of throwing the whole thing away. So you can still do scrum without that stuff. Choose your flavor of estimation just because a scrum book tells you that you're estimating. They're giving lots of examples of detailed estimates. It doesn't mean you have to do that, right? So features, some don't estimate it at them all. Just count them. I gave an example the other day of a big government project with 60 people where we didn't estimate these at all. Why should we do this, but just small, medium, large? But then we planned about just counting how many get done every week for the whole project. Some do estimate, but they just estimate teacher size just to get a rough sense, right? Because it might influence priorities. If I have two features and they're both just about as important, but the team says that one's large and this one's small, that's useful input because I might choose to not build a large one or build it later or split it, right? Some estimate story points, which is kind of the vanilla agile scrum XP type of approach, and some actually do prefer to estimate in ideal mandates. You can do that too, although most trainers would not recommend doing that for various reasons. It doesn't mean it's always a bad idea. For communication reasons, this could be useful because sometimes customers and managers and people get thrown off by the story point notion. What is that, right? So be pragmatic, and if you're not sure which one, experiment, right? What about tasks, right? So a story is like the thing we deliver, the thing customers care about. Task is the work I do to finish the story. Task is stuff that customers don't care about. So these are typically objectives. Like a feature, and tasks are typically verbs, like set up to database, implement this or that code, right? Some teams don't have tasks, or more like they don't track tasks, they just have these on the board. Some teams do have task sticky notes, right? But they don't estimate them. Some teams estimate them in days, some estimate them in hours. All these are options, right? So choose your flavor. This is typical scrum. Scrum teams typically do more of this. Codmon teams typically do more of this, and scrum too, right? All right. Yeah. Don't be a scrum zombie. What does that mean? What's a scrum zombie? I'm wondering how many of you have been to scrum meetings that sound kind of like this? Yeah, yesterday I coded. Today I'm coding. No problem. Yesterday I coded. Today I'm coding. No problem. Hands up. That's familiar. Whoa! Whoa! That's like, damn! High leverage improvement point. Yeah, I call this being a scrum zombie, right? So you don't have to be a scrum zombie. Congratulations. You don't actually have to be a scrum zombie. What can you do to get rid of this problem? I mean, an idea. You ask the tester to explain what the developer's been working on. That's very interesting. I've never seen that before. Yeah. The key here is you change something. That's what counts, right? If this format is boring you to death, change something, right? There's all kinds of different variants of the three questions. Maybe you have this more informally in the coffee area. Dan North had a nice one. He stands up and he asked the group, what is the best possible today that we can have? And then people chat about that and then they go sit down. So yeah, experiment with the format. Don't follow the rule book exactly, right? I'm going to steal a metaphor that I learned from Jeff Patton. I think I mentioned it the other day about skiing and actually I was in this room so it feels like I'm going back in time now. About skiing, right? When you learn to ski, you learn to plow, right? Which is putting your feet like this. And if you don't do that, if you try to ski like a pro on the first day, you're probably going to hurt yourself, right? So don't do what the pros do, plow to get down the hill. It's a safe way to get down the hill, right? Provide safety. So you learn that skill. But the reason for learning the skill is not because you want to get good at it, it's because you want to get rid of it, right? That's why I learned to plow. So once you start getting good at it, you can start finding more fun ways to ski. So think of a, if you grab my Scrum and XP from the trenches and you'll read it and it says, here's how we do sprint planning. If you do sprint planning exactly the same way, it'll be pretty safe. You'll probably get through the meeting. You'll probably get some useful results, right? But it'll be like plowing, right? There's probably better ways to plan it for your context. So whatever you do, don't keep doing it that way, right? Experiment. So I'm curious, have you seen Scrum being abandoned when it could have been adapted? Anybody? Yeah? Just not so many, maybe five or six, right? The most common case I'm seeing is from Scrum to Kanban. Teams like, we don't do Scrum anymore, we do Kanban. Or why? Because we didn't like sprints. Okay. So what about the other things? Cross-functional teams and all that. Well, yeah, those were pretty good. In fact, I've noticed that actually Scrum and Sprint seems to have become synonyms. So quite often when I meet teams that say we stopped doing Scrum and we started doing Kanban, what they're actually doing is pretty much keeping all of Scrum except for the Sprint bit, which is actually perfectly fine. All right, anyway, evolve your own dialect of Scrum, right? Don't get stuck by what the books say. All right, so using the process wrong, blaming the messenger, being impatient, not adapting the processes of four different possible diagnosis, right? But suppose you don't think of any of these. Maybe it is the fifth one. You're using the wrong process. And this is where I get shot by Ken Schwaber. Distinguish between, yeah, distinguish between what? What's the difference between these two cases? Something about tools, what's the difference? Okay, without using agile waterfall connections, just what's... Yeah, someone said it. Using the root, this is using the right tool the wrong way, right? Chainsaw is a great tool for getting trees to come down. But I'm using it the wrong way. I'm trying to chop down the tree with the chainsaw. Here, I'm using the wrong tool in the right way, right? A hammer, you swing hammer at things, but not trees. There's a very important difference. So think about if there seems to be a problem with your tool, whether it's Scrum or whatever, think about it. Are we using the wrong tool the right way or the right tool the wrong way? Or for the wrong context? And note, neither of these problems are caused by the tool. There's nothing wrong with this hammer or probably nothing wrong with that chainsaw. So don't blame the tool. Scrum doesn't succeed or fail. People do, right? People choose where, when, how, and why to use Scrum, right? What's wrong with this question? And I hear this sometimes. Our problem is that we can't figure out how to do Scrum in operations. What's wrong with that question? Yeah, there are assumptions built into here, right? So what a good coach would do is find the assumptions and put them out to the light and question them, right? So the assumptions I'm hearing here are two assumptions. I'm assuming that Scrum is the right tool for this context. And I'm assuming that implying Scrum itself is some kind of goal, right? So once we can get these assumptions out, we can start talking about what is the real problem we're having with operations, right? Once again, root cause analysis, useful tool, right? Give me an example of when would it be a bad idea to even have daily Scrums? And I'm picking on daily Scrums because that's one, what I think is one of the best practices in any environment, having dailies. But even that good practice has some situations where it's just not needed or not good. Okay, so there's not much to talk about. There's not much change, not many dependencies, so maybe you do it every second day. That might be an example. When, in which context, would you just not do Scrum, daily Scrum at all? Well, people collocate and tend to like to do it daily Scrums and it tends to solve problems. But yeah, we're getting closer. Get back to that. Yeah. Maybe we're just three people. We're sitting right next to each other. We're talking all day, right? We're like one mind. So why would we suddenly stand up at a certain time by board? Like what am I supposed to say now? Because the Scrum coach says we have to. So yeah, be pregnant. Think about what is the purpose of the daily Scrum? And if you can achieve that purpose in some other way, then that's fine. But disclaimer, I think this is one of the best practices. Yeah. Yeah. Yeah. It's a good point. Before abandoning this practice, you might look at what are the advantages of it. Maybe there are other advantages. This is a time and point when other people can come and get a feeling for what we're doing, talk to us. So you might keep the daily Scrum for that reason. But the important thing is to bring up the question, right? Don't just assume that we have to do this, right? Make sure you know why you're doing it. Good way to stop multitasking. Yeah. Okay, so when our sprint's a bad idea. When our sprint's a bad idea. When we don't have a backlog. On planned. Okay, we got... Yeah. Well, not having a backlog doesn't mean you don't have good stuff to do. A backlog is just a cue. But I think the second thing you said there was unplanned items, right? If we have a context. First of all, what is a sprint? Well, putting all these different things into one cycle. Like plan, commit, review, and retrospective. All these into one cycle. That's what a sprint is. And it's strictly time boxed. It always ends on time, right? That's core Scrum. It has great advantages, right? But sometimes it's not suitable. And I'll give an example. Here is a Scrum going on. And we look at the board and this is in the middle of a sprint, right? And a product owner or somebody steps in and says, I'd like to have E, okay? So what will this Scrum team probably do? They'll probably say something like, wait until next sprint. Which may be for a good reason. Because maybe these people won't get anything done if they can't focus at least a little bit. For a little period of time, right? That's kind of the roots of Scrum. Let us focus for a little while. And we'll be 100% flexible between the sprints. So this is kind of core Scrum. But suppose that during their retrospective, they decide that wait a sec. It's okay, you know, to have more change more often. It's not disruptive to us. Let's say this. Maximum one item in progress is a policy we now introduce. And we allow to-do items to be swapped out. So we introduce the policy. So there's our policies. It's good to write these things down. Because that way you can easily challenge them and question them and improve them. So now what happens when a product owner says in the middle of the sprint, I'd like to have J? Yeah, we love to do J. So just take one of these. Yeah, so this is our sprint, right? We chose these four items. But it's okay if you put something in as long as you take something else out. We haven't started it yet. So it's not disrupting to us, right? Now we're being pragmatic. This is pragmatic Scrum. Or wait until next sprint. Still an option, right? So is this still Scrum? How many things this is Scrum? That's the majority. How many things this is not Scrum? A few. So the majority says it is Scrum. I say not. I say I don't care. Maybe we'll just have a vote and decide and move on, right? Example, sprint to retrospective. What it is, it is process improvement. That's what it is, right? So now the next retrospective, they're like these were our new policies from last sprint. Now let's add some new policies. Maximum two items in to-do, right? Now we're limiting our backlog or our sprint backlog. And to-do items can be added at any time as long as the limit isn't exceeded, right? So we're being devious here. We're conbanizing our process, step by step. So look, there they are, right? Whip limits. So one thing in progress, two things in the buffer. We don't, because we don't need to have more stuff than that. It'll just sit and wait, right? But two is just enough to keep us busy, you know? Make sure there's something for us that we can pick next. In case we run out of stuff to do and we really have no idea what to do next, right? So product owner says I'd like to have P. What does the team say now? You can choose, right? You can swap out M or P, right? Or wait until there's space in to-do. It might happen tomorrow or in one hour. Just wait until this gets sucked in. And nope, now there's a slot, right? So now the sprints have kind of lost a little bit of their significance. If you're the product owner, which of these three models would you prefer? Probably this one, right? Because the team is giving you options. It's not just saying no, come back next sprint every time, right? So is it scrum? I don't know, I don't really care. It's process improvement, that's what matters, yeah? Yeah, so what he had, time box iterations change now, right? Time box iterations no longer have a specific scope. So maybe because we don't know, he might change his mind in the middle, which we've allowed for. So we no longer promise, or actually in scrum, it really isn't a promise anyway. But we no longer set the expectations that these four things will be done by the end of the sprint. The expectation we set that something will be done by the end of the sprint will demonstrate something will have a stable state. So the sprint does not morph into a cadence, a release cadence, for example, right? So I would say this is not scrum, just to avoid getting into trouble, right? I would say it's not scrum. We've taken a hybrid of Kanban and scrum, right? In fact, I would call it, some might call it scrumbub. But the key is to not be locked in, you know, be willing to experiment. So yeah, maybe, you know, this is one model, right? Another option would be we separate these cadences and say, retrospectives happen every four weeks, we take a whole day offsite, do root cause analysis and stuff like that. Planting cadences every Monday, no, every second Monday, we have a planning meeting where we look at priorities and check what's next in the queue, right? Talk to stakeholders and product owner. And release happens whenever, or sorry, no, release happens every Friday, right? Whatever is done gets released on Friday. And if there's a feature that was half done, then we either put it on a branch or you have a feature toggle to make sure it doesn't stop us from releasing. So every Friday there's a release trade, right? This is really nice, actually, getting this. So we still have these cycles, but we just decoupled them, right? This team here, they're event-driven. So, okay, retrospectives every four weeks, they still do that. But planning is on demand. So what that means is the team will trigger a planning meeting when they're starting to run out of stuff to do and they need to talk with stakeholders, right? The stakeholders or product owner will trigger a planning meeting when priorities change, right? So anybody can trigger a planning meeting anytime, which is fine. And release happens whenever there's something worth releasing. These are all just different options, right? So keep that in mind. The scrum cycle has its value in some context, but it's not the only option. So have you been in a context where sprints are not the best alternative? That was quite few, only about maybe 10% of the room. That was interesting. I thought there would be more. The scrum practice aren't the only way to be agile. Scrum practices aren't the only way to implement the scrum values, right? Give me an example of a scrum value. Retrospectives is a practice, right? But what is underlying principles? Inspect and adapt, continuous improvement, right? So how do we do continuous improvement without retrospectives? Yeah, ad hoc retrospectives, right? We're meeting every day in front of the daily scrum, right? And someone says, you know there's a problem. Okay, let's go talk about it and maybe improve it. So yeah, retrospectives, I think they're great, but once again, just like any practice, can be clear about the purpose and realize that there's probably other ways to achieve the purpose as well. By the way, there's nothing about iterations in agile manifesto. Did you know that? The word iteration isn't even in there. It's just one way of doing it. Small increments, yeah, release early and often. At my current client Spotify, we have 35 teams. We tell them you can choose any flavor you want, scrum, kanban, or any, whatever. But release often, right? So our focus is really that, releasing often. So most teams release about every week. Some do it every other week. But that's the principle. And as long as they can release often, then we know we're getting feedback and whatever they're doing is probably fairly decent, right? Okay, here's a small case study. I worked with a company that turned out they were doing what I call broken scrum, which is they call the process scrum, it's broken. And what I mean by broken is, well, they had a one to two year release cycle, right? They had no definition of done, so things were hanging up on the board for a long time. And each backlog item, like a story, had to be split across several different teams. This was what Craig talked about in the first keynote. Of course, that was a few days ago, some of you weren't here. But basically, yeah, component teams. So we have to do our part, they have to do their part, and until we put our stuff together, there's no value to the customer, right? So this is really a bastardized scrum. And look at alternatives. This doesn't mean they're bad people, maybe they have an intent to implement scrum and they're on a journey, right? So be careful about going and judging someone, right? They call their method scrum. But the question was, okay, what are we going to do? And we have options. We have alternative one, keep doing broken scrum. And that's an option. We might not call it scrum though. Or option two would be do scrum right, which would be make backlog as I'm small enough so you could finish in a sprint. And shipable software, every sprint. And feature teams. We'd have to rearrange the teams. Okay, that's a lot of work. We're changing the organization. Option three would be Kanban. So combine the teams. In this case, this is what it would mean. Separate the cadences, like I showed you in the last slide. Visualize a whole value stream of how story A gets from idea to production. And limit whip. I'm not going to show you the details of this. But basically these are three alternatives we looked at. And you might summarize them as, number one is denial, right? Number two is revolution. Number three is evolution, right? So choose your pick, right? Revolution has its cost. It has its risk. But you can get quick results. Evolution is more careful. Denial is easier. They pick number three. Okay. I talked a little bit about this in one of my earlier talks about Kanban and scrum. But just to show one example of when it might not be appropriate to do scrum. Here, in scrum all backlog items must start and finish within a sprint. That's one of the scrum rules, right? So that means that you don't start something in a sprint unless you can finish it in a sprint. So that forces you to break things into small pieces, which is good, right? But it also forces you to waste a lot of time trying to figure out how am I going to make this thing just a little bit smaller so it doesn't, you know, leak across the border. So, yeah. Advantages, disadvantages to everything. The alternative is combined big feature development with support maintenance. Suppose we have some very big things we're doing and a lot of little things are doing at the same time, right? We want to combine these things. So we might choose to say, never mind this rule. We'll allow long running features that take a month to finish. And while we're doing that we're doing all those little things also, right? But to avoid getting stuck with all these big things we introduce a whip limit saying that, we only do three features at a time, right? The first one is that big long one. The second and third one are the little ones. There's a lot of turnover in those. But it's just another option, right? Limiting whip in a different way. Instead of limiting whip per unit of time we're limiting whip explicitly, right? Work in progress. Yeah, so sometimes the best solution is to stop using scrub. But I'll wait, I'll look at the other diagnostics first before I just throw it out, right? So this leads us to this notion of scrub butt. What is scrub butt? You heard that? Yeah, we're doing scrub butt, but yeah. So we're modifying scrub. Scrub butt is normally pitched as a bad thing, right? It's an implicit assumption that this is bad. Which gets us back to this scrub mentalism issue, right? So, don't be dogmatic. Like, thou shalt use pure scrub. This is dogma. But also it doesn't have to be... No way, don't talk to us. We're in a sprint, right? This is dogma. Come back in three weeks, right? Well, but the server crashed. We're losing money every second, right? Oh, come back to us in three weeks. Put it in the backlog, right? Talk to the product owner. I mentioned the skier example, right? I'm going to mention another useful model, which is from Japan, Shuhari. Just to give you some buzzwords. Anybody heard of these? Oh, about a third of you, right? This is from module arts. It's actually from even earlier. But the basic idea is really learning something new in the beginning and just follow the rules. Do exactly what the teacher says. Don't think, just do, right? Follow the moves. And once you get really good at that, right? That one specific move, it could be something like doing a sprint planning meeting exactly this way, right? Then you get to the next stage where it's hot, change the rules, right? What's interesting is if you're in this stage, you're new at something, like tell me how to do sprint planning, right? Or tell me how to write stories or something. You don't want some coach to say, well, it depends, right? Here are eight different options you pick. It's like, no, no, no. Just tell me the fuck how to do it, right? I mean, but if you're here, you don't want somebody to tell you exactly how to do it, right? You want to hear the options and you want to hear advantages, disadvantages. So it's important to think about where are we right now, right? In the thing we're trying to learn, whether it is technical practices or whether it is agile or whether it is how to write code and Ruby or whatever, right? Because this kind of matters a lot. And then a read basically means, never mind the rules, I don't need rules. In fact, I don't even know the rules, right? A good cook, if you're going to an expert level cook and you tell them, show me how to make a great steak, they'll be, well, just make it, right? What are you talking about? Just make it, right? So, scrumped about alphobia, new word, scrumped about alphobia, is the fear of doing scrum wrong, right? It is related to scrum to mentalism, right? So the fear of doing scrum wrong gives you scrumped about alphobia and the symptom of scrumped about alphobia is stuck in shoe, right? You're stuck here. You're doing it the same way every day. You're doing the scrum zombie, daily scrums and all these things, right? Stuck in shoe. So confession of a scrumped aboutist. This is all of us here who are scrumped aboutist. We raise our right hand and confess, so my name is Henrik. You can stay with me. I'm a scrumped aboutist. I'm not afraid of scrumped about. Sometimes scrumped about is a problem. Sometimes scrumped about is a stepping stone. And sometimes scrumped about is a solution, right? So, yeah. Let's just not use the term. Let's just kill it, all right? Is that all right? We just, we don't need it, right? Great. Okay. Here's another person who I know agrees with me on this. And his name is Alistair Coburn. And he did this cool thing. On his site, he wrote this thing which he calls the oath of non-allegiance. And basically he says, I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation, right? So did this idea come from scrumped or from someone I talked to at a conference? It doesn't matter. What's interesting is so, yeah, you can go in there, you can sign it. There's even a t-shirt. So how many of you would, how many of you feel that this is something that you agree with, you support? I'm just curious. Anybody saying, hell no, burn the blasphemer? No? Nobody would admit it? Yeah. You can burn me later. So wrap up. Let's wrap this up. What to do if scrump doesn't appear to work? I added a little thing there. Do root cause analysis. And then depending on your diagnosis, if the diagnosis is using the process wrong the solution is use it right, right? Get help if you need. If your diagnosis is we're blaming the messenger the action is don't, right? Don't blame the messenger, fix the problem. Not the messenger, which could be scrump or the scrump master or whatever. If the diagnosis is being impatient, the solution is don't be impatient. You notice how easy it is to solve the problem once you have the right diagnosis, right? If the diagnosis is not adapting the process the solution is adapt the process. If the diagnosis is using the wrong process the solution is try something different, right? So I'm done. I'm going to add another. I've added all these unpleasant scrumb words. I'm going to give you a pleasant scrumb word. It's called scrumptious. It's a real word. It means it's blended, very pleasing, right? I think there's a little bit of time for questions. Wait, I just realized something. This room is really hot and there's some people who want to go. So let's end it and whoever wants to talk will talk right outside the room. Is that okay? Right, so thanks for coming.