One under-appreciated shortcoming of Scrum is that it doesn't deal well with dependencies on other orgs that have their own schedules and probably don't use Scrum themselves. We ran into this at Red Hat, where the other org is an external open-source community. You do your work quickly like Scrum forces you to, submit the work upstream, where people not operating under Scrum's artificial time pressure ignore or reject it. Hardly surprising, since quick often means dirty. In any case, you have no control over how long it takes that process to complete, let alone when the new code gets into an upstream release so you can pull it back in. What always ends up happening is that developers have to take on more work in progress while code works its way through someone else's process. If it's done officially it's no longer really Scrum. If it's done unofficially it's still no longer really Scrum, and even worse the time spent shepherding patches upstream is invisible to the Scrum planning process.
Maybe Scrum works when you're a passive consumer of the frameworks, libraries, etc. that you use, with no expectation that any significant time will be spent contributing back. I don't know; I haven't worked in that kind of environment for a very long time. That only seems like a tiny segment of how real development gets done, though.
I don’t see this as really an issue. When your work is done it’s done. If it’s someone else’s work that needs to be done now before you can do something else, those should be separate issues/stories/tickets that are blocked until that external work happens.
In my mind it’s no different than waiting on a design or pricing sheet or API key or any other dependency that holds up work. Yeah you might have to context switch to something else for however long you are waiting but that’s what happens.
Also why the “do your work fast like SCRUM forces you too”? SCRUM doesn’t mean do your work shitty and fast. Maybe your organization wants it to but whether you prioritize speed or doing it the best you can or whatever is up to you, I don’t see that as part of SCRUM.
Have you ever worked on open source? Getting code accepted upstream is not somebody else's work. It usually involves significant ongoing effort by the author on top of what they did to implement and test the code in the first place. That work is usually very interrupt-driven too, responding to review comments etc. whenever someone upstream happens to wake up, and that makes it even worse. Your "separate issue" idea is exactly how Scrum fails to account for real work in progress when open source is involved.
I'm not exactly the biggest Scrum fan, but just a few weeks ago, I had this exact issue (we're dependent on getting fixes and changes accepted upstream), and it wasn't a big deal to fit it into the framework.
You can only get folks to commit stuff they have responsibility over. External dependencies are not really part of Scrum per se; they are part of the the larger project management part of managing every team.
We assigned an LOE task to me to shepherd/beg/nag my bits through. I (nor anyone else dealing with an outside party) couldn't commit to getting it done, but I can commit to helping it along.
If that work is non-development work like writing emails or getting in hangouts or Slack conversations or whatever then you’re right it doesn’t get tracked in SCRUM tickets/issues/stories (typically.) but that’s fine. Because it should be reflected in your velocity automatically by the reduced development work you can accomplish.
If it does result in development work; like your pull request results in revisions. You have choices about how to account for that. If you feel you have confidence about how much extra work that will add based on the issue you’re working on, you can account for that when pointing it. (Much like you’d account for writing tests or going through code review process within a team.)
If you have no handle on how much work it takes for whatever reason (contributing to multiple projects with wildly different expectations) then you can make new issues for each set of revisions. This will give you clear history that you can reference afterwards and learn from.
In any case; it’s a poor craftsman who blames his tools. SCRUM can work for all these situations if you want it to. If you have a defeatist attitude or if you prefer to blame systems and tools for your problems instead of finding solutions, you can do that too.
Let me be clear; I’m not saying SCRUM is for everyone or the best system or any of that. I’m just saying these specific claimed problems don’t hold water with me.
It's an even worse craftsman who persists in using the wrong tool. If the tool does a poor job or requires more maintenance than the work it saves - as would be the case if your suggestions were followed - then it should be abandoned in favor of another. Which is what we did. Solutions found, nothing defeatist about it, and I notice you didn't answer the question about whether you've actually tried to do this.
I have contributed to open source occasionally. It’s not a part of my job most of the time so it’s rare.
But it’s also not relevant at all. As I tried to spell out the situation you describe is not unique at all. It’s the same thing every software dev encounters.
I’m glad you found tools that work for you, but this exchange has been unpleasant so I’m done with you.
> It’s the same thing every software dev encounters
No, it really isn't. "Upstream first" development such as Red Hat does is fundamentally different than developing in private, even if that includes throwing the occasional scrap back over the fence.
If you think this exchange has been unpleasant, consider that casually dismissing others' experience rarely leads to any other outcome. Did you do your part to make it pleasant for anyone else?
Maybe Scrum works when you're a passive consumer of the frameworks, libraries, etc. that you use, with no expectation that any significant time will be spent contributing back. I don't know; I haven't worked in that kind of environment for a very long time. That only seems like a tiny segment of how real development gets done, though.