3 ms·

scrum works great when it is about the teams getting things done and not letting things fall through the cracks. It fails quick when it becomes about scrum pro

scrum works great when it is about the teams getting things done and not letting things fall through the cracks. It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly.

Silhouette 4y ago
It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly. If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.
- mgkimsal 4y ago
  > What specific, immediate, measurable benefit is that extra field going to provide? As more people turn to automation, I've seen people triggering actions based on field values or changes. And... the ever popular "reporting". It won't have an immediate benefit to you to have another 3 fields, but someone else can measure and chart and report some other set of data points because of those 3 fields. Usually there's not any real actionable benefits to come from that info, but you won't know for 3-6 months until you have a baseline then some comparison data, and by then - who wants to remove those fields?
  - Silhouette 4y ago
    So no demonstrable advantage or actionable information then? (This whole thread is - I hope - obviously /s. But the point behind it is real and serious. Far too often things like improving tooling or refactoring messy code at the end of a project that is now "working" don't get the time they should because bad management fails to realise that not everything is about immediate results. Meanwhile the same bad management has no problem steadily growing their own tools and processes - and using up ever more of their technical team's available time as a result - when there may be little or no demonstrable advantage to the business from doing so. Scrum is a textbook example of this problem.)

Silhouette 4y ago

It fails quick when it becomes about scrum process and making sure the 3000 fields in Jira are filled out correctly and making sure every processes is done correctly. If management types had to go through the same process to add each field to a task or each step to a process in their tools that they expect their teams to go through to get any real development done the world would probably be a much more efficient place. What specific, immediate, measurable benefit is that extra field going to provide? How important is it compared to the other ones you suggested last month? How much effort will it require for the team to fill it in (measured in arbitrary units that everyone on the team can dispute subjectively)? How will you monitor the performance of the team in using the new field? We can have a retrospective in a couple of weeks scheduled right in the middle of the afternoon when you need to take a call with a potential huge customer to discuss the new field and then if it's not working very well we can ignore that meeting and not change anything anyway.

mgkimsal 4y ago
> What specific, immediate, measurable benefit is that extra field going to provide? As more people turn to automation, I've seen people triggering actions based on field values or changes. And... the ever popular "reporting". It won't have an immediate benefit to you to have another 3 fields, but someone else can measure and chart and report some other set of data points because of those 3 fields. Usually there's not any real actionable benefits to come from that info, but you won't know for 3-6 months until you have a baseline then some comparison data, and by then - who wants to remove those fields?
- Silhouette 4y ago
  So no demonstrable advantage or actionable information then? (This whole thread is - I hope - obviously /s. But the point behind it is real and serious. Far too often things like improving tooling or refactoring messy code at the end of a project that is now "working" don't get the time they should because bad management fails to realise that not everything is about immediate results. Meanwhile the same bad management has no problem steadily growing their own tools and processes - and using up ever more of their technical team's available time as a result - when there may be little or no demonstrable advantage to the business from doing so. Scrum is a textbook example of this problem.)