"Speed trumps everything"? - Really?

Two young men are beside a river with their buckets to collect water for their nearby village.  Suddenly they hear a shout of "Fire!" from the village.  Grabbing their full buckets of water they head for the village.  One young man, full of adrenaline and concern, runs at full speed sloshing water as he runs.  When he gets to the fire, he has very little to throw on the fire.  The second young man, aware of the need for haste, carefully hurries to the scene of the fire and throws the bucket of water on the fire helping save the family home.

I've been in the situation where the title phrase of this article was offered as a pithy rallying cry by an executive and as catchy, pithy phrases will do, this one got the "rush to delivery" types all excited and was used repeatedly and to great effect in any encounter where thoughtful analysis was attempted.

Make no mistake, if the second young man had become so obsessed with not spilling a single drop that he had slowed to a very deliberate walking pace, the delivery of the water would have happened too late to be of value.  In the same way, obsessing over unnecessary refinements in search of "perfect" requirements can kill an effort just as surely.

After more than a decade of "Agile" projects, and in particular Agile projects aimed at enterprise-level data/information initiatives, the lesson is that it is CRITICAL to work only as fast as understanding of the bigger information requirements map allows, otherwise the "solutions" built on a substandard foundation will be forever inaccurate, inflexible, unstable, poorly understood, difficult to use and in constant need of repair/modification.

There are a couple of ways to approach supporting Agile-empowered enterprise data/information initiatives.  The best way is for the data architecture types to anticipate upcoming information needs, get out in front of development initiatives and have the information requirements as thoroughly refined and documented as possible prior to any developers showing up to work.  Make no mistake about it, this first approach needs to be targeted and time-boxed so it doesn't devolve into an activity similar to the old "Enterprise Data Model" initiatives of the eighties and nineties that did little but produce wall-art. 

The second approach is to have "zero" sprints before the developers show up in order to get a broader look at the context, enterprise strategic information/data needs and potential external interfaces that need to be considered.  This still dangerously short-changes the strategic vision needed regarding information requirements, but it is better than not doing it at all.

The reality is that there is no such thing as a perfect requirements document and any solution architecture needs to be designed to accommodate change.  Information requirements will change because of missed details, evolving regulatory requirements and changing business strategies.  Refactoring the underlying data structures and applications is an unavoidable reality and must be supported for a solution to be viable long-term.

Successful design is not the achievement of perfection but the minimization and accommodation of imperfection. - Henry Petroski