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

221–230 of 341 posts

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

#221

Post by watwut »

Double_a_92 wrote: post #131
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…

I've seen many people complain about reviews and retrospectives in those threads... But they don't seem like a bad thing to me. The problem is if the sprint is too short. But if the review and retro are done e.g. once every month or so, it can be a good way to see what the other teams have been doing and get an overall picture of your software. And the retro can be a good opportunity to talk about any problems that y…

I do not want to talk about these problems again and again and again. I would like to see some improvements.

First few times it works as a psychohygiene, but then it just becomes annoying. So teams stops talking about actual deep issues on those meetings and they are are creating an illusion of happiness.

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

#222

Post by watwut »

ethbr0 wrote: post #52
crazygringo wrote: post #27

Earlier quoted context omitted.

But velocity of code written is not the same as velocity of value delivered. In Scrum, estimation meetings usually result in follow-ups with stakeholders that can (and often do) radically change the stories themselves. Totally different code winds up getting delivered that increases actual value delivered, even if "lines of code written" slows. That's the whole point of agile, to deliver value rather than code.

The differences I've observed between successful-and-unsuccessful, Scrum-and-Kanban have been dominated by people over process (yes, I know). 1. Does the team have the right people, with the right skill sets, wearing the right hats? (e.g. BAs or PMs doing those actual jobs) 2. Does the team have self-motivated, high-performance people? I have yet to see any process that can overcome "No and no." Large tech org's knee…

Yeah, but scrum can overcome yes-yes by taking a bunch of skilled and motivated people and forcing them into an ineffective process. That is exactly what happened in my last team.

So those skilled and motivated people are estimating piecemeal tickets, too micromanaged to be able to fix actual issues they clearly see around them. It is forced helplessness You can't overcome bad process and scrum is a bad process.

Scrum advocates always end up blaming the people on team. Even if that exact same team was performant and scrum literally killed 70% of what was good in it.

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

#223

Post by rightbyte »

layer8 wrote: post #149
rightbyte wrote: post #132

Earlier quoted context omitted.

We are way way past "doing it right". It is agile that is at fault, not the average management on the average company. If the average manager and dev won't be able to do it, then it is a lousy process.

I agree about Scrum, but if you read the Agile Manifesto, Agile isn't Scrum.

It is too vague. Compare to the ten commandments. Half of them are repeating detailed versions of "don't mess with your neighbour" to make things clear.

The Agile manifesto should have been written in a similar style ...

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

#224

Post by theshrike79 »

IshKebab wrote: post #211
theshrike79 wrote: post #79

Earlier quoted context omitted.

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

Depends on what the "you" is here.

If the "you" is the team, go ahead. Add anything you want, as long as you deliver what you promised in the beginning of the sprint.

If the "you" is an external person asking for a "quick job", then the default answer is "talk to the scrum master" whose default answer will be "No.". Then they can start discussing if it is so urgent and important that it can't wait 1-10 business days for the next sprint and/or small enough not to disrupt other work.

The rules are there to protect the team. If the team is willing to take ad-hoc work, nothing in the agile rules says they can't do so. The point is that nobody outside of the team can force them to take on extra work mid-sprint and disrupt their planned work.

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

#225

Post by jaybrendansmith »

Gareth321 wrote: post #177
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…

As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at…

Great comment. If you are enforcing due dates, you are doing it wrong, and stacking up debt and creating bad quality. It's about transparency. As a developer I never loved transparency, because being imperfect, I would sometimes make mistakes. As a manager, I cannot see how anything can be done correctly without transparency. It's not about the developer, it's about the quality analyst, the dev/ops, the UX designer, the customer, the documentation, the salesperson, the stakeholder, the investor, the business analyst, the quality analyst, the configuration analyst, etc.

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

#226

Post by theshrike79 »

drvd wrote: post #208
theshrike79 wrote: post #194

Earlier quoted context omitted.

Yes, you need the protection. You shouldn't be protecting yourself because it takes time from your work. Or do you enjoy explaining how project priorities work at length for the fifth time in two weeks? Do you enjoy sales just "quickly popping by" your desk to request "a small tiny feature I promised the client we'll have done by end of week". This is why in Agile we have the Scrum Master who fields all requests like…

> Yes, you need the protection. You lost me there. This is the fundamental problem with Scrum; this type of paternalism where "programmer" is a synonym for "idiotic code monkey", borderline autistic who isn't capable of dealing with demand from the outside. And all programmers are the same, all organisations are the same and all type of development work is the same. Everywhere. If only we would be doing "Agile" right…

The protection in Scrum is "opt out". By default the process says that you're protected.

If the team feels that they don't need it or want it, they can drop it and just hang an "extra work and ad-hoc requests welcome" sign on their team area :)

Most teams I've worked with want to focus on the agreed work just among the team for the assigned sprint length and not have to deal with ad-hoc requests.

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

#227

Post by baby »

IshKebab wrote: post #212
baby wrote: post #21

Earlier quoted context omitted.

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

Could be much worse in practice. You could have retrospects every two weeks, daily standups, messages every day from your nontechnical manager asking you for estimate markers on each of the tasks, breaking down tasks further, renaming tasks they don’t understand but other engineers do, etc.

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

#228

Post by watwut »

Gareth321 wrote: post #177
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…

As a Product Owner I am biased, but sympathetic. The ceremonies and oversight certainly can slow down velocity. But there are many benefits, and they are not immediately apparent to developers. Alignment is so important, and it's rare that I've found a team not using scrum which is working harmoniously. In reality, some members of the team aren't pulling their weight and it's causing animosity. Or they're working at…

Franky, scrum teams I worked in were pretty much worst in all the points you list, except higher management feeling of control. Especially in alignment between developers point. The cooperation is never really good in scrum, it is sorta kinda passable at best. Interpersonal relationship are either horrible or passive to non existence.

> Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other.

I mean, what are you exactly talking about here? Because developers do criticize each other all the time, both in code review and outside of it. If they have trust, they talk plenty. If you do not see developers communicating, it is because of how you lead a process.

> Sometimes it's adapting to different ways of work, or neurological issues with a team member

Scrum is so inflexible, that it literally prevents accommodations for issues like this. And that is not even speaking about the fact literally this should be job of people management. This is literally what leaderships should do, because they have actual power to change the things.

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

#229

Post by _heimdall »

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?

Unless the contractor is willing to put in writing a "not to exceed" price, I've never put any faith in build estimates. I'd expect a professional to be able to give a rough estimate based on experience and scope, as well as clear communication as the project progresses. Rough estimate meaning accurate withing something like 20-30%, not a detailed breakdown by ever project and material expense.

I try to do the same in software projects. Estimating projects by hours is impossible, fibonnaci numbers are a meaningless abstraction, and spending time each sprint to discuss how it went, what the next sprint plan is and estimate every task is a waste of time.

What I can say is whether a task looks like something that could be done in an afternoon, a few days, a few weeks, or multiple months. Accuracy there comes with experience, but no one gets better by chopping the calendar year into 2 week intervals and pouring a ton of process all over it.

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

#230

Post by hgsgm »

fendy3002 wrote: post #91
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 problem is even scrum doesn't give the predictability and observability better than kanban. It's extremely hard to predict what we need to do in next 2 weeks and what we can achieve in next 2 weeks. At my current company, half, if not more, of the tickets come in mid-sprint. So even though the current company is using scrum, in my team I treat it as kanban with story point limited, meaning I start with a certain…

Scrum is t really designed for an ops team. It's for product dev teams that need to organize and plan their work.
Post reply on HN