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

151–160 of 341 posts

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

#151

Post by DoingIsLearning »

josephg wrote: post #53
DanHulton wrote: post #3

Every team I've worked on that has switched from Kanban to Scrum has slowed down and never regained the previous velocity. Further, many of the promised benefits of Scrum (things like better insight and predictability about delivery rates) never materialized. Every team that I've worked on that has switched from Scrum to Kanban saw an immediate improvement in speed that never disappeared. Once, just once, I was lucky…

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 personal.

- Managers that have a 'clear roadblocks' mindset and have a service-providing mindset towards the team.

In this scenario you can really have high value retros, with continuous adjustments to workflow, processes, design, without continuously repeating the same mistakes or falling in the same pitfalls.

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

#152

Post by switch007 »

misja111 wrote: post #112

You don't need Kanban, you just need to do Scrum right. It seems most people who are complaining about Scrum, are really complaining about the lousy implementation of it in their company. Which tends to be the result of lousy management. With lousy management, any process will be a pain. Doing Kanban with a manager behind your desk asking why your feature is not ready yet isn't a pleasure either. There also seems to…

If we all had a dollar for every time we read “you just need to do scrum correctly”, HN would be full of millionaires.

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

#153

Post by seanhunter »

emodendroket wrote: post #136
nprateem wrote: post #135

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 scrum provided that it might have some value.

It’s extremely doubtful if you get even a roughly accurate estimate of effort within one project let alone relative effort across two.

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

#154

Post by kqr »

emodendroket wrote: post #136
nprateem wrote: post #135

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.

Meh. The time it takes to complete a project is usually somewhat flexible. What really matters is how valuable the project is. That is what needs to be estimated explicitly, and not just "I really like these two ideas lets do the cheaper one".

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

#156

Post by dragonwriter »

esafak wrote: post #77
1123581321 wrote: post #69

Earlier quoted context omitted.

Cycle time on a board gets you that as well.

This provides more visibility and granularity, increasing confidence and satisfaction of customers.

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-should-end and then new-work-items-should-start cycle around that; continuous flow makes more sense.

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

#157

Post by dzikimarian »

jdkoeck wrote: post #117
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…

No idea what you mean with outcomes vs means/tasks. Just put outcomes as cards in your Kanban board, they don’t have to be tasks.

That's often to big to be single card.

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

#158

Post by theshrike79 »

RamblingCTO wrote: post #119
theshrike79 wrote: post #75

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 But this will happen from time to time. People writing tickets or even devs when checking the tickets don't read the related code. So you have a big and important source of uncertainty. Some things are technically constrained.

That's what the backlog grooming and planning sessions are for. The devs who will be doing the work estimate the work.

If stuff looks really vague, do a "planning" or "discovery" task on the issue first, where you dig through and maybe even prototype what you need to do.

But yes, requirements can change during a spring, but it should be very very rare and not a regular event.

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

#159

Post by irjustin »

mongol wrote: post #142
irjustin wrote: post #116

Earlier quoted context omitted.

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…

Is that common? I thought it varied depending on the team, but usually that 1 pt is the shortest meaningful piece of work. Where I work now, 5 pt is not especially much. We have total story points delivered in a sprint around 120.

As mentioned, it's technically arbitrary, so you just need to get used to how your org does it. There's no right or wrong as long as your org agrees on the value of those points... sort of like bitcoin, ha ha (cries in BTC).

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

#160

Post by kqr »

danmaz74 wrote: post #127
kqr wrote: post #106

Earlier quoted context omitted.

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

We're saying the same thing. If we haven't built it (or something very like it) before, then we cannot possibly know exactly what it is we are building, because reality has a surprising amount of detail.
Post reply on HN