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

271–280 of 341 posts

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

#271

Post by watwut »

Gareth321 wrote: post #254
watwut wrote: post #245

Earlier quoted context omitted.

> It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as unkind and destructive. This is the piece which I rarely see working well without a framework. It doesn't have to be scrum. I just see scrum solving this and many other problems really well. Scrum does not help with effective communication at all. Its only tools for f…

> There is literally no place in it for private feedback or some kind of learning plan or a weaker developer having tasks adjusted so that he can catch up (getting simpler ones, or only frontend ones till he learns that), literally nothing... Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it. Sure, scrum is a team tool, not a personal development plan tool. The l…

You started by saying that scrum helps team alignment, communication and dealing with weaker developers. That introverted developers need something like that to communicate, because they are avoiding tough discussions. You was literally talking about developers.

When I said that developers do tough part regularly in code reviews, you said that effective communication is more and scrum provides that more.

When I said that scrum does not provide "the more" and makes it harder, you said that scrum actually should not do any of that, manager should. And oh, scrum has scrum master and no manager, so no I guess no one is doing it.

-------

In a non scrum process, seniors do frequently take actively care about Juniors or own development. They can do it in systematic manner. They can actually work together on a lighly larger units of work with them. They can split work in a way that makes sense between the actual two people in question rather then based on what someone else prescribed.

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

#272

Post by esafak »

conradfr wrote: post #113
esafak wrote: post #59

Earlier quoted context omitted.

Everybody wants their ticket serviced ASAP. Scrum helps manage that expectation. If a sprint is underway, new requests have to wait for the next sprint unless an agreement is reached to drop an existing ticket.

What's the difference with prioritizing tickets in a Kanban queue? In the end it's the work of the PM in both cases. People with enough power in the org will insert their ticket in your precious sprint anyway.

If you're going to constantly groom your backlog to maintain priority order that is fine, but that's more work than maintaining a partial order. In fact, scrum is even less work than a partial sort; it just says "we're going to work on your ticket in sprint X" without being more specific.

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

#273

Post by seniorThrowaway »

kqr wrote: post #166
Double_a_92 wrote: post #139

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…

It's not a misconception when it's what many organizations are actually doing. Any that implement SAFe, for instance.

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

#274

Post by davemp »

emodendroket wrote: post #249
gilbetron wrote: post #234

Earlier quoted context omitted.

Constructions remains a terrible analogy for software development, as it always has been.

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.

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

#275

Post by kstenerud »

przemo_li wrote: post #255
kstenerud wrote: post #78

Earlier quoted context omitted.

When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information. Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sp…

Have you tried to just track time on board / time on column on each task on Kanban board? You just need to keep track of time to trigger those discussions.

You can technically do everything with both tools, but each is optimized for a particular situation. They're so closely related that many people think of them as competing alternatives rather than as situational alternatives.

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

#276

Post by dragonwriter »

esafak wrote: post #269
dragonwriter wrote: post #156

Earlier quoted context omitted.

It provides less granularity and visibility, but it provides regular, well-defined touch points. OTOH, nothing stops you from having biweekly reviews with customers in Kanban, or delivery goals on the same cycle that guide decisions of which work items to pull in and whether to allocate more effort or defer ones that run into unexpected complexity. There’s no reason to (and plenty of reason not to) build a work-shoul…

A kanban with periodic commitments to the next batch of tickets to be worked on is functionally scrum to me.

Even in Scrum, a Sprint Goal is not a batch of tickets, and for kanban the period re-evaluation of goals/priorities can be even less like that. And, of course, a review can be whatever there is to review.

What I am saying is that, insofar as cyclical touch points are a valuable customer-interaction feature of Scrum (and even when doing “proper Agile” with daily interaction with the customer as part of development, which is more an exception than the rule in most “Agile” places I’ve seen, the fact that “the customer” is usually an organization and the ideal daily interaction is individuals at the working level, not whole-team-to-whole-team level, those periodic touchpoints are useful) you can have them in Kanban while maintaining continuous flow as opposed to sprint-oriented flow in the development team.

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

#277

Post by sodapopcan »

DoingIsLearning wrote: post #151
josephg wrote: 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 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've worked on a team that had amazing retros: lots of difficult discussions that resulted in change. We also made sure to discuss positive things too to ensure they keep happening. I think a lot of people miss this about retro.

I also worked on a team with terrible retros. The "good" column would always be extremely long and was only full of platitudes, nothing of actual substance that was brought forward into the next week. If anything difficult came up, someone would say, "Ok, let's book a meeting to talk about this later". It was an extreme misunderstanding of the value of retros. Though everyone else seemed to enjoy them so that's arguably valuable? I dunno.

Anyway, yes, lots has been said on this topic in the past. SCRUM is just Agile for stakeholders. There is the whole "SCRUM But" joke but I actually think a bunch of things in SCRUM are valuable BUT if something isn't working out, don't do it! I get the impression that lots of companies just do all the rituals "because SCRUM" and don't actually understand why they are doing them. Case in point, I was at a company that would always spend time story-pointing but no one ever looked at them. Not the teams and not the stakeholders.

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

#278

Post by azangru »

> 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 through the scrum guide [0], you will not find any mention of estimates whatsoever.

Second, the purpose of a planning meeting is to identify what next to work on in order to add the most value to the product. Therefore, the meeting involves the product owner, who has the clearest understanding of the business value of the product at any given point, and the developers, who have the clearest understanding of what's going underneath the hood of the product. Their conversation informs both the developers of what's most valuable, and the product owner of what's doable.

Third, in the planning meeting developers, who are actually going to be doing the work, have an opportunity to decide how they are going to split the work, how they are going to collaborate on it, and whether there are any unsolved dependencies preventing them from taking the work into the next iteration.

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

[0] - https://scrumguides.org/scrum-guide.html

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

#279

Post by klik99 »

jdkoeck wrote: post #237
Closi wrote: post #191

Earlier quoted context omitted.

I think they mean it from a softer perspective - Scrum encourages more time ensuring all the team and tasks are clearly directed towards an outcome for that sprint. Just putting outcomes as cards on a kanban board will not have that same effect in all instances, as it's more about the soft points of engagement and teamwork driving towards that common goal.

Thank you for your answer. Actually it’s perfectly doable, just put an outcome swimlane in your kanban, with a rule that says there can only be one card in the « doing » column. I’m starting to realize that most people don’t know how customizable Kanban is. You can put as many columns and swimlanes as you want, and then implement constraints in the system with rules around how cards move on the board.

I actually do agree with you that kanban is very flexible - and I have used plenty of additional swimlanes - for my original example we tried using "concepting" stage, multiple iterations, "mix" swimlanes for individual sound effects. These aren't "outcome" swimlanes, because I found that tracking an outcome becomes overly complex tracking subdependencies of the tasks of that outcome. At that point, Scrum becomes better at handling that complexity.

Which is why I always come back to "the best tool is the simplest that meets your need" - starting at Kanban is good, then you can add complexity. If that complexity starts to "outgrow" kanban (though it's a bit like comparing apples and oranges - it's not like scrum is just a more complex kanban, so I'm oversimplifying here) then you want to consider switching to another technique.

It's great that kanban has worked for all your projects and you haven't needed to use scrum!

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

#280

Post by monkpit »

emodendroket wrote: post #124
rightbyte wrote: post #98

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?

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.
Post reply on HN