 This recording is indeed in progress. This session, so Jeff approached me the other day saying, hey Nigel, would you like to do a session for me and my community? I said, yeah, great. I've got something I'd like to talk about. I'd like to talk about the Nigel scale. Jeff said, great. Is there anything else you want to talk about? Maybe something about presentation skills or a humor or something. I can talk about that as well, but I really want to talk about the Nigel scale. And Jeff said, OK, we'll send you two sessions. Should we do the presentation one first? I was like, no, we won't be doing the presentation one first, but we're doing the Nigel scale first. OK, so let me introduce you to the Nigel scale. OK, the Nigel scale is invented by me. That's why it's called the Nigel scale. If it was invented by someone else, it would have a different name. I'll tell you why I called it the Nigel scale in a moment. But basically, here we go. I've got some slides to you here. Let me share some slides. Everyone loves some slides. There we go. I've got a slide saying Nigel scale. And that's quite good, don't you think? There we go. Exactly what it says in the tin. Here's the problem, right? So this is me. So I've been in IT for a billion, billion years. I started off as a childhood programmer. I've been in IT 27 years. A lot of those years working with Jeff, by the way, many years ago, using agile over 20 years. Think 20 years now, isn't it? Been an agile coach, blah, blah, scrum trainer, blah, blah, all these things I've been doing, right? So I've seen a lot of stuff over the years. I've seen lots of interesting stuff. I've seen, as they say in Blade Runner, things you wouldn't believe, OK? And what I've been discovering in the last few years is that Jeff and I and people like us, like we were accidentally part of history, but we didn't kind of realize it was history at the time. It was just stuff that happened, right? So let me take you back to about, here we go, about 2009, right? So what's that? 13 years ago, certified scrum trainers, right? We always certified scrum trainers across the world in the scrum alliance are having what is politely known as a discussion. In most worlds, it'll be called a bit of a bar fight. So people are throwing things at each other in a variety of forms, bickering, bickering with each other. And the thing that was the big bug bear 13 years ago was the term agile project managers, right? Which hopefully you will realize now 13 years later is a bit of an oxymoron. It's like, say, military intelligence, you know, or accurate estimates, you know, like one word kind of hits the other ones, not kind of inlined. And so there was a big discussion amongst trainers, some pro the word, some anti the word, all backing and forth. And as internet discussions are want to do, that discussion went every bloomin' where. It went off into a release planning. It went off into project manager stroke scrum masters. I don't recommend stroking scrum masters. And it was all generally all over the place. Now, you have to appreciate the context of the time. That world's famous scrum guide document that everyone seems to assess about these days had been written one month before and no one was impressed with it. It was hugely disappointing. Why? Because we had all been promised something called the scrum hub which was gonna be like a community, a source of agile knowledge and scrum learning. And it was gonna be this wonderful, almost like an encyclopedia of greatness. And what we got was like a 10 page document specifying scrum. And we were kind of all, oh, okay. That's great. I think I thought we were gonna get a bit more, but hey-ho, we've given Ken Schraber all this money. He's given us 10 pages. Great. And at this time as well, they were developing the exam for certified scrum master like an examination for the end of that training. So you may not realize this, but when CSM started and Jeff and I started teaching it, there was no test. Because there was no sort of verifiable body of knowledge to test against. So we had to use our own experience and judgment calls on people in courses and go like, you kind of feel a bit agile. I guess you're okay. I'm not too sure about you. And that puts you in a really difficult spot. So there was lots of conversations going on at this time, basically around scrum and that guide. And hang on, what are we teaching in scrum master training? And hang on a minute, what are we gonna exam? And there was a big issue here because frankly, what was in that guide wasn't quite lined up with what people thought scrum was, which wasn't quite lined up with what people were teaching because they were teaching other stuff. And it wasn't quite lined up with what we're gonna test. Shenanigans. So everyone's arguing and bickering and having a moment. And at this time, I thought, do you know what this conversation needs? This conversation needs just a little bit more trolling involved in it. So what actually had a trolling is a strong term, I admit. Maybe let's say humorous critique. Okay, let's use that word. So I posted in this discussion, I said, look, all of you arguing about this stuff, you need to be using the Nigel scale, right? I've been using it for years, I hadn't, I just made it up that second, right? It's what it's called the Nigel scale. I said, you need to use this Nigel scale as a way to help you better understand the conversation. Now at the time, and again, you may not realize this, there was something that was really popular in the agile world. It was called the Nokia test. Don't anyone's ever heard of the Nokia test? It was very trendy for a little bit. It was effectively a test built by, well, it wasn't Nokia hilariously. It was Nokia Siemens networks. And hilariously, it wasn't a test. It was more of a self-assessment, but hey, but it was like a little self-assessment you would give yourselves and judge your relative agility. And at the time, everyone was kind of desperate for anything to help them make judgment calls. So I thought Nokia test, Nigel scale, sounds a bit familiar, aren't I the wit? And what I came up with was the Nigel scale. So here we go. Here's the Nigel scale patent pending owned by me, not by you, just remember this. I'm watching you, Frankie. Mine, not yours. Here's the Nigel scale. Nigel scale one. There are things that are a bit scrum guide-tastic thing. And this is actually there is stuff that is fundamental, stuff that is like core to everything we do, okay? And if we bend this or we manipulate this or we tweak this, we get into a whole heap of trouble. So the example I often use is surgery. Imagine you're a surgeon, okay? Imagine, you know, ha ha ha, imagine you are a patient about to go in for surgery and your surgeon comes up to you and says, hello, I'm your surgeon. I'll be performing the operation. I just want you to know that I don't believe in the concept of bacteria. I think bacteria and viruses were invented by big pharma as like a grand conspiracy. And so I don't wash my hands before an operation. There's no reason to do so. But how would you feel about that? Or maybe they would say, do you know what? Actually, I don't know if you know this, but bacteria is good for you. Bacteria is good for your body and good for your digestive transit. And so I deliberately dip my hands in cow manure to get loads of good bacteria on it before I perform the operation on you and remove your spleen. How would you feel about that? How would you feel about that, that surgeon? Yeah, you'd be like, shut up, shut up, get out. So like, you're not touching me, get away from me. You are grossly incompetent, okay? And so there's like fundamental things that if we bend them, life just gets into a horrible, horrible mess. The problem is, is that most of life isn't that. In the world of complex problem solving, most of our life is here. What I call the Nigel scale too. Stuff that Scrum doesn't officially care about. And this is life. There's loads of things in the world of good practice. The euphemism of good practice. Hey, it works for them. It works for them. Maybe it'll work for us. Maybe. But then again, maybe not. And that's where as coaches, we have to use our previous experience to coach organisations, to self-organise their own answers to their own complex problems. Help them find their own ways just because it works for you doesn't guarantee it's gonna work for me. And the vast majority of, okay. So let's have a conversation about this. A lot of what people used to think was Scrum isn't. And do you know what? I was gonna say at this moment, obviously in 2022 we now know the difference between Scrum and good things done in Scrum. And then I made the fundamental mistake of this morning going on LinkedIn. Okay. And that was not wise because there were millions of people on LinkedIn complaining about stuff, going, oh my God, you know, like velocities the spawn of the devil. Like, well, it may be the spawn of the devil, but the Scrum is rubbish. Why in that one back? You hate velocity, legitimate. You saying the Scrum is rubbish. They're two different things. You like story points. Good idea, maybe. Not compulsory, not by the Scrum. Burn down charts, you know, release planning, standing up in a daily standup. Hilariously, I tell you what, I haven't stand up for standup in forever. I'm on Zoom. They're all sort of good practices. They're all nice practices, most of them, but they're not that fundamental hearts. They're not that fundamental core that if they are fiddled with or adjusted, life fails. You know, like if you sit down for a daily Scrum, spoiler warning, the world's not gonna explode. You know what I mean? And so we gotta be very careful here because a lot of people seem to confuse what is contextual good practice with like fundamental principle best practice that must be followed by all. And of course, we get to Nigel scale one, three. Nigel scale three, there we go. Nigel scale three, which is, of course, there is an ocean of bad rubbish. I would have said a rude word, but Jeff is recording. But there's loads and loads and loads of anti-patterns that if you do them, you will hate your life. We can call them anti-agile, but they're just bad ideas. And they're probably bad ideas in the most approaches. There is an absolute ocean of those bad ideas, okay? And it's very easy. And this is actually what I said. So this was the direct quote from the post I made 14 odd years ago. And I'm gonna have to read it to you because I can't remember it. I think it's very important to remember, which is which. I believe some people are treating that core idea as if it's optional, good practice. And they're treating bad ideas as if they're good ideas. And I think it's good to have lots of good chance on here about best practice ideas, but it's important we can distinguish between one, two and three. And I'm not sure all of us can yet. I think, and if you don't even ever heard of scrumb but was a big issue back in the day, or we're doing scrumb but we're not doing that utterly vital piece of it. But that phenomenon is when people don't realize where they have flexibility and where they don't have flexibility. And at the time I realized even in like the high end agile community, there was a confusion on that sort of thing. Okay, that was the idea. So I made that post, it had moderate success. By the way, people started using the Nigel scale, referencing the Nigel scale, mocking Nigel for calling it the Nigel scale because it started as a joke and turned something real great, right? Whatever it was, 2009, right? And that's where it should have stayed really the idea. But there's an awful lot of bad ideas out there. We've got a tiny little ocean of core fundamentals that we should actually follow. There's a range of good practices we can follow as coaches, scrumb masters, et cetera, where there's an ocean of bad. And so I did was, I'm not trying to self-aggrandize here, but I've spoken to a lot of conferences, right? And the reason I speak at conferences is they pay your fees if you speak at the conference. So it really incentivizes you to come up with something new each time. And over many years, I've kind of evolved this Nigel scale idea, sometimes intentionally, sometimes unintentionally, right? Well, I've just been doing something else and by accident, I discovered new things. And what happened was, I'm not gonna go into all this, but what happened was I was very, very interested about a fundamental aspect that I hadn't considered when I started talking about this core, good and bad. And this is all the fault of Dr. Who. I don't know if any of you know who Dr. Who is. Are you aware of the British TV show, Dr. Who? Anyone not aware of Dr. Who, by the way, anyone like unaware of the concept of the doctor? Well, fantastic, you're all aware, time traveling, time lord. I thought it'd be funny to do a presentation based around time, okay? And when I started doing this presentation around time, it was really, I was trying to get into the idea of coaches and scrum masters using time as a coaching tool, letting people experiment, letting people try, letting people fail, that was the idea. But I thought, why not put the Nigel scale in? It's your most famous thing. And when I put it in, I started talking about the Nigel scale over time. And I very quickly realized things don't stay good. Some good practices decay. Some bad practices sort of mature into a good practice with a more mature team, you know? Some things are like mayflies, they live fast and die young, and some practices are like elephants and go on forever. And something by looking at it from a time point of view, I realized a lot of us have been speaking about agile in 2D, you know, two dimensions. Is this good or is this bad? Is this scrum or is it not scrum? And in fact, the entire idea is these things evolve and change. Wow, I impressed myself, I have to admit, right? But the greatest thing that happened was this. Just before the world blew up. Remember when the world blew up, global apocalypse? No, not that one, the other one. No, not that one, the other global apocalypse we've had. Remember that one? Before we did that, I put in for a session in Vienna. And I thought, do you know what, I've got a good idea. Wardley mapping. I don't know if you've heard of wardley mapping. This is not a session on wardley mapping, but a really cool technique. I thought, could I combine that with a Nigel scale in some way and do like half an hour session in Vienna? And the answer turned out to be no. I completely failed, I blew it, I couldn't do it. I was literally, but what I discovered was an accidental thing. I reinvented someone else's idea. So in systems thinking, they have these blocky behavior over time graphs, right? And I accidentally reinvented their idea. I started plotting the Nigel scale concept over time visually. And this gave me some really, really interesting discoveries. Now, bearing in mind, you've already may have discovered this, so you're gonna have to pretend now that you're impressed. Just remember that, practice your, that's a good, that's good Kevin, thank you for that. Thank you, that's very good Francis, thank you. But the idea was looking at stuff over time and seeing how I felt. So for instance, at the time, a few years ago, planning poker. Let's have a note, right? So is planning poker, in the chat box, one, two, three, core good, bad? Is planning poker a fundamental core principle of agility and scrum? Is it a good practice within scrum or is a bad practice within scrum and within agile? Vote now, vote now. Don't look at the other votes. Do not look at the other votes, just vote now. Don't copy other people. Go for it, go for it. Let's see the votes now. Thank you, Kevin, for at least using the scale. Oh, hang on, hang on, okay, yeah. Keep going, keep going, keep going. I don't know if there's any more of us voting. Oh, we got here, we got a good, we got a good, we got a good, we got a okay. Thanks for that, Ashley. Sorry, Senator Nigel, is one core? What is core? Oh, sorry, sorry. I meant to say two, three and two then. Ah, thank you, that's what I was about to say, because obviously, hopefully we all know, it's not actually a core technique. If some people treat it like it, I've just been working with a company just two weeks ago who literally thought it was like fundamental law. They called it scrum poker. And it was like, this is the law here, we all, and they actually enjoy it and it's good, and that's great. But that is what I think it is, myself, for my experience. Actually, in a new team, in a new context, it's a really good thing to do. It's really helpful, gets people talking, gets people chatting, but it's got a short half-life. I think James Grenning invented it, he didn't, he reinvented it, Barry Bowen invented it back in the 80s. But even he, I think, stopped after six weeks. They did it for six weeks as a getting-going technique. But again, the problem with the world today is you just get people arguing from their own singular point of view. So you get someone here looking down. Gee, I've just done a vampire. Okay, there's some vampiric, how's supposed to be a nice normal eye? God, just monstrous, let's give it some under, there we go, make it purely evil. The Eye of Sour on here. So the Eye of Sour on here looks down and goes, ah, this is good for me, it is universally good. And you get someone else over here who looks down, that's much better face, and that looks a bit like me, and they go, no, it's a terrible idea. It's awful, how could anyone think it's a good idea? I'm gonna write a LinkedIn article about how planning poker is dead and how it's awful. And someone else going, no, you're an idiot. It's a fantastic idea. How could you, of course, it's all the same elephant, just from different angles. You've probably heard the, I think it's an ancient Indian story, but I'm not sure, but the story of the blind people, or the wise men who are blindfolded and touch an elephant, one touches the ear, and goes, ah, it's obviously a fan. And one touches the trunk and goes, out a fan, it's a snake. And the other one touches the tail and goes, snake. It's obviously a rope. And of course, they're all correct. It's all the same elephant, just from a different angle. And I think we, as coaches, scrum masters, advocates, we need to appreciate this third dimensionality to it, this decay. Of course, then you get something like affinity-based estimation, or magic estimation, I believe it's called in Germany. That's the one where you sort of lay out the cars and put the scale on afterwards, do it silently often. Again, try that with a new team with no experience. They often drown, but in a reasonable age team, it's a really powerful idea. So great, that's wonderful. That's good news. We now know that horses for courses, as they say. This practice decays, this practice grows, but what's the interesting thing about this picture? Okay, let me rephrase that. What's the interesting thing for me about this picture? You or me? Well, if for you, you can jump in, but I'll try to get it to get to my mind. What do you think I find interesting about this picture? Ashley's saying the intersection, Kevin's saying that second. Was that? Yeah, that bit. That's what interests me, right? Because that's an interesting conversation, isn't it? It's all well and good saying one decays and one improves, but what do you do when you hit that Nexus point? I can't use Nexus, can we? It's copyrighted. When you hit that point in the middle. Because that's what's interesting to me. It's like, okay, so what do we do there? And I think this is conversations people don't have enough of, which is not like, this is good, this is bad, this is good, but in changing, growing, improving, the act of transition, the act of motion. I think that's interesting. Because you could do a hard swap, couldn't you? On a Tuesday morning, go, right team. I've got a new estimation technique I'd like to show you. Or could the team hybridize it? Sort of mix the two together, sort of blend them as they grow. Could they run them in parallel? Do both and see which one they like and then fade one out over time. These are all options in that scenario. But I think this is the sort of stuff we should be talking more about, about in changing, improving, not necessarily just, that is good, that is bad. Very categorizing. Now, oh, of course you could mention things like no estimates as well. Of course, no estimates movement, chop it and count or whatever you want to do. Again, probably a great technique. A lot of people talk about it online as if it's the changing of the world. Chopping and counting stories or some equivalent model. But a lot of people look at it and they drown because they're like, well, that's not my context. I can't imagine what that looks like. I can't imagine the context. I'm not in that space yet. That makes it a hard sell, doesn't it? A lot of things we've got to talk about here. Oh, that's interesting. Refinement and sprint planning. When do, or backlog refinement in general? If you do it in sprint planning, probably a bad idea. Oh, should we spend five hours breaking the backlog up and then we'll spend five hours decomposing into tasks? Team, team, team, come back, team, come back. Just like, maybe they wouldn't appreciate that. So a lot of people, what do they do? There we go, let's jump forward. A lot of people, there we go, that's what I'm looking for, do have a backlog refinement meeting, don't they? In the previous sprint, maybe they'll have a meeting where they all come together, do some backlog refinement, nice. But is that good? Well, it probably starts off okay, but we've all been in those meetings after a few months and we've been, it's still three hours. So people then start talking about having meetings, multiple meetings in a sprint. Lovely. Some people even have it, they don't have a meeting at all. They just do it just in time. They do their backlog refinement as and when they need to do so. But again, think of the profile of that, think how it flows. Like for me, I think the journey's interesting here. Maybe I'll start off with having one meeting, but as it starts decaying, maybe, oh, will we maybe start heading off into multi-meetings? Then maybe we can get into that just in time approach. But I think, and this is what was interesting for me, these graphs, I said they're not wardly maps. Like I couldn't make wardly maps work. Well, actually you can use these graphs a bit like a map to help you have some conversations. So you map out these patterns and then you start thinking, okay, how am I gonna maneuver my way through these patterns? Imagine there's some lines on the map. How am I gonna head here? How do I get to here? How can I spot when this condition is approaching? I think having a visualization like that can help you on that journey and help you just ask yourself some more difficult questions in there. What else is there? What else is there? Yeah, that was me drawing a potential pathway we could take through, but of course you wouldn't do that. It could just be, it's just one example. What else is there? Oh, yeah, this is another interesting one for me. So like classically Scrum Master is core, right? Scrum Master is core, absolutely core part of Scrum, fundamental, yet just this week I'm working with a large company that has no Scrum Masters, none. None at all, right? None at all. Now bear in mind, this company's been doing agile for, let's rephrase that, they've been claiming agility for, I would say nearly 10 years, nearly. So where have the Scrum Masters gone? Where have the Scrum Masters gone? Can people now make up a reason why a company would claim they don't need Scrum Masters anymore? In the chat box now, please, in the chat box, give me your best, what would a company say to claim they don't need Scrum Masters? Let's see, let's see what excuses you can come up with for this, right? They have amazing, yes, exactly is number one, right? They have amazing, empathic product owners, our managers know Scrum, this is exactly what they say, we have agile coaches, this is also exactly what they said, exactly. The team is self-power enough and they're all awesome, yes, we've heard that one as well, right? It's all three on the internet. So all those are completely true, we rotate, they didn't even do that, they did that for a while, it didn't work very well, so they decided the concept of Scrum Master was rubbish. It's kind of like homeopathy, watering it down to make it stronger, but they said exactly those things, because they thought, oh, our agile coaches can cover it, they couldn't. Our product owners are amazing and empathic, by the way, they are and dying, because that's why I was there, the POs were dying, they were just like, save us, it's just awful, we can't do all this, we can't cope, you know? And so it's interesting, because there's always been a conversation in the agile space, especially around the extreme programmers who came along, they've always thought I think of Scrum Mastery as a short-term role, as a role that can dissipate over time, a role that can dissolve, once we know about the Daily Scrum for a while, we don't need someone there saying, team, team, Daily Scrum time, but again, every day, but of course they missed the fundamental part of it, isn't it? There's actually a fundamental core of Scrum Mastery that is far more crucial, which is the coaching side, you know, for me, that is the absolute heart, and I think actually Scrum Masters in reality, sort of grow into their jobs a little bit, they start off a bit, it's not great, we were all there, I don't know what I'm doing, we start off being not so great and grow into that role, as we build those relationships, as we build that trust, as we build that rapport, I feel actual Scrum Masters evolve into that role and deliver more value in that role. Once I start knowing the organisation, knowing the team, knowing the people, the team starts off organising, I can really start helping them improve the work, improve the business, and I'm worried a bit about that, because I think that sort of, there's that secret background thought of people that think of Scrum Mastery as temporary, Scrum Mastery as ephemeral, Scrum Mastery as a hat, when it's actually a fundamental core heart of what we need to do. What else is there in here? So I've been doing graphs and loads of things, by the way, now this is my latest one, this is why I wanted to do Nigel Skel with you, because I was just having this conversation in another company, and as we were talking about it, and as I was drawing it, I had a bit of a revelation, again, a revelation you may already have had, but never let me said that I'm quick. And so product backlog estimation, okay? The magical world of story points. I think the world's been talking a lot about story points recently, a lot about story points. And if you read link to or read any article anywhere, where do story points fall? Oh, by the way, that's not the torical, and now I want an answer in the box, I'm so sorry. Let's get an answer, okay. Good practice, become a bad practice? Here's an interesting thought for you, right? I go to a lot of companies, right? And they told me, oh, we do story points here. We're struggling with story points, we're struggling with them, okay? I'm like, okay, we're struggling with them, okay? We're struggling, yeah. I say, okay, what are you struggling with? Well, you know, they're hard to use, I don't know. And some companies say, well, it's not too bad here. And I say, why? Well, we say one day a point, and then it's not too hard. You know, one ideal day a point. And I'm kind of like, hmm, but it's not, they're not measuring ideal days. And they go, why no? So we changed it to half a day a point. So it's no longer 1.1 day, half a day a point. And I'm like, I think you're missing the point here. Like, I think someone's missing the point here. And so, what about, okay, what about this then? Very popular at the moment still. There we go, let's go for this one. Ideal days. Why don't we do ideal days in our backlog then? How's some ideal days in our backlog? So is that, is that, let's talk about that one then. Let's go, is that core good or bad? Two point by, yeah, the mix at all. Two to three, three to one. Yeah. Okay, so this is what I was having a chat about. I had, okay, it is a thing, right? So I've done some work recently and I've been doing a lot of stuff with Chet Hendrickson, right? So Chet Hendrickson is one of the first, one of the extreme programmers. Like he was on the first Christ the extreme programming team. He was involved in the creation of extreme programming. He was, did like the books famously, Chet is incredibly grumpy because he didn't go to the Snowbird Ski Lodge in February 2001 for the summit. Cause he thought there's, oh, Kent's going, Ron's going, I don't like the snow. Oh, I'll just stay at home, I can't be bothered. All right? And so he reached out, I can't be bothered. You guys go, I'll stay here, you don't need me. And of course now he's not one of the 17 and people always ask, are you one of the 17 agile founders? And he's like, no, but I was invited. Anyway, but he was telling me something really interesting. So he was saying, with extreme programming, they experimented loads, they tried out loads of ideas. They've failed on so many things in Chrysler before. They were trying out all these ideas. Kent had all these ideas. They were experimenting, experimenting. And then they came to a shape that really worked for them for the payroll system, it really worked. And Kent and other people wrote the books on extreme programming. But what Chet said, he said, I think we made a mistake. He goes, what I think we should have written a book about is not what we ended up at, but the journey we went on. You know, that would have been interesting, you know? Because people have been copying what we did. Like, oh, extreme programming, I'll do that in my company. Oh, it doesn't work. Not, but I think they would have got so much more if they had really explained our choices, why we made our choices in the journey we took. Because that would have helped them make better choices in their own worlds. Because like famously, they went, they've been on this journey. They've been through the real time, you know, classic estimation where it's very contextual and fragile and rubbish and move to ideal days. They were using ideal days and got burned. It's why one Jeffrey's invented story points, effectively knocking the units off so people couldn't come back in three days and see where they were. I realized, perhaps to actually really get points to work, you have to have done the other stuff. Perhaps you can't, perhaps just jumping into points without any context is a really, really difficult thing for people to do. And this is what interests me, well, let's go this way, correct way, there we go, there we go, that type of thing, right? And this, when I did that presentation on time, time laws, by the way, I dressed up as Dr. Who as well, just for the presentation, it was very good. Well, I had this dream of there being like, methods that start off poor, become good and fade into poor again. Methods with an actual birth, life and death, but I couldn't actually identify any in that presentation. But I think story points is that technique. I think it's a technique that if you start with a new team, it's really blooming hard, really difficult to get the point across, really difficult to get them to understand, right? But ideal days, everyone knows, but they're a bit crap, they're a bit rubbish. And so maybe starting with ideal days is a good idea. I think we used to say this back in British telecom, when Jeff and I worked there, you say like, you could do ideal, they start there maybe trans, because does people are so behind the times, even doing things like ideal days was a bit of a challenge for them. But maybe starting off with ideal days, understanding it's not good, but it's a transition technique to get you on to something better. And then understanding things like points are good to a certain point. But if your work starts getting stable in size and similar sized, all of a sudden you don't even need to point, you can just count and chop and count, so that there's no estimates or do some sort of measurement like the, I'm a bit, I'm not anti the lean thing, but Monte Carlo, I think I'm a bit worried, because that's kind of applying a manufacturing metaphor to stuff that is not repeatable, which always makes me a bit nervous, but generally there are techniques out there that could become opportunities or directions for the more mature team. But if we know this and we understand this, then we can start with some interesting conversations on things, okay, I'll start here with this, knowing it will fade, and I know this one won't work yet, but I can bring this one on over time. So as a coach, you're sort of layering on techniques. Like with, you know, Jeff talks about like player led coaching, et cetera, and his stuff. Well, I know nothing about that, but I watch my kids get taught tennis, and it's really interesting to see the tennis coach layer on techniques. Originally outside tennis, actually by the way, layering on techniques, so the children learn, and then they can bring it to the game of tennis, which I found very fascinating. And so that idea of not being splat everything, you know, the idea of layering and building and growing as a coach, your methods and approaches as a scrum master, taking them away after a while, say, okay, this technique is decaying, let's cut it back, let's garden these processes rather than just layer them on. Now interesting, well, it made a really interesting point here about the safe recommendation, but recommending safe is always a deadly thing to do at the best of times, but maybe there is a place, this is awful, almost heresy, because I am renowned for absolutely hating safe and everything it stands for, but maybe there's a place for it, but not how they sell it. Literally as a transition mechanism to get you off of the bad stuff on to the better stuff. The metaphor I have used trigger warning, but it's the only metaphor I can think of, I apologize in advance, is methadone. Don't if you know methadone, but where I grew up, I went to a really rough school, very rough, and a lot of the people I went to school with, about half of them I would say, maybe an exaggeration, but not too bad, got into heavy drugs heroin, right? And luckily a lot of them are coming out of that now in their 40s, they're getting off of it, right? And so I know a few of them are on methadone, which is a drug used to help you transition off of heroin. Okay? Now, if you've ever looked up methadone as a drug, it's awful, it's absolutely awful. As a drug, as the medical, when it does to you, it's an awful thing, but it's better than heroin. And so when you're on it, the idea is to transition you off of it, like you use it as a pathway to free you. And that's kind of not saying safe is like a legal drug, but maybe as a pathway to a better future, some of those heavy methods could have a place, but we've got to be very careful with them. Sometimes the cure can be worse than the treatment can be worse than the cure. I know I mentioned heroin, very famously, that's diamorphine, which was invented to try and get people off of morphine addiction. So we've got to be a little bit careful here and understand that if we're going to get into this world of introducing techniques and removing techniques, we need to be aware of how the techniques are shaped. So not part of this presentation, but one thing I've been trying to write about a lot more is, you know, safe to fail experiments. We always talk in agile about safe to fail, safe to fail experiments. Well, unfortunately, some processes are like a beastings, you know, like a beasting or like a harpoon where it's easy to introduce the technique, but hard to withdraw it. You know, hard to take the technique back out again. And those are things we've got to be very careful of as coaches, because we'll put this in for now, but don't worry, we'll take it out later when the team gets better. Oh no, and the thing is wedged in there. By the way, can you think of any, quickly just give me in the chat box. Can you think of any things, tools, techniques that are a little bit beasting, a little bit harpoon, easy to introduce, hard to remove? Can you think of anything at all? Maybe in your world, easy to introduce, hard to remove? There is one I see all the time, all the time, all the time, all the time, all the time, which is, again, I'm not here to bad mouth, I'm not here to criticize, but what I will say, Jira, the world, the wonderful world of Jira, easy to introduce. A company goes, we're going agile, we need an agile tool. Oh, Atlassian have got a suite, we can purchase. Oh, it's so easy. But once it's in, oh boy, oh boy, is it hard to get out. You know, it's wedded into your infrastructure. And so just be a little bit careful with that type of thing because that can be really hard to remove. And there's more, there's more, there's more. You know, we could get into if we wanted to, things like engineering, split backlog items, tasks. They're tasking as a concept, you know? It's not compulsory, but it's probably a good idea in a new team, but tasking your work may not be a great idea in a mature team, but it's important to understand things like the scrum guide are what I call a lagging metric. Remember, where Dev and I were scrumming, you had to task, you had to size them in hours if I remember correctly, it was like compulsory. It wasn't, and so you just have to appreciate that a little bit as well, like the good advice follows behind, it's like, it's lagging. So I just be a little bit aware of that. What else is there to talk about? Oh, and then we could, okay, breaking down stories, not breaking down stories, you know, as you mature, probably working on small stories with no tasking is a good idea, maybe. Could there be a place for story pointing tasks? I don't know, but I do know some people use it as a transition to get from real-time estimation of tasks onto no estimation of tasks that you notice in my drawing. I didn't have the guts to everywhere put it near a good idea, just less bad. Very cool, less bad, less bad, less bad again. But what's more interesting to me, I'm gonna jump forward a little bit here, is not so much that, not so much that, that's interesting actually, but I'm gonna jump forward this one actually. I'm gonna come back to this in a second. Come back to the second. So I wanna show you, no, go away. This one I wanna show you. Should your PO be in your retrospective? Yes, that's the official answer. Yes, core, PO, part of retro. But if you bring, if your PO is not part of the retro, you are bad, core not bad, bad scrubbing. But real life, you know, like if your PO turns up and says, hello, I'm your new PO, I'm here to help accelerate the, sorry, let me rephrase that. Hello, I am your new product owner. I am here to facilitate the enhancement of your roadmap. I will see that you are working hard enough. The joke being that if you haven't got rapport, if you haven't got a relationship, your PO could feel like an adversary. And if you bring that person into the retro, maybe the retro won't work very well, but we wanna get them into the retro, you know? So again, it's about how, it's the transition, isn't it? It's ideals this, realities that, you can't just go think and hope everything's gonna work. Hope is not a strategy. I need to work out how am I gonna build that rapport, build that relationship, build that trust over time and bring them in. And this is the point I wanted to get to. The entire point of the word coach is get somewhere quicker. You know, who coach comes from coach, kind of like the actual physical coaches, get somewhere quicker. So that's what interests me. Not so much should they be in or out, but how can I transition them into the experience quicker and more effectively without ruining the team and ruining their own dynamic, you know? And what could happen to slow that down? What could happen to make that longer and slower and worse? So what anti-patterns could we do to make it more difficult to bring our PO as part of the experience? They're jumping backwards. I said you haven't seen this. But this one here is interesting, just like retro, you know? Retros age out really quickly with their fundamental, their core, but they age. You know, if you do the same retro more than a few times, teams get bored quickly. And we've all been in retro, it's like 44th version of the same retro and everyone's just dying a death. So what did you do? What did you do well this sprint? Teamwork. What should we do differently this sprint? Testing. What did you learn? What did you learn this sprint? Nothing. What barriers do you have? What did you, what puzzles you? Everything. You know, what action should we take? Let's stop doing these bloody things. And so like the joke is like there are meta patterns as well where we need to kind of say, okay, if retro's decay quickly, we need to keep changing the retro, don't we? We need to keep changing the method to keep people interested, keep people engaged, maybe change the topic, maybe change the focus, but all things to keep that interesting and engaging. And so by visualizing it, you can start seeing, okay, it's not a case of just do this. It's a case of, okay, we need to revolve and rotate some of these practices to give novelty factor, at least or to give a new direction or a new idea or a new thought to keep people fresh and refreshed in the experience. And again, visualizing, you can come up with meta patterns like this. When you're, okay, now I can see the pattern, now I can see perhaps what I need to do about it. And there's more and more and more. I need to be getting bored with my own voice. But you know, we've done this, done this, done this. Let's look at this one. What's this one? Yeah, like sprint locking. Remember sprint locking? How sprints used to be locked and you couldn't change them on pain of death? Like there used to be like a ceremony you had to do to break your sprints. I can't remember what it was again. Was it like, what was it Jeff again? I can't remember if you had to lay down and scream or something or? Lay down, kick your legs and scream in. Yeah, kick your scream. And of course people took that seriously when it was just Ken making a joke in a training course. And this is another big problem with our world which is people fetishizing good practices into best practices. So say, oh, I once saw in a training course Ken said we had to sit in a circle and scream and then they go back to work and try and implement that as best practice policy. It's kind of like, maybe not, you know, maybe you're missing the joke there but he always used to be sprints are locked, good, sprints unlocked, bad. Right? And of course, as we all know, life's not as simple as that. Are sprints locked? No changes are made that would endanger the sprint goal. Oh, so they're locked but scope maybe clarified and renegotiated. Oh, so they're not locked. So there's a bit of wobbly hand and even in the scrum guide, but generally and we all know this in immature teams with new to the tech, probably it's a good idea to keep the sprints bounded and protected. So they don't get uncontrolled change happening to their faces every five minutes, you know. Yeah, a mature team running a Kanban approach who knows how to do it, minimizes working progress, good code quality, continuous integration, yada, yada, yada, you know what locking sprints is no longer needed. And so again, it's like having a 2D guide trying to cover both worlds in one statement ends up covering neither world, you know because the villains will go, ah, scope maybe clarified and renegotiated. Okay, hi team, hi, hi team. Let's have a quick renegotiation of my scope. I think you're gonna get a lot more done and commit to more now or you're all fired. How's about that? And yet, and so I think we've got to be, again how we communicate this is important, understanding this nuance, maybe visualizing helps people get a better appreciation of why we do things the way we do and why a good idea may be a good idea. What else have I got here? Oh gosh, she's 10 minutes to go. So I got fundamentally carried away with this, right? I horribly carried away with this idea. I massively carried away. So I started saying, okay, can we start like mapping things like Shuhari onto this? You know, the Shuhari concept from martial arts, Shuh sort of follow the martial arts slavishly, like karate kid, wax on, wax off. You don't know why, but you're following the moves. Ha, you're the black belt, you understand, you're stretching the martial art, you know the martial art. And Ri is your Bruce Lee. You are the martial arts, like you, wherever you do is the martial art, wherever the martial art is, you do. You live and breathe it. Like my favorite thing in life is Alastair Coburn on the Agile 17. He's such an agile person. Like everything that comes out his mouth is pretty much agile. You know, it's like, as a human being, it just exudes from his pores, you know? And so I started saying, okay, like we could use that model perhaps on the, on the nitrile scale to help us say, okay, follow a process, bend a process, transcend a process. But then I started getting horribly carried away again and said, okay, but what about the organization? That's a dimension we haven't mentioned yet. When we talk about like Shu or a learner, that's maybe a team, your team, but what does the organization look like? Cause I feel there are organizational, gravitational forces on your work and on your methods. So let's say you're a really cool team. That's great. Ha, we're advanced, but in a Shu organization, there is pressure on your methods. You know, come on, come on, points are nice. But, you know, we need to report back to the customers in days, you know, putting heat on your estimation or maybe saying, oh, Kevin, Kevin, no, I agree. That's really agile, Kevin. Thank you for sharing your agility. That's why we hired you, Kevin. That's why we hired you. But you know what? We're new to this agile thing. Maybe we'll just have the project managers doing the scrum mastery at the moment, just at the moment to get things going, you know, and it's all sort of gravitational forces pulling your bad practice to try and pretend it's viable or making core practice and try and pretend it's conditional. Frankie, I know self-organization is a really important thing. But in this organization, we believe in more of a meritocracy where the cream rises to the top and then makes the decisions for the rest of them. And like, thanks, but if we're not gonna self-organize, we're not doing scrum, we can't even call it agile. We call it something else. Hell, no, maybe, but whatever name you're gonna give it is gonna be agony. So that's why I've been on to now, really. This is really what I've been, yeah, don't go there. This is what I've been experimenting with now is like mapping other things to this. Bit of connevin, get a bit of connevin in there. But for instance, again, I think we don't define our terms. So they say 101 in like any form of scientific paper, define your terms before you start talking about it. Because when you say complexity, that may not be what someone else means with complexity. And I do find a lot of what we're doing is this crashing into each other because each person's got a different interpretation of what they're actually talking about. Like for instance, there may be clear parts of your work where certain things work well, but it doesn't mean that work well in the complicated world of software development or the complex world of product development. And so maybe we could see, and I haven't done this, I don't panic. I haven't drawn anything for this, calm down. But what I'm interested about is just the idea of those different contexts and what effect they would have on practice. And I think we just need to be aware of that a little bit more. Oh, oh yeah. You couldn't even get into Kempbeck stuff, explore, expand, extract. This is very similar to Kenevan in its own way, but Kempbeck's idea of there being situations where you're exploring, you're discovering, you're trying to find your fit, then expand as you found your fit and you're trying to grow it into new markets, grow it into new dimensions and extract as you're a mine and you can keep mining. You've got, if there's nothing new, you're just looking to get money out of the old quarries. And again, you know, we spoke about safe earlier on. Could there be an argument that if you're in an extract situation of product development where there's nothing new coming, you're just looking to exploit and pull more value out of preexisting quarries, maybe something that looked a bit safety would be legitimate as an organizational structure. But if you're looking to explore or expand, it almost certainly wouldn't be having that fixed structure in place. And then there's a couple of other coaching stances. These are my stances. I stole them from my wife, my wife was a teacher. She was taught these, you know, the idea of famously consult, tell, collaborate, work together, coach, they have the answer, not you, or character, role model it, or even silence, keep your mouth shut. But could you use those stances and think about how you use stances on process, depending on the situation? To be algorithmic, which I haven't done it, but I do think it's an interesting conversation to have with yourself, thinking, okay, just being aware. I've got a team in this situation. I've got a practice that does this. How can I best approach that as a coach? What stance would be best for me in this situation, in this moment, and be able to swap between stances so you don't just end up blasting one stance forever in every conversation? You know, I use all the stances as long as it's tell, consult, just tell people what to do. So there could be some interesting conversations there. Oh yeah, if you wanna learn more, if for some reason, I don't know why you want to, by the way, I have no idea why you would want to, but if for some reason you're crazy enough to think, do you know what, that sounded interesting. Can I get even more on that? There is videos available. I did a video on Nigel's scale versus scaling frameworks. So taking that core good, bad model and actually analyzing the top four methods, you know, so Nexus, Less, Safe, Scrum at Scale and using that model to sort of lens to look at and to judge basically those models, which I thought was quite interesting. It's a very popular video, got thousands of views, so it's quite popular on there. There's also a video, if again, if you're interested, just in terms of using the Nigel scale on Scrum itself on the Scrum Guide, because each time they adjust Scrum, here's the thing, I feel that Ken and Jeff are trying to make Scrum core, right? So they're trying to make Scrum just the fundamental core that everyone has to really do, right? A lot of people think core equals Scrum, which is a slightly different algorithm. If you think about it, like, okay, so it's Scrum, thus it's core, eh, it should be, it's core, thus it's in Scrum, okay? But every time they give Scrum a little tweak, every couple of years, I get a bit twitchy sometimes because often you get unexpected things start happening. This is not the video for that. Hey, those of you watching on video, did you make it this far? But for the live audience, if you wanna go more and learn more about that, you can watch this video. Okay, it's from the two years ago Scrum Guide update, but they haven't updated it since. Just talking through some of those changes and how we can look at it from a Nigel scale approach. It was interesting, I felt. They're also quite popular online. Yeah, oh, and by the way, this is not just me. Okay, the Nigel scale is me, but if you look at other communities, other communities seem to be having similar ideas. So Dan Vakanti has come up with like, you know, prokamban.org and they really seem to be getting back to a back to basics Kanban approach, getting away from sort of the lean Kanban university noise that has come before, sort of getting back to basics, keeping it lean. And I think that's quite interesting. Obviously I've never heard of the Nigel scale, but I think it'll be interesting to apply that across what they're doing and seeing what they feel is actually core and what's crept into those approaches. And oh, there's a couple of things here. I've made a big assumption, right? I've assumed time to be linked to experience and experience to be linked to learning, right? And that is a big assumption. With those graphs, I think there is a possibility that some people could end up in like a time loop, you know, trapped forever in early experiences. I don't have the talent or intellect to map that sort of z-dimensional thinking on a graph, but I think it would, I'd just be aware of that. I'm making an assumption here that teams will get better if you keep them together, work together, et cetera, et cetera. And that's the conclusion, really. That's the conclusion at the end of time. It's all about ink. All about ink, changing, scaling, improving, learning. Agility is for me about transition, about motion, about the third dimension, fourth dimension in terms of time, depth and time, not just this two-dimensional pictures, they keep showing everyone. And so that's what I'm trying to work on still. Agility, agility ink, agilifying is the word we could use if it wasn't already owned by one of our friends. But the idea of that idea of motion, I think is important for us as coaches, because the term coach comes from coach, moving vehicle, moving item, an item that moves, it is not static, you know? But there we go. And that's me done. I got there within one minute. I don't really have that. Second? Justin wants to know if it's a maturity model before he runs away. Yeah, no fuck off. That's like, no, but I made a joke about that because you could see people easily saying, oh, we are a shoe organization, thus we must do X. We're a horrible, I could see people doing that. And again, all they're trying to do is take a really delicate third-dimensional picture and just take a slice of it and treat that as a model, you know? I think it's like, I don't know, I don't know the metaphor, but taking a slice of something three-dimensional, I think it's a pretty bad idea. Not thinking of doing the Nigel test then, not the test. How do you know about that? No, no, no, no, not at all. Now, why don't we like three, you can do the Nigel test, take the Nigel scale, apply it to anything and then see what results you get. Because of course, the joke is, I think it'll be interesting to see where people agree and disagree as well. It's because what I think is core may not be what you think is core, which is interesting as well. Cool. Thanks Nigel. Any questions? The great man. No questions at all. Anyone just want to make statements, masquerading as questions. That's not really the best thing to do after a session, isn't it? Well, I feel a thought. No. Nigel. Nigel, I'll show you twice delivering this talk in person and here and both times has been amazing. Thank you. Thank you. It's changed this last time. The story points thing was added in the middle. Story points was added. Yeah, if you're interested, just stay in touch. I keep adding things to this. I'm just trying to, I'm trying, I don't have no value in this to anyone but me, I think, but I'm just trying to understand better for me why people clash on this stuff. And I think they're missing that aspect of the conversation, that motion, that dimension. Peter. Hi, Nigel, Jeff. I joined half an hour late, but I still wanted to join to hear you. I'm curious about the first question I heard when I joined, which was, what is the excuse that you hear for not having proper Scrum Master embedded in the team? As in, Scrum Master is a roll hat. So in one of the places I'm in at the moment, there is this thing about we need delivery leads, not Scrum Masters. And it's always, it's a company-wide rule that there are no, it's only a roll hat. What do you say in response to all those excuses you get? I'm just curious to know what, how you might react or respond or do about it. I just want to know what delivery lead does. What was missing that they needed that role? My impression is they want it as a policy. They want it to make sure things go through the door. They want someone who's accountable, one person that's accountable, whether something goes through the door or not, probably possibly there's a new client so I cannot claim to know everything about them just yet. But probably and possibly this thing about team being responsible together, maybe it's a bit too woolly for them. Because I get worried about where's the product owners in this scenario? Like, because they're the ones who are accountable for the delivery. So do they exist or not exist? You know, that's normally where the issue is. Only enough in this particular organization when they moved to Agile, a lot of project managers were given a role title of product owners. But then slowly they're getting better product owners savvy, if you like. And I think slowly also feeling the pain of a lack of a real scrum master. Yeah. My big thing is both, I've got to say one thing for anyone goes, if you want to buy Agile Bear merchandise, we have a red bubble page where you can buy Agile Bear t-shirts with a range of sarcastic Agile statements on it. I have that over, but I've got to make some money out of this thing. But Geetha, like my big issue is, like process is scar tissue, right? So this is happening not because there's context. Some things happen somewhere that has burnt someone that meant they're doing this. And what I would be interested to find out is what that is. Because then once I find out what that is, then I can help them find an answer that lines up more with our principles. So it could be for instance, they did the old scrum self-organizing team thing with rather than all of us be responsible, none of us are responsible. And so we get away with everything scot free. And I can see how that could bother a company. And so, but once I find why the gap exists, then I can start tracing through an argument to say, okay, I can see what happened. I can see where you think this is a good idea, but there's some other options here as well. In terms of sort of like coaching and that sort of side of the conversation improving. And so that's why I would try and do to try and find out myself. But I've seen, do you want to say, I've seen everything recently. The last few weeks, I don't know what's happened. People have just gone mad. And I'm just seeing like some weird and wonderful concoctions coming up from organizations. And again, you want them to own their agility. So we've got to be a little bit careful. If we go in, Scrum's the answer, what's the question? It's kind of like, we're kind of being the most unnatural people ever. Having said all that, it's like if they don't believe in facilitation, coaching and self-organization, that's going to be a hard slog, doing anything. Yeah, yeah, all right. Yeah, no, good. Thank you. Cool. Thanks, Noij. No problem. When's the next one? When's the next one? Indeed. I can't remember. But basically the next one is going to reference this one. Not the content, thank God, you're not doing that again. But hopefully we're going to talk about presentation and visualization and storytelling and those types of things. And we'll try and use this as kind of an example to reference forward that one. That's the idea. Anyway. Friday, the 17th of June. What was the date? Friday, the 17th of June. Excellent. So what I'll do is I'll watch this video back. Now, if I don't reference this video on the 17th of June, you will all realize I watched the video and went, oh God, oh God, oh God. Oh God, I can't use that. And we'll do another conversation instead. I give that's the idea. Cool. Thanks for telling me, everyone. Thanks, Zagran. Thank you. Have a look at the weekend. Jeff, are these calls usually 4.15 to 5? Oh, sorry, 4. Yeah. There's no real normal. Right. I'm not as organized as that, Peter. OK. OK. Thanks. Here's the ad, Giovanni, Jeff. That's how it is. We're holding to the vagaries of the people that I get in, so. Right. OK. I'll just look out then. Yeah. It's really enjoyable. Thank you. OK, everyone. Bye.