3 ms·

Imo the fundamental failure of Scrum as a planning methodology stems from the fact that it gives user requirements ('user stories') to developers and expects th

Imo the fundamental failure of Scrum as a planning methodology stems from the fact that it gives user requirements ('user stories') to developers and expects them to translate them to a technical implementation almost as an afterthought that's barely acknowledged in the framework. Most of us work on huge codebases with tons of baggage and hundreds or thousands of engineer-years invested into it. Implementing a feature into such codebase requires a combination of architecting, reading the code and experimenting - making the change is usually easy compared to that. Scrum has no proper way of handling these activities. - Figuring out how to do the feature is usually part of the 'planning' and 'grooming' activities which are 'invisible work' with timeboxed team meeting slots allocated to it, even though a well-thought out implementation can save tons of time - Just plunging in and doing it means that a large uncertainty exists as to how much effort said feature wil take. This can either lead to time overruns or padded estimates (or both) Scrum just doesnt' offer anything valuable imo. Its just feelgood management consulting ceremonies devs would rather do without. And I haven't even touched on the tyrannical micromanagement dark patterns it enables.

itronitron 2y ago
>> 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.
dsalfdslfdsa 2y ago
I've always wondered that - why the pathological aversion to "solutioning" in Scrum / Agile? Any solution is going to invovle compromise of some sort, it's daft to hand over the "user story" and pretend that it's all going to be ok.
- DragonMaus 2y ago
  In my experience at $OLDJOB, working under Scrum, there were two types of user stories that came in. The first would be issues from the QA team that absolutely had to be fixed. The other were commands from On High that absolutely had to be implemented. Not much room for compromise (from the story, at least) in either case.
cbsmith 2y ago
> Figuring out how to do the feature is usually part of the 'planning' and 'grooming' activities which are 'invisible work' with timeboxed team meeting slots allocated to it, even though a well-thought out implementation can save tons of time. Those time-boxed meetings aren't where you come up with the well-thought out implementation plan. They're where the work is prioritized, the well-thought out implementation plan is communicated with the team, and the work size is estimated. > Just plunging in and doing it means that a large uncertainty exists as to how much effort said feature wil take. This can either lead to time overruns or padded estimates (or both) At the start of a project where you're going something different from what you have done before (and with software, if you're not doing something different... why aren't you just using the software you've already written to do the job? ;-), and needs/circumstances change faster than you can complete projects anyway, so unless you can predict those changes (in which case, you have the wrong job ;-), even if the task was without any novelty, there is intrinsically a lot of uncertainty. Recognizing that the uncertainty is intrinsic, the agile approach to manage it is to break down the work into lots of smaller chunks with well defined checkpoints. This allows for many opportunities for course corrections in response to changing needs/circumstances and/or learnings about the size of the work. It's basically just a standard pid controller dealing with a noisy system. You're right though: another approach is to spend a great deal more time up front making a detailed estimate of the work... although that doesn't control for uncertainty about changing needs/circumstances, which will often change during the time you make your detailed estimate. ;-) There's also the matter then of estimating how much time it will take to estimate the work... since until that part is complete you would have increasing uncertainty. Now you can estimate how much effort the estimate will take to complete. That's a smaller task that will take less time to complete, so there's less uncertainty about changing needs/circumstances while you're coming up with an estimate of effort for the estimate. Also, if you estimate how much effort it will take for you to estimate the effort to make the estimate. Once you observe how far off the mark you are estimating how much effort it will take for you to estimate the effort to make the estimate, you'll have more information to calibrate your estimates with, so you can use that to have a more accurate estimate of the effort to make the estimate... Yup, it kind of ends up as the same thing.
mytailorisrich 2y ago
> Scrum has no proper way of handling these activities. That's not true. A high-level user story will indeed require investigation, architecting, perhaps experimentation. So create tasks for each step and add them to the backlog! The 'planning' part in Scrum is mostly planning the sprint, i.e. what the team is going to work on during the next incremental period based on the tasks in the backlog. This is very different from thinking about how designing a feature, which is an activity that should be treated as a task. Working in short "sprints" also helps in the investigation and architecting phases, because the format is aimed at forcing small, incremental progress when a potential common pitfall of investigation and architecting is spending a lot of time dreaming up something and writing extensive documentation, which will end up being useless or performing poorly in the real world [1]. But you can use "sprints" along perhaps modeling tools to split this into shorter architecting-experimentation-refining cyles. Again, the common issue here is the superficial, literal reading of Scrum without thinking of the deeper point, which is what matters. [1] Remember the Agile Manifesto's point about "working software over comprehensive documentation" because of that.
lenkite 2y ago
This is why any feature that is not simple should have a "Feature X Proposal" which is a task that is created in the planning. Development is only done in the subsequent sprints after "Feature X Proposal" has been completed, discussed and reviewed by the team.

itronitron 2y ago

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

dsalfdslfdsa 2y ago

I've always wondered that - why the pathological aversion to "solutioning" in Scrum / Agile? Any solution is going to invovle compromise of some sort, it's daft to hand over the "user story" and pretend that it's all going to be ok.

DragonMaus 2y ago
In my experience at $OLDJOB, working under Scrum, there were two types of user stories that came in. The first would be issues from the QA team that absolutely had to be fixed. The other were commands from On High that absolutely had to be implemented. Not much room for compromise (from the story, at least) in either case.

cbsmith 2y ago

> Figuring out how to do the feature is usually part of the 'planning' and 'grooming' activities which are 'invisible work' with timeboxed team meeting slots allocated to it, even though a well-thought out implementation can save tons of time. Those time-boxed meetings aren't where you come up with the well-thought out implementation plan. They're where the work is prioritized, the well-thought out implementation plan is communicated with the team, and the work size is estimated. > Just plunging in and doing it means that a large uncertainty exists as to how much effort said feature wil take. This can either lead to time overruns or padded estimates (or both) At the start of a project where you're going something different from what you have done before (and with software, if you're not doing something different... why aren't you just using the software you've already written to do the job? ;-), and needs/circumstances change faster than you can complete projects anyway, so unless you can predict those changes (in which case, you have the wrong job ;-), even if the task was without any novelty, there is intrinsically a lot of uncertainty. Recognizing that the uncertainty is intrinsic, the agile approach to manage it is to break down the work into lots of smaller chunks with well defined checkpoints. This allows for many opportunities for course corrections in response to changing needs/circumstances and/or learnings about the size of the work. It's basically just a standard pid controller dealing with a noisy system. You're right though: another approach is to spend a great deal more time up front making a detailed estimate of the work... although that doesn't control for uncertainty about changing needs/circumstances, which will often change during the time you make your detailed estimate. ;-) There's also the matter then of estimating how much time it will take to estimate the work... since until that part is complete you would have increasing uncertainty. Now you can estimate how much effort the estimate will take to complete. That's a smaller task that will take less time to complete, so there's less uncertainty about changing needs/circumstances while you're coming up with an estimate of effort for the estimate. Also, if you estimate how much effort it will take for you to estimate the effort to make the estimate. Once you observe how far off the mark you are estimating how much effort it will take for you to estimate the effort to make the estimate, you'll have more information to calibrate your estimates with, so you can use that to have a more accurate estimate of the effort to make the estimate... Yup, it kind of ends up as the same thing.

mytailorisrich 2y ago

> Scrum has no proper way of handling these activities. That's not true. A high-level user story will indeed require investigation, architecting, perhaps experimentation. So create tasks for each step and add them to the backlog! The 'planning' part in Scrum is mostly planning the sprint, i.e. what the team is going to work on during the next incremental period based on the tasks in the backlog. This is very different from thinking about how designing a feature, which is an activity that should be treated as a task. Working in short "sprints" also helps in the investigation and architecting phases, because the format is aimed at forcing small, incremental progress when a potential common pitfall of investigation and architecting is spending a lot of time dreaming up something and writing extensive documentation, which will end up being useless or performing poorly in the real world [1]. But you can use "sprints" along perhaps modeling tools to split this into shorter architecting-experimentation-refining cyles. Again, the common issue here is the superficial, literal reading of Scrum without thinking of the deeper point, which is what matters. [1] Remember the Agile Manifesto's point about "working software over comprehensive documentation" because of that.

lenkite 2y ago

This is why any feature that is not simple should have a "Feature X Proposal" which is a task that is created in the planning. Development is only done in the subsequent sprints after "Feature X Proposal" has been completed, discussed and reviewed by the team.