3 ms·

Oh god.... SAFe is the opposite of agile, and PI planning is for people who don't understand the truth in "plans are useless, planning is essential." It's days

by dkarl 4y ago

Oh god.... SAFe is the opposite of agile, and PI planning is for people who don't understand the truth in "plans are useless, planning is essential." It's days and days of planning whose value depends on everything happening exactly as planned. And then, every quarter, reality diverges from the plans, meaning 90% of the PI planning was useless, and people insist on hours of meetings about how to do PI differently so that next time planning will match reality. Rinse and repeat. And people use the failure of PI planning as an excuse for everything being stressful and chaotic. SAFe is the methodology of choice if you want your organization to work smoothly for the first few weeks of a planning increment and then become progressively more dysfunctional as people freak out and/or give up because it no longer makes sense to do exactly what the plan says. Exactly the opposite of agile.

ruh-roh 4y ago
I am probably 95% in line with this, SAFe is mostly terrible, but there are some nuggets in there that I think are good. Mostly around the cadence and checkpoints on progress in delivery. (Yes, we can argue whether some of these things originated with SAFe, but it's how I was originally exposed, so that's how my mental model is mapped.) - Quarters (every 12 weeks): Big ticket things that should move the business forward. This requires Engineering participation because items like technical debt, system re-architectures, pipeline improvements, etc. should be on the table. - PI (every 3-4 weeks): Light checkin on progress to current items. A ballpark estimate on what can be delivered in the upcoming PI given the current constraints (capacity, quality, etc.). This works out to 3-4 checkpoints per quarter. - Sprint (every 1-2 weeks): Real commitments to tangible requirements are made here. If thorough discovery leads to changes to the ballpark estimates or development is delayed for other reasons, it is communicated at the PI checkpoint and forecasts can be adjusted. (imo) SAFe is just a solution to problems that may or may not actually exist - eager-beaver middle management-types adopt it chiefly because they think it makes them look good, but also because Product/Engineering teams don't commit-escalate-communicate well. I encourage folks to take a step back and ignore the specific SAFe guidance, but do consider the value of the inputs & outcomes.
- dkarl 4y ago
  > Product/Engineering teams don't commit-escalate-communicate well I'm not sure which way the causality points, maybe you're right and organizations that already have poor communication tend to adopt SAFe, but my experience is that it discourages communication between teams and encourages passive-aggressive irresponsibility. In a healthy organization, anyone responsible for the success of a project (management leadership, project managers, and senior individual contributors) will periodically think, "Next week we will do X, but only if Y is going to be done soon, so I need to check in with the team working on Y," and people constantly keep their finger on the pulse of work relevant to their own. SAFe claims to replace this with process, so people don't do it. In the company where I work now, there's no plan (I mean, there are various plans and timelines, but they're tools, not totems) and we constantly talk. I can message anyone I want or schedule a quick informal meeting with anyone I want without thinking about the political ramifications. Under SAFe sometimes we needed info from another team and discussed how to approach them, who to ask, how to frame it, etc., and ended up deciding there wasn't a good way and it would be better to make our best guess and not engage with them. A few times I was put in the position of refusing to say how I knew something, because I found a way to get the information I needed to do my job, and I didn't want my source to suffer any consequences from communicating outside the SAFe process.

by dkarl 4y ago

ruh-roh 4y ago

I am probably 95% in line with this, SAFe is mostly terrible, but there are some nuggets in there that I think are good. Mostly around the cadence and checkpoints on progress in delivery. (Yes, we can argue whether some of these things originated with SAFe, but it's how I was originally exposed, so that's how my mental model is mapped.) - Quarters (every 12 weeks): Big ticket things that should move the business forward. This requires Engineering participation because items like technical debt, system re-architectures, pipeline improvements, etc. should be on the table. - PI (every 3-4 weeks): Light checkin on progress to current items. A ballpark estimate on what can be delivered in the upcoming PI given the current constraints (capacity, quality, etc.). This works out to 3-4 checkpoints per quarter. - Sprint (every 1-2 weeks): Real commitments to tangible requirements are made here. If thorough discovery leads to changes to the ballpark estimates or development is delayed for other reasons, it is communicated at the PI checkpoint and forecasts can be adjusted. (imo) SAFe is just a solution to problems that may or may not actually exist - eager-beaver middle management-types adopt it chiefly because they think it makes them look good, but also because Product/Engineering teams don't commit-escalate-communicate well. I encourage folks to take a step back and ignore the specific SAFe guidance, but do consider the value of the inputs & outcomes.

dkarl 4y ago
> Product/Engineering teams don't commit-escalate-communicate well I'm not sure which way the causality points, maybe you're right and organizations that already have poor communication tend to adopt SAFe, but my experience is that it discourages communication between teams and encourages passive-aggressive irresponsibility. In a healthy organization, anyone responsible for the success of a project (management leadership, project managers, and senior individual contributors) will periodically think, "Next week we will do X, but only if Y is going to be done soon, so I need to check in with the team working on Y," and people constantly keep their finger on the pulse of work relevant to their own. SAFe claims to replace this with process, so people don't do it. In the company where I work now, there's no plan (I mean, there are various plans and timelines, but they're tools, not totems) and we constantly talk. I can message anyone I want or schedule a quick informal meeting with anyone I want without thinking about the political ramifications. Under SAFe sometimes we needed info from another team and discussed how to approach them, who to ask, how to frame it, etc., and ended up deciding there wasn't a good way and it would be better to make our best guess and not engage with them. A few times I was put in the position of refusing to say how I knew something, because I found a way to get the information I needed to do my job, and I didn't want my source to suffer any consequences from communicating outside the SAFe process.