5 ms·

The difference is that Kanban won't require a million useless meetings and will actually help you plan and get stuff done.

ruzig 2y ago
If you Scrum correctly, the daily standup should be quick and rewarding. The planning for a sprint should be done carefully at least 1 sprint before.
- CRConrad 2y ago
  But unfortunately nobody can "Scrum correctly".
antupis 2y ago
Scrum is good in those cases where it was created so zero trust environment (consulting, horrible PM, etc) and when you have multiple stakeholders. Usually prefer kanban but sometimes you need a pretty rigid process.
zuppy 2y ago
you don't have to have a million useless meeting, most of the things can be prepared before and it won't waste the time of everyone. from a developer perspective, sure, kanban is the king, nobody bugs you... but on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc. also, sprints help you avoid keeping unreleased code, which has a very high cost. i would add that you should pick one or another depending of your type of business. for example, we use scrum, but before black friday we partially switch to kanban because we don't know all we have to do in advance (there's much more to do than we can), we just know the resources available and we need do switch/move/reprioritize faster. each has it's own strength.
- pydry 2y ago
  >on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. It isnt. Not really. It gives the illusion of predictability. Businesses do crave predictability but when a problem space is naturally chaotic it's unrealistic to assume that you're going to get it just by switching development methodologies.
- JasserInicide 2y ago
  on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc. Yeah you'd think after several decades of software development that curmudgeon-y developers would finally realize that writing software for a living is a team sport but nope, we're still having the same complaints of "wHy cAnT i JuSt WrItE cOdE iN PeAcE?" every time the discussion comes up. If you want to code with 0 distractions, do it on your own time.
  - sgarland 2y ago
    Zero distractions is a nice thought, but I’ll settle for fewer. My main issue with Scrum is that it’s designed to boil often complex tasks down into tiny pieces, such that anyone can pick them up and do them. The administrative and mental overhead with slicing tasks up (and holding meetings to do so) is significant, and frustrating. In a high-performing team where you have specialists, let people do what they’re good at. If someone doesn’t know Terraform, jumping into a complicated task involving it isn’t a great idea; instead, have them take on things they can do, and occasionally shadow the expert doing it to pick some knowledge up. I’m also a big believer in gating off chunks of your day explicitly for learning. Your manager has to be onboard with this obviously, but dedicating an hour to increase your knowledge pays dividends over time (now there are two TF experts, etc.)
    - steve1977 2y ago
Ensorceled 2y ago
The worst place I every worked as far as useless meetings went was a Kanban shop. You can do bad things with any process, just some make it easier to the the bad things.

ruzig 2y ago

If you Scrum correctly, the daily standup should be quick and rewarding. The planning for a sprint should be done carefully at least 1 sprint before.

CRConrad 2y ago
But unfortunately nobody can "Scrum correctly".

antupis 2y ago

Scrum is good in those cases where it was created so zero trust environment (consulting, horrible PM, etc) and when you have multiple stakeholders. Usually prefer kanban but sometimes you need a pretty rigid process.

zuppy 2y ago

you don't have to have a million useless meeting, most of the things can be prepared before and it won't waste the time of everyone. from a developer perspective, sure, kanban is the king, nobody bugs you... but on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc. also, sprints help you avoid keeping unreleased code, which has a very high cost. i would add that you should pick one or another depending of your type of business. for example, we use scrum, but before black friday we partially switch to kanban because we don't know all we have to do in advance (there's much more to do than we can), we just know the resources available and we need do switch/move/reprioritize faster. each has it's own strength.

pydry 2y ago
>on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. It isnt. Not really. It gives the illusion of predictability. Businesses do crave predictability but when a problem space is naturally chaotic it's unrealistic to assume that you're going to get it just by switching development methodologies.
JasserInicide 2y ago
on a business you need predictibility, and even more than that: predictibility across teams, for which sprint is better at. in a well run company, the managers are not the enemies of developers, they work together to make the entire process better. there are many teams involved in a project, not only development... think about legal, accounting, warehouses, etc. Yeah you'd think after several decades of software development that curmudgeon-y developers would finally realize that writing software for a living is a team sport but nope, we're still having the same complaints of "wHy cAnT i JuSt WrItE cOdE iN PeAcE?" every time the discussion comes up. If you want to code with 0 distractions, do it on your own time.
- sgarland 2y ago
  Zero distractions is a nice thought, but I’ll settle for fewer. My main issue with Scrum is that it’s designed to boil often complex tasks down into tiny pieces, such that anyone can pick them up and do them. The administrative and mental overhead with slicing tasks up (and holding meetings to do so) is significant, and frustrating. In a high-performing team where you have specialists, let people do what they’re good at. If someone doesn’t know Terraform, jumping into a complicated task involving it isn’t a great idea; instead, have them take on things they can do, and occasionally shadow the expert doing it to pick some knowledge up. I’m also a big believer in gating off chunks of your day explicitly for learning. Your manager has to be onboard with this obviously, but dedicating an hour to increase your knowledge pays dividends over time (now there are two TF experts, etc.)
  - steve1977 2y ago

Ensorceled 2y ago

The worst place I every worked as far as useless meetings went was a Kanban shop. You can do bad things with any process, just some make it easier to the the bad things.