Why I Prefer Kanban Over Scrum

[Disclaimer: This does not reflect an Agile 2 viewpoint - rather, it is my personal viewpoint.]

Some Agile coaches choose a tribe: Scrum or Kanban are the main tribes. Others are not tribal: they look at each situation and consider which workflow process would work best, and then - if they are good at their job - they ask the team and discuss it.

I personally think the workflow is not one of the most important issues: I feel that issues such as user involvement, product design, testing strategy, and investing enough in automation are far more important; but workflow is important, even if I don’t put it at the top.

Scrum is very problematic to me. I have seen lots of debates in LinkedIn over the years about issues that a sprint creates. Some of these are,

• What should really happen at the Sprint Review.
• When should users get to see new features?
• Is the sprint commitment really a commitment, or a best effort guess?
• Should there be hardening sprints?
• Should there be refactoring sprints?
• Should there be low pressure R&D sprints?
• If a story ends up being harder than thought, should its actual difficulty be used when computing sprint velocity, or should the original estimate be used?

I don’t want to get into the validity of these questions, or what the correct answer is. My point is that these are questions that often arise and spur debate and often confusion.

Yet all of these questions arise as a result of having a sprint in the first place.

If one did away with sprints, other questions would arise, such as when should new features be shown to a business stakeholders and accepted? Well, to me, that is an easy one: as soon as it is done.

But the real reason I don’t like the Scrum process is this start-stop workflow. It seems unnatural to me. I look at organizations like SpaceX, and they don’t do that. They have continuous flow.

There is a practice that is extremely important for successful Agile and DevOps, known as Behavior-Driven Development (BDD), and it turns out that, based on my experience, BDD does not mate well with the Scrum start-stop workflow. Really, I should call the Scrum workflow a work-jigger, since it does not actually flow.

Here’s why BDD and Scrum don’t mix well:

Consider that it is the start of a sprint. There is a sprint planning session, during which the stories for the sprint are chosen and estimated. The team (why is it always one team? - that’s another thing I don’t like) then starts working on the sprint backlog. But wait: in the BDD process, each story’s acceptance criteria need to be written as “executable tests” - in other words, Cucumber feature files.

I often hear that a Scrum Product Owner (PO) should write the feature files. Are you kidding me? If they do, they are not a real PO. A real PO - especially when there are many teams - is a very busy person. They usually have operational responsibility - that’s why they were able to create the product vision - and the time they spend with the team(s) is precious, so why have them sacrifice time they could be spending with a team, just so they can code test specs in Gherkin? That’s nitty gritty work that is best done by a business analyst.

Plus, in my experience, each story acceptance criteria usually translates into five or more test scenarios - it is not one-to-one - not if you want a high coverage test suite.

So now the sprint has started, and we need these feature files. How long does it take to create them? Programmers need feature level BDD tests to run, but no one can start on those tests until there are some feature files; so we have a bottleneck right off the bat.

Let’s move toward the end of the sprint. At this point we have feature files, and we have automated tests, and programmers are running those tests in a red-green cycle, and all is great. But remember those people who wrote the feature files? What are they doing? They don’t know which stories will be chosen for the next sprint, so they can’t start on those. If they are analysts, they are sitting on their hands.

Sometimes I hear, “The developers - that is, the team members (as if they are all the same) should write the test specs”. Really? Have you seen test specs that developers write?

I can say unequivocally from experience that developers write terrible feature level test specs. To write good test specs, you have to have a test mindset: you have to be in the mindset of trying to make the code fail. Developers have the opposite mindset: they don’t want their code to fail, because if it does, they have more work to do.

It is important to understand that BDD is not Test-Driven Development (TDD). TDD is a test-first process at the unit test level. In the TDD process, developers write method-level tests (very, very granular, on the internal methods of their code), and they get their code to pass the tests. That is not BDD, which is about external behavior tests - BDD tests are at the acceptance test level.

Also, one should never have a developer write test specs for the same feature that they will develop: if one does that, and if the developer misunderstands the feature, their misunderstanding will be replicated in both the test spec and the application code: all tests will pass, but it will be wrong!

So in a BDD process, one really does need business analysts and test experts - those are the people who write high quality test specs, which can then be implemented as automated tests. But we then have a workflow problem, because there is an inherent handoff from story acceptance criteria to test spec to programmer, which means that some people will be idle at the start of a sprint, and others will be idle at the end. I don’t like idle: it is a Lean waste.

Scrum fans will say, “We can fix that! Just have some people start on the next sprint’s test specs”. But then we have to decide which stories those will be for; and then that is not Scrum anymore.

And so what? Is it bad that it is not Scrum? No!

What we need to make BDD work well is a workflow that has these handoffs, but that also allows for iteration, so the handoffs are not strict handoffs: they can have feedback. Thus, it is not a pure Kanban process either, although Kanban is a much better fit.

What is needed is a Kanban-like flow, but where work items are allowed to flow back upstream when they need to. It needs to be collaborative. Suppose a developer realizes that a test program is wrong. Do they fix it? They might, or they might talk to the team member who wrote the test and say, “This is wrong, but it is a big change, can you do it?” and the programmer who wrote the test might say, “Sure”, or they might say, “I am snowed under by these other tests that Susan will need, so I don’t really have time”, and the programmer who found the problem will say, “Okay, just checking, I’ll fix it”.

So it is a Kanban-like flow, but not entirely.

Update: David Anderson has clarified: “Kanban Method is agnostic on the issue [of whether tasks can flow backwards], all that Kanban requires is that your policy on it is explicit. Kanban may highlight the pros and cons of different policy choices but it does not prescribe or prefer one over the other. The key is to realize that Kanban isn’t a process at all, Kanban is something you do to your existing process.”

Also, you can’t manage BDD entirely by tracking WIP. It is important to make sure that developers have tests to run, and that test programmers (who might be any programmer) have test specs to code to. In other words, there is lead time, and so someone needs to be looking ahead. Instead of worrying only about what people did yesterday and will be working on today and whether they have blockers, one needs to be looking three days out, to predict if someone will need tests to run, or test specs to code to. One needs a three-day forward view.

So this is not Scrum. It is not true Kanban, but Kanban is a much better fit. What tends to work well is Kanban with some adjustments that allow for backflow, emphasizes collaboration between the steps, and has less focus on WIP and more on looking ahead (WIP is still important).

Scrum is just an obstacle for all this. Plus Scrum treats the Product Owner as a user proxy, which is a whole other topic in its own right.

That’s why I prefer Kanban over Scrum. What are your thoughts?