Comment by rpmiskin | Hacker News Reader

Comment by rpmiskin | Hacker News Reader

Parent Full thread

We’re in the midst of a ‘SAFe transformation’ from having been running in a fairly lightweight scrum-style manner for year.

There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you.

Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process.

Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people.

If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.

Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.

> there is loads about how you /should/ adapt it to work for you

Is this really happeninig in your org when adopting SAFe? At least for us - we went to all the trainings but it was essentially a two-day heavy course of a SAFe consultant telling us how to run dailies, groomings, plannings, PI plannings, retros, demos etc. etc. ALL of these were mandatory and our team was assigned a Scrum master to make sure we were actually doing them (granted, he took responsibility of organizing also the retros, which was previously a full workday for me every two months.)

I even remember reading from the SAFe book that teams are only afforded a limited autonomy of deciding on the implementation technologies of the features that are assigned. No word of having any autonomy over the process, since I understod the uniform process being a requirement for the inter-team coordination to work.

>If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong.

the comment you are answering was on point

>I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way

My bad, not ‘doing it wrong’, just trying to use the wrong methodology for your problem :)

sledgehammer to crack a nut.

This particular company was in fact seriously in need of a corporation-wide business development methodology, so sledgehammer was called for – and I can see the appeal they saw in SAFe. But completely replacing autonomous agile teams' existing self-organized processes with a new top-down forced SAFe variety of Scrum with the same swing of the hammer -- not really called for, but mandated anyway in name of SAFe having to be an "organization wide" effort.

Reality is of course that the dev teams are the only ones ever trained in the new process, and must suffer the chaos while rest of the org just don't care or hate it just as much – apart of course from the new middle managers who were hired to "help with the SAFe transformation".

My prediction: max two years from now senior management announce "the end of the SAFe experiment", and go back to some ad-hoc version of the preceding organization model "with lessons learned" etc. Rinse and repeat every four-five years.

Sometimes you actually are doing something wrong though. Preemptively stating that you know someone will tell it to you doesn’t necessarily mean that it isn’t true.

If you want to lose weight, a diet where you can eat as much McDonald’s as you want is probably doing it wrong. Applying SAFe to a small team is probably wrong.

Reply on news.ycombinator.com