4 ms·

> When your work is done it’s done Have you ever worked on open source? Getting code accepted upstream is not somebody else's work. It usually involves signifi

> When your work is done it’s done 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.

jnwatson 9y ago
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.
ebbv 9y ago
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.
- notacoward 9y ago
  > it’s a poor craftsman who blames his tools 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.
  - ebbv 9y ago
    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.
    - notacoward 9y ago
      > 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?

jnwatson 9y ago

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.

ebbv 9y ago

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.

notacoward 9y ago
> it’s a poor craftsman who blames his tools 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.
- ebbv 9y ago
  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.
  - notacoward 9y ago
    > 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?