Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…
Yes but raw velocity is not the only thing that matters. For some projects it is, but for many the accountability of Scrum + the grouping helps with dependency management across an organization.
You don't need Scrum, you just need to do Kanban right (2022)
61–70 of 341 posts
Re: You don't need Scrum, you just need to do Kanban right (2022)
#62Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.
Someone is either working on a task, or idle. A task is either being worked on (making progress), or it's not being worked on. -- A task will get completed quicker if you can minimize the amount of time it's "in progress" but not being worked on.
If you have 5 workers and 15 tasks in progress, 10 of those tasks won't be making progress.
Often, a task may be blocked by requiring some action from someone else. (e.g. PR review, or more resources, or blocked on some other task).
The 'kanban board' is about visualizing work in progress. -- By visualising the work in progress, it's easier to identify bottlenecks & inefficiencies.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#63> This demand for estimations leads to unproductive and unnecessary estimation meetings. These meetings are unproductive because they cause developers to spend time debating whether something is worth two or three story points instead of actually writing code. They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter. Only if all tasks are of equal…
> They’re also unnecessary because if you feed the system with more work as soon as software comes out, estimations don’t matter.
The question is: estimations don't matter to who? As much as I'd like a constant stream of quality features to be good enough, in reality senior managers and clients want to know what they're getting for their money, and when they'll get it (at least roughly). If your software is doing something important, it's likely that people will be depending on it and when a new feature ships can have a significant impact on how they work, and in turn, what they can deliver.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#64Earlier quoted context omitted.
To be honest I have never seen this materialize. Usually you get some input from product management, the devs estimate it and then do it. I have never seen feedback from estimation to requirements.
Isn't that because the product manager is gathering requirements from other orgs/users? > I have never seen feedback from estimation to requirements. Perhaps you work with perfect pms! jokes aside, usually all it takes is an estimation of 8 or 13 and something changes real fast.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#65Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…
I can actually see predictability improving, but mostly because we will ship whatever at the end of the sprint and let any issues come back as bugs later. We always ship on time at one Scrum job, but the quality is very low.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#66Scrum is for less predictable work, where many/most of the requirements and/or challenges are not well known or defined yet, or are likely to change as new information becomes available. For this kind of work, you need a constant feedback mechanism so that the captain can adjust course as needed while traversing uncharted waters.
I currently work in a team that builds code that accesses poorly or completely undocumented systems, and is seeking a market fit for new products. In both of these cases, agility is far more important than velocity, so scrum is the right approach. In previous places, the work my team did was very predictable, so kanban was the right approach.
Note: There's nothing wrong with having both in the same company. Team has predictable work? Kanban. Else scrum.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#67I’m not a huge scrum defender - I’ve seen it done right and wrong. Same with Kanban. The only real problems I have with Kanban is that without those annoying team planning/documentation meetings, work will get duplicated, done hastily, done with no discussion or thought toward testing, architecture, maintainability. And that’s not exclusively true of Kanban. But I feel like the lack of organization can turn it from l…
Those same problems still happen in Scrum and it's very hard to get out of duplication hell once the backlog gets sufficiently large. I personally think Scrum is theoretically great if done right and with smart people, but that is rarely the case.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#68I am probably missing something but is kanban even the correct metaphor for creative work(like software development). Kanban is a back pressure mechanism that can get your factory logistics system running smoothly. However the logistics of creative work is very different than the logistics of assembly work. There are almost no parts needed, why is a backpressure system for part delivery even useful?
See also "lean manufacturing/software development" and obviously "software engineering".
Re: You don't need Scrum, you just need to do Kanban right (2022)
#69Earlier quoted context omitted.
I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.
Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.
Re: You don't need Scrum, you just need to do Kanban right (2022)
#70Kanban is great for systems with predictable output. If the work units remain mostly the same, you can greatly increase flow efficiency and velocity using kanban. It's basically waterfall meets JIT delivery (which is why it worked so well for Toyota). Scrum is for less predictable work, where many/most of the requirements and/or challenges are not well known or defined yet, or are likely to change as new information…
From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.