Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it might be the most important thing. If developers and all the owners are not continually reviewing the items in the backlog together, clarifying them and making sure everybody understands what is being asked for and what the priorities are, breaking down stories that are too big, making sure that, yes, some tech debt gets in there, then all you've accomplished is a kind of mini-waterfall where stories get shoved to the top of the backlog by whoever comes last and then developers hammer away at them frantically at the beginning of each sprint.
> I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".
Scrum consistently fails because everybody thinks in terms of the "who" and the "how." Scrum books are all about the process, the daily meetings, the roles and the responsibility. This a symptom of a much larger issue here, the "technological paradigm" that pervades nearly all corporations. There's an unfailing obsession on organization charts, department boundaries, and processes.
It's all kinda silly.
As somebody who's managed too many scrum teams to remember here's the secret: don't focus on the "who" or the "how", focus on the "what." The what is all that matters. In Scrum there are certain key artifacts: stories, the backlog, the increment, blockers, and retrospectives. Relentless focus on the quality of these artifacts as documents and you will excel at Scrum. But you have to really care about the quality of these documents. Everybody, not just the scrum master, has to keep iterating over these document/artifacts until they are awesome. This means continually refining stories until people know them inside and out. Continually polishing the backlog until it shines. Making sure everybody understands exactly what will be delivered at the end of a sprint, the increment, and when it's delivered having people write feedback and rate the increment. It means investigating and documenting every single time a developer is blocked for more than 15 minutes and then making sure it never happens again.
I've worked with remote/distributed scrum teams and what I've found is that you can even throw out all the ceremony -- the daily stand-ups, the endless sprint review meetings, the endless retrospectives. When the team is distributed between London, Shanghai and Sydney and most of the developers work from home at oddish hours such meetings are impossible. But by focusing on the documents even such a distributed team can fly. So, yeah, at the end of the day this all boils down to effective communication and writing things down. Most knowledge games do.
I'm not sure if you are arguing against what you quoted from me (that I think a technical lead is neccesary, cause it is a "who"), but the reason I come to this conclusion from my experience is because technical decisions on the macro or medium level need to be decided on a fairly regular basis, and I do _not_ want continual endless consensus committee meetings hashing them over. Or a free-for-all with no coordination.
It is not only more efficient, but better for morale to have an agreed upon person upon whom the buck will stop. Sometimes when things are "everyones" responsibility they end up actually having nobody take responsibility for them. Such a person with ultimate responsibility and authority for technical decisions should be both competent and not an asshole, they should be in constant dialog and taking feedback from everyone else, and paying real attention to their concerns about technical matters.
But for the same reason you need a Product Owner (instead of just the amorphous group of all stakeholders) to ultimately take responsibility for decisions about priorities and acceptance criteria, you need a technical lead to ultimately take responsibility for technical decisions.
I think that "Scrum" doesn't have this is just part of it's attempt to commoditize developers (something I think is characteristic of "scrum" but not part "agile" generally or at it's best). "Scrum" sometimes seems as if it's designers thought there _are_ no technical decisions to be made, just a bunch of widget-ized, swappable developers churning out code to meet the requirements set by the PO. But, in fact, there are technical decisions to be made, that will effect other people's work and the product as a whole, in the short- and long-terms. Regularly.
Backlog grooming is a thing [1]. In fact, I'd say after the Increment, it might be the most important thing. If developers and all the owners are not continually reviewing the items in the backlog together, clarifying them and making sure everybody understands what is being asked for and what the priorities are, breaking down stories that are too big, making sure that, yes, some tech debt gets in there, then all you've accomplished is a kind of mini-waterfall where stories get shoved to the top of the backlog by whoever comes last and then developers hammer away at them frantically at the beginning of each sprint.
> I _do_ think the development team needs a "technical lead" in addition to product owner, not just an amorphous bunch of people "self-organizing".
Scrum consistently fails because everybody thinks in terms of the "who" and the "how." Scrum books are all about the process, the daily meetings, the roles and the responsibility. This a symptom of a much larger issue here, the "technological paradigm" that pervades nearly all corporations. There's an unfailing obsession on organization charts, department boundaries, and processes.
It's all kinda silly.
As somebody who's managed too many scrum teams to remember here's the secret: don't focus on the "who" or the "how", focus on the "what." The what is all that matters. In Scrum there are certain key artifacts: stories, the backlog, the increment, blockers, and retrospectives. Relentless focus on the quality of these artifacts as documents and you will excel at Scrum. But you have to really care about the quality of these documents. Everybody, not just the scrum master, has to keep iterating over these document/artifacts until they are awesome. This means continually refining stories until people know them inside and out. Continually polishing the backlog until it shines. Making sure everybody understands exactly what will be delivered at the end of a sprint, the increment, and when it's delivered having people write feedback and rate the increment. It means investigating and documenting every single time a developer is blocked for more than 15 minutes and then making sure it never happens again.
I've worked with remote/distributed scrum teams and what I've found is that you can even throw out all the ceremony -- the daily stand-ups, the endless sprint review meetings, the endless retrospectives. When the team is distributed between London, Shanghai and Sydney and most of the developers work from home at oddish hours such meetings are impossible. But by focusing on the documents even such a distributed team can fly. So, yeah, at the end of the day this all boils down to effective communication and writing things down. Most knowledge games do.
[1] https://www.agilealliance.org/glossary/backlog-grooming/