Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

lucasfcosta.com

Post reply on HN
Print view View original

71–80 of 341 posts

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

#71

Post by [deleted] »

crazygringo wrote: post #27
DanHulton wrote: post #3

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…

But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.

[deleted]

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

#72

Post by henenbdki »

emeraldd wrote: post #31
leetharris wrote: post #10

Earlier quoted context omitted.

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.

Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team d…

> Of course, the counter to that is that we're not doing scrum right.

That’s almost always the excuse in my experience. It’s not that it doesn’t work, it’s just no one has ever done it correctly.

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

#73

Post by lmm »

JenrHywy wrote: post #63
lmm wrote: post #19

> 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…

Picking up on > 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 softwa…

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

IME most of the time they need to get over it. The reality is that estimating in that kind of detail would be expensive and not worth the effort.

However what they do reasonably need is the ability to prioritise feature A over feature B and they need a vague comparison of costs in order to do that (like, is feature B going to be 3x as much work as feature A?). Scrum provides that at minimum cost.

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

#74

Post by cloogshicer »

crazygringo wrote: post #27
DanHulton wrote: post #3

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…

But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.

Why do you need an explicit meeting for that? Just talk to each other as you uncover new information.

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

#75

Post by theshrike79 »

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/product, the client can prioritise the backlog.

During the sprint they can't give any input or request "just this one quick feature". The work is locked during the sprint. If they REALLY want something, the Agile Manifesto says to drop and delete all ongoing work and start a new sprint from scratch. Exactly zero clients have agreed to that - they really weren't in that much of a hurry with the feature.

After the sprint the client gets a demo of what the team achieved. An actual demo with the actual product. Not a powerpoint presentation of an ideal state or a video done in a demo environment. At this point the client can provide feedback and new features and we GOTO 10.

Usually a single member needs to be defined as a firefighter who takes on bugs and production issues that can't wait for the next sprint, but we don't tell that to the client. If there is no urgent work, they work on the sprint tasks as normal.

--

Kanban on the other hand works if the tasks have no dependencies with each other, like building maintenance or IT/DevOps type stuff.

"Install new laptop for Karen with standard package" doesn't require a sprint, anyone on the team can do it. Or "Set up AWS account with ECS for team B"

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

#76

Post by ptmcc »

josephg wrote: post #53
DanHulton wrote: post #3

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 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 top to satisfy management and/or external parties.

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

#77

Post by esafak »

1123581321 wrote: post #69
esafak wrote: post #59

Earlier quoted context omitted.

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.

Cycle time on a board gets you that as well.

This provides more visibility and granularity, increasing confidence and satisfaction of customers.

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

#78

Post by kstenerud »

cloogshicer wrote: post #70
kstenerud wrote: post #66

Kanban 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…

Genuine question: How does Scrum help with less predictable work? 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.

When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information.

Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sprint to give more time to plan for the new challenges) you already have a new estimate. And you have a paper trail of what happened and how you dealt with it.

Your velocity goes down and you lose some predictability, but your agility goes up because you can adjust instantly to new challenges. None of these tools are a panacea; you have to thoughtfully decide which trade-offs will offer the greatest benefit for your particular project.

The "deadlines" shouldn't be thought of as hard deadlines. They're estimates of what you expect to have done at the end of some arbitrary period. Your accuracy in this should be measured statistically over time. If it turns out that you're consistently under or over, you adjust how you estimate. Ideally you want your estimates to average out to break-even over the course of a year. The point isn't to be able to determine exactly how much work you'll do, but rather to determine with a high degree of confidence (80%? 90%?) when the work will be done, with the understanding that it's not guaranteed (i.e. it's a point statistic). It's a planning tool, not a performance measure (the moment you treat it as a performance measure, it becomes useless due to the cobra effect).

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

#79

Post by theshrike79 »

TobyTheDog123 wrote: post #12
beoberha wrote: post #8

Is “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.

I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thi…

> in my org tickets overflow from one sprint to the next all the time, tickets get added mid-sprint

That's not Scrum then. You don't add stuff mid-sprint, that's the whole point. Unless the world is literally on fire, you don't touch the sprint content.

What's your scrum master doing when you get stuff added? It's their job to prevent it.

And if work overflows, you need to spend time grooming the tasks to manageable chunks and adjust the team velocity. You can always pick up more tasks if you run out of stuff to do.

Post reply on HN