Live data from Hacker News

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

lucasfcosta.com

241–250 of 341 posts

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

#241
post #205

Earlier quoted context omitted.

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…

You make it all sound like a factory and blame developers for going rogue. That’s not how it works. It’s as though developers are dumb and can only execute if you tell them to do exactly as needed. Rather where’s the leadership and direction? Perhaps that’s not clear or the developers don’t even agree with what’s going on. You statement is so 1-sided. If someone is not performing you shouldn’t need scrum to work that…

It's not about blame. Developers are paid to develop. They're not paid to care about the interlocking parts, so many of them don't. It's not an indictment. It's just what it is. They have a different set of skills.

> Rather where’s the leadership and direction?

We're right here, implementing scrum for the reasons I listed.

> If someone is not performing you shouldn’t need scrum to work that out otherwise you have bigger problems.

I have found that poor performance is often not because an employee is "bad." It's because the team dynamic is not working. Maybe their skills are poorly utilised. Maybe the team isn't make accommodations for their neurodivergence. Maybe they don't understand how to integrate well into the team. Maybe they don't feel confident to bother the senior devs, and maybe the senior devs have told them to fuck off. I've seen all of this and more.

> I’d argue alignment is useless as most of the time developers are told to implement useless features.

Sure, there's no point in any of the work you do if you're being told to develop things that no one wants. My baseline assumption here is that the business has need of your work. If it doesn't, you should brush up no your CV.

> So what would you prefer? Developers without scrum delivering in 4 months or with scrum and taking a year?

If the four months gives me something no one wants, I'll take the year.

> The problems aren’t accountability or alignment. If people aren’t following a plan, that is if there is 1 then it’s a leadership problem.

That's the whole discussion: how best to follow the plan. I don't think it's as easy as criticising developers for "not following the plan" if we don't provide a strong foundation in which to do so. Cue scrum.

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

#242

The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically

I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.

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

#243

Earlier quoted context omitted.

> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected deliv…

> We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture. Now where have I heard that before? Ahh yes, at this little website: https://agilemanifesto.org/ My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push ba…

Great point. We should do a better job of delineating scrum from agile.

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

#244
post #232

Earlier quoted context omitted.

I don't see retrospectives being that much of a time-sink, it's a 30min/1hr meeting every 2 weeks. Even when I was on a kanban team they still had a fortnightly retrospective, it's useful to have a checkup occasionally.

Every time someone hates Scrum they always complain about 2 week sprints, which are an insane choice (should be 4 weeks), that shows they aren't doing Scrum, they are micromanaging with "Scrum" as the excuse.

Yes, I don't know where the 2 week sprint thing came from, but everyone uses it as a default. I've tried to get it to 3 or 4 weeks but always get resistance. The main reason I think is the business wants their features NOW.

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

#245
post #228

Earlier quoted context omitted.

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

> I mean, what are you exactly talking about here? Because developers do criticise 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. It's not just communication which is needed. It's effective communication. For example, criticism without structure and consideration comes across as…

> 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 feedback are code review and retrospective. Its tools for teaching are code review, demos and planning sessions. 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. And with public feedback, it provides zero guidance on how to do it anyway.

Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.

> The catch is that changes should be agreed by all, rather than one member going rogue. "Rockstars" hate scrum.

Neither of these is true. Scrum is inflexible and the moment you change the process, you are not doing scrum and you will be forced to go back to scrum. Second, you will need to specify what you mean by rock starts. If you mean toxic personalities, they do well in scrum. If you like to control other people, scrum provides quite a lot of opportunity for that.

What it does not provide is opportunity of people to use full extend of their capabilities. People who are able to perform well and able to get along with others, you will definitely do better in processes that allows you to perform and get along with others. If rocks start here means a positive, a capable non toxic person with good social skills, yeah, those tend not to like scrum.

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

#246

The underlying triangle here: Out of time, scope, and quality, you can pick two to specify but you can't constrain all three. Scrum specifies fixed time and quality ("definition of done"), with scope as the flexible variable, as tasks get pushed out of each sprint. Kanban specifies fixed scope and quality, letting time be the floating factor for each task. Waterfall specifies fixed time and scope, with the inevitable…

I've always understood the triangle to be cost, time, scope. Quality should not be mutable.

https://www.projectmanager.com/blog/triple-constraint-projec...

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

#247
post #186

Earlier quoted context omitted.

...for anyone who already knows that waterfall isn't iterative

Can I start a waterfall every two weeks?

Yes, a professor I had called it "cinnamon bun," and it's been a thing since at least the early 90s. Waterfall doesn't have to be end-to-end.

In my experience it's better to have more than a 2 week cycle though. I've seen it at 3 months and 6 months, both worked fine. Even if waterfall is end-to-end, it should still be broken up into phases for sanity checks.

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

#248
post #50

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 did scrum once and we were literally always sprinting. The daily standup consisted of trying to think of excuses why the multiweek task wasn't completed (like they expected) and one dude who "zereo'd his inbox" every day.

who is "they" here?

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

#249

Earlier quoted context omitted.

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?

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.

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

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

I think you where sold on "scrum is all you need"lie.

Kanban isn't there to dictate process, but as a tool to correctly and truthfully inspect your process.

E.g. we recently used length of UAT column to prove that we need more business people doing testing in next few weeks as we close to feature release and more tests take form of exploratory testing.

Scrum isn't blind to benefits of such inspections either! So doing simplified Kanban board is frequent.

Post reply on HN