What you taught me about Scrumban. (And Kanban.)

I asked you for your thoughts on Scrumban and you responded in some numbers. I also got more than I bargained for. I've been getting something very wrong and it's time to come clean about it. Welcome back to the shed at the bottom of the garden. You know I had a comment not too long ago casting doubt on whether I really am in a shed at the bottom of the garden. So I think we need to put that one to rest and take this thing outside. Yes, it is a shed. Yes, it is at the bottom of the garden. You're not seeing it at it at its best: that's undercoat; I need to get a top coat on. That's on my Kanban board. But to business! Let's get straight into some of your many many comments. Here's one that I liked: "Dear Gary, I followed your channel for a while and it become quite a fan of Scrumban (excellent!) So now I'm scared... but always excited to see what insights you have to share". Yes, I do have some new insights. And the person who sent me this email is probably not the one that should be scared because, as you'll see, it's more me that became scared the more that I went into the comments. And to foreshadow that a little bit I had another email (I think it was an email - I'm not sure) saying that - in quotes - "If you tell me you're doing Kanban I also have a good idea of what you're doing". I think that was a quote - that was a quote - from me from my previous video all about Scrumban where I talked about how I thought it had an identity crisis and this person has basically said, "The Kanban bit: are you sure?" He actually says "Do you think so?" Yeah, we'll come back to that because that's quite key to some new realizations that I've been having. As I said, we'll get to that in due course. I sent out an email. I sent out some various quick questions on various places: I guess there was the video itself, all the comments that came into that. I also sent an email to my whole list saying if you have any thoughts on Scrumban please let me know. And last but by no means at least, LinkedIn. I also put a post on LinkedIn asking for feedback and I got plenty. But let's start with a real simple one: "Scrumban isn't that a cross between Agile Scrum and Kanban? I think I've heard of it. But other than that I don't really have a strong opinion on the matter." Okay. The one that really made me smile was from Krishna on LinkedIn where he just says "Scrumban the agile turducken." And he provided a nice little picture of that dish - I'll put it up on the screen. And Krishna, you got me. I went looking for the etymology of that word expecting to find it was German or perhaps East European. It's not. It's just the words chicken turkey and duck. Not in that order, is it? No: turkey, duck and chicken squashed together. A portmanteau word. I've tried to group these. I've tried to put some structure to it. That's not always easy to do. I had many people saying, well, expressing concern about "this Scrumban thing". Here's a good example of that: "I think many people who want to implement Scrumban don't always have the best intentions. They want some sort of easy watered-down version of Scrum. So really they want ScrumBUT rather than ScrumBAN. So it's Scrum but we're not doing the things that we don't like doing." Yeah, and I think in my in the previous video I'd expressed that very sentiment. This is a good one, also on an email. (By the way, when it's an email I'm not going to mention people's names. When it's LinkedIn I may mention people's names.) This is a good one: "Generally when a team tells me they're using Scrumban, it's another way of saying 'We do Sprints. We don't meet Sprint commitments. We can't make commitments. We pick the parts of Scrum and Kanban we want to do. We get all worked up done so don't bug us'". Yeah. The next series and Malcolm Lisle. Malcolm sent me an email but he also sent me there's also a post on LinkedIn and I think it was from Malcolm that I first heard about "ScrumBUT". I've already mentioned that: 'Scrum BUT the-bits-you-don't-fancy-doing'. I think it was also from Malcolm that I first heard about ScrumAND: 'Scrum and all the things you can do to Scrum that don't break Scrum'. I think he said that in those very words: "Anything you care to add to the Scrum framework that does not break Scrum". And I had many people saying things along the same lines. And actually one person.. this was this was I think the nicest statement that I got - also on LinkedIn - Michael Lloyd said "Scrum expects Kanban in my opinion. Scrum without a workflow management system probably won't create long-term success. Yes you can technically do without it, but you're leaving value on the table". And yeah, so kind of another reminder as if one was needed that Scrum is a framework: we're at liberty to add things to it as long - as we stay within the framework; it's not a methodology - I think we hear that a lot. And yeah. And this person is actually going one step further and said "If you just stop at Scrum and you don't start adding in those bits of Kanban, well yeah you're missing out. Now there was a moment when I saw on LinkedIn that Kirk Bryde had replied to my message about my question about, you know, "Scrum what do you think? Discuss!" Now Kirk Bryde is kind of famous in the agile world, so I was worried. And in a way that worry was justified. So let me share his view of the world. which I think is better than mine - just to give away a little bit of the ending! "Srumban is like vegetable soup. It starts with the usual broth - Scrum - and then vegetables are added to it according to the chef's taste and according to what vegetables are in season or ready to pick from the family garden. Thus there will be many, many versions of this 'Scrumban soup'. Corey Ladas's version may have been the first but many others have been created over the years. There's not one single version. There's not a Scrumban Guide at least not an official version. There's no 'Manifesto for software development using Scrumban'. There have been few books written about Scrumban apart from Corey Ladas's book, which is no longer current. [That's true.] And there's no longer any authoritative book or author of Scrumban. Kanban is not an Agile Framework (and Scrumban isn't either). The Kanban method is only one way (and a good one) to improve the workflow processes of our Agile software development teams. Professional Scrum with Kanban is a flavour of Scrum (and a good one). Think of Scrumban as a mix of vegetables that can be added to the soup. But you need a you need to start with a broth or it ain't vegetable soup". I can't tell you how many times I read and re-read that and realized that, as a model, this vegetable soup model it is it's mostly okay although flawed. Back to that in a second. I think it is flawed but that's where I'll definitely be looking to you for your thoughts. But really why read and re-read it so many times it is that it made me realize that my version - my model - was very seriously flawed. If you've seen any of my stuff I start with Scrum over here (when I'm talking about Scrumban) Scrum's the starting point, Kanban at the endpoint, and with various way stops in between which are "The Scrumban Journey". Because Scrumban as described in this book is kind of about the journey - about adding things. Like adding those vegetables to the soup. So, yeah, step by step by step. But what's flawed in my model is this that they just kind of assumes or kind of implies - it strongly implies - that this end point this destination is a framework and it's a framework called Kanban. And that's something that has been running through my stuff - this idea of Kanban the framework - it's been running through my stuff pretty much since the beginning, and that's eight years of videos on YouTube. So this is a kind of an awkward moment where I have to say, I have to concede, that that's not technically correct. And maybe for some people - and I think for many people - it's been kind of a useful model: that we have Scrum over here and we have Kanban over there. But it's not technically correct: Scrum is a framework. It has a Scrum Guide that guides you through what the parameters of that framework are. It defines the parameters of the framework. There's now - there wasn't back when I started doing these videos - there's now a Kanban Guide. But it doesn't detail a framework, it details a series of principles. So it is kind of like those vegetables to be added to your broth. So having said that, and having acknowledged that the vegetable soup analogy is a far better model than my "starting framework, ending framework", I have a small problem with it, a small problem with it, and like I said, much better: it's a much better model than the one I've been pushing for the longest time but I have a little bit of a problem with it, and the problem with it is that this book is not well it definitely is about adding those vegetables to a broth of Scrum. It definitely says start with Scrum and add things to it. But it ends with something that is no longer Scrum. And I think the intention of the book was that by the end of it you wouldn't be doing Scrum - even though for quite a lot of it you still are. Because as someone said I think in one and I hope I read it out - you kind of have to start some (actually maybe I didn't read this out) but you do have to start somewhere. You do have to be doing something in order to come along and apply those Kanban principles and practices. So that kind of brings us to the next section of the comments where people were talking about on we're talking about Frameworks maybe is that - if that's the right word. As you can see I'm now very cautious to use that word "framework" but talking about "approaches", let's say, that are NOT ScrumaAND but we're getting into the region of ScrumBUT... but (if this is possible - if this makes any sense and I know it doesn't) ScrumBUT in a good way. So with positive intent. Not just leaving out stuff that we that we don't like the look of it. And so here's a comment that I think was on the on the YouTube video: "Don't we and shouldn't we fit the processes to our situations?" This person says "We use Scrum ceremonies but we like to feed in work as needed as Kanban does. It fits our situation." Yeah, good point well made. Framework rigidity. This is another. This is also on LinkedIn. Joe, thank you for this one: "Framework rigidity will take you further away from agility versus being adaptive and following the values and principles of the manifesto". Interested to hear from everyone watching this what you think about that because I think that's fairly compelling. Here's a another good comment on the on the last video. This person says, "I tend to agree with you in past videos but here I strongly disagree strongly [disagree with what I was saying in my previous video]. In my opinion, it's bad to be a framework purist in follow a framework to the letter. A hybrid of bits from all frameworks is what I find best as long as you are agile and evaluate in evaluating your process of what works best for your team then you get the best of everything". This person goes on to say, "If you call it Scrumban or some other name or nothing at all it's not the main point here the point is that is to work in a manner that fits you and your team. Yes, not a popular opinion among licensed Scrum Masters: it threatens their job if everyone does what's best for them and not what the guide or framework says)". Yeah and I think there was someone else who chimed in that basically upvoted that comment and said, "The overall point is to do what works for your team". Hmm. This I think is where things get a little bit tricky, possibly where they get quite interesting. So what we're talking about, we're imagining a state of affairs where we're doing something that is valid - perhaps we've started with Scrum and we've added in as much Kanban as we possibly can everything's working well and we get to a point where we want to drop something from Scrum. And at that point we're - I'm sure you know as well as I do that any part of Scrum left out means that you're no longer doing Scrum. Or... we come in from an entirely different starting point never having passed through the Scrum framework. To use - or perhaps misuse - Kirk Bryde's model, we start from a different broth. And end up with something that, well, I think quite a lot of people (according to this) thought was valid. But what I really want to know is what you think is valid. What would such a framework that-isn't- Scrum look like? What have you found works for you and your team? And how specifically does it differ from Scrum? I want to hear all about it! Let me know you know where: in them-there comments below.