Monday, July 5, 2010

Scrum vs Kanban

While having a twitter "discussion" on some of the differences between Scrum and Kanban with Alan Shalloway, he prompted me to an article he wrote about the subject. It's a very interesting post and I would encourage you to go read it now.

I like how he attributes a team's learning ability as a result of retrospective done throughout different projects. On a scrum project, this would happen once at the end of every iteration. Kanban, by Alan's thinking, do mini-retrospection every day while reviewing the Kanban board. Would many mini-retrospection be equivalent or better to a "prescribed" end-of-iteration retrospection? I don't know, but the thought is interesting. Obviously the team also gets key learning outside of retrospective but this is true regardless of process.

In the same section he describes scrum as a black box, with well-defined inputs and well-defines outputs (product backlog -> software built). Although he mentions that these words are not his but Ken Schwaber's, I don't agree with them. I hate the thought of any process to be described as a black box. It almost implies that the results are guaranteed when given a set of similar inputs. We all know that this isn't true in software development. In fact, that's why we look at empirical process in the first place instead of traditional prescribed methodologies. The input might be well defined as a product backlog, but the product backlog itself is not important, what's interesting is the stories it contains and the complexity behind them. Given a similar project with a different team, the product backlog might look completely different. Scrum is a black-box as much as any other process is a black-box, requirements-in -> resulting assets out. This usage of black-box in that context is not very interesting and obviously can't be used to differentiate methodologies.

In both Scrum and Kanban, they have a solution for one of the most frustrating aspect of our work: interruptions. There's ton of different types of interruptions (meeting, phone calls, company outings)but one that really is costly is switching tasks because of priorities. I don't know of a worst thing for a developer to put his solution on hold while he's switch to another "more important" task.

Scrum's approach is to lock an iteration down (normally 30 days) where you cannot changed anything that you planned to worked on (sprint backlog). If you do change something because of grave priority, then the scrum master may cancel the sprint entirely if the sprint goal is invalidated. This is normally an exception and not the rule.

Kanban's approach is more flexible, you cannot change the task that you are currently working on unless you haven't attained your limit, but you can certainly changed what's the priority for the tasks in your to do list. Iteration isn't a prescribed practice in Kanban.

In my mind one of the most important factor between Kanban and Scrum: Inclusion of Management. I actually agree that Kanban is better on the relationship between management and their team. Although I don't agree that Scrum stops management from providing "proper interference"(maybe an oxymoron?). Interference might not be allowed at the daily Scrum meetings, why waste everyone's time if only a few are concerned. There's no reason why a guiding discussion can't happen with the Scrum master on information that could help the team. Having said that, scrum does create a barrier between management and the members of the team that many managers would find uncomfortable (more on this later).

I disagree on the visibility being the main factor (it could certainly be a factor). One of the factors I attribute to Kanban being easier to accept by management would be "Controlled Change Management", which Alan says is the biggest difference between Scrum and Kanban. I think that this factor alone make it so much easier to get backing from middle management and above. I believe having buy-in from management is one of the most important aspects of adopting a process (agile or not) for a company.

If you do Scrum by the book, using the Chicken and Pig analogy, how many business do you think would be ready to accept it top-down? It takes so much control and power away from the management (even if it might be for the better good) and they are the ones that should make the decision to use Scrum. Or at least endorse it because the different teams believe it will help. Most of the time, Scrum is instead implemented bottom-up (it's easier to ask for forgiveness instead of permission), and then it's up to the Scrum master to act as a proxy between middle/high management and the team. Gantt charts over Product backlog, Scrum meetings where he urges some "chickens" to remain silent etc. Maybe eventually, the results will speak for itself and will break down the barrier for an adoption of Scrum throughout the organization, but that takes time. Managers that employs a "servant-leader" approach already know instinctively why a methodology like Scrum would work, but not everyone is so open-minded.

I've been with a company where one of a project really hit an impasse with one of our customer. We were in trouble, everyone was desperate. We called in some expert to put a process in place that would help us out with our problems. I wonder how many companies are in that state of mind when they accept Scrum? It's unfortunate, but I can see more companies accepting it because of desperation rather than wanting to change for the better. I think this is fast changing though.

So the ability to slowly adopt Kanban in your organization will certainly be easier to sell than the Scrum "in your face manager" attitude. Especially with managers reading books like "The inmates are running the asylum" :)

5 comments:

  1. I believe your thoughts about a black box actually mirror Ken's. The idea of a black box is _not_ that it is repeatable or predictable but rather just the opposite - there is no way to figure out in advance what to do for different situations. In other words, one has to adjust each time to the new situation at hand. In other words, the team works as a black box - they figure it out, but the exact mechanisms are only known to the team.

    ReplyDelete
  2. I'm sure you are right, Ken is certainly using it in that context. I find the use a bit odd. If you think as black box as in black box testing, essentially you don't look at the innards to figure out how to test. You give it precise input and expect precise output. Although I think you are right in how he meant to use the term, I still don't like the usage myself. Then again, who am I to argue with the likes of Ken Schwaber? :)

    ReplyDelete
  3. anyone can argue with Ken Schwaber - or me. Merits lie in what is said, not who says it.

    ReplyDelete
  4. Thank you for the info. It sounds pretty user friendly. I guess I’ll pick one up for fun.

    Thank u.

    Scrum Problems

    ReplyDelete
  5. This comment has been removed by the author.

    ReplyDelete