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

181–190 of 341 posts

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

#181

Post by lucumo »

rightbyte wrote: post #98
ptmcc wrote: post #76

Earlier quoted context omitted.

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…

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?

Is padding really cheating? I'd describe that as accounting for unforeseen setbacks and correcting for overenthusiastic optimism.

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

#182

Post by Gareth321 »

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

> 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

This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management.

I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.

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

#183

Post by midoridensha »

marginalia_nu wrote: post #150
dilyevsky wrote: post #105

Earlier quoted context omitted.

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

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

I think that's why Agile was invented: for situations where requirements are not fixed. If you have fixed requirements, I don't see why you'd need Agile development in the first place, though some parts of it might be useful for just keeping everyone on track.

In a recent job, we used Scrum and it generally worked well, but we didn't have the luxury of fixed requirements. The customer needed new features on a regular basis (features which they could not have foreseen the need for beforehand), and we'd regularly give them deliveries of the version of the product we had, which they'd immediately put into use. A waterfall model would never have worked there.

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

#184

Post by fogzen »

As someone who runs a software agency, kanban sounds like nonsense.

If you don’t know exactly what you’re doing, for whom, by when, you fail to meet expectations by delivering the wrong thing by the wrong time.

There is design & estimation, planning, development, and evaluation phases. End of story. It doesn’t matter what you call those phases. If you don’t do design and estimation, you have no idea what you’re building or any metric for success. If you don’t do planning you have no schedule for delivering it.

“I’ll do this feature as defined by a two sentence ticket whenever I complete it” is incompetent and reckless. It’s idiotic. I’ve seen many companies operate this way, and they are constantly delivering the wrong thing by the wrong time (particularly VC-backed startups).

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

#187

Post by ithkuil »

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…

> Especially if nobody can actually quantitatively measure the loss of efficiency.

Yet ironically they care and tout about their ability to measuring efficiency.

An easy way to boost efficiency: hide inefficiency out from view!

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

#188

Post by theshrike79 »

ResearchCode wrote: post #178
theshrike79 wrote: post #79

Earlier quoted context omitted.

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

Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them. The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project. Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.

Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel.

Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing requirements or not what the customer wanted because there is no way to change course after the project specification was locked.

...or you spend so much time doing an exact specification that the Agile team has already delivered 3 incremental versions.

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

#190

Post by Scarblac »

kqr wrote: post #162
irjustin wrote: post #116

Earlier quoted context omitted.

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…

Thanks. My teams have always estimated in hours (though at times these hours were called points) so I was a bit frightened to hear that an estimation of 13 hours would be considered bad! I guess if 13 means 26 person-days I get why people would be nervous – even I would suggest breaking it down into smaller pieces, if possible!

The main point of points is that they are not supposed to be equivalent to x amount of time.

They're supposed to represent a measure of complexity.

How much time that then takes depends on who does the work, the order in which tickets are implemented, how much distraction there is, luck (do you encounter any unforeseen problems), and so on.

They're then used to see how many issues will fit in a sprint, which is a measure of time. So everybody ends up treating them as representing time anyway...

Post reply on HN