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

311–320 of 341 posts

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

#311

Post by mock-possum »

vikingerik wrote: post #85

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…

Is there a longer article you have a link to, covering that triangle and the three project management strategies? It’s a fun concept.

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

#312

Post by lowdownfork »

"Scrum shortens planning horizons by limiting batch-sizes to two week sprints. . . Still, because Scrum is a push-based system, it still requires you to do some form of estimation . . . This demand for estimations leads to unproductive and unnecessary estimation meetings."

I actually prefer Kanban over Scrum, but none of this matches my experience at all.

1) People plan multiple sprints ahead in Scrum. Not necessarily the full sequence of tasks, but things like telling a stakeholder which sprint their task will be in.

2) Many people are in a situation that's inherently push-based and requires estimates. Scrum is just a way to achieve that. The author gets snarky in the first paragraph about choosing Scrum vs having it chosen for you, but really . . . most people know full well that Scrum was chosen for them, and that it was chosen for planning purposes. And that they do tasks because other people need them done, not because they had some free time. Heck, the whole project usually exists to serve the needs of others, not the joy of working fast.

3) Even in Kanban, we'll usually have basically the same grooming meeting. That's because the meat of that meeting is sharing information and thoughts about what the upcoming tasks involve and discussing whether and how to break them down into sub-tasks.

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

#313

Post by michaelcampbell »

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…

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

This has been my experience. I've seen more than once management teams happier with numbers and estimates that weren't met than actually getting software out quicker at an unanticipated rate.

They'd rather have estimates that they could yell about than revenue generating software through (presumably) happy customers.

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

#314

Post by emodendroket »

davemp wrote: post #310
emodendroket wrote: post #290

Earlier quoted context omitted.

Even to the extent that is true it doesn’t change my argument at all.

Maybe I don't see the relevance of your question then. Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees. Agile is a development process not a contract pricing strategy. If any…

They don’t have to hire you every two weeks but they are paying for you and do have to decide how to allocate your time and plan various projects with interlocking dependencies. How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? You are, in effect, still asking them to write you a blank check to accomplish something when they might want to change gears if apprised of how difficult it is.

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

#315

Post by TobyTheDog123 »

theshrike79 wrote: post #79
TobyTheDog123 wrote: post #12

Earlier quoted context omitted.

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…

So if we finish all of our tickets early (which is often the case because measuring complexity is impossible to do up front), we're just supposed to sit around until the sprint ends?

A scrum master? Man, I thought my team was bloated with process but the fact that role exists elsewhere means I should probably be more grateful.

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

#316

Post by xputer »

theshrike79 wrote: post #194
drvd wrote: post #169

Earlier quoted context omitted.

> Scrum is meant to protect the team from changing requirements mid-work Do I need this protection? Why cannot I protect myself? Do I want this type of protection? Especially if it comes with all the negative downsides of Scrum. Scrum is based on the imho often wrong assumption that a team needs "protection" of some sort. If your team consists of 16 year old youngsters only this might be true and this type of protect…

Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work. Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week". This is why in Agile we have the Scrum Master who fields all requests like…

+1 in my experience most people that criticize scrum simply have a bad experience with a half baked implementation of scrum.

If it's implemented well it's fantastic. You get to focus on the important stuff during the sprint. Issues tend to get caught early on because experienced team members chime in during planning poker. The whole team takes responsibility for the sprint together. This leads to lots of knowledge sharing and collaboration within the team.

Once the team velocity is predictable it also becomes much easier to ask for x amount of time per week for refactoring work as the impact to project timelines can be easily quantified.

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

#317

Post by theshrike79 »

IshKebab wrote: post #240
theshrike79 wrote: post #224

Earlier quoted context omitted.

Depends on what the "you" is here. If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint. If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days…

> If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No. I hate working with people like this. So unhelpful.

I hate being interrupted by people too, that's why I like the Scrum style of working when there is an external client (or an unruly internal one).

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

#318

Post by pg_1234 »

vikingerik wrote: post #261
pg_1234 wrote: post #171

Earlier quoted context omitted.

Actually the most effective strategy I've seen is Kanban, but with a fixed release deadline. Inevitably there are some essential tickets and some nice-to-have tickets. For the nice-to-haves it's a case of progress or die. Think of it as time constrained Kanban with semi-fixed scope. The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit). P.S. From…

That's functionally scrum anyway, you're just not calling it that to avoid the ceremony, yeah.

No that's not scrum, as any "scrum master" will tell you ... scrum imposes it's own artificial cadence.

This is kanban ... just culminating in a release event anything from weeks to months in the future (driven by time factors independent of dev management i.e. actually having to produce something as a business). I mean nobody can seriously be proposing no time bound on kanban (please clear the board this decade?)

If you're behind schedule pausing for a ridiculous high school level show and tell will only delay you more ... and if you're ahead of schedule, just keep doing what you're doing right.

What kanban provides is visibility, how much you're getting done. Scrum sacrifices momentum for theatre.

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

#319

Post by tharkun__ »

fendy3002 wrote: post #264
emodendroket wrote: post #125

Earlier quoted context omitted.

If the sprint commitment gets bounced in favor of stuff coming in mid-sprint, they in itself might be useful information to someone who’s interested.

But the reality is you cannot hope for management to realize it, and for a good reason. If reprioritize a new feature can bring more revenue compared to original plan, or if a better flow is now available due to other team's completed task, or if a severe bug is discovered someday, it's just logical to reprioritize.

Things changing as a complete 180 mid sprint every single sprint doesn't mean Kanban is more suited as a process. It means your company is not using any process but rather is just a chaotic "who screamed the loudest most recently".

If you do Kanban right you have to have predictability through tasks of roughly equal size. If you will you can think of Kanban as Scrum where all tasks have to either be sized 2 or 3, else they don't make it into a sprint.

New items get added to the end of the backlog by default and stakeholders know when they can expect their request to be done because you know your velocity and queue length.

Putting every single request that comes in at the top of your Kanban backlog is orthogonal and bad.

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

#320

Post by emodendroket »

kqr wrote: post #307
emodendroket wrote: post #293

Earlier quoted context omitted.

But estimating revenue is just as much of a shot in the dark as estimating effort, and if the effort is great enough it will cancel out the revenue.

The variation in effort is orders of magnitude smaller than that in value. Great value is very rarely canceled out by high effort and low value almost always cancel out low effort.

If revenue from a venture were so predictable you wouldn’t see the Funko Pop company destroying tons of inventory but you do.
Post reply on HN