4 ms·

I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation. A lot of the arguments being made are reall

I appreciate the article but I worry that Scrum implemented too rigidly is the reason why it gets a bad reputation. A lot of the arguments being made are really difficult to generalize and say "this works for every org!". One example: > When that happens, instead of designing features by committee, which demands a significant amount of back-and-forth discussions, decisions happen locally, and thus are easier to make. This works really well when the engineers themselves have all the knowledge+ability to tackle the problem. Smaller startups are perfect! and teams that are pure technical. But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback. The danger is trying to measure things purely on developer velocity. I'm not saying kanban is wrong or scrum is wrong, just do what's best for your org by building what's important to your business.

ajmurmann 3y ago
"This works really well when the engineers themselves have all the knowledge+ability to tackle the problem." This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.
colonwqbang 3y ago
> But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback. But how does Scrum help out here?
- irjustin 3y ago
  Scrum has prescriptive method of who is supposed to gather requirements, the meeting for requirements gathering, estimation for "understanding of requirements", and demo... well for demo'ing the feature back to "the powers that be". Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization. This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way". I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.

ajmurmann 3y ago

"This works really well when the engineers themselves have all the knowledge+ability to tackle the problem." This reminds me of a similar situation almost a decade ago where someone watched a talk on how GitHub uses GitHub to build GitHub. The people who watched the talk all tried to convince me that we should adopt similar process that puts less emphasis on PMs. However, this worked for GitHub because their engineers had such a strong similarity to their customer base. For us that wasn't the case at all and we typically needed PMs to have lots of customer conversations and explain to us how customers used our product because we were building Enterprise software for people whose day-to-day we didn't understand easily.

colonwqbang 3y ago

> But once a key portion of the requirements lives outside the team, this is no longer effective because then you're building without that feedback. But how does Scrum help out here?

irjustin 3y ago
Scrum has prescriptive method of who is supposed to gather requirements, the meeting for requirements gathering, estimation for "understanding of requirements", and demo... well for demo'ing the feature back to "the powers that be". Kanban doesn't prescribe any stakeholder methodology. It's not that it's not important, it's just up to the organization. This is definitely a point of contention in Scrum because "oh this is so slow", "there are too many stakeholders", "why do we have to do it this way". I'm at the belief - some way is better than no way. If you don't like Scrum, cool! Go build your own, but if you don't mind it, Scrum is good-enough^tm.