Kanban or Scrum for tough deadline project?

Question

Sorry in advance if my question looks silly, but it's bothered me for quite a long time and haven't found the answer to it yet. I work in an IT outsource company and due to specifics of my job I participate in interviews quite often on either side (as a candidate or interviewer). And I can say that there is one popular question for a team leading roles that I never really knew how to answer correctly:

Which process methodology (Scrum or Kanban) would you prefer for a project of tough deadline?

This question doesn't make a lot of sense to me. I actually don't think that any approach is better in this context, since both have approximately the same amount of process overhead compared to no-process approach. I think the goal of either of them is to make things predictable and transparent, but not faster, and I don't think that time aspect is any measurable here.

People tend to answer Kanban to this question since it's more flexible and has lower restriction for WIP, but i think that Kanban won't win the race if you work on a well-documented huge project and can just scale sprint length to fit your team speed perfectly, so it rather depends on project preconditions.

Am I correct here?

Answer 1

I assume as an interview question, the primary purpose of this question is to see how you think through these ideas and decisions. In that regard, it's a fair question for an interview. For real life, it's an overly-simplistic question that ignores far too many other factors.

First, there is the argument to be made that neither Scrum nor Kanban is a process methodology. Scrum is a process framework which may seem nit-picking, but it means there is a lot of room in that framework for other practices that can influence your process immensely. Kanban is a change management methodology meaning that it's a thing you do to improve and optimize your process, so a lot depends on the process you are applying it to.

What you could say about the approaches is this:

If you are practicing Scrum, you have a potentially-shippable product every sprint. This means that if the product isn't done by the deadline, you still have some shippable product.

Kanban puts a focus on optimizing systems, so you should be more effective at delivering work as your team progresses.

I've also worked on Scrum teams that use Kanban to improve the flow of work through their team, so it's not truly and either-or question.

Perhaps an even more interesting question to ask in response is what a "tough deadline" means. Usually when I hear that what it means is you have a fixed scope, a fixed schedule, and fixed budget to build it in. Of course, we don't need Agile to tell us why that doesn't work. Every project management theory for the better part of a century calls that a recipe for disaster. As I said, fair enough to see how someone thinks through a problem, but ultimately, the question is flawed from any real-life application standpoint.

Answer 2

TL;DR

If you have a very tight deadline, use whatever framework the team is most familiar with. Trying to learn a new framework on a tight deadline is just asking for trouble.

Both frameworks can accommodate deadlines, but Scrum has the notion of time-boxing baked in. Kanban solves many of the same problems, but is not primarily concerned with deadlines or time boxes as first-class (or even second-class) concepts. If you have equal experience with both, then Scrum is often a more intuitive fit.

Comparing Approaches to Scheduling in Scrum and Kanban

Which process methodology (Scrum or Kanban) would you prefer for a project of tough deadline?

Neither framework is actually focused on deadlines. At a high level, Scrum is about negotiating scope, while Kanban is about negotiating cycle time. That isn't to say Scrum doesn't care about cadence, or that Kanban doesn't care about scope or time-boxing, but each one by itself tends to focus more on one than the other. That's why Scrum and Kanban are often used together in many agile shops: they're complementary approaches, not orthogonal ones.

With that said, if someone handed me a project with a very small number of iterations to complete it, I'd choose Scrum. That's not because things would get done faster or better with Scrum, but rather because the framework requires the Scrum Team (and especially the Product Owner) to continually ask "How much can we reliably deliver within the given time box?" Whether that time box is a single Sprint, or a time-boxed project with a hard deadline, the framework is designed for adding or trimming scope to meet short-term goals.

Kanban can do the same thing, really, but scope is less front-and-center in a methodology that's primarily focused on optimizing for flow. If you're a Kanban expert, you can adjust your queues and batch sizes to control cycle time and scope, but it's not an intuitive fit for time-boxing (which is what a deadline really is).

It's also worth mentioning that Scrum explicitly calls for a Sprint Goal, which is the central cohesion for each iteration. In contrast, Kanban isn't goal-oriented. While you can certainly queue work in Kanban in a way that expresses goals or evolving priorities, the system itself is really about continuous flow rather than focused, goal-oriented delivery.

In summary, you can use either method, or both together if you like. However, for time-boxed, goal-oriented work products I'd certainly consider Scrum a more natural fit.

See Also

How to Perform Agile Release Planning

Answer 3

I have been a long time skeptic on agile methods, not because I am against new methods to develop but mostly because of the almost church-like, faith based approach a lot of folks seem to exhibit. So there's my bias. That said, however, I do try to find any published science to see if there is some efficacy of one approach over another, and by science I mean a truly independent examination using sound qualitative and quantitative research methods, peer reviewed, etc. I have, so far, been unable to find anything but I do see a lot of pro and anti publications with anecdotal claims supporting their position from obviously biased sources. So the answer to this question or any other question similar to this is unknown and is more about finding a candidate who agrees with the interviewer. There might be some goodness around doing that for fit, but doesn't really expose anything else.

Answer 4

Its a trick question. Kanban isn't a process methodology. Scrum has to be the right answer.