38 ms·

>> a well-thought out implementation can save tons of time I think there is a bias for many developers to feel like they are not doing anything unless their ac

>> a well-thought out implementation can save tons of time I think there is a bias for many developers to feel like they are not doing anything unless their actively producing/editing code. Once I realized that I could just state in a standup that I was 'investigating' and 'researching' the best approach to XYZ then I felt a lot less resistance to the process.

lupusreal 2y ago
Almost all standups I've been in have abused the "investigating loophole" egregiously. There is only investigation and completion. Day 1 through N: "I'm investigating X" Day N+1: "I checked in X and am now investigating Y"
- Arnt 2y ago
  I've worked somewhere where that would be like this... Days 1-N: Investigating. N+1: "I've made a WIP PR, who's free to look at it with me?". N+2 would often be "we've merged" but it could go differently. The whole process made a lot of sense to me. I like Scrum.
torginus 2y ago
You can tell that, but if you are 'researching' during the implementation phase, how the hell did you give an estimate on the task? I'm not blaming you, I'm just pointing out Scrum is ridiculous
- mytailorisrich 2y ago
  If your high level story is to "implement a button that cancels the order when cliked", for instance, then this can be broken down into several taks, the first of which may be about reasearch and investigation. Even during the implementation phase you might hit an unexpected issue that will need to be investigated and researched. If you're trying to fix a bug then investigation and research may be the bulk of your time. The point is that tasks/tickets/stories and what you're spending your time on don't have to be only about typing code and it's perfectly normal to report as such. Regarding estimates, the issue in the real world is that estimates on incomplete data very often end up as commitments when told to project management. This is quite orthogonal with Scrum and is part and parcel of working on any project.
- Fire-Dragon-DoL 2y ago
  You could do the reverse, timeboxing it. Goal being to avoid spending excessive time on the task. Having a well defined amount of time for a research task makes sense, the business decides how much they want to spend. I'm against estimating every task, but I definitely provide a ballpark idea when a project will be delivered. Keeping a research task in check is important for myself too, otherwise I can go on for weeks.

lupusreal 2y ago

Almost all standups I've been in have abused the "investigating loophole" egregiously. There is only investigation and completion. Day 1 through N: "I'm investigating X" Day N+1: "I checked in X and am now investigating Y"

Arnt 2y ago
I've worked somewhere where that would be like this... Days 1-N: Investigating. N+1: "I've made a WIP PR, who's free to look at it with me?". N+2 would often be "we've merged" but it could go differently. The whole process made a lot of sense to me. I like Scrum.

torginus 2y ago

You can tell that, but if you are 'researching' during the implementation phase, how the hell did you give an estimate on the task? I'm not blaming you, I'm just pointing out Scrum is ridiculous

mytailorisrich 2y ago
If your high level story is to "implement a button that cancels the order when cliked", for instance, then this can be broken down into several taks, the first of which may be about reasearch and investigation. Even during the implementation phase you might hit an unexpected issue that will need to be investigated and researched. If you're trying to fix a bug then investigation and research may be the bulk of your time. The point is that tasks/tickets/stories and what you're spending your time on don't have to be only about typing code and it's perfectly normal to report as such. Regarding estimates, the issue in the real world is that estimates on incomplete data very often end up as commitments when told to project management. This is quite orthogonal with Scrum and is part and parcel of working on any project.
Fire-Dragon-DoL 2y ago
You could do the reverse, timeboxing it. Goal being to avoid spending excessive time on the task. Having a well defined amount of time for a research task makes sense, the business decides how much they want to spend. I'm against estimating every task, but I definitely provide a ballpark idea when a project will be delivered. Keeping a research task in check is important for myself too, otherwise I can go on for weeks.