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

171–180 of 341 posts

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

#171

Post by pg_1234 »

vikingerik wrote: post #85

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…

Actually the most effective strategy I've seen is Kanban, but with a fixed release deadline. Inevitably there are some essential tickets and some nice-to-have tickets. For the nice-to-haves it's a case of progress or die.

Think of it as time constrained Kanban with semi-fixed scope. The dropped tickets may carry over to a later release (if there is one), or just die forever (make it easy to cull bullshit).

P.S. From this perspective, the first thing to die is the time wasting sprint rituals that Scrum layers on top of Kanban.

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

#173

Post by cauliflower99 »

Kanban and scrum are solving different problems. Kanban focuses on the flow of work through the team. Scrum is a framework with the bare essentials to deliver value to the customer. Most scrum teams use kanban to control the flow of work through their team. They're separate processes.

What the article is saying is that bad scrum is much worse than no scrum - which is so so true. But good scrum is waaaay better than no scrum. Combine it with effective Kanban (eg. controlling WIP) and you're on your way to a very productive team.

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

#174

Post by jrockway »

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…

Is Scrum supposed to increase velocity? I always view these processes as a consistency enhancer. "What can we accurately promise 6 months out" vs. "how can we get the most done possible?" This is important because the big risk is that you do 80% of 10 projects, rather than 100% of 1 project, especially if you have a team and not just a couple of individuals.

Lots of stuff pushes organizations in the direction of doing 80% of 10 separate projects, and it's a killer. This is good reading in this domain: https://apenwarr.ca/log/20171213

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

#175

Post by gedy »

robertlagrant wrote: post #145
throw3823423 wrote: post #100

Earlier quoted context omitted.

I have seen a very predictable scrum, but the tradeoffs with productivity were comical. In this very large corporation, most developers could do most of the tasks in their 2 week sprints in 3 days of actual work. But they don't know if they are going to get 3 days of actual work, or some other team is going to keep master broken for a week. Therefore, your typical sprint involves mostly fictional standup updates, as…

SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.

These type of problems usually are not "actionable" with big legacy apps, poor coverage, etc.

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

#176

Post by Jochim »

darreninthenet wrote: post #134
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…

This is just doing scrum badly... management break it by insisting the metrics etc are used as a reporting mechanism, they just cannot get away from "intensive control mode". The metrics are supposed to be for the team to use internally. But I do agree with the post - Kanban is way way better and you can include the scrum continuous improvement elements as well on a regular cycle.

> The metrics are supposed to be for the team to use internally.

You've already pointed out that this is basically unheard of but I'm struggling to think of situations where scrum metrics have provided benefits that outweighed the cost of taking, and exposing them.

My experience has been that most development teams intuitively recognise problems that might be revealed by these metrics. Is this not often the case?

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

#177

Post by Gareth321 »

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 odds and not communicating the pieces they're developing. A huge one for me is stakeholder alignment. Without scrum it's awfully common for developers to build things the stakeholder doesn't want. Scrum forces regular check-in and demonstration which otherwise rarely happens organically.

A big part of scrum is accountability. As I touched on, when people aren't pulling their weight, it hurts everyone. Unfortunately developers are rarely extroverts, and they often don't have the skills or desire to have tough conversations with each other. Sometimes it's just agreeing on what they find acceptable behaviour and work. Sometimes it's adapting to different ways of work, or neurological issues with a team member. You might be surprised to learn that a lot of developers are on the spectrum. Scrum forces these conversations to the fore and provides a tested framework for conflict resolution.

We also gain transparency. This is really important so that all the other supporting business functions can operate. Sales can communicate with customers about important updates and new features. Marketing can plan campaigns. Support can prepare. Finance can ensure adequate budget for new infrastructure and FTEs. Sure it's annoying, but this planning is essential for a business. It just doesn't happen organically. Scrum forces developers to work to some kind of schedule, offering short-term (but flexible) estimates on what can be delivered, when.

In a perfect world, none of this is a problem, and all of it happens organically. I've just never seen that happen. The sacrifice in velocity is worth the increase in value output to the stakeholders.

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

#178

Post by ResearchCode »

theshrike79 wrote: post #79
TobyTheDog123 wrote: post #12

Earlier quoted context omitted.

I also don't fully understand what "doing Kanban" means - like you, I see Kanban as a type of board rather than a method of going through said board (maybe because of a lack of understanding of process & an over-indulgence in Trello's marketing). That being said, I would say that having a Kanban board without any sprint structure (or any attached micromeetings) would skyrocket my productivity. The two-week sprint thi…

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

Why do you need a "scrum master" to prevent that? Linux kernel seems to be doing just fine without them.

The real solution is of course not to have any "sprints" at all. A manageable chunk of work is a 3 to 6 month project.

Non-tech enterprise treat software engineers as children and create bad software. FAANG and adjacent companies treat software engineers more as professionals and create better software.

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

#179

Post by lucumo »

DoingIsLearning wrote: post #151
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 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 perso…

I found that retros tend to devolve into gripe sessions when the team isn't able to change its environment. Best to keep them focused on things they can actually change, and just to let them fix what they need instead of talking about it.

Also, after an initial stabilisation period, teams need fewer and fewer changes. Talking about it every sprint gets really pointless and takes time away from the things they're good at and they're motivated to do.

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

#180

Post by robertlagrant »

gedy wrote: post #175
robertlagrant wrote: post #145

Earlier quoted context omitted.

SAfE is definitely a bad idea, but keeping master broken should be a "automated tests guard master" retro action.

These type of problems usually are not "actionable" with big legacy apps, poor coverage, etc.

Someone who's not a technical junior needs to make it very clear that breakages will keep happening and support staff will need increasing if no one has the time to figure out a test harness or similar for the software in question. If people are literally blocked because someone else has broken master then they should be working on a test harness right now, in fact. That would actually be useful.
Post reply on HN