3 ms·

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 th

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)
    - vannevar 4y ago
      I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban. But I'm confused by this statement: >planning is just complete BS To me, planning is where design meets reality. Planning involves several activities, but probably the most important is prioritization. I'm curious why you think that prioritization happens more frequently in kanban, where the convention is to simply take the next task off the stack. Are you saying that every time someone takes a task off the kanban backlog, they independently re-prioritize the entire stack? Or do you have regular re-prioritization sessions with the team? If it's the former, that seems like a lot of overhead and opportunity for conflict and misunderstanding. If it's the latter, how is that really different from regular sprint planning? Because surely, as part of the prioritization, you would also consider things like estimation of difficulty and risk.
- twic 4y ago
  > By keeping the backlog prioritized at all times You can't really do this without having some idea of how long each item in the backlog will take. If feature A is twice as valuable is feature B, should A or B come first in the backlog? Depends if A takes the same time as B, or four times as long. (ignoring various other considerations about how you prioritise, and just focusing on delivering value here) This is why rough estimation is part of the planning process in XP. The developers estimate stories so that the product owner can prioritise them. The estimates don't need to be precise, just roughly right relative to each other, to act as a denominator. Since the developers are only pulling from the top of the backlog, the product owner doesn't need to prioritize the whole thing, just enough to keep the team busy. That means the developers only need to estimate stories which the product owner is considering for prioritization. You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. But that would involve everyone interrupting everyone else quite often. So typically, you get together once a week and do this until you have enough stories to keep the developers busy until the next get-together. You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity.
  - seadan83 4y ago
    Sure you can keep your backlog prioritized at all times. Prioritization can be net benefit, or can be net ROI, the choice is yours! If you find out that item A will take half the time, perhaps that will boost its ROI and change its position in the queue. If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. Nothing in this way of defining priority is really any different between scrum & kanban. Perhaps the only key difference is when work is allocated to be done, scrum often focuses on 'how long will it take' to avoid "assigning too much to one sprint". Hence, a low ROI item could certainly be fit into a sprint simply because of time constraints, even though it might be really low on the overall ROI list (thus a priority inversion where the wrong thing is worked on simply because it fits an arbitrary time period). > You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. If you have your backlog prioritized (or at least deep enough you can pull work for a while), then doing this continously is cake. The developer pulls from the top of the backlog. When a new task or a story is introduced, it is stack ranked. When and how often you introduce new stories in kanban is really up to you. So it need not be a constantly disruptive process. Typically new stories are looked at on a daily basis, which allows for a lot of responsiveness. At the same time, if knowledge changes about a story, it's priority rank is changed right then. It does not take very long to do stack ranking. > You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity. Tl;dr, velocity makes some interesting assumptions and uses bad math Velocity does not take into account error bars. This is bad math! Each story has an error bar of give or take 30% (assuming it is well estimated with Fibonnacci). EG: An '8' could be a 6.5, or could be a 10.5. Yet, somehow by adding up the expected size of stories together the overall accuracy increases.. This is an oddity and bad math. Velocity should always be reported with a plus or minus, yet, it doesn't.. Somehow all of math behind propogation of error is assumed to cancel out. Beyond bad math, velocity only says how well you did last sprint, and "past performance does not guarantee future results." In short, velocity assumes that people can estimate. The only tasks that will have reliable estimates are ones that are very similar to something you have already done many times (eg: how long would it take you to brush your teeth with this new electric toothbrush? You know how long it takes to brush teeth with a convention toothbrush, so your estimate would be pretty good). But let's say, how long will it take you to learn Electromagnetism? Cool, you just learned that, how long will it take you to learn Calculus III? If you've taken Calc I and II, you would perhaps have something of an idea, but you're still to be really way off on estimating that.
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.

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)
  - vannevar 4y ago
    I answered your general point in a separate reply, since others brought up the idea of continuously planning and retrospecting in kanban. But I'm confused by this statement: >planning is just complete BS To me, planning is where design meets reality. Planning involves several activities, but probably the most important is prioritization. I'm curious why you think that prioritization happens more frequently in kanban, where the convention is to simply take the next task off the stack. Are you saying that every time someone takes a task off the kanban backlog, they independently re-prioritize the entire stack? Or do you have regular re-prioritization sessions with the team? If it's the former, that seems like a lot of overhead and opportunity for conflict and misunderstanding. If it's the latter, how is that really different from regular sprint planning? Because surely, as part of the prioritization, you would also consider things like estimation of difficulty and risk.
twic 4y ago
> By keeping the backlog prioritized at all times You can't really do this without having some idea of how long each item in the backlog will take. If feature A is twice as valuable is feature B, should A or B come first in the backlog? Depends if A takes the same time as B, or four times as long. (ignoring various other considerations about how you prioritise, and just focusing on delivering value here) This is why rough estimation is part of the planning process in XP. The developers estimate stories so that the product owner can prioritise them. The estimates don't need to be precise, just roughly right relative to each other, to act as a denominator. Since the developers are only pulling from the top of the backlog, the product owner doesn't need to prioritize the whole thing, just enough to keep the team busy. That means the developers only need to estimate stories which the product owner is considering for prioritization. You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. But that would involve everyone interrupting everyone else quite often. So typically, you get together once a week and do this until you have enough stories to keep the developers busy until the next get-together. You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity.
- seadan83 4y ago
  Sure you can keep your backlog prioritized at all times. Prioritization can be net benefit, or can be net ROI, the choice is yours! If you find out that item A will take half the time, perhaps that will boost its ROI and change its position in the queue. If you instead want your prioritization to be strictly based on expected return, then it does not matter how long it takes. Nothing in this way of defining priority is really any different between scrum & kanban. Perhaps the only key difference is when work is allocated to be done, scrum often focuses on 'how long will it take' to avoid "assigning too much to one sprint". Hence, a low ROI item could certainly be fit into a sprint simply because of time constraints, even though it might be really low on the overall ROI list (thus a priority inversion where the wrong thing is worked on simply because it fits an arbitrary time period). > You could try to do this continuously - a developer needs a story to work on, so they ask the product owner, who picks a few candidates, then asks the team for an estimate on them, then selects one to be next. If you have your backlog prioritized (or at least deep enough you can pull work for a while), then doing this continously is cake. The developer pulls from the top of the backlog. When a new task or a story is introduced, it is stack ranked. When and how often you introduce new stories in kanban is really up to you. So it need not be a constantly disruptive process. Typically new stories are looked at on a daily basis, which allows for a lot of responsiveness. At the same time, if knowledge changes about a story, it's priority rank is changed right then. It does not take very long to do stack ranking. > You can tell, roughly, if you have enough stories for a week by counting how many size units of stories the developers get through in the previous week - that is, your velocity. Tl;dr, velocity makes some interesting assumptions and uses bad math Velocity does not take into account error bars. This is bad math! Each story has an error bar of give or take 30% (assuming it is well estimated with Fibonnacci). EG: An '8' could be a 6.5, or could be a 10.5. Yet, somehow by adding up the expected size of stories together the overall accuracy increases.. This is an oddity and bad math. Velocity should always be reported with a plus or minus, yet, it doesn't.. Somehow all of math behind propogation of error is assumed to cancel out. Beyond bad math, velocity only says how well you did last sprint, and "past performance does not guarantee future results." In short, velocity assumes that people can estimate. The only tasks that will have reliable estimates are ones that are very similar to something you have already done many times (eg: how long would it take you to brush your teeth with this new electric toothbrush? You know how long it takes to brush teeth with a convention toothbrush, so your estimate would be pretty good). But let's say, how long will it take you to learn Electromagnetism? Cool, you just learned that, how long will it take you to learn Calculus III? If you've taken Calc I and II, you would perhaps have something of an idea, but you're still to be really way off on estimating that.

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.