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

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

#301

Post by jabradoodle » Mon, May 08, 2023, 5:45 PM UTC

esafak wrote: post #59

Tagbert wrote: post #54

Earlier quoted context omitted.

I’ve always considered Kanban’s lack of sprints to be well suited to service teams where individual requests are not naturally tied to each other and there is no benefit of delaying delivery into sprints.

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.

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

#302

Post by ResearchCode » Mon, May 08, 2023, 6:03 PM UTC

emodendroket wrote: post #292

ResearchCode wrote: post #147

Earlier quoted context omitted.

Would you hire a mathematician that doesn't "story point" conjectures? Yes. Would you hire one that does?

I find this analogy harder to understand. What am I hiring the mathematician to do in this example?

Research mathematics.

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

#303

Post by emodendroket » Mon, May 08, 2023, 6:19 PM UTC

ResearchCode wrote: post #302

emodendroket wrote: post #292

Earlier quoted context omitted.

I find this analogy harder to understand. What am I hiring the mathematician to do in this example?

Research mathematics.

Do you get paid to do research or is there a deliverable at the end?

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

#304

Post by emodendroket » Mon, May 08, 2023, 6:19 PM UTC

flappyeagle wrote: post #296

emodendroket wrote: post #249

Earlier quoted context omitted.

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.

Research. We’re researching cures to cancer, nuclear fusion, space flight, etc. with no idea what the total cost of ownership will be. Software dev can resemble research on a smaller scale. The more interesting or complex your requirements and environment, the closer it resembles research. The original point of agile was to lean into this fact and get out of planning and predicting. Scrum culture has corrupted this g…

Yeah it turns out if your object is having working software to use to make money you’re not that interested in the mysteries of theory.

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

#305

Post by azangru » Mon, May 08, 2023, 6:34 PM UTC

shuntress wrote: post #285

azangru wrote: post #278

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

What you say is completely true for a spherical team floating in a frictionless void. The reality is that it is quite difficult to break products down into separate features then work on those features separately and in order. Because of this, it's very easy for planning meetings to accidentally become "What did we work on last week? Will this still be done on time ?"

So. The article is comparing Kanban done right with Scrum done wrong. That doesn't seem fair.

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

#306

Post by robertlagrant » Mon, May 08, 2023, 6:34 PM UTC

re-thc wrote: post #201

robertlagrant wrote: post #148

Earlier quoted context omitted.

> business also needs to accept that there are limits to the amount of predictability you can achieve in software development Scrum is based around this idea, so adopting it (or adopting it better) should be a sign they understand it. If they start saying "oh points are basically time" then you're probably in trouble.

It’s sadly mostly a sign that they don’t understand it. Most scrum these days is bastardized.

But it has made the PA Consultings of this world a lot of money doing "agile transformations".

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

#307

Post by kqr » Mon, May 08, 2023, 6:52 PM UTC

emodendroket wrote: post #293

kqr wrote: post #270

Earlier quoted context omitted.

Value meaning roughly revenue, not profit.

But estimating revenue is just as much of a shot in the dark as estimating effort, and if the effort is great enough it will cancel out the revenue.

The variation in effort is orders of magnitude smaller than that in value. Great value is very rarely canceled out by high effort and low value almost always cancel out low effort.

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

#308

Post by AtNightWeCode » Mon, May 08, 2023, 7:15 PM UTC

Some benefits of Scrum over Kanban: * Scrum is less flexible. It is easier to force everybody into a fixed process. Kanban can easily become cowboy development especially with junior devs on the team. * Scrum comes with clear short term goals. Kanban may hide the important milestones.

With that said. I think the drawbacks of scrum are just too many. It is inflexible. You have to sit in meetings to solve Scrum-problems instead of real problems.

Retrospectives are just magic though when you work with people that are great at agile software development. Ad hoc talks during daily work can never replace that. The velocity one can achieve by constantly improving and challenging the software developing process during dedicated sessions is just ridiculous. But it also have to do with having the right people. 2 hours of people whining about test environments will not accomplish anything.

Edit: Btw, problems with test environments is usually down to poor architecture and hard to solve. Design for testing too...

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

#309

Post by 1123581321 » Mon, May 08, 2023, 7:24 PM UTC

esafak wrote: post #267

DangitBobby wrote: post #92

Earlier quoted context omitted.

How? How is pulling 10 points of work into every two week sprint "more visible" or "granular" than pulling anything as it comes up at a velocity of 5 points per week? I'm not even being contrarian, I truly don't understand how sprints could be better than knocking down a work queue.

Scrum informs the customer that their ticket will be processed in the next sprint or not. It gives visibility into the future. A Kanban backlog, which is unordered, only tells them if their ticket is being worked on now.

Putting a ticket into a sprint is the same as putting it into a queued stage of kanban for purposes of reporting, although the reported number will differ (“this sprint” vs mean cycle time with percentile bounds.) Both methods can have unordered backlogs where something can sit indefinitely.

(Many orgs are understandably nervous to automatically report a simple number as an estimate; in those cases, you could translate cycle time into a date range estimate so long as you’re not also expected to report “we’ve started” etc. since those won’t necessarily line up.)

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

#310

Post by davemp » Mon, May 08, 2023, 7:26 PM UTC

emodendroket wrote: post #290

davemp wrote: post #274

Earlier quoted context omitted.

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.

Even to the extent that is true it doesn’t change my argument at all.

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 anything proponents of "Agile" would be more hesitant to quote you a firm fixed price contract than "Waterfall" teams.