3 ms·

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, t

by ebbv 8y ago

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.

notacoward 8y ago
> 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 8y 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 8y 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 8y 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 8y 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.

by ebbv 8y ago

notacoward 8y ago

> 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 8y 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 8y 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 8y 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 8y 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.