[SoulMan]

I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality".

I am not saying Agile does not have any value at all. I think it helps middle management (top management only see some high level slides) get some numbers to measure how much work has been done and how much time is remaining to complete the features in the road map (epic progress). On the flip side everyone else forced to make those numbers good (either by working on weekend or taking short-cut with tech debts or in worst case compromise quality). This becomes obvious when managers set rules like - 90% of the stories must be completed at the end of two weeks sprint (if there are less than 10 stories, you have to close all of them). I see all stories coming to code review , merged, deployed , tested & closed on the last day of the sprint. Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing) scrum master end up make it happen as his job is to make sure "sprint commitments" are met.

Now enter the world of SAFe. You plan for 3 to 5 months and can't do anything different in this time period (Where is the agility ?). You can't prioritize tech debts that you carried when you took shortcuts earlier to deliver MVP as "things are going alright". Hence, no iteration , only look ahead deliver more features. Spend a week on just planning and trying to accommodate feature based on "High level estimate" which is usually 50% accurate because you have not broken down to stories yet or has not done any experiments to check if some technology or recipe works or not. In addition to this you have hours of grooming, standups planning, retro , review in each up coming sprint involving the whole team.

I think every time you fit a process which may have worked in auto-mobile industry to software industry trying to "get more value " (lean is a new thing) you cease to be an innovative company.

[ju-st]

Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.

[djeikyb]

I think scrum gets a bad name because folks get so caught up in strictly adhering to a concrete implementation of the agile philosophy that they lose track of the philosophy. Folks doing scrum often value scrum processes and tools over the individuals using them. Scrummers stick to their scrum plan rigidly instead of reflecting on and changing their process.

It's fine to say such teams aren't really doing scrum. It's true, right?

I wish that instead of promoting scrum as a one-size-fits-all agile process, scrum was taught as a place to start. That if in a couple months, a team was still doing scrum exactly as taught, they were probably failing to respond to the team needs, and also the business.

[ju-st]

Yup, the problem is that many people just implement agile without understand why you're supposed to do the rituals. I'm deeply convinced that most things of scrum really benefit the developers. You have to be aware about this and think about it and not just implement it as it was thought.

To pick an example: the OP described how the managers enforce the completion of a story at the end of a sprint. This obviously doesn't make any sense. The philosophy of scrum is that you as developer have the (1-week long) sprints to iteratively learn how long you need for a story. So after several months the team will finish most stories as planned because they have a better understands of their own speed and more importantly how to judge stories.

The most important thing about software development is to understand the "requirements". Or in plain text: what the fuck shall I do? The customer doesn't know this either but it is your job (and that of the product owner and actual customer) to clarify this on a business level. On the concrete implementation level you have the scrum planning where you talk about a story and you try to understand it. You try to clarify what it means and how to implement it. Assigning story points is not a "work item" itself. Assigning story points is only the result of the process of clarifying what the story means. You can only judge how much time you need to implement the story when you really understand it. After a scrum planning you should exactly know how you should begin the implementation of a story. In a scrum planning session the team basically implements the story in English words.

In the first few sprints nothing will work correctly, your estimates are completely wrong and you are not sure how to handle storys. But this will improve sprint after sprint. Shorter sprints = faster learning. And this learning is the whole point, if your manager decides how long your story is and giving you deadlines you won't learn anything. Instead of learning how to evaluate and interpret a similar story in the feature you have to work on the weekend.

[doseofreality]

This is the inevitable and unwinnable argument in any thread that dares to question the value of Scrum.

[ju-st]

Sorry, I have clarified my point with an example in another post: https://news.ycombinator.com/item?id=15004260

[zo1]

Because it's a version of the No True Scotsman fallacy. You're not doing "true" agile, they would say.

[redler]

You may be right in this case, but is there any discipline more rife with no-true-Scotsman rejoinders in its defense?

[ju-st]

Well I don't know any other disciplines where so many people are implementing an idea so badly :-)

See my another post for a real discussion of an issue is see with OP's post: https://news.ycombinator.com/item?id=15004260

[djeikyb]

> Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing)

If the engineers are speaking up and are actively ignored, then the business's feedback loop is broken. The things in the agile manifesto need buy in beyond the people writing code.

> scrum master end up make it happen as his job is to make sure "sprint commitments" are met

The whole idea of using the word "agile" is to allow commitments to be re-evaluated. Respond to change, don't rigidly follow a plan.

If someone is mandating a rigidly adhered to practice of scrum, and doesn't allow teams to adapt that process to the individuals and interactions at hand, it's not agile.

[alkonaut]

I don't think Scrum should be judged on how well it can perform but how well it actually performs. If 9 organizations out of 10 can't succeed in applying it, that's certainly a bad evaluation of Scrum even if technically Scrum was never properly applied in those organizations.

[UK-AL]

Honestly, most agile people don't think safe is agile.

It was literally created to try to fit agile methods into company that still thinks in waterfall.