Live data from Hacker News

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

lucasfcosta.com

161–170 of 341 posts

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

#161
The experience i have with scrum is similar to what the procrustean bed suggests. Funny thing -to me - is that usain bolt did not use scrum to win, neither did federer. You can’t go to the moon with scrum. But I do see value in it as long as I drop 80% of what it proposes. Scrum is just a passion killer. We shoud use the ideas from the No Estimates and Accelerate books

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

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

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!

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

#163
People trying to shoehorn scrum into their startup is the problem - not scrum itself

It is specifically designed for interfacing with project-external stakeholders.

It works well for “project teams” in a large org for whom the project isn’t the primary business focus. e.g. an internal tool to assist with problem X, or a development project for an external entity.

There is no other use case for which scrum is a good fit - and it’s those mismatched experiences that always result in scrum hate.

I think people just got caught up in the cool name and the certifications and blah.

Stop using scrum for the wrong thing!

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

#164

I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation. A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example: > When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make.…

> But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback. But how does Scrum help out here?

Scrum has prescriptive method of who is supposed to gather requirements, the meeting for requirements gathering, estimation for "understanding of requirements", and demo... well for demo'ing the feature back to "the powers that be".

Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization.

This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way".

I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.

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

#165
post #8

Is “doing Kanban” just having tasks on a board without any sort of sprint structure? I feel like it’s a bit of a false equivalence. While I won’t ever defend all the cruft that comes with Scrum, the article seems like a bit of a straw man.

Kanban means constrained capacity. You decide on an upper bound on how many things are allowed to be in progress at any one time and if you need to start work on something new you finish things that are in flight to provide headroom to do that. The board is just a device to ensure good communication so everyone in the team has shared state.

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

#166

Earlier quoted context omitted.

I've seen Kanban work well on smaller scales, and Scrum work well on larger scales. I cannot for the life of me work in the churn and development pace of a Scrum team, so Kanban (and the culture around it) is best fit for me. I think it also depends upon the type and culture of people working in the team as well. Some teams work really, really well with the predictable cadence, others do not. It's a case by case kind…

The commitment to sprints was literally the first thing that got dropped in our company. It's so nonsensical to create completely arbitrary deadlines without any real urgency. We now have long sprints (~1 months) for reviews and retrospectives. Which are usually well received. You get to see what all the other teams have been doing, and you also get a formal chance to talk about any problems.

Sprints and timeboxing more generally is not about enforcing deadlines. That's such a common misconception and I wish it would die.

Timeboxing is about committing only a small amount of time and money at a time, so you can choose to double down on winners and stop investing in losers, rather than suddenly finding yourself having sunk 3 months of time into something that turns out wasn't that good after all.

The question is not "How much can we definitely complete in two weeks?"; it's "What things are promising enough that we are willing to dump two weeks into them, with no promise of ever making a profit?"

If one month counts as a small amount of time and money for your organisation, then you're doing it right!

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

#167

People trying to shoehorn scrum into their startup is the problem - not scrum itself It is specifically designed for interfacing with project-external stakeholders. It works well for “project teams” in a large org for whom the project isn’t the primary business focus. e.g. an internal tool to assist with problem X, or a development project for an external entity. There is no other use case for which scrum is a good f…

That sounds sensible. Soo... How do you get your managers to this insight? In my company each team uses scrum and I think no one is really happy with it. Mine certainly isn't. I'm not even talking about the engineers: at least from my point of view everyone involved suffers from it. But I have the impression we lack responsibility for such decisions. Oh well, I think I'm just venting now :)

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

#169

Scrum is meant to protect the team from changing requirements mid-work and it's a good way to work when you have a "client" that requires "features" to a product. There is a well-defined standard process for them to add things to the backlog and there is a written down definition in which state items in the backlog have to be in so that they get picked up for the next sprint. If the team works with just one client/pr…

> 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 protection might be useful.

All this "protect the team from changing requirements mid-work" is nonsensical anyway, because no _really_ valuable work is done in 2 weeks. If the requirements _really_ changes you have to throw away the code for the old requirement. You can throw away 2 weeks of coding or 2 days. I'm pissed off more by 2 weeks of dead code. If the requirements adopts a bit its better to adopt early. And change in focus and priorities (which is _not_ a changing requirement): I'm happy to do so if I'm convinced it's for the good of the company and I'm happy to say "Sorry, this will have to wait until I'm done with what I'm currently doing. Please come back next Tuesday.".

Post reply on HN