Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Piling on:

> So instead of setting a goal to create the complete software system from the beginning, you set a goal that can be accomplished within a fixed timeframe that people can make reasonable estimations in and that will test some of your key assumptions about the software.

In Kanban you can do all of that, except faster. Instead of waiting for the arbitrary sprint boundary, you can immediately evaluate an item that has landed in production and immediately re-prioritize the backlog based on any learnings. That would be compared to: we will deploy this in sprint A, then in B we will see the results, and then in sprint C we will work on our updated items. The latter is a many week delay compared to assigning tasks in strict sequence of "ship/measure/adjust".

In the worst case, you ship at the beginning of a sprint and then instead of working on the next priority thing (that you learn from having shipped), you instead keep working on the other sprint items. At that point, it could be waterfall, working on items that you now know are pointless, but you still have to anyway because it was planned some time prior to do so.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: