Comment by throwaway5752 | Hacker News Reader

Comment by throwaway5752 | Hacker News Reader

I really want to say this: SAFe is an awful process and a trend that will hopefully go the way of Unified Process/RUP. I won't go into it, but it's largely created and popularized by a vendor to sell their software. It is poison and exists to keep its practitioners employed. It attracts the highest-ego PMs like moths.

I find it interesting that they author references Skype circa 2012. It sounds like classic "uppercase A" agile: they reframe success as shipping and hitting other invented agile milestones, while masking shipping lousy and incomplete product that is not succeeding in the market. That was right around the time Skype started being bad. It may succeed on some metrics because MSFT started bundling it, but anyone that actively used it at that time should know what I mean.

The idea of an "agile enterprise" is intrinsically absurd. Teams are agile, not companies, and teams and products should be loosely coupled. That's why the big tech companies in this link have converged to similar answers to this problem (they are not "agile enterprises" but give teams some latitude to solve their own problems, and rather focus on results). Kanban is better in most ways for most teams.

Also, Tuckman is a silly model that is only popular because it rhymes.

PS: Strawberry-Jam-O-Meter and a Wrong-Order-O-Meter and their descriptions could hardly be more cringe inducing. Skype should be a part of the curriculum looking at less than ideal acquisitions and post-acquisition execution. https://www.wired.co.uk/article/skype-coronavirus-pandemic has is a reasonable overview if you're not familiar. They lost the consumer market and failed at enterprise (see Teams) and Teams in turn essentially failed in the general market- where most places that were free to do so went with Slack.

As a Dev, I loved SAFE. It changed everything about how our program operated to the point our delivery became extremely predictable and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted. That program purred like nothing else I've ever been a part of. Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen before we started doing PI events. Antagonism dropped. We went from not being trusted to deploy during an annual heavy use period to being totally trusted to deploy and given additional contracts for maintenance. And this was with the exact same people who had been there. We just weren't working very well before we got into SAFe.

I think one of the keys to this was the buyin everyone had. It wasn't totally consistent at the beginning, but over time everyone got on board, we did trainings, actually incorporated feedback consistently.

I hear SAFe hate all the time, and when I ask how things went, inevitably it turns out they never actually did SAFe. Somebody made them email a 10 week plan and used the acronym and that was it. If you're gonna do SAFe, do SAFe.

Why is it that every criticism of agile/scrum/safe is met with "well you just weren't really doing it?"

A general goes to the commander of a group of soldiers and says "In 3 months, I want them to be able to demo the "march in formation" feature in front of the big-wigs who decide whether to give us more funding."

So the commander says "Yes General, we'll do Drills™ to make it happen."

And then the commander writes down "Do drills" on a TODO list, gives presentations to the soldiers about the importance of drills, and maybe even hires a certified Drill Sergeant.

But the commander and soldiers never actually do drills. They clean their rifles, practice shooting, and do other soldiery things, but no drilling.

3 months later, surprise surprise, the soldiers walk all over themselves at the big parade, the general is angry, and the commander is confused why simply talking about drilling didn't work.

But lots of developers actually hates Scrum even when done correctly. The problem is that Scrum is very rigid, it tells you how long your development cycle should be, what your meetings should look like etc. They'd prefer to just do what needs done, have the meetings that needs to be had, deliver features when ready rather than have arbitrary deadlines (sprints) etc. I understand that many developers loves having that rigid process since it is easy to just go and do your work without thinking about the bigger picture, but lots of people wants to do the other parts and feel constrained by Scrum.

And no, "adapting the process for your needs" doesn't work. The problem is having the process mandating meetings and timelines in the first place. If you just do everything freeform as these people wants then it isn't Scrum.

That's a far stricter presentation of Scrum than it deserves. The scrum guide doesn't prescribe a sprint length any more specifically than "less than a month"; it doesn't say "you can only deploy once a sprint".

Now, it might be that some people selling Scrum have Very Specific Views about some of these things, but that's not Scrum either.

> it tells you how long your development cycle should be

No it doesn't. Refuting claims about Scrum that are definitionally wrong stops us actually having useful conversations about whether actual Scrum is good or not.

By your analogy, the purpose of doing Scrum (drills) is to get better at doing Scrum (parading) rather than doing actual work (soldiery things) - which I think pretty accurately sums up my experience with it.

As I understand the analogy, the purpose of scrum (and particularly reporting), similar to the purpose of parading, is to demonstrate that you have in front of you a large group of individuals trained to work in an organized, consistent and predictable way. The implication is that if given any other "somewhat similar" task, this group would be able to perform that task in a similarly organized manner too. The choice of what the task should actually be is then left to someone on a higher pay grade.

But this isn't actually what happens when agile and similar have gone wrong in my direct experience and the parent poster would note that this is the same kind of general "no true Scotsman" response to "it didn't work" that you get from self-help gurus. The system always works, all failures are that you did it wrong.

This. You can recognize the agile cult members by how they respond to failed projects. No matter why they project failed they always say "we need to be more agile next time".

Probably because a lot of people aren't really doing it, for reasons that are entirely predictable if you've ever worked at a big company. Consider the core of the Agile Manifesto http://agilemanifesto.org/:

> Individuals and interactions over processes and tools

> Working software over comprehensive documentation

> Customer collaboration over contract negotiation

> Responding to change over following a plan

How many big companies do you know that are organizationally capable of valuing individuals over processes and tools, or responding to change over following a plan? Almost all big companies have the opposite value system on those two points, imposed from the top down by the CEO (with the exception that they do value individuals if those individuals are senior management). Many big companies also have incentive structures that strongly countermand the other points, too. Comprehensive documentation is crucial ammunition for redirecting the blame for bad decisions, for example. (Cf. https://news.ycombinator.com/item?id=28674388: "we not only need very thorough clarity on what feature development will yield the greatest returns, but also deniability that we had good reason for doing what we were doing if it turns south.")

A perfect example of using agile rhetoric without agile practices comes from today's post about what tech managers do—"standup" meetings where people don't stand up! https://news.ycombinator.com/item?id=28677250 This results in the meetings lasting half an hour, doubling or tripling their cost per participant, even before you grapple with the increased number of participants that likely results!

I have my doubts about how effective Scrum could be even if practiced perfectly, but Jeff Sutherland, Mike Beedle, and Ken Schwaber are among the authors of the original Agile Manifesto (not just the signatories!), so at least they endorse those four core values and tried to make Scrum reflect them. So I think it's justifiable to say that if you value processes and tools over individuals and interactions, or following a plan over responding to change, you're not really doing Scrum, or any other agile process.

> Why is it that every criticism of agile/scrum/safe is met with "well you just weren't really doing it?"

Not every criticism. Just every criticism that is actually people just not doing it. "Standups become status update meetings, therefore Scrum is stupid" is an example.

These things are tools to be used. If you use focus on the tool and not the end user, things will go badly. Typically you will see teams that are very hyper focused on some particular metric (time, points, stories churned, etc). Yet not focusing on 'how do I get my customer what they need'. These tools help devs break down the tasks and tell the end users 'hey we only have this amount of time so focus!' If they become about metrics or just randomly skip steps that depend on each other, you will fail.

“Senior leaders sat with devs, started talking to everyone about their priorities - people we had never seen before we started doing PI events”

Pretty much every process will work successfully if everybody participates in good faith. I don’t think SAFe has special properties that people honestly work together. For example in my company it would just create a new bureaucratic nightmare where we would hire even more managers, project managers and consultants while senior leadership still would never talk to the lower ranks.

SAFe has roles. If you don't have people doing those roles, you're not doing SAFe. If you have people doing roles that aren't in SAFe, you're not doing SAFe. It's really quite simple and I don't understand the pushback. Do it or don't, but trash it if you didn't actually do it.

As with all "Agile Frameworks", they are marketed as "If it worked it's because you did it right, and if it didn't work it's because you didn't do it right".

Is something actually valuable if it is A.) Inflexible and B.) Rarely goes well?

> and we still had every 9th and 10th week to tinker on new ideas or do refactoring and cleanup where we wanted.

We do PI planning from SAFe. We would get the last sprint of quarter for slack, improvements, they said.

Instead, we use it to clean up the mess created from waterfall scrum in the previous sprints.

In the first PIs after we started moving, this was the case for us too. But it got better every PI. The last few PIs I was in had 10 teams and a couple of them would be playing catchup, but most would be working on other unplanned projects. Either refactoring or learning or getting extra things done.

You'd have to trust me, but I know SAFe well in theory and practice. I still don't like it, but I am glad you've had a good experience with it. It may be that it's the right fit for some companies. It is definitely better than organizational dysfunction. It sounds like your environment was dysfunctional and bringing SAFe in fixed that, at least.

> The idea an "agile enterprise" is intrinsically absurd. Teams are agile not companies

I’m really not sure what you are basing this on. Agile, as I’m familiar with it is framed in terms of lean management which is a well established approach to running business, exemplified by Toyota. Now you can debate the suitabilities of this and the effectiveness til the cows come home, just as you can with agile and scrum etc but it isn’t accurate to say that there aren’t a lot of businesses that aspire to the lean approach.

I don't think it's fair to say that http://agilemanifesto.org/ is "framed in terms of lean management", or indeed management at all. While there's nothing making it impossible to organize a company along those lines, you may be interested in https://news.ycombinator.com/item?id=28677886 where I explain why the Agile Manifesto values are deeply opposed to many established company value systems.

Reply on news.ycombinator.com