Live data from Hacker News

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

lucasfcosta.com

251–260 of 341 posts

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

#251

Earlier quoted context omitted.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

You won't gain that understanding until you actually complete both of those projects. Industries and occupations that manage estimates well do so because bulk of the work is repeatable and predictable, and the people doing that work have done nearly identical kind of work before. There is some variability involved, but there's only so much of it, and it yields to tried and true classical project management techniques…

You’d think, but wildly inaccurate estimates are not rare at all (and many software projects are fairly routine themselves)

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

#252

I've heard over and over from managers that scrum is better at anticipating delivery dates. Even when the dates are consistently missed. They'd rather slow teams down with process so they can have a date to give their stakeholders, regardless of its accuracy.

You can calculate the team velocity pretty easily in Scrum (amount of story points completed per sprint) and from that you can estimate what gets done in what time. BUT it needs the exact same team to be together on the same codebase. You add or remove people, the velocity changes. You change projects, velocity changes. People also need to be honest when estimating tasks, don't be a 10x cowboy and say something is a…

In Kanban you multiply cycle time by tasks and do some modeling on that value. Only difference is that in SCRUM whole team does produce raw value upfront of work, while in Kanban manager computes raw value downward of work.

Raw value here refers to lack of statistical analysis.

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

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

Going longer than two weeks for a sprint just makes the lies happen at different place. There are approximately 0 teams that can accurately state all the work they will need to do four weeks in advance, even two is a stretch. Planning and retro per sprint become a burden though, on less than two week sprints.

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

#254
post #245

Earlier quoted context omitted.

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

> 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... Instead, scrum prevents effective, safe and compassionate communication. It provides rituals, that is it.

Sure, scrum is a team tool, not a personal development plan tool. The latter is best handled with one's manager. Note that I am not claiming scrum is an everything tool. It won't solve world hunger either. How on earth does scrum "prevent effective, safe, and compassionate communication"?? It just sounds like you're throwing accusations at the wall now to see what sticks.

It sounds like we've had vastly different experiences. I'm sorry to hear yours have been so unpleasant.

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

#255

Earlier quoted context omitted.

Genuine question: How does Scrum help with less predictable work? From my experience, the opposite is true: New things are discovered during sprints, but at that point it's already too late because that work item has already been estimated in the sprint planning (most of the time incorrectly). Also the arbitrary sprint deadlines don't help either.

When new information exposes issues with the current piece of work in a sprint, you discuss it, and then change whatever part of the plan no longer makes sense given the new information. Will it mess up the numbers? Absolutely, but only for that piece. And as a result of the change of plans being entered into the current sprint (with something perhaps bumped to make room, or maybe the work itself bumped to a later sp…

Have you tried to just track time on board / time on column on each task on Kanban board? You just need to keep track of time to trigger those discussions.

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

#256
post #52

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…

[deleted]

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

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

That's the whole trick with "doing Kanban". You don't need special magic methods to do your work- just pick up a ticket and do the work, repeat forever.

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

#258

Earlier quoted context omitted.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

If revenue they bring is estimated you may only need relative comparison. After all if dev team days that more perspective project is very likely cheaper to make, why would you choose the other one? See? No need for detailed answers if there is sufficient difference in qualities.

Relative comparison is exactly the scrum method which is why they don't estimate with time. And I don't think revenue estimation is any less subject to variance.

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

#259
post #154

Earlier quoted context omitted.

Surely an understanding of how much effort is needed to complete one project or another will inform their decisions of which to pursue.

Meh. The time it takes to complete a project is usually somewhat flexible. What really matters is how valuable the project is. That is what needs to be estimated explicitly, and not just "I really like these two ideas lets do the cheaper one".

How can you estimate "value" without any idea what resources are needed or what else you will have to forgo to pursue the project?

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

#260

Earlier quoted context omitted.

Scrum does not provide accountability. It creates the illusion of accountability while creating artificial touch points that effectively become the only time anyone thinks about what's going on. At least that's how I've seen it operate in almost every instance I've ever worked with it. Of course, the counter to that is that we're not doing scrum right. The question in my mind then is if I haven't seen a single team d…

> 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 team to "commit to completing" some mostly arbitrary total of these numbers that has been determined to be your teams "capacity".

The entire premise of this kind of estimation is fallacious on face. It completely ignores the skill level, overall capabilities, and specializations of your developers and effectively equates them to an common minimum of mediocrity. Worse, it pre-supposes that your team fully understands all of the places that a particular task can go sideways which is almost never the case.

About the only way I can see it working is a situation where you know exactly what needs to be done, step by step, from or near the very beginning of a project. Otherwise, all you're doing with Scrum is forcing the team to make decisions on a Sprinted cadence rather than at natural break points along the completion of a project. This creates artificial delays, particularly when other teams are also working on sprinted cadences because you're likely to be requesting things that won't make it into some other teams sprint. Creating at least a sprint long delay before your team can complete their work, and well, breaking your sprint goals, etc..

Sigh ... Hence the accountability and predictability that's supposed to come out of Scrum is illusory at best and usually self deception.

Post reply on HN