I love a tongue in cheek satire especially about dogmatically held beliefs.  Here is a great one by Scott Ambler.  It could readily be applied to those who believe in creating copious amounts of documentation and following a waterfall process instead of Keeping Agile.  Enjoy! –Brian

The Glacial Methodology™ is a data-centric approach to software development based on sound software engineering concepts. With a Glacial approach you begin by developing a conceptual data model, followed by a detailed logical data model (LDM), and then finally a detailed physical data model (PDM). After several months of this comprehensive modeling effort development activities are then permitted to begin.

Conceptual data models explore the main business concepts and their interrelationships. Workshop participants will learn that conceptual data models form the foundation upon which all development is based and that it is therefore imperative that you start with a reviewed and accepted model. Strategies for streamlining this effort will be presented, it is possible to finalize a conceptual data model within the first six to eight weeks of your project.

The next Glacial step is detailed logical data modeling. An LDM fleshes out business entities with detailed descriptions of their data attributes and the relationships between entities. Data requirements are gathered during this stage, information which is captured within your LDM as well as in your data requirements specification–Glacial data professionals understand the importance of comprehensive documentation. Strategies for putting the LDM into 74th normal form will be discussed, as will the need for practicality by only going to somewhere between 67th and 72nd normal form. During the workshop participants will learn how to justify a parallel LDM activity even though the application development covers the exact same ground, faster and more thoroughly, with their object modeling activities. A side benefit of the Glacial Methodology™ is that it ensures a large and growing data group within your IT department regardless of the obvious redundancy which they represent.

With a Glacial approach you develop a detailed physical data model (PDM) based on your reviewed and accepted LDM. The PDM is used to generate your database schema and to help drive the modeling efforts of the application developers (they still need to worry about a few secondary issues listed below). You need to invest significant time modeling it because it needs to be right, due to the fact that it is incredibly difficult to make changes to your database schema once it is in use.

A comprehensive requirements change management to prevent scope creep is a vital component of any Glacial process. All change requests must go through a change control board (CCB). In the case of requests affecting the database, the CCB must defer to the data group to ensure data quality. Instead of considering changed requirements immediately, it is far better to invest the time to consider each potential change thoroughly. Better yet, by following such an approach your stakeholders will soon learn to stop suggesting all but the most important changes–with the Glacial Methodology™, bureaucracy becomes your ally because it helps to minimize, if not completely avoid, change.

Following the traditions of the traditional data community, the Glacial Methodology ignores trivial issues which are better left to application development teams. These issues include, but are not limited to understanding the usage requirements for the system, system usability, security, network architecture, hardware architecture, deployment, scheduling, estimation, component design, user interface design, overall functionality, and testing. Justification for why all of these issues are secondary to data-oriented concerns, and political techniques for sidelining anyone naive enough to think otherwise, will be covered in detail.