This is probably the most level-headed introduction to scrum / agile processes I’ve ever read.
I have come to think of estimation and time tracking as being similar to code coverage. People who have never really tried using code coverage tools are quick to point out all the reasons why code coverage is a waste of time. They can describe in great deal why code coverage will not solve all their problems. They know that even 100% code coverage does not guarantee that software is correct. All of their excuses are built on facts. But it is also difficult to find someone who has used code coverage who believes it is pointless.
It is true that best practices can be taken too far. Many of them produce their greatest returns when applied in a small way. Nobody’s going to be hiring me as an agile coach, but I’ve got more experience than I did two years ago, and I’ve learned some great lessons. Nowadays, when somebody tries to tell me that estimation and time tracking are pointless, I ask them, “Have you tried these practices with 4-week sprints and a burndown chart?”
He approaches the topic as a skeptical skilled-practicioner and it seems their team was constantly adjusting the “final target” aim for their software release.
There was a period of several months where every time we finished a sprint we had to insert a new one to deal with the stuff that didn’t get done. Ian described sprint 15 as the first sprint where he didn’t have to redo the 1.0 plan.
This is in pretty stark contrast to most sprint-based projects I’ve worked on which have been more of “small batches, updating production” and no final marketing or release push for any of the “bigger” things that might shift / delay from sprint to sprint.
In any case, if you are an “agile skeptic”, please read the linked article, it’ll give you some healthy food for thought.