False Agility

In my last post, I mentioned that I am working privately on sorta-Scrum tracking system for agile project development. My working name for the project is TMX. (T)eam (M)anagement and the X is because everything cool that ever came out of the Fox world has to end in X.

I'm not going to repeat here the definition of agile processes or Scrum in particular, but if you already understand it you know that there is a high reliance on the professional judgement of the development team and that management acts more as an obstacle remover and facilitator.

What bothers me is that, for Scrum at least, this blind assumption that the development team knows what they are supposed to be coding and most whitepapers confidently posit that you can retrofit any sort of project management structure into Scrum.

Wrong.

Birds cannot fly free without the structure of wings. That is, no amount of expertise or instinctive talent will guarantee success without the support structure. Scrum seemingly substitutes open communications between customer, management, and the development team as a panacea for that structure.

This is wrongheaded. Open communications are great, and absolutely required for agile development, but must be backed up by rigid and detailed functional requirements which are created from dedicated and formal requirements gathering.

Scrum is described as best working for small teams. My take on this statement is that this is the case when all you have is real-time communications and no written, formal documentation of the form and function of the application. This is absolutely required to reduce bad assumptions and people wheelspinning by having to undo the wrong work.

I have found in the real-world that detailed requirements are absolutely a key; they are the wings of the bird. Good strong wings let that bird fly with the greatest agility...