Scrum disempowers developers

First it’s “no true Scrum implementation would have property X.”

Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”

Bingo. That is the key point to me. Scrum, and other agile-family methodologies, are great when fully implemented. But what usually happens is that the higher-ups refuse to relinquish a bit of control, and stick tightly to their traditional command-and-control approach, and the dev teams are forced to do something that looks-kinda-like-scrum (or looks-kinda-like-XP or looks-kinda-like-AUP, etc.) while operating in a structure that isn't really compatible with the principles of Scrum, XP, AUP, etc.

Basically, we're forced to try and fit a round peg into a square hole because people higher up the org-chart either don't really understand agile-family methodologies or are actively opposed to truly implementing them.

I've organised many XP teams that regularly hit our sprint commitments virtually every time. The times when I've found it problematic to hit sprint commitments were due to the following:

- Sprint was too small. 1 week sprints are awesome, but they are extremely difficult to hit. I run 2 week sprints if I can manage to get people to agree. It can also significantly reduce planning overhead.

- Stories were too big. Stories should have a median delivery time of about 1-2 days for a 2 week sprint. The occurrence of 5+ day stories should be in the 1:100 range. High risk stories should always be arranged first in the sprint so that even a 5 day story doesn't blow the sprint out of the water.

-Stories were ill-defined. Goes together with the previous point. If you have a really high variance on your stories, it's probably because of this. You should have a "backlog grooming" session once every 2 weeks. At that meeting, you go over any new stories in the backlog and any stories that might make it into the sprint commitment. All developers should attend the meeting. At the meeting you decide: Do you understand what the story means? Could you start coding the story today? Should the story be broken up? It helps if project managers are not in this meeting -- they just respond to the feedback after the fact. Only stories that get the thumbs up, make it into the sprint commitment.

- Stories did not have acceptance criteria. Similar to the above, but more specific. Everybody might feel they understand what to do, but if you can't answer the question "How do I know when it is done?" then it isn't a story.

In the above cases, you can fairly easily fix the problems and still have sprint commitments. I have also been in some situations where I think sprint commitments didn't match the team. For a variety of reasons, I really like sprint commitments, but it is a bad idea to stick to it if it's not going to work. Here are some situations where I've had problems:

- Developers had many disagreements about how/when to merge code. They would take unpredictable amounts of time to merge code. If pressured to merge in order to hit targets, conflict would eventually erupt in the team.

-There was a young team that did not know how to relax when there is a deadline. Sometimes they merged inappropriate code just because they are afraid to be the one on the critical path. Sometimes the cut corners for the same reason. If you can pair program, it can really help with this.

In these cases, it's a matter of training the team. It helps if you can keep the team together for a long time and if you have a manager who isolates the team from a certain amount of surrounding politics. But sometimes, for a variety of different reasons, it isn't going to work. It's not bad to reach for something else at that point.

Sprint commitments can be really beneficial in my experience, but it's one of those things that is the result of having a high functioning team. It's not necessarily the way to make a high functioning team.

And yes, integrating it with the rest of the company is the biggest question, e.g. if you really are agile, what does your sales team tell customers about future upgrades?