We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html

Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints.

Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do.

Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead.

I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™.

My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.

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.

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.

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

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.

sledgehammer to crack a nut.

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.

I guess you just weren't Agileing and Scruming hard enough!

Scrum (as intended, not as actually done in most companies) is in essence a set of rules to prevent things from falling apart after you have ditched the managers:

* know what you want to achieve during this month -- planning for longer time is unrealistic, weekly planning is micromanagement;

* at the end of the month, make a demo of new features -- make sure that all pieces fit together, and get feedback whether this is actually what the customer wanted;

* reflect on what happened during this month and why -- this is the moment to speak freely, complain, and propose changes (for example, this is the occassion when the developers could collectively decide to stop using Jira);

* decide where to go during the next month -- together with the customer: the customer decides "what first", developers decide "how fast";

* make sure your colleagues know what you do and whether you need help -- this shouldn't take more than 3 minutes a day.

If your sprints are weekly, you are doing it wrong. If you don't make a demo, you are doing it wrong. First, with continuous integration, deploying the demo should be trivial. Second, if you don't show the demo to the customer, who is giving you feedback on your progress? (Nobody? Management?) If you skip the retrospective, or if you don't feel free to speak openly during the retrospective, you are doing it wrong. If you don't have an idea what to do next, and what is important for the customer, you are doing it wrong. If management gives you deadline, you are doing it wrong. If your daily standup takes more than three minutes, you are doing it wrong. (For anything that requires more time, you should arrange a separate meeting, for only the people involved, not the whole team. Note that the "separate meeting" could still be like five or ten minutes long.)

So much for the dream. Now here is what actually happens: in your company, the managers have the power, and they are not going to fire themselves. So instead, they will impose on you some kind of management-driven pseudo-Scrum, which looks like this:

The sprints are short, because that gives the managers greater feeling of control. You don't talk to the the actual customer, and the customer doesn't see your product before it is officially delivered; the managers acting as middlemen is how they justify their jobs. There is no retrospective, because this is the first and the last time in history when management decides that something is a waste of time. You have sprint planning, but you also have deadlines, so your choices are often limited to "do X this sprint and Y next sprint, or do Y this sprint and X next sprint". The daily, instead of team members synchronizing with each other, becomes team members reporting to the manager. You get Jira, which is set up according to the manager's wishes.

This is not a coincidence. The managers insist it needs to be done this way, because they want to protect their jobs. The same thing would happen with any other methodology.

That's the gold standard! You know you are doing fake agile when the team is not allowed to decide stop using Jira.

In all seriousness, thanks - very valued insights! I did not even know those were the original purposes of the Scrum ceremonies, having only ever worked witn almost exactly the kind of pseudo-Scrum you describe.

This is the moment you know you are doing fake Agile and your scrummaster is just the managers puppet in disguise to spy on the team.

I am not sure what would be the right solution. One possibility is to fire the management, or never even hire them at first place -- if you want to have a software company that uses Scrum, do it from start. Another possibility is to have a Scrum Master with strong political skils... which more or less means, it cannot be a former developer.

Probably the fatal mistake is having too many managers in the company. At that moment, it is practically guaranteed that they will try to interfere with everything. They have to, because that is how they protect their own jobs. And they will hire more managers, because that is one way to get higher on the company ladder (hire more people into positions below you). And at that moment, everything is doomed, because now the company serves the managers instead of the other way round.

I guess this means that Scrum can work as intended only in small companies. Where the Scrum Master is not below several layers of management, but on the same level as the few managers, right below the company owner.

I would argue that most companies cannot afford to give that kind of "empowerment" to most developers, especially if these companies rely heavily on masses of junior/inexperienced developers. So they figure a strong management layer is necessary to properly direct the project's goals.

Now I'm not saying that's how it should be, but that's the reality of the software talent market today.

The problem is that this means you need leaders—managers or not—who are comfortable without an illusion of control or visibility and who understand how to lead and communicate effectively. And you really need this all the way up the chain. If you manage this, though, you'll be amazed at how productive even heavily junior teams can be.

Development isn’t an assembly line process—and cannot possibly be. It’s about theory building and mental models. It requires experience.

It’s fine to have juniors, but they need to lean heavily on experienced colleagues. No amount of management and no management process can change that. A team where the juniors outnumber the seniors 3-to-1 is going to cost more money in the long run.

What you’re describing is exactly what I’m talking about when I say companies are unable to achieve this. Hire 3 senior people instead of 12 junior. You’ll get more done. Reduce your collaboration costs. But, as a manager, you get paid more if you manage more people, or if the people below you manage more people, so there’s a perverse incentive to build as much bureaucracy as possible and staff the lowest layers with the cheapest possible hires.

Personally I'd almost always rather hire a single senior engineer and pay them what two juniors make. I suspect I won't get double the JIRA throughput, but will get more than double the actual effect on the product.

Anyone who says the Agile Manifesto and Scrum are not directly at odds is trying to sell you something.