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

141–150 of 341 posts

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

#141

Post by yieldcrv »

klik99 wrote: 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…

I hate walking into organizations and they treat their style and acronyms like they’re sacrosanct

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

#142

Post by mongol »

irjustin wrote: post #116
kqr wrote: post #104

Earlier quoted context omitted.

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

Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.

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

#143

Post by layer8 »

DangitBobby wrote: post #96
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…

Of course fixing time and quality requires the ability to create accurate estimates.

Not if you can reduce scope (to zero, in the worst case).

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

#144

Post by rightbyte »

emodendroket wrote: post #124
rightbyte wrote: post #98

Earlier quoted context omitted.

Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?

Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?

At some point there is a need for time estimates, ye.

I don't ask contractors for a detailed breakdown, just the whole thing. And they either do a high padded fixed price or work per hour.

A friend who is an elictrician might do 100 similar rooms in a building and they have a detailed breakdown of "time per screw" more or less.

So I guess the accuracy depends on the sameness of tasks to do.

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

#145

Post by robertlagrant »

throw3823423 wrote: post #100
fendy3002 wrote: post #91

Earlier quoted context omitted.

The problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint. So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain…

I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as…

SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.

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

#146

Post by hnick »

moring wrote: post #122
hnick wrote: post #102

Earlier quoted context omitted.

This sounds a lot like the coastline paradox. The more precisely you try to measure a coastline, the harder it gets due to its fractal nature. Software estimation, similarly, is fractal in nature - you can always drill down deeper to measure but it gets increasingly complex and at some point you have to ask, is it worth it being "accurate"? Or do we just do it? Org charts require the former while developers desire th…

I think that analogy is broken. Measuring a coastline more precisely doesn't just become more complex (measuring precisely often does), but actually increases the measured length towards infinity. Unless you wanted to say that the same is true for software estimation, e.g. due to the measurements taking up more and more time.

Yes, I meant the time taken estimating. The act of measuring estimated hours becomes more complex because the closer you look, the more you see, you could do it forever and have to stop somewhere.

But maybe instead of infinity, it's better to say estimation can take longer than the work itself which has been the case a few times for me.

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

#147

Post by ResearchCode »

emodendroket wrote: post #124
rightbyte wrote: post #98

Earlier quoted context omitted.

Ye padding estimates and report time according to the estimate to make the burn down chart straight was what I learned to do when Scrum was forced on my team for no good reason at all. -"It is impossible to do accurate estimates" -"You will get better at it" I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat". Do anyone else share this experience?

Estimation often is way off for construction projects, but would you hire a contractor who refused to hazard a guess of how long a job would take or how much it would cost?

Would you hire a mathematician that doesn't "story point" conjectures? Yes. Would you hire one that does?

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

#148

Post by robertlagrant »

danmaz74 wrote: post #99
enkid wrote: post #87

Earlier quoted context omitted.

Having predictability and observability is key to a business though, as higher level decision need to be made based on progress of the lower level teams.

Yes, predictability is better for business, but business also needs to accept that there are limits to the amount of predictability you can achieve in software development, and trying to force too much process is only going to predictably increase delivery time. In my experience, working with high level estimates which you keep updating from time to time is the best compromise.

> business also needs to accept that there are limits to the amount of predictability you can achieve in software development

Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.

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

#149

Post by layer8 »

rightbyte wrote: post #132
misja111 wrote: post #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…

We are way way past "doing it right". It is agile that is at fault, not the average management on the average company. If the average manager and dev won't be able to do it, then it is a lousy process.

I agree about Scrum, but if you read the Agile Manifesto, Agile isn't Scrum.

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

#150

Post by marginalia_nu »

dilyevsky wrote: post #105
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…

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically

I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe).

My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality.

There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way.

That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding.

My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.

Post reply on HN