Live data from Hacker News

You don't need Scrum, you just need to do Kanban right (2022)

lucasfcosta.com

111–120 of 341 posts

Re: You don't need Scrum, you just need to do Kanban right (2022)

#111

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…

I think one key issue here is that Scrum without Extreme Programming and rigorous iteration can become a shallow process. Often, products that don't undergo much iteration are broken into arbitrary two-week windows under the guise of iteration.

However, Scrum doesn't make much sense if you don't continuously iterate. Another symptom of this is people measuring velocity instead of value created. To properly implement Scrum, you actually need to measure the impact of the work completed in the past two weeks. Unfortunately, most teams don't do this, instead they focus on measuring velocity since it's easier and within their control. It's worth noting that it's completely fine for teams not to constantly iterate and change direction (including high-performing teams), and in those cases, Scrum simply isn't the best tool for the job imo.

I must admit that I personally prefer Kanban for almost all workloads.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#112
You don't need Kanban, you just need to do Scrum right.

It seems most people who are complaining about Scrum, are really complaining about the lousy implementation of it in their company. Which tends to be the result of lousy management. With lousy management, any process will be a pain. Doing Kanban with a manager behind your desk asking why your feature is not ready yet isn't a pleasure either.

There also seems to be some misunderstanding about speed of development and Scrum; some posters are complaining that Scrum slows them down. Yes it does! And this is on purpose. Scrum focusses on delivering business value, not on delivering lines of code that possibly nobody needs. So there are moments in the development process when feedback is gathered from stake holders. This is important, because it gives them an opportunity to adjust what's being built, or even switch to a more important feature altogether. The downside is that this takes time. But the upside is that you will have far greater chance of delivering something that is actually needed.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#113
post #59
post #54

Earlier 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.

What's the difference with prioritizing tickets in a Kanban queue?

In the end it's the work of the PM in both cases.

People with enough power in the org will insert their ticket in your precious sprint anyway.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#114

The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…

This is a good explanation about differences between the three

...for anyone who already knows that waterfall isn't iterative

Re: You don't need Scrum, you just need to do Kanban right (2022)

#115
post #76
post #53

Earlier quoted context omitted.

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their e…

I agree. In my experience that outside visibility is mostly a mirage. Velocity metrics, burndown charts, point estimations, and all of that have been at best aspirational white lies and at worst outright falsehoods on almost every scrum/agile team I've ever worked on in the past fifteen years. In actuality many scrum teams are doing something closer to kanban day-to-day under the fake veneer of scrum/agile sprints on…

Totally with you. But since I'm currently preparing to get certified for Scrum, I'd like to point out that all those things you mentioned above aren't really part of Scrum at all...

Re: You don't need Scrum, you just need to do Kanban right (2022)

#116
post #104

Earlier quoted context omitted.

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.

I'm almost afraid to ask but what unit of time does that "8 or 13" correspond to?

nah it's all good. it's just the "estimation value" which is technically arbitrary, but a common practice is in a 2-week sprint, 1x eng 1x sprint is ~5 points.

By saying 8pts the team is effectively saying it's probably a 2 sprint job and individual tickets are not supposed to be 2 sprints long meaning there's complexity that either needs to be broken apart or on the rarer case, team agrees the ticket is fine as-is then it'll take 2 sprints.

Anything 13 or greater is saying this ticket is so big we can't even begin to accurately estimate it - PM take it away from us! It's fun to see 21 or 34 pts... it's all a joke at that point.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#117
post #48

Beware blanket statements! I work with sound in games and have multiple times tried to do Kanban, both from an internal team and an outsourcing team, because of basically the same reasons mentioned in the article - it's agile and task based, and seems like a good fit to be a "factory" for sound assets. However games are iterative by several orders of magnitude more than traditional tech (I've also been CTO at a more…

No idea what you mean with outcomes vs means/tasks. Just put outcomes as cards in your Kanban board, they don’t have to be tasks.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#119

Scrum is meant to protect the team from changing requirements mid-work and it's a good way to work when you have a "client" that requires "features" to a product. There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client/pr…

> Scrum is meant to protect the team from changing requirements mid-work

But this will happen from time to time. People writing tickets or even devs when checking the tickets don't read the related code. So you have a big and important source of uncertainty. Some things are technically constrained.

Re: You don't need Scrum, you just need to do Kanban right (2022)

#120
post #53

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…

I think the "problem" is that Scrum orients more to the needs of people outside the team. So, (in theory) you get clearer reporting and more visibility into whats going on. People expect that extra reporting to be free, but its not free. The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. The sad truth is that most management teams would prefer their e…

I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.
Post reply on HN