4 ms·

I've used both Scrum and Kanban. Kanban, for me, is by far the superior method. There are no artificial sprint deadlines, no ticket sizing, far fewer ceremonies

by Osiris 6y ago

I've used both Scrum and Kanban. Kanban, for me, is by far the superior method. There are no artificial sprint deadlines, no ticket sizing, far fewer ceremonies, gives a lot of flexibility, but still provides enough structure to place emphasis on tracking and completing work. If you've never worked in a Kanban environment, I highly suggest you research it and encourage your employer to experiment with it.

perlgeek 6y ago
Note that Kanban requires a certain maturity and self-discipline from the development team and the stakeholders. If that's a given, Kanban can work very well. Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet". In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever. If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.
- pracer 6y ago
  > the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time". I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
  - perlgeek 6y ago
    > I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny. I develop internal tooling for a b2b company, and we ship features multiple times a week. Much of that is backend. Often not huge features, but still features that make life easier for colleagues.
tarcon 6y ago
A team commitment based on the learning from the last sprints to scope the next one, so that you can predict the delivery scope, is an artificial deadline?
- Too 6y ago
  Yes. Either "commitments" are ignored and tickets casually spill over into next sprint, or they are enforced leading to inflated estimates by the team so you dont have to work overtime the next sprints. See also the commitments-vs-forecast discussion further above. Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.

by Osiris 6y ago

perlgeek 6y ago

Note that Kanban requires a certain maturity and self-discipline from the development team and the stakeholders. If that's a given, Kanban can work very well. Scrum was really invented for situations where management is constantly asking "when do we get X?" and the development always says "we aren't done yet". In this scenario, the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time, and forces the development team to put something out in a given time frame even if not yet perfect / finished / whatever. If that's not a problem, Kanban can be indeed be a much better fit, and come with far less overhead.

pracer 6y ago
> the sprint is meant to reassure management that they'll get at least *something (even if not a full X) in a predictable time I would rephrase it as "sprint is meant to make management to believe that they'll get at least something in a predictable time". I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny.
- perlgeek 6y ago
  > I also notice that lots of comments seem to be coming from front-end or customer-based companies. For backend and b2b, 2 weeks sprint for some new functionality is funny. I develop internal tooling for a b2b company, and we ship features multiple times a week. Much of that is backend. Often not huge features, but still features that make life easier for colleagues.

tarcon 6y ago

A team commitment based on the learning from the last sprints to scope the next one, so that you can predict the delivery scope, is an artificial deadline?

Too 6y ago
Yes. Either "commitments" are ignored and tickets casually spill over into next sprint, or they are enforced leading to inflated estimates by the team so you dont have to work overtime the next sprints. See also the commitments-vs-forecast discussion further above. Kanban still has estimates and you can still do bi-weekly demos of whatever has been done since last demo. Management can still get a sense of when they will get stories by judging how far down the backlog they are. Team is still protected from interruptions by their WIP-limit but PO can still swap out highest prio item not currently in progress, win-win.