4 ms·

I have more faith in empowered teams at least for companies where software is not the main focus. For software companies, it makes sense to do more DevOps, how

I have more faith in empowered teams at least for companies where software is not the main focus. For software companies, it makes sense to do more DevOps, how much depends on the company. Scrum and all the events/meetings that go with it will certainly not be missed. That goes for SAFe as well.

brightball 4y ago
Most of the meetings for the SAFe process aren’t team oriented but collaboration oriented, to empower the team to work the way that’s best for them. Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc. The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth. When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.
sumtechguy 4y ago
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.)
MisterBastahrd 4y ago
SAFe has been nothing but a giant timesink for our company, but I guess our managers got certifications out of it. For our org, it added a day and a half of planning each 10 week period plus devs are now in roadmap meetings, which we never were in before. We haven't increased in productivity. At all. For our small dev staff, they've added over 1000 man-hours worth of meetings per year.
- krzyk 4y ago
  Same for ours. Fortunately for me, when I attended first PI planning (of 4 teams that have very slight interactions, and I do not care what they are doing and how, I care only that they give me APIs/deliverables) it was the last one. My manager doesn't insist on me (or any other dev/qa) to attend those.

brightball 4y ago

Most of the meetings for the SAFe process aren’t team oriented but collaboration oriented, to empower the team to work the way that’s best for them. Teams within SAFe can use any methodology that they want, scrum, kanban, lean, etc. The world outside of your dev team is what the other meetings are for: keeping business side informed of progress, checking in on cross team dependencies, deciding whether a change in plan needs to happen based on some unexpected problem, etc. That’s one of the reasons that SAFe insists on PI planning, it’s to consolidate as many meetings as possible into 2 days per quarter so they don’t invade every week as a back and forth. When the business side and dev side of the house are communicating and on the same page, there’s a lot less friction in the work relationship.

sumtechguy 4y ago

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

MisterBastahrd 4y ago

SAFe has been nothing but a giant timesink for our company, but I guess our managers got certifications out of it. For our org, it added a day and a half of planning each 10 week period plus devs are now in roadmap meetings, which we never were in before. We haven't increased in productivity. At all. For our small dev staff, they've added over 1000 man-hours worth of meetings per year.

krzyk 4y ago
Same for ours. Fortunately for me, when I attended first PI planning (of 4 teams that have very slight interactions, and I do not care what they are doing and how, I care only that they give me APIs/deliverables) it was the last one. My manager doesn't insist on me (or any other dev/qa) to attend those.