2

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?

  • Scrum does not impose WIP limits. Sprint length does not scale to the team speed. Where have you learned these ideas? – Venture2099 Jan 13 at 8:45
  • @Venture2099 Sprint scope should not change until the next Sprint is started, should it? This is considered additional WIP restriction, so you have to know your team speed well enough to fit it's capacity for a sprint – The Dreams Wind Jan 13 at 11:04
  • That is not WIP. Work in Progress is the amount of discrete items in progress at any one time. It is not the sum of Sprint Planning. Sprint plans are designed to produce a product increment to enable fast feedback from stakeholders. Test and learn. WIP limits are there to ensure staff do not take on too much work at once. – Venture2099 Jan 13 at 11:34
  • The sprint length does not scale to team speed. The sprint length is whatever makes the most sense for your environment, product, team and technology. The team's capacity for work is what scales. – Venture2099 Jan 13 at 11:35
3

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.

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

0

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.

  • David and @Venture2099: While there is certainly a body of science behind agile frameworks like Lean, David is correct in saying that there aren’t a lot of studies showing framework causality. Statistically, agile projects properly implemented often outperform properly implemented non-agile projects, but correlation doesn’t prove causality. So, the non-statistical science is still out, leaving room for alternative interpretations. – Todd A. Jacobs Jan 14 at 18:05
  • On a moderation-related note, some comments on this thread have crossed the line on the SE CoC and “be nice” policy. As such, I’m deleting them rather than moving them to chat. Comments are mostly for clarification or minor footnotes, not for debate or heated criticism. Please bring this up in meta if you have questions about this decision. – Todd A. Jacobs Jan 14 at 18:09
  • 1
    My apologies for my participation on that. – David Espina 2 days ago
-2

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

  • It is an interview question. They don't have a right answer by definition. – Bart van Ingen Schenau Jan 13 at 8:16
  • Neither is Scrum. – Venture2099 Jan 14 at 11:55

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.