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

281–290 of 341 posts

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

#281

Post by JohnFen »

azangru wrote: post #278

> As I mentioned before, sprint planning meetings are unproductive because they lead to “designing by committee” and focus on getting estimations right, which is not only a waste of time, but also impossible to do in a stochastic process such as software development. This sentence alone reveals an incorrect understanding of scrum. First, scrum does not "focus on getting estimations right". In fact, if you search thro…

> How this can be dismissed as a waste of time is beyond me.

I think a lot of it is because Scrum as practiced is often not like you describe.

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

#282

Post by JohnFen »

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?

> I wonder if the Scrum Master knew that in the end "get better" is "starting to cheat".

I was a trained Scrum Master and I knew this very well.

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

#283

Post by klik99 »

flarg wrote: post #130
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…

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…

Yeah, I didn't mention in my earlier comment but I've found that scrum does work better with larger teams because it adds ownership into the process. You can define ownership with Kanban (or any process) but it's not integrated into how it operates without some hacking.

edit I sometimes find myself in the position of apologist for Scrum, which is weird because I'm not that crazy about it, I'd almost always prefer to use something less heavyweight. But people are so quick to throw out the baby with the bathwater - there are a lot of great concepts in scrum, and it's quite interesting to see how all the parts interact when it's actually working.

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

#284

Post by darreninthenet »

Jochim wrote: post #176
darreninthenet wrote: post #134

Earlier quoted context omitted.

This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally. But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.

> The metrics are supposed to be for the team to use internally. You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them. My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?

This is where a decent scrum master or agile coach is valuable - fighting off the misuse of the metrics by external (to the team) management.

The thing is with metrics is that they are hard to argue with, whereas intuition is a debatable opinion. Perhaps not everyone in the team agrees. Perhaps it's about showing interfering management or dependent teams where the issues lie. Perhaps the team doesn't realise how long a particular stage in their workflow is holding things up - I mean they know that stage is a problem but have they realised it's actually their biggest blocker to finishing work?

Also depending on what you use to generate metrics - something like ActionableAgile that use Monte Carlo simulations against a few weeks worth of activities can show a team what their cycle time is, what items are in danger of blowing that and how long it's likely to finish just their current backlog (for example).

As you say, in their worst case they tell teams what they already know and then again that's the value of a good SM or AC - finding out why nothing is being done about it (whilst beating away interfering managers).

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

#285

Post by shuntress »

azangru wrote: post #278

> As I mentioned before, sprint planning meetings are unproductive because they lead to “designing by committee” and focus on getting estimations right, which is not only a waste of time, but also impossible to do in a stochastic process such as software development. This sentence alone reveals an incorrect understanding of scrum. First, scrum does not "focus on getting estimations right". In fact, if you search thro…

What you say is completely true for a spherical team floating in a frictionless void.

The reality is that it is quite difficult to break products down into separate features then work on those features separately and in order.

Because of this, it's very easy for planning meetings to accidentally become "What did we work on last week? Will this still be done on time?"

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

#286

Post by klik99 »

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

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?

Yeah scrum, or any process really, sucks when it's used like spyware. I've been lucky enough to be part of teams in companies that don't treat their employees like the enemy. So doing scrum the every day work aspect happens at the local level. What I like about scrum is being able to talk to other teams about higher level things while keeping the day to day tasks just within our team. It's similar in programming to the TDD approach of making a public interface and testing against the functionality, while the implementation details are kept internally.

Doing reports I find people care less about the day-to-day work and more about when it gets done, and this is where scrum in theory works well but breaks down in reality. In practice is estimation works when team members are kept consistent, because over time you can track historically "t-shirt size" complexity of task as estimated by the team translates to "x number of man-hours". However in game design we get a lot of major team shakeups pretty regularly with teams changing across different milestones. It's hard to fight against the instinct of "Oh this thing needs our a-team players for this release"

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

#287

Post by bluefirebrand »

przemo_li wrote: post #215
lucumo wrote: post #179

Earlier quoted context omitted.

I found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it. Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good…

Proposing retro board be available 24/7 and retros be skipped if board is empty is good use of retro time. ;)

This sounds amazing.

But I do wonder if it just encourages people not to bring up real problems so that they can skip a meeting.

I think having the board up at all times is a great idea though. Just have to have some way to figure out "is it empty because things are fine or is it empty because no one cares anymore".

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

#288

Post by emodendroket »

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.

That’s not the point though. The point is to have an answer when someone asks why the original thing didn’t get done.

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

#289

Post by emodendroket »

monkpit wrote: post #280
emodendroket wrote: post #124

Earlier quoted context omitted.

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?

Contractors charge you based upon the value they provide you, not their costs and labor. A time estimate is reasonable to expect, though.

Depends. Being billed by the hour is far from unheard of.

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

#290

Post by emodendroket »

davemp wrote: post #274
emodendroket wrote: post #249

Earlier quoted context omitted.

Would you agree to pay for any service where not even an estimate of the price could be given? I guess healthcare is the only example I can think of where anyone consents to that.

Estimates you get are what the estimator thinks you will pay (mostly) not how much it costs them. Prices in the real world are barely linked to costs. Budget risks are bundled in markets with high variance.

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