Hacker News Reader

Comment by daigoba66 | Hacker News Reader

> Perhaps Kanban is better suited towards long-lived product development than Scrum.

This is the key take-away. And in my experience this is absolutely true.

On the other hand, working now as a consultant where I am frequently on shorter-term projects with a definitive "end" for the engagement, the time-boxed sprint approach (or "Scrum") actually seems to work well.

Scrum might work for individual "projects". It does not scale or coalesce well with long-term development and maintenance.

> Perhaps there is indeed a natural progression of engineering teams adopting Scrum, then moving to Kanban.

This also mirrors my experience.

View on HN

I completely agree with this.

In shorthand, having been Product Manager for a number of teams at a variety of companies in several industries, I've found that Scrum is better for teams developing mostly new features, with relatively little maintenance; and Kanban better for teams focused primarily on maintenance, with fewer large features.

The rationale is really simple: for new feature launches, reporting and tracking vs. schedule is key; for maintenance, throughout is key.

That said, regularly missing predicted story points by more than about 10% is not the sign of a healthy team. Being bedeviled by routine bug fixes is not the sign of effective management. Both are routine issues that most highly-effective teams, whether Scurm or Kanban, deal with well.

Kanban was invented at Toyota in the '40s and '50s: https://en.wikipedia.org/wiki/Kanban

Depending on the scale you're operating at, it's easy to see this as a waterfall methodology. There are lots of different words to describe organizing work, but what's important is that the methodology remains consistent enough that the team understands it.

I think of time-boxed sprints as great for training. Humans aren't going to get better at estimating how long it takes to complete complex engineering tasks. But teams that work together over a long enough period of time can plan ahead better. (For example, time-boxed sprints would suggest that everyone has to take vacations at the same time for Scrum to be effective.) There are plenty of ways to deal with the fact that humans are asynchronous. I particularly liked this author's focus on team morale as a major factor.

My experience too. A short deadline (few months to a year) and a green new codebase is a good place for scrum.

A medium/large project (200 man years in the code over 10 years say), then it's a lot harder. A required refactoring in the codebase that would take 200h is a common discovery in issues estimated at a few h.

Reply on news.ycombinator.com