This was the case in my few months there. We had "sprints" and "stories" but 75% of all the stories in every sprint would just get pushed to the next sprint with no thought behind it. Part of that was because our stories themselves were so broad and were worked in a long term waterfall manner. Our standups were just everyone falling asleep while each person took their turn saying what they did the previous day. If someone did actually have impediments or useful information to convey, most did not pay attention enough to notice. And finally, we didn't have retrospectives, which are a great time to be able to reflect on how to improve as a team and prevent issues in the future.
A lot of this came down to the people, but it didn't help that there was no leadership to help steer it in a good direction or notice the underlying issues. Story points were fabricated to help give good spreadsheets and charts to upper management, which led to us working insane overtime before our release due to how behind we were.
This is just one anecdote though, and I know there were other departments much better off than mine was. It was enough for me to want to get out though after I realized how difficult it was to get any change in place.
Sounds like pro-forma agile - phagile - if you will.
I was taught agile by a certified scrum master, but the dude was completely serious about 'this just lets you fail faster, and you will fail, and often, as this process starts' which really helped.
He was right. It took a while to learn how to keep people honest and create succinct stories with a real scope. Particularly the guys who want to be architects or engineers perceive their jobs to start with the abstract and work down to specificity.
They can struggle with "What should this screen to today. Right now, today?" and want to talk about database design, message passing, data structures or anything else that doesn't answer the question.
At least for me and my planning it was far easier to make stories as small as possible and let the complexity build into a release which was roughly plotted out after velocity stabilized (even if into an upward slope).
I was probably doing it all wrong, but the hardest part was always keeping anyone from saying "well 6 more 2 weeks sprints means your release date is x, right?". Everyone wanted to just take the backlog depth, divide by velocity and project a date.
When enough companies start coming to you and saying they want "agile" development, you give it to them. Even if the companies don't know what agile means. "No, I don't want to prioritize, I want everything in this requirements document we are handing over."
A lot of this came down to the people, but it didn't help that there was no leadership to help steer it in a good direction or notice the underlying issues. Story points were fabricated to help give good spreadsheets and charts to upper management, which led to us working insane overtime before our release due to how behind we were.
This is just one anecdote though, and I know there were other departments much better off than mine was. It was enough for me to want to get out though after I realized how difficult it was to get any change in place.