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 2023 saying you need to
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.