[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.