The Agile Waiting Game

I think the difficulty in evaluating programming is its often subjective nature. Your article talks about avoidable and unavoidable delays and some of their causes, and while I think you're right, it's only half a picture, and incomplete on its own. Yes, you mention that some perceived delays (e.g., TDD) are actually long-term time-savers (and I agree), but, as one example of how I thought the article might be improved, there's little guidance on differentiating the two.

The important questions, including whether the delay is reasonable, and how can unreasonable delays can be identified and avoided, are the things keeping development managers up at night. Knowing what some delays might be is a first step, but I suspect managers who deal with these delays already know they exist. They'll read, nod and say, "Yup", and continue on their way.

I'm in early discussions with a company that wants to apply better measurement to its agile processes. Its a seeming contradiction to some of the principles of agile, but without knowing how productive teams are, even relative to each other, they can't know if a team is improving or stagnating, except by gut feel. You don't offer any heuristic to improve managers' already subjective instincts.

I feel like an article like this requires a call to action, or at the very least series of specific steps that worked for you in separating the wheat from the chaff. Sharing your experiences on how you handled unnecessary delays would be doubly useful.

-------- Aside: As a specific example of an unhelpful solution in the article: "Start looking for delays in your ... process. [H]ere are some examples: ... * learning to look for delays." Finding ways to trim text enhances its readability. (Something I'm still working on, I think you'll agree.)