5 ms·

Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning. If you're using sprin

Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning. If you're using sprints and not kanban, the "cycle time" is fixed, and only the amount varies (approximated inexactly by story points). This statement FTA is completely antithetical to agile development: "A manager who wishes to make their team’s cycle times more uniform can try matching the rate at which tasks enter the system to the rate at which they leave." On an agile team, "the manager" doesn't moderate the work rate; rather, the team measures their own work rate (approximately) via velocity and manages themselves accordingly.

hbarka 4y ago
Isn’t kanban a tool within sprints?
- vannevar 4y ago
  Kanban is an alternative to sprints, for contexts in which the team is persistent across projects and it makes sense to let them manage their work apart from the projects that they contribute to---e.g., an ops team that supports the organization via a help desk and ticketing system. You could certainly think of the sprint board as a kanban board with a finite lifespan, but I don't think there's any benefit to doing so.
  - seadan83 4y ago
    There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog. Rather than predicting what you will get done (and invariably failing to predict well, or using developers own predictions as their accountability and a way to pressure overtime), perhaps just see what you get done instead. Then instead of planning, actual work could get done. Anyone needing estimates can look back historically and compute number of tasks getting done and extrapolate against the backlog. By keeping the backlog prioritized at all times, and pulling from the backlog instead of a 'sprint backlog' - it avoids priority inversions. Planning what will be your highest priority, that possibly changes mid-sprint, is a priority inversion. Kanban works well in all situations where sprints work well. Instead of trying to predict in a planning, you just do the work instead. Any predictions are still the same based on looking at historical data and comparing to the backlog, just less waste involved and less subterfuge to try and get developers to work overtime (I'm not aware of any sprint planning that really takes into account error bars, so the prediction/planning is BS & management planning porn, nothing more)
    - vannevar 4y ago
      >There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog. The purpose of sprints is not to divide up the work---this is a common misunderstanding. The purpose of the sprint is to set incremental goals based on incremental learning. 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. Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure, since there is no opportunity to reflect on the larger picture: the team is too busy focusing on the assembly line and not paying attention to the product. And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong. As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
      - seadan83 4y ago
        That incremental goal is not mutually exclusive to kanban. The difference is whether you are stating at the beginning what goal you will hit, vs just working towards that goal. It's the same thing, one creates pressure to hit inaccurate estimates, the other just marches towards the goal. > Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure Why is that? Scrum has the same backlog. > since there is no opportunity to reflect on the larger picture Why is this the case? Kanban often says that you talk about retrospective items any time they come up. You then even can re-prioritize such items right when needed, meaning you solve todays problem today, not tomorrow. Retrospectives in scrum can often come too late (and personally I've never really seen them work well, too little, too late, and often compete against 'business' priorities that always win out). > And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong. Kanban is less susceptible to priority inversion. You keep the highest priority at top, it is evaluated more often, and you pull from the top. Why does this mean that months can go by? Why is that any more the case than say scrum where you are encouraged to fix priority for weeks at a time? > As I said, there are appropriate times to do kanban, but the situation you describe is not one of them. I think the burden of proof is on you to state places where scrum uniquely bests kanban. The statement that kanban is best for places where ad-hoc work comes in constantly is a case where scrum spectacularly fails. For regular project work, kanban can be a great fit (I'd say universally better than scrum, since planning is just complete BS. Kanban is often little more than scrum without the planning sessions and with far more frequent prioritization, and you get to keep all of the same retrospective & estimation tools)
  - AdieuToLogic 4y ago
    Kanban is an alternative to sprints, ... Agreed. ... for contexts in which the team is persistent across projects and it makes sense to let them manage their work apart from the projects that they contribute Here I disagree only in applicability. Kanban can be successfully used in a single development project if the team maintains prioritized tasks based on risk and/or dependencies. To wit, a development team with sufficient maturity can identify and plan their work, address same in the requisite order, and have confidence that the probability of success will increase as each task is completed.
    - vannevar 4y ago
      Prioritization is an output, not an input, of the scrum process. That's the whole point, to engage the user early and often so that information about the desired functionality can be derived from experience and not just speculation, and then fed quickly back to the team for iteration. So sure, if you: - release usable software - collect feedback from stakeholders based on the release, and - re-design and re-prioritize the perceived work remaining on a regular basis as a team, then you can use Kanban for a single project. But it will look an awful lot like sprints, because it's hard to do all that on a continuous basis, it would be a lot of overhead and context-switching to do it daily. On a project of any size, you'd have to do it all periodically. Say, every couple of weeks.
- spaetzleesser 4y ago
  Kam is basically a big to do list (aka backlog) and you just work through it. I find it way easier to manage than scrum with sprints and sprint planning.
  - vannevar 4y ago
    It's much easier to simply hit the accelerator and drive straight ahead, too, but you wouldn't win many F1 races that way. And most software projects are a lot more complex than an F1 track. Sometimes the easiest thing to do is not the best thing to do.
    - spaetzleesser 4y ago
      I don't think F1 is a good analogy. In any case, I prefer to deal with complexity directly and not add more complexity in the form of sprint planning, velocity and other stuff. Maybe some people run scrum well but I have yet to see that.
doktorhladnjak 4y ago
> Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning It's nice in theory. Usually once these metrics exist, PMs and other managers get a hold of them, and they always seem to turn into hard deadlines or interpreted as predictions with high certainty.

hbarka 4y ago

Isn’t kanban a tool within sprints?

vannevar 4y ago
Kanban is an alternative to sprints, for contexts in which the team is persistent across projects and it makes sense to let them manage their work apart from the projects that they contribute to---e.g., an ops team that supports the organization via a help desk and ticketing system. You could certainly think of the sprint board as a kanban board with a finite lifespan, but I don't think there's any benefit to doing so.
- seadan83 4y ago
  There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog. Rather than predicting what you will get done (and invariably failing to predict well, or using developers own predictions as their accountability and a way to pressure overtime), perhaps just see what you get done instead. Then instead of planning, actual work could get done. Anyone needing estimates can look back historically and compute number of tasks getting done and extrapolate against the backlog. By keeping the backlog prioritized at all times, and pulling from the backlog instead of a 'sprint backlog' - it avoids priority inversions. Planning what will be your highest priority, that possibly changes mid-sprint, is a priority inversion. Kanban works well in all situations where sprints work well. Instead of trying to predict in a planning, you just do the work instead. Any predictions are still the same based on looking at historical data and comparing to the backlog, just less waste involved and less subterfuge to try and get developers to work overtime (I'm not aware of any sprint planning that really takes into account error bars, so the prediction/planning is BS & management planning porn, nothing more)
  - vannevar 4y ago
    >There would be a benefit to thinking that way. Instead of doing a ridiculous sprint planning, instead just keep pulling from the backlog. The purpose of sprints is not to divide up the work---this is a common misunderstanding. The purpose of the sprint is to set incremental goals based on incremental learning. 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. Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure, since there is no opportunity to reflect on the larger picture: the team is too busy focusing on the assembly line and not paying attention to the product. And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong. As I said, there are appropriate times to do kanban, but the situation you describe is not one of them.
    - seadan83 4y ago
      That incremental goal is not mutually exclusive to kanban. The difference is whether you are stating at the beginning what goal you will hit, vs just working towards that goal. It's the same thing, one creates pressure to hit inaccurate estimates, the other just marches towards the goal. > Simply throwing everything into a massive backlog and grinding through it indefinitely is a recipe for failure Why is that? Scrum has the same backlog. > since there is no opportunity to reflect on the larger picture Why is this the case? Kanban often says that you talk about retrospective items any time they come up. You then even can re-prioritize such items right when needed, meaning you solve todays problem today, not tomorrow. Retrospectives in scrum can often come too late (and personally I've never really seen them work well, too little, too late, and often compete against 'business' priorities that always win out). > And of course you can still have "priority inversions" in kanban, but unlike the finite sprint, you may go months before you realize what you've done wrong. Kanban is less susceptible to priority inversion. You keep the highest priority at top, it is evaluated more often, and you pull from the top. Why does this mean that months can go by? Why is that any more the case than say scrum where you are encouraged to fix priority for weeks at a time? > As I said, there are appropriate times to do kanban, but the situation you describe is not one of them. I think the burden of proof is on you to state places where scrum uniquely bests kanban. The statement that kanban is best for places where ad-hoc work comes in constantly is a case where scrum spectacularly fails. For regular project work, kanban can be a great fit (I'd say universally better than scrum, since planning is just complete BS. Kanban is often little more than scrum without the planning sessions and with far more frequent prioritization, and you get to keep all of the same retrospective & estimation tools)
- AdieuToLogic 4y ago
  Kanban is an alternative to sprints, ... Agreed. ... for contexts in which the team is persistent across projects and it makes sense to let them manage their work apart from the projects that they contribute Here I disagree only in applicability. Kanban can be successfully used in a single development project if the team maintains prioritized tasks based on risk and/or dependencies. To wit, a development team with sufficient maturity can identify and plan their work, address same in the requisite order, and have confidence that the probability of success will increase as each task is completed.
  - vannevar 4y ago
    Prioritization is an output, not an input, of the scrum process. That's the whole point, to engage the user early and often so that information about the desired functionality can be derived from experience and not just speculation, and then fed quickly back to the team for iteration. So sure, if you: - release usable software - collect feedback from stakeholders based on the release, and - re-design and re-prioritize the perceived work remaining on a regular basis as a team, then you can use Kanban for a single project. But it will look an awful lot like sprints, because it's hard to do all that on a continuous basis, it would be a lot of overhead and context-switching to do it daily. On a project of any size, you'd have to do it all periodically. Say, every couple of weeks.
spaetzleesser 4y ago
Kam is basically a big to do list (aka backlog) and you just work through it. I find it way easier to manage than scrum with sprints and sprint planning.
- vannevar 4y ago
  It's much easier to simply hit the accelerator and drive straight ahead, too, but you wouldn't win many F1 races that way. And most software projects are a lot more complex than an F1 track. Sometimes the easiest thing to do is not the best thing to do.
  - spaetzleesser 4y ago
    I don't think F1 is a good analogy. In any case, I prefer to deal with complexity directly and not add more complexity in the form of sprint planning, velocity and other stuff. Maybe some people run scrum well but I have yet to see that.

doktorhladnjak 4y ago

> Velocity is not intended as an engineering management metric, it's intended for use internally by the team as a guide for sprint planning It's nice in theory. Usually once these metrics exist, PMs and other managers get a hold of them, and they always seem to turn into hard deadlines or interpreted as predictions with high certainty.