3 ms·

> Kanban is essentially abolishing of any forecasting This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combine

> Kanban is essentially abolishing of any forecasting This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. Do you really think the car industry, where Kanban originates, doesn't care how many cars they're going to produce in a quarter, or whether they're ahead, behind, or on track on hitting their targets? Come on. The idea that "forecasting" and "agile" are somehow at odds with one another is a gross misunderstanding of both. Edit: As an aside, that article's use of Google as somehow the paragon of software development superiority really dates it. Google is notorious, at this point, for being an unreliable software development organization. They fail to listen to their users by building features people don't want, canceling projects that vocal users do want, and shipping incredibly buggy products (Android 12, anyone?) All of this is, at least in part, caused by many of the problems the blog post highlights but claims have been resolved, including a lack of strategic cohesiveness and issues with building and maintaining staffing for projects that are no longer sexy.

stephendause 5y ago
> This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. That's interesting to me as I hadn't heard that about Kanban before. Do you have a particular reference in mind that you think describes this well?
- BaseballPhysics 5y ago
  First off, it's important to understand that Kanban relies on a backlog built of stories that are all of similar size and complexity. Yes, that means you need to estimate. But those estimates come in the form of "is this roughly as complex as other work the team has done?" So it's a lot less onerous to assess. Then you can measure throughput (number of stories per unit of time) and cycle time (amount of time a story takes from start to finish). Using those measures you can forecast, with monte carlo simulation as a common method. Here's a book on the topic: https://www.amazon.ca/Forecasting-Simulating-Software-Development-Projects/dp/1466454830 https://www.amazon.ca/Forecasting-Simulating-Software-Develo... There's plenty of other resources about this if you bust out your google-fu.

stephendause 5y ago

> This isn't even remotely true. Kanban establishes specific measures, including throughput, that, combined with statistical modeling, specifically allow for forecasting to be done. That's interesting to me as I hadn't heard that about Kanban before. Do you have a particular reference in mind that you think describes this well?

BaseballPhysics 5y ago
First off, it's important to understand that Kanban relies on a backlog built of stories that are all of similar size and complexity. Yes, that means you need to estimate. But those estimates come in the form of "is this roughly as complex as other work the team has done?" So it's a lot less onerous to assess. Then you can measure throughput (number of stories per unit of time) and cycle time (amount of time a story takes from start to finish). Using those measures you can forecast, with monte carlo simulation as a common method. Here's a book on the topic: https://www.amazon.ca/Forecasting-Simulating-Software-Development-Projects/dp/1466454830 https://www.amazon.ca/Forecasting-Simulating-Software-Develo... There's plenty of other resources about this if you bust out your google-fu.