|
|
|
|
|
|
by lee
1322 days ago
|
|
|
I worked for a company that adopted SAFe and sent me to get certified as a SAFe Program Consultant. So I worked to set up "Agile Release Trains" and coached a few teams that had never used any Agile methodology before. I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner. However, It's not entirely terrible as it provides some tools that can be address some organizational problems. I think at best if a large organization is already doing well and is "agile" overall, SAFe won't provide a lot of value and is unlikely worth the investment. If an org is highly siloed, dysfunctional, and lacking inter-department coordination then SAFe it at least offers some tools to address those issues. |
|
|
> I can absolutely understand the frustration that many have with SAFe, especially when it's pushed from a top-down manner
This is the wrinkle, and in my experience the #1 factor for whether or not any particular methodology is going to work within an organization: top-level buy-in. Before I got too jaded, I worked with and helped some teams that wanted to try bottom-up agile, and it would help the team get better, but if a layer or two up in the management chain still wants e.g. fixed timeline, fixed budget, fixed scope projects, you're going to run into impedance mismatches all over the place and lose most of the benefits in the medium term.
This can also happen in the other direction. An organization I worked with adopted EOS on the business side of the company but didn't really roll it out on the engineering side, except for expecting everyone organization-wide to specify their quarterly goals. After setting those quarterly goals, the engineering teams would still get yanked around in multiple directions, being asked semi-randomly to work on things that had nothing to do with their quarterly goals and then at the end of each quarter everyone just scratched their heads and went "why didn't we accomplish what we wanted to accomplish?"
Maybe I'm jaded, but I've gotten to the point where I don't really care which methodology is used, but rather that everyone top-to-bottom is on-board with it and actually following it. If it's Scrum, management needs to 100% buy in to the idea that they're going to get releases at a constant cadence and that those releases will contain whatever was prioritized as the highest value, with lower value features potentially missing. If it's something more conventional/waterfall-esque, management needs to be on-board with the fact that there's going to be some very costly analysis up front (that must include engineering) and that changes to that plan are expensive and will cause the schedule to slip; engineering needs to be on-board with the fact that they will be expected to deliver everything according to the schedule they built. It doesn't matter nearly as much which approach everyone wants to take, just that everyone understands the tradeoffs with that approach and that everyone's going to follow it.