Live data from Hacker News

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

lucasfcosta.com

121–130 of 341 posts

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

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

All the estimation stuff is only for your team, not for outside consumption. If you release it and care what people say about it, then that I don't think that's the methodology's fault.

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

#122
post #102

Earlier quoted context omitted.

I have the software engineering uncertainty principle. The more you try to measure and estimate and predict software velocity and delivery the more you slow it down. I think this is probably true of any largely creative and problem solving task, but compounds because most of the uncertainty derives from dependencies requiring those dependencies to likewise measure and slow down. The more complex and interconnected an…

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.

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

#123

- PM/PO loves scrum, that gives them an illusion of controlling the dev speed/progress... - the estimate is a joke... - the standup is useful to know who is pretending work. but no need a daily standup for sure. and a non-technical PM with scrum makes things worse.

Sounds like you have a very poorly run and dysfunctional team. When applied correctly, good project management ends up better for everyone.

I hope you are correct. Finding companies with good project management has so far been quite elusive though. In my career I've had about eight project managers so far, six of which were in a scrum environment. Without exception the scrum PMs have not been effective at all.

I don't doubt that effective scrum management is theoretically possible, but based on personal experience and also by reading through the rest of this thread it seems that scrum is too difficult to do correctly for the vast majority of project managers.

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

#124
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?

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?

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

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

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…

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.

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

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

It is kinda typical that management likes Scrum because it gives the illusion of control. How much insight into the every day work do you have?

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

#127
post #106

Earlier quoted context omitted.

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.

There's no limit to predictability achievable in software development per se. You can have perfectly predictable software development -- if you know exactly what it is you're going to build. The trouble is -- as with any product development -- we don't know exactly what we are going to build because it depends on fickle market sentiments, new technology, etc. That is what sets the upper limit on predictability, and t…

> You can have perfectly predictable software development -- if you know exactly what it is you're going to build.

That's not enough - you can have pretty good predictability if you know exactly what you're going to build, and if you already built the same kind of thing with the same technologies/tools that you're going to use this time. Which is very often not the case: business very often wants new things that others don't already have, or the technologies/tools from previous times are now outdated (or believed so...).

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

#128

Earlier quoted context omitted.

> It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a sin…

> This I 100% agree with. I've come to look at these frameworks (kanban, scrum etc) as I look at the Bible... no church gets it right and never will. It's not possible. It's interesting that you use this analogy. I've always compared Scrum to Communism or faith healing: If it doesn't work for you, you either didn't implement it correctly or you didn't believe in it enough.

Right, exactly. In other words, the claims it makes are unfalsifiable, because if they don't come to fruition then clearly there must be some other factor in play.

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

#129

Earlier quoted context omitted.

Sounds like you have a very poorly run and dysfunctional team. When applied correctly, good project management ends up better for everyone.

"When applied correctly, good project management ends up better for everyone." With good project management you can make any process work, be it waterfall, scrum, kanban or others. All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.

> All dysfunction comes from people perpetuating processes that don't work. That's what agile was about originally.

Agile is far worse than anything I experienced earlier. It was pushed as some sort of dogma where you are a cranky non-teamplayer person for arguing it is a bad idea. A counter-revolutionary blocking utopia.

Giving non-programmers insight into every small tasks is a big mistake.

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

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

This is the real comment here. I've worked in all three, scrum, kanban and waterfall, and I know from personal experience that they all have their shortcomings and it really depends on what you are trying to deliver and how well your team responds. We've moved from waterfall to scrum to kanban and back and the one standout is clarity of minimum requirements and boy is that hard to get from the relevant people. If you don't get that then stick with waterfall because then no one is responsible!
Post reply on HN