Live data from Hacker News

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

lucasfcosta.com

211–220 of 341 posts

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

#211

Earlier quoted context omitted.

I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thi…

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

See that's the main problem with strict scrum. Why can't you add things to the sprint mid sprint? Sometimes things come up that you didn't think of.

There's really no point being that strict. I think two week meetings/sprints are good for keeping focus and as an opportunity to agree short term priorities. But the point is to get work done, not to precisely obey scrum rules.

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

#212
post #21

Earlier quoted context omitted.

I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thi…

Kanban is about organizing the work to be done and periodically revisiting the board to understand the work done and what’s next (which involves reprioritizing, pivoting, etc.) Some people might debate on how active a kanban board should be.

That sounds identical to how companies I've worked for "do agile". A kanban board. Every two weeks you revisit the board, see what got done, prioritise what to do next (usually by dragging it from the "backlog" to "todo" column).

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

#213
post #166

Earlier quoted context omitted.

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

[dead]

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

#214

Earlier quoted context omitted.

Most companies have already hired the contractor though so this little dance is just pointlessness that kills motivation and velocity.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

If revenue they bring is estimated you may only need relative comparison.

After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one?

See? No need for detailed answers if there is sufficient difference in qualities.

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

#215
post #179

Earlier quoted context omitted.

>The time taken to do team task estimation, update jira tickets and have retrospectives is time spent not programming. Agree with everything _expect_ retros. I think the value of the retros is proportional to how senior the team is and to how seasoned managers are. But for me retros are extremely high value _if_ you have: - Teams that can look at problems head on and be civil addressing things without making it perso…

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

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

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

Imo, padding estimates is not cheating. It is just doing estimation right. Teams that do not pad estimates literally always underestimate amount of time needed.

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

#219
post #181

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?

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

Padding estimates is fine. But not when you report actual worked time, which was what we did to make management happy with the burn down charts straightness.

If you don't report actual time for the task, the excercise is useless.

E.g. shift work time from a slower than estimated task to a faster, or "wait" if the task was done too quickly.

Post reply on HN