4 ms·

>The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall. It is incredibly rigid though. Very few people on my team f

>The biggest complaints that I see around SAFe are that it's too rigid and/or that it's waterfall. It is incredibly rigid though. Very few people on my team files defects; in fact in the last year we've probably had 4 maybe opened internally. This is in spite of the fact that there's constant complaints and identified problems and risks that we keep finding. The problem is that in filing a defect, we must go through the entire ceremony. The PO and SM must evaluate and prioritize, then gather the team so that more details can be filled, a Definition of Done written, acceptance criteria written, and the time estimates voted on. Along with the the fact that the defect requires two reviewers to read over and approve merges, and then an additional two reviewers to read over and approve the defect. It's more time and cost effective for us on the team to wait until either someone else finds it, or until it actually explodes, rather then going through the rituals of preventing the problem in the first place because we strictly follow good SAFe practices. During PI planning is when it really comes to a head; often times stories have to be tortured into either fitting into our mandates that no stories can be over estimated over 3 points. The mandates been a mixed bag; in some cases it sensible splits the feature into an investigative phase and an implementation phase. But other times we have to torture the story to the point where the split is meaningless or even detrimental to the delivery of the feature. Just a rough example; if we split the time boxed investigation, the implementation story is in the next sprint kept at the same story points even if it turns out we've drastically underestimated the work. It also perverse incentivizes just voting 3 points even if it's a slightly more complicated work because the team often doesn't want to deal with the headache of writing more stories, and pressure during PI planning to get it done. >Have you ever been in a scrum environment where the teams didn't have a clear path to coordinating? It's awful. It's still pretty bad. PI planning for us is 2 weeks of planning for a 12 week PI. 8 hour days of nothing but sitting in a virtual meeting room staring at someone write up stories and then voting on them (to be fair we've gotten it down to 2 weeks now by running some of the ART planning in parallel). And these stories are not easy to write; the current standing directive is that they need to be detailed enough so that anyone off the street, irregardless of level of skill or familiarity, can read the story and bring it to completion (which has led to some disagreements on how long it should take to write a story). Then voting on story points which in theory are supposed to be complexity but in reality are treated as 1 story point = 1x 8 man hours. The two week sprints in the PI starts with a 3 hour review meeting. During this time we also have to come up with sprint goals, often times an exercise that ends up with our SM instructing that he didn't care what goals were (which has about the effect one would expect; meaningless goals). Then we have another 3 hours planning where the PO reads off a chart that could've have sent prior to the customer as an email with an executive summary, followed by time spent by the SM calling out stories and then asking for volunteers. And then voluntelling if no one does. Each day is then set with a 15 minute scrum and then an additional hour standing review / second daily check in. So every day is at minimum 75 minutes of meetings per day. And the SAFe process really does encourage mediocrity if not idiocy (one of the biggest pushes for return to the office I've heard in fact is because SAFe requires face to face meetings. This was said by certified SAFe Professionals). >I'm a huge fan of SAFe because it's goal is to provide an environment where developers can thrive. Every time I see comments about SAFe and ask questions about it, I get responses like "they didn't do that in our SAFe implementation." I went through SAFe training. We have something around 15 or so certified SAFe Professionals. One of the things that really stuck with was this ridiculous sentence; that we have teams build ownership by letting them pick their own team name. Not by letting them decide architecture. Or somehow figuring out how to build trust between the SM/PO and the team. By letting them pick. A team name. And this was stated straight faced and completely seriously by a certified SAFe Professional with two other certified SAFe Professionals. Kind of gives you a hint of how we've implemented SAFe. All of the rituals followed, all of the ceremonies performed, but done in an air distrust between management and engineers. It's not that it's all bad; there's many pieces that makes sense but many more that don't and if the foundation is on the view from management that engineering is little different then factory work..... well, just look around this thread. I think you can see the result.

tbalsam 4y ago
Thank you for helping me recognize that the hellhole I'd previously worked in in my first software dev job out of college was a SAFe gig. I'd referred to it a lot as "weaponized agile" (which I believe it is), but somehow I hadn't connected the dots of my middle manager casually mentioning safe to the inane, almost preschooler level of sticker-award-insult that strips away developers abilities to, well, do what they've spent their career learning to do and instead "gives them the ability" to "pick their own team names (and we can name our epics in a theme! :") )" (insert gratuitous "yay"s, clapping, and suggestions of how fun it will be). This helps paint a lot of things in retrospect a lot more clearly. As you can see, I am still intensely salty about this experience many years later. >:')
brightball 4y ago
There are two things you're saying that simply don't align here: > we strictly follow good SAFe practices. and > PI planning for us is 2 weeks of planning for a 12 week PI This is a hellhole that in no way reflects good SAFe practices. PI Planning is 2 days. 2.5 if you're partially time shifted to accommodate teams in disparate time zones. There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment. Any label put on the process your describing is probably not fair, whether somebody called it SAFe or Scrum or Kanban or Lean or Extreme Programming or whatever else. This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe.
- throwaway93494 4y ago
  >This is a hellhole that in no way reflects good SAFe practices. PI Planning is 2 days. 2.5 if you're partially time shifted to accommodate teams in disparate time zones. Our PI planning consists of a combined demo session and Q&A, a combined I&A, then separate demos and I&A's for each of the ART's. That in of itself can take 1 to 2 days because of the number of demos that each ART has to include. Then 3 or 4 days of team breakouts for writing stories, a full day for draft plan review, then another 2 to 3 days ish days to take in feedback from the review and adjust the plans, then another day of final draft plans review. You can't fit that into two days. You can't even fit that into a week. But those those rituals are more core to SAFe Agile then an arbitrary time frame for PI Planning. So the 2 day limit had to be dropped to fit in the core principles of SAFe. So yes it does align and yes it follows good SAFe Practices. Didn't you yourself say that one shouldn't try to the organization into SAFe's structure? > There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment. Our sprints are loaded to 50% to 65%, with few exceptions. But with how big our team is, that means that 2/3 loading is around 40 points per sprint that needs to be planned. And our standard practice also are expected to pull in New Features / stories from the next sprint, or work on items as assigned by the PO from the backlog if things are finished on schedule. >This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe. All our Certified SAFe Professionals says this is SAFe. The training I got aligns to what we practice. This is SAFe by the strictest definition of following processes and practices. But like Russian elections and referendums, you can have all the form, technically meet all the criteria, and have none of the of substance. And be honest... would it surprise you one bit to think that insincere ceremony isn't exactly what many so called leaders want?

tbalsam 4y ago

Thank you for helping me recognize that the hellhole I'd previously worked in in my first software dev job out of college was a SAFe gig. I'd referred to it a lot as "weaponized agile" (which I believe it is), but somehow I hadn't connected the dots of my middle manager casually mentioning safe to the inane, almost preschooler level of sticker-award-insult that strips away developers abilities to, well, do what they've spent their career learning to do and instead "gives them the ability" to "pick their own team names (and we can name our epics in a theme! :") )" (insert gratuitous "yay"s, clapping, and suggestions of how fun it will be). This helps paint a lot of things in retrospect a lot more clearly. As you can see, I am still intensely salty about this experience many years later. >:')

brightball 4y ago

There are two things you're saying that simply don't align here: > we strictly follow good SAFe practices. and > PI planning for us is 2 weeks of planning for a 12 week PI This is a hellhole that in no way reflects good SAFe practices. PI Planning is 2 days. 2.5 if you're partially time shifted to accommodate teams in disparate time zones. There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment. Any label put on the process your describing is probably not fair, whether somebody called it SAFe or Scrum or Kanban or Lean or Extreme Programming or whatever else. This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe.

throwaway93494 4y ago
>This is a hellhole that in no way reflects good SAFe practices. PI Planning is 2 days. 2.5 if you're partially time shifted to accommodate teams in disparate time zones. Our PI planning consists of a combined demo session and Q&A, a combined I&A, then separate demos and I&A's for each of the ART's. That in of itself can take 1 to 2 days because of the number of demos that each ART has to include. Then 3 or 4 days of team breakouts for writing stories, a full day for draft plan review, then another 2 to 3 days ish days to take in feedback from the review and adjust the plans, then another day of final draft plans review. You can't fit that into two days. You can't even fit that into a week. But those those rituals are more core to SAFe Agile then an arbitrary time frame for PI Planning. So the 2 day limit had to be dropped to fit in the core principles of SAFe. So yes it does align and yes it follows good SAFe Practices. Didn't you yourself say that one shouldn't try to the organization into SAFe's structure? > There's so much more about this that I want to respond to but I'm going to shorten it to this: SAFe calls for planning a maximum of 2/3 of your estimated capacity (based on historic velocity) and then leaving the last 2 weeks of the PI entirely unplanned. All of this is built in buffer time specifically to ensure time built in to deal with unexpected things that will inevitably come up. Defects in production should be addressed immediately in any environment. Our sprints are loaded to 50% to 65%, with few exceptions. But with how big our team is, that means that 2/3 loading is around 40 points per sprint that needs to be planned. And our standard practice also are expected to pull in New Features / stories from the next sprint, or work on items as assigned by the PO from the backlog if things are finished on schedule. >This is simply a terrible and broken environment facilitated by people who apparently had no idea what they were doing. This is an environment where managers have exerted strict control rather than allowing people close to the problem to take the action that they know needs to be taken. Which is again...not SAFe. All our Certified SAFe Professionals says this is SAFe. The training I got aligns to what we practice. This is SAFe by the strictest definition of following processes and practices. But like Russian elections and referendums, you can have all the form, technically meet all the criteria, and have none of the of substance. And be honest... would it surprise you one bit to think that insincere ceremony isn't exactly what many so called leaders want?