If you have done any development in Java-land, then surely you came across the dreaded three letter word EJB.  And you were most likely duped into thinking it was great.  I did!  Then I realised it was just a specification.  It was a great big, furry, non-executable PDF.  A specification for managing objects but the creating of these objects were just horrid.  EJB3 was a clean-up exercise, but still far from nice.
A couple of months ago I ran into OSGi again, but with SCA on top of it.  Horrid!  SCA is yet another warm and huggable specification.  But it’s so ugly to work with.  Everything feels so over the top complicated and restrictive in expression.  And the tools that I saw built on this SCA implementation were just awful.  Beyond being buggy, the enforced paradigm was just counter-productive.  When will tool vendors realise that talented developers do not want a diagramming interface to write code?  But the root cause is that the SCA specification describes the diagramming notation. Yuck!  Same reason that I do UML sketches with a lot of bastardisations with no tie-in with my code.

And let me not go into domain specific big vendor specs, designs, blue prints, etc. like IBM’s Insurance Application Architecture (IAA). Nasty stuff.

More commonly, I see so many self-confessed agile teams fearing the dreaded big design up front, and the big requirements up front document thrown over the wall.  If there is such a fear for big-x-up-front, why is there no fear for big-industry-and-vendor-specs-up-front like EJB, SCA, IAA, etc?

Why?

There are deep lessons and principles lurking beneath this surface.  Agile demands you to be a lot more aware of actions, decisions and consequences.

So why do you choose not to be agile when you are trying so hard to be agile?