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

321–330 of 341 posts

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

#321

Post by tharkun__ »

alfons_foobar wrote: post #209
robertlagrant wrote: post #120

Earlier quoted context omitted.

I think I'd pick any team, not just software, telling me when something will exist over them saying they're more efficient. Efficient isn't even a metric I'd understand in most cases, e.g. a plumber telling me the house will be done as efficiently as possible but I won't know when any particular room will be unavailable so I can't plan around that info.

But isn't the problem exactly that, that oftentimes we cannot know in advance how long it will take to implement X?

I think your parent is trying to say that you won't hire the plumber that only tells you he will be efficient doing his job. But you will hire the plumber that tells you "if I don't find surprises behind the wall, this is a 2 hour job". And then he opens up the wall and finds old corroded iron piping he has to trace down to where it attaches to the main line and replace it all or else you won't get your new bathroom done at all.

And that job takes more than 2 hours. You could also have said "well if that's the case can you poke some exploratory holes in the drywall please so I can get a better estimate" (aka a "spike").

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

#322

Post by davemp »

emodendroket wrote: post #314
davemp wrote: post #310

Earlier quoted context omitted.

Maybe I don't see the relevance of your question then. Software developers are not negotiating fixed price contracts with their project managers every two weeks. Just how toxic such a situation would be should be obvious. Managers need to understand the context of the job and determine if they're satisfied with the productivity of their employees. Agile is a development process not a contract pricing strategy. If any…

They don’t have to hire you every two weeks but they are paying for you and do have to decide how to allocate your time and plan various projects with interlocking dependencies. How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? You are, in effect, still asking them to write you a blank check to accomplish something when they might want to change gears if a…

> How can they do that without even a rough idea of how many people it takes for how long to accomplish anything?

This is not exclusive to scrum.

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

#323

Post by irjustin »

emeraldd wrote: post #260
irjustin wrote: post #58

Earlier quoted context omitted.

> It creates the illusion of accountability while creating artificial touch points I'm surprised at the conclusion because this statement can be said of any framework. It's up to the people to actually make it accountable. Doesn't matter if it's Scrum/Kanban or another one. If your org treats accountability as "an illusion" then it's doomed to fail regardless. > The question in my mind then is if I haven't seen a sin…

> If your org treats accountability as "an illusion" then it's doomed to fail regardless. That was a reply to "...but for many the accountability of Scrum..." in the parent comment. There's an idea that Scrum creates accountability by making it possible to measure how well a team is meeting their commitments. It really doesn't. The metrics that Scrum exposes are little more than semi-random numbers. You're asked as a…

I understand better, thanks for the explanation.

To me, what you're looking for doesn't exist. Ignoring Scrum, the question is "how do we know our engineers are effective?"

You know Scrum's attempt to answer that. Regardless, no matter what methodology you pick - it's bad. But, you have to answer it. Otherwise engineering is a black box without a way to peer in.

I know many engineers would prefer it that way, but that's just not realistic.

In the end the whole thing has to be an agreement between people.

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

#324

Post by esafak »

jabradoodle wrote: post #301
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.

It would be amusing but I've never been told to wait until the next sprint when contacting customer support.

Customer support is one kind of a service. I was thinking of something like a platform team, which creates complex tooling for other teams. I don't know if you were just joking, but I thought I'd clarify.

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

#325

Post by emodendroket »

davemp wrote: post #322
emodendroket wrote: post #314

Earlier quoted context omitted.

They don’t have to hire you every two weeks but they are paying for you and do have to decide how to allocate your time and plan various projects with interlocking dependencies. How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? You are, in effect, still asking them to write you a blank check to accomplish something when they might want to change gears if a…

> How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? This is not exclusive to scrum.

If you go way back up in this thread the reason given for Scrum being bad is it features estimation, which is useless because it's inaccurate, so telling me that systems other than Scrum feature estimation is not a rebuttal.

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

#327

Post by midoridensha »

ResearchCode wrote: post #199
theshrike79 wrote: post #188

Earlier quoted context omitted.

Linux kernel is more like Kanban than an Agile project, you can't really compare it to a project with an actual client who pays money to receive features in a timeframe. Stuff gets done when it's done and the BFDLs decide when the feature gets into the actual kernel. Waterfall-style projects had 3 to 6 month timeframes of delivery and we all know how that goes. The result is always either out of date due to changing…

I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front adm…

In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structure seemed to work very well for the type of work we were doing.

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

#328

Post by jdkoeck »

klik99 wrote: post #279
jdkoeck wrote: post #237

Earlier quoted context omitted.

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

Thank you for explaining, and it’s great that Scrum is working for you and your team! However, I have to admit I still don’t get it. How is Scrum better at handling outcomes? Are you talking about the sprint goal rallying all the team around a specific outcome, within a specific time frame? I gotta admit I am very suspicious of this way of working because it gets unsustainable pretty quickly, but I would like you to elaborate if you have the time.

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

#329

Post by theshrike79 »

midoridensha wrote: post #327
ResearchCode wrote: post #199

Earlier quoted context omitted.

I don't see what use a "scrum master" is. That sounds like a small task for the software engineer or their real manager. There is nothing showing that heavy agile actually leads to features being developed earlier. In my experience it's the opposite as you build up heavy tech debt by micro-managing and optimizing for a 2 week return instead of the long term. Waterfall were 1 to 2 year projects with heavy up-front adm…

In my experience on a scrum team, the scrummaster was basically a coach. They helped deal with external issues as the other responder said, so the manager (team leader) didn't waste his time with that and could use his time dealing with team members and doing engineering work too. In my case, the scrummaster had this role for a bunch of parallel teams, not just one, so it was a full-time job for him. The org structur…

Yea, pretty often scrum masters are hired coaches that are let go when the team knows how to self-manage - or like you said - they coach multiple teams at the same time.

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

#330

Post by davemp »

emodendroket wrote: post #325
davemp wrote: post #322

Earlier quoted context omitted.

> How can they do that without even a rough idea of how many people it takes for how long to accomplish anything? This is not exclusive to scrum.

If you go way back up in this thread the reason given for Scrum being bad is it features estimation, which is useless because it's inaccurate, so telling me that systems other than Scrum feature estimation is not a rebuttal.

This is not really a discussion in good faith.

> the reason given for Scrum being bad is it features estimation

This seems like a strawman and not at all what I was picking up from further up the thread.

---

https://news.ycombinator.com/newsguidelines.html

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Post reply on HN