By Rebecca Jones
Episode 34 of The Board covers:
Agile for Non-software Teams by Gil Broza: a summary
Gavin Coughlan: Hello, and welcome to episode 34 of the board. I’m Gavin Coughlan, an Agile Coach here at Boost Agile. Today we’re going to be talking about the Scrum versus Kanban. I know that’s not the correct pronunciation of Kanban, but we’ve been trying all morning…
[crosstalk]
Paul Flewelling: …We have been…
[crosstalk]
Gavin: …We just can’t do it…
[crosstalk]
Paul: We’ve actually got Ruka, who’s behind the camera, she’s actually Japanese. We’ve been asking her for correct pronunciation, but we’ve failed miserably, so let’s not go there.
Gavin: An Englishman and an Irishman just can’t do it. This is?
Paul: Paul Flewelling, and I’m also an Agile Coach here at Boost.
Gavin: The reason that this whole Scrum versus Kanban came up recently, why I’ve addressed it, why we’re talking about it today, is because I did a training yesterday with a group, and they were new to Agile.
They had a vague idea about some of the concepts, but they already knew about it. For example, they didn’t know the values and stuff, they just knew bits and pieces.
I was talking to them about Scrum and Kanban and they wanted to start with Kanban. I was a little bit concerned because they didn’t work in an Agile way. I feel Kanban is a little bit freeform. I thought Scrum would be a good place for these people to start.
They are all software so they’re in a perfect situation. They have teams of between five to nine people. They are in a ready position to move to Scrum.
I think Scrum obviously gives you very strict and fixed rules and things to do. I don’t think it is necessarily a bad thing for somebody who’s new to it.
I just wanted to talk about that and some of your thoughts about this as well, Scrum versus Kanban and when is it good to move to Kanban, when is it good to move to Scrum, and what the main differences are.
Should we start talking about the differences first?
Paul: Yeah, let’s do that and then we can talk about the origins and where it came from and why it works that way.
The main difference I think is that Scrum limits work in progress by limiting the amount of work that’s in the sprint backlog.
Each iteration the team commits or forecasts how much work they can complete. That becomes their work in progress and that’s the work they will complete. That’s how Scrum limits work in progress.
Kanban does it slightly differently. It has a backlog, but the backlog you don’t commit to a certain amount of work and you don’t necessarily work in iterations. Most Kanban systems don’t work in iterations.
The backlog is prioritized, but you just pull the next thing from the top of the backlog into whichever column…
Gavin: And the columns will have a work in progress limit.
Paul: That’s right.
Gavin: So you can only have, say, two items in one column and three items in another.
Paul: And so, in the work in progress limits, worked at by the team. Something you have to really work on as part of your Kanban system is when…What works well, if you’ve got three developers and a couple of testers, then it’s probably going to be three in the development.
Gavin: Yeah
Paul: WIP, and then two in the test column.
But of course it doesn’t always work like that. People work together and so on, but the other problem is, of course, if you’ve got three in development and, you might overload the testers quite quickly.
Gavin: Yeah.
Paul: You know? And so, work in progress limits, or WIP as it’s called, is something you refine as you go along.
Just to give you some sort of ideas of why that is, Kanban comes from manufacturing. Kanban was originally the Toyota production system. They’ve been using Kanban since the 1950’s. The guy called Taiichi Ohno, who came up with this concept of Kanban which means message, or it’s a token essentially, it indicates when a piece of work should be done. And so…
Gavin: And he got the idea from, uh, supermarkets.
Paul: That’s right.
Gavin: From supermarket shelves, because you don’t try to put stock onto shelves that’s already fully stocked. Yeah, because it just doesn’t work. And so you wait until some of that stock has already been taken off by customers, and then you put the stock on, and so it’s a pull system rather than a push system.
Paul: That’s right.
Gavin: Where you’re trying to push the products on there. And that’s another big aspect of Kanban, that it is a pull system.
Paul: Yep. And so is Scrum.
Gavin: Absolutely. And I’ve seen people say otherwise, but if it’s a push system, there’s something broken there.
Paul: Yeah.
Gavin: Which shouldn’t be.
Paul: The pull nature of it means that…They used to think in manufacturing that you spent all of that money on machines, if they were sitting around idle, then you were wasting money, essentially.
So people would try to fully utilize their machines and their staff. Of course, if you’re making components for a product, and the machine that makes component A is a lot faster than the machine that makes component B, but you need equal amounts of component A to component B, then the temptation is to get the machine that builds your component A producing as many component A’s as it can.
Then you soon get a surplus of component A’s. If the production, or the product changes, and component A becomes redundant, then you’ve got all that waste.
That’s what Kanban tries to avoid, is overproduction, and realize that it’s not efficient just to have machines running. It’s not efficient to have machines running.
We’ve got a couple of questions from Petty here.
Gavin: She says, “Come on guys, it’s easy to say Kanban.” It’s not. We’ve been trying all morning. “Kahn Bahn” It’s the best I could do, I’m not sure if that’s correct.
Paul: And, you know, I’m very tempted, Petty, to put an Australian accent on the way you’ve put it there. “Can Ban” Anyway. Let’s not dwell on how to pronounce Kanban.
Gavin: We could spend half an hour trying to do that. It would be enjoyable for us but I’m not sure for anybody else.
I’ve seen a lot of teams were using scrum, and they feel like they’re, they feel restricted by some of the rules, by the…
Paul: Well, they feel the scrum is too prescriptive.
Gavin: Yeah, and then, they feel they have…Those meetings are taking up too much time. You know, they feel that some teams are getting burned out, which obviously is, I think, means something is going wrong there as well.
So they want to switch to Kanban, because there’s no meetings proscribed, there’s no iterations, and for a lot that works and for a lot of people it does work.
I think when you move from scrum to Kanban, sometimes you lose that urgency that scrum gives you, which isn’t a bad thing. You’re trying to complete your sprint backlog before the sprint is actually over, whereas Kanban there’s no sprint so like I said, the sense of urgency devolves a bit.
Paul: Yeah, but you still have that around individual items in the Kanban system. If you start getting a block in one area, for example, then the easiest way to unblock is to either put more people into the clearing that block.
Gavin: Yeah. Yeah exactly.
Paul: They’re doing the work in that column. If the test becomes suddenly overburdened, then you take some of the developers, or some of the developers will go from what they’re doing and help the test team.
Gavin: I think that’s from the Toyota production line, as well, because they have a system where, if somebody finds an issue they press stop and everybody gathers around and tries to fix out the problem.
It looks like we have a couple of more questions there.
Penny Morgan says, “The complaint in here is committee meetings in scrum, but they are efficient enough if your communication between meetings is, is good enough to meetings shouldn’t be dragged out.”
That’s one of the things that came up yesterday, when I was training this group in Agile. We talked about scrum. They said there’s so many meetings there, when do you have time to actually do work?
I said, well, there’s a whole middle period of the sprint there, where you shouldn’t have these big long meetings. Meetings in Scrum are there to provide real value and they should be time boxed.
Meeting are pretty strictly time boxed and if people don’t get the value out of it in time, they should learn through, well, they learn through failure. So if they haven’t done their sprint planning by the time, say, the two hour time box ends, you just cut it off anyway.
But those meetings should be providing real concise good value each time you’re actually holding them. If they’re not, there’s a problem with the meeting there, I think.
Paul: And they’re really asking, are we building the right thing? And are we building it right? And they’re looking for feedback as quickly as possible to validate if you’re doing those things.
Gavin: A lot of people who use Kanban, they still have retrospectives. For example, they might call them “Kai Zen” meetings. Kai Zen means continuous improvement.
Paul: Small incremental changes, yeah, that’s right.
Gavin: Small incremental changes. So people still have some of those meetings in place, but I suppose the planning meeting doesn’t really, really happen. The daily standards don’t necessarily need to have one either.
Paul: No, but that’s the thing, I think, they do happen in Kamran. They do. They just happen on a more granular level. So those meetings still happen, someone is still going to sit down with a pro turner and prioritize the backlog. There’s no doubt about that.
There’s still going to be that product backlog grooming, or whatever you want to call that.
Then, in terms of planning, there isn’t a need for a planning meeting. That’s true, since you’re not planning iterations, but you’re still going based on the priority of the product earners.
Backlogging is pulling the next item off, so no need for planning. But then, most people will have a coordination meeting at some point in the day, even using Kanban. They will do a daily standup. Most people will, like you said, do some form of Kai Zen, which in Scrum is the retrospective.
In Kanban, it’s when something breaks, there’s a block in your system or whatever it is, then everybody stops.
In Toyota, on the production line, they stop the entire production line. They have this policy of “Go see.” Go see is where all of the people involved plus management will gather around the particular part of the production line that stopped and work out what the problem is. They will do some root-cause analysis.
Gavin: I think one thing that Kanban really helps there is because the three main tenets of Kanban are limit your work-in-progress, visualize your workflow, and keep the workflow happening with a pull system, right?
Paul: That’s right. And optimize your workflow.
Gavin: Optimize your workflow. I think the visualizing your workflow with these columns with limits of work-in-progress really helped to see where a bottleneck is happening and where people do need to implement that sort of stop system from the Toyota methodology or whatever you want to call it.
Where everybody just say, “Oh there’s a lot of buildup in testing. Let’s all see what we can do there and see what we can do unblock that column so we can keep work flowing through.”
It’s really easy to see that’s happening in Kanban. That’s what’s so great about visualizing your workflow. If you don’t do anything else in Agile, making your workflow visible is going to be really, really useful for people, I think.
Paul: Absolutely. I actually prefer Kanban’s approach to Stop and see or Go see. You’re fixing the problem as they pop out.
What often happens with Scrum is you wait until the retrospective. Then people would often have forgotten what the burning issues were at the beginning of the sprint, for example. I like Kanban’s approach in that sense.
Like I said, you’re still spending time improving your process. I think it would be bad not to, I think.
Gavin: Yeah. Like the people I was talking to yesterday who are new to Agile and everything, I think Scrum is a good way to start because of the four Agile values. The framework of Scrum really helps those happen. Just because you’re doing Scrum doesn’t mean you’re Agile.
It certainly helps because we have the iterations, which is helping you get the working software out there quickly.
You have the meetings, which is helping the customer collaboration and also the individuals and interactions. As well the iterations and the backlogs really help with responding to change and so are the reviews and the planning sessions as well.
I think it’s really good training wheels.
I can’t help but feel people jumping into Kanban are going in ill-equipped with actually being Agile. What do you think? This is possibly another question you can’t even answer.
How would you know where the team is talking to you and they want to be Agile and they say, “Should we go with Kanban or Scrum?” How do you gauge that? Is that even possible to do?
Paul: I think it is. I’m currently talking to a team at the moment who is considering Kanban for their operations.
I think Scrum for us has a better sense of collaboration between the two because I have to work together with the product owners. There’s much more conversation that happens around the user stories as I get ready to come into the sprint.
Then as I get worked on in the sprint, there’s much more conversation. I think the danger with Kanban is that it can…an individual can just go and pull the next work item. They don’t necessarily have a conversation that involves the entire team. They certainly won’t have that conversation. They probably won’t have a conversation with the product owner about what is going on with the work they’re doing.
It works well for tasks where the work is known or can be analyzed and worked out. I don’t think it works well for stories where you’re building something with unknowns or uncertainties or you need technology or new ideas.
You don’t know how to implement those. You need to collaborate quite heavily on those types of user story. I haven’t answered your original question. I’ve gotten off on a bit of a [indecipherable 14:34] .
[crosstalk]
Gavin: Well, no. I think that answers it a little bit. I mean I did ask you. How do you tell when a team approaches you whether Scrum or Kanban is the right thing for use? You’re basically saying that Scrum is good for teams where they’re working with a lot of unknowns. Kanban is good for teams when they’re working with a lot of…
Paul: It’s more known, yeah.
Gavin: …the more known stuff. Then they already have sort of planned their tasks that they have to do rather than like I said stories.
Paul: What I’ve seen as well is people who do Kanban where there are unknowns, they end up integrating some of the Scrum meetings into that. They will have, like I said, daily standups. Then they will also have retrospectives.
They’ll have a fixed period of time, which is at the end of an iteration will be every couple of weeks with that retrospective to make sure they could [indecipherable 15:22] .
[crosstalk]
Gavin: They often start working in iterations as well. It becomes a Scrum/ban around a lot. A Scrum/ban seems basically like Scrum just with a different…
Paul: Type of backlog.
Gavin: Yeah.
Paul: The key thing there is that Scrum kind of fixes the backlog in place for the sprint so that the developers are working with kind of some knowns at least within their work. Whereas Kanban, the priorities can change and shift assuming the work hasn’t already been started on that particular backlog item.
Gavin: I think another time when a team can move to Kanban, I feel if they’ve been using Scrum for a long time and they’re really an Agile team. They’re high-performing Agile team.
They’ve got those four values. They’re living by them. They’re not just going through the motions. They really understand the benefits of being Agile. That’s just the way they are at that point.
I think then, that they can make a move to Kanban fully confident that they’re still going to adhere to the Agile values. It’s like that whole “Shu Ha Ri” thing.
Shu when you’re learning and you know the rules, possibly then Scrum is a good thing because it gives you that framework.
Then Ha when you can start modifying things a little bit and brings some of your own flavor into it.
Then Ri when you are basically making up your own rules. You’ve thrown away the rulebook a little bit. Obviously to get to that last point, you need to go through those first two stages, I think.
Paul: Yeah. That’s right. You’re basically taking up the training wheels that Scrum provides. I’m just going to check. I think we’ve got [indecipherable 17:08] chatting away.
Petty has come back and said, “This is written in reference to the meetings. There’s too many meetings. If they are efficient enough, if the communication between meetings is good enough, then the meeting should be dragged out the other side.” That’s Petty’s viewpoint.
That’s right. I do believe that to some of the case that Scrum fosters is that collaboration so that you don’t have the meetings, we find, don’t last anywhere near their time boxes apart from retrospective maybe.
Gavin: That whole customer collaboration Scrum does faster.
For example, we’ve got a situation here where we’re working on a project. The product owner comes in from standups and then is not collocated for the rest of the day but is in contact a lot by email.
We’re actually going to get them in at least for a couple of days a week now because there are so many emails, that we just know if they are here in the office, it’ll save so much time and the communication will be so much better.
It’s fantastic that that they can actually give us the time to do that, and it obviously shows their commitment to the project as well. Plus having them here is going to just make life a lot easier and more efficient for those couple of days.
So Kanban obviously doesn’t have a product owners?
Paul: No, but they do have that kind of…There is that role in product development. If you just came in for product development, then obviously you need someone who has ownership or the vision essentially, and the budget. I think those are still essential, and for the success of a Kanban project for product development.
It’s worth going back to the fact, in this research, Kanban does come from manufacturing, and Scrum comes from product development. Kanban operates, uses principles of Lean and Don Reinertson’s book, “The Principles of Product Development Flow.” He’s really started to cross that over to a lean kind of ideas.
He’s starting to cross over into product development, lean manufacturing concepts in there, and slot it into the product development sort of space.
But the key thing is with product development is, when you are manufacturing, you have to have most of your unknowns already, and then you are just going into a production process.
Whereas, when you are actually building a product, you are building something completely new from scratch. Lots of uncertainties, new technologies, new idea, unknowns involved in building that, so you need a more empirical process, and Scrum already fosters that empirical process.
You are stopping, you are experimenting to see if something works. If the experiment works, then you amplify the experiment, if it doesn’t work, you dampen the experiment and you try something different.
But that’s the real key things. If you are building a brand new product and you are in the early stages of that, Scrum I think is essential. Kanban really works well in terms of operations or business as usual, where you’ve got a continuous flow of work, especially in operations where the work is often coming from different sources.
Gavin: I think we’ve got another comment there; Paul is going to check that.
Paul: It’s from Tony. There’s a good and free book called Kanban and Scrum, “Making the best of both,” it’s by Henrik Kniberg on InfoQ.
Gavin: That is a free download like Tony says there, and it is very good. We’ll put a link up to that on live stream after the show as well, and we have a look at it. It is very good white paper.
Paul: What I really like is it’s 120 pages, lots of illustrations, and there’s a particularly good section which is “The day in the life of a Kanban,” and there’s also “one day in Kanban land,” it’s called “One day in Kanban land.”
Then the first section, the first half of it, is there’s a description of Scrum versus Kanban, and the differences. The second part of the document is a case study which is I think a brand operations.
Gavin: Used from the concepts from that to explain the differences to those guys, yesterday they were talking differences between Kanban and Scrum. Is there anything else you want to discuss?
Paul: Well on that just note, Kniberg has written a number of good texts, and one of those is called, “Lean from The Trenches,” which is their project. They did it with the Swedish police a few years ago. They were using Kanban, a massive Kanban board to manage that project.
I really recommend it. It’s not a very long book, it’s called Lean from the trenches, and it just talks about the kind of things that they ran into while they were running.
What I really liked was some of the concepts where they, not necessarily anything to do with Kanban. They were for example…They’d limited themselves to 30 bugs, and they never had more than 30 bugs.
Gavin: Can you explain that actually? Well I know better, I’d just like you to explain that whole concept, because I think it’s a great idea, and a good way to get people out of a certain rut.
Paul: Well we’ve got the same issue here. One of our projects has been going on for five years. We’ve got a bug tracker which has got hundreds of bugs in it, none of which are, or very few of which are relevant the current status of the system. But no one has got time to actually go through in triage or remove those bugs.
We did try, we spent a few days, about six months ago, maybe a year ago, trying to clear up the system, and realized we were…Well I can’t think of an expression that isn’t great, pushing stuff uphill. We realized we were pushing stuff uphill quite badly.
The concept that Kniberg and his team came up with was that they only ever had 30 bugs ever. There were 30 slots. If a bug came up that was more important than one of the bugs in the top 30, then you worked that way with one, which bug is replaced, and you slot the bug out, and you put this bug in.
It meant that they were constantly only focused on the top priority bugs. If a bug came back, then what is naturally going to happen? If a bug is important or it keeps recurring, then it will come back into the top 30 at some point, then they will fix it.
Gavin: I love that idea because just having a list of 30 bugs is mentally just so much easier to approach, than this ever expanding list of bugs which just seems insurmountable and becomes impossible to actually prioritize.
Having that fix limit of just 30 in there, I think it’s really great, and I’d be interested to try that on projects.
Paul: The key to understand with that approach as well is they were trying to fix both…They had a system which isolated bugs as quickly as possible, and so those bugs wouldn’t get recorded.
If that was still in development, that particular product backlog item was still in development, then they wouldn’t even bother recording those bugs, they’d just get rid of them, pin posted notes, and fed back to the developers to fix. Often the testers would go and work with the developers to fix those bugs, pair style.
So those bugs that made it into the top 30 list were the only ever bugs, what we call “Escapees” or “System test” or something like that, or in a wider test somewhere else. So I think it was basically production escapees.
Gavin: I wanted to ask you this little spin-off topic with Kanban versus Scrum, but I think this is a really interesting idea.
Paul: The Kanban board actually had the top 10 features, the top five tech stories, which are like architecture stories, and then they had the top five bugs.
So that was how they kept filling those slots, and they worked out, who is allocated to features, who is allocated to tech story, and who is allocated to bugs, and they would work that.
Whoever was allocated to features would pull from the top 10 features and so on.
Gavin: Just before we go as well, I wanted to talk about an image that you sent around which I find quite interesting. Because your Kanban board, so you can have different columns, and different people have different columns. Sometimes you’ve sent around a really interesting one.
There is a team who wasn’t adhering to the definition of Done, which is still sometimes a problem.
Paul: You can use this is Scrum as well; this doesn’t need to be restrictive to Kanban.
Gavin: Absolutely, because they weren’t looking at the definition of Done, making sure they were going through their definition of Done. They made each column an item from that definition of Done. So a card had to go through each of those columns and still work out into the Done column.
That obviously ensured and made visible that every item was being really absolutely done completely.
Paul: That’s right. So they had columns like Browser tested, and Automated tests written, Documents written, and so on. So each column was an item from their definition of Done. It worked really well.
In Kanban systems, what they do is each column has a set of rules, the definition of Done rules, meaning it can go from that lane to the next lane, assuming there’s space in that lane, neither working progress limits, the availability or a slot in the next lane. They explicitly state their definition of Done under each column on the Kanban board.
Gavin: I think this is a really nice idea if people are forgetting about their definition of Done, or if you are still feeling the definition of Done is actually being adhered to.
So I think that’s about it for today. So thank you very much.
We’ll be uploading this to YouTube as well and we’ll put a link underneath this to that white paper that Tony mentioned about Kanban and Scrum.
We’ll have to make them work together. I think that’s the theme of it, making the best of both. Thanks very much and we’ll see you in two weeks’ time.
Paul: Thank you, see you soon.
Kanban and Scrum – Making the Most of Both – Henrik Kniberg and Mattias Skarin
Create a Kanban board and go Agile in an instant
Scrum and Kanban: Less is more
Scrum and Kanban: a developer’s perspective
The Board 22: Scrum and Kanban
