Last month I developed a whitepaper and a webinar on data modeling in an Agile environment. These works focused on what we as data modelers can do to ensure that data models (and therefore data modelers) continue to be valued on IT projecs. This blog series touches on the key takeaways from these works.
The Agile Manifesto calls for "Working software over comprehensive documentation" and many developers consider this a commandment to never write anything down at all. In fact, even the word "documentation" is used in a derogatory way. So I recommend we strike this label completely from our vocabularies. I just say "writing it down" or "modeling".
When I work on a data model, I'm not "documenting" an application. I'm actually modeling requirements, then later modeling a physical component of the application I'm working on. Most developers have only ever been exposed to data modeling as an after project task list of reverse engineering a database and "turning it in" to the project manager, as if they were still in middle school working on a book report.
We need to fix this belief system by demonstrating to them the value in writing down (modeling) the discussions and decisions made by product owners (users) and development teams. That's agile because we don't have waste time going back to these discussions over and over. Writing it down *is* agile.
When a developer tells management "we don't need documentation" your answer should be "We need just enough documentation. And all the modeling we can get done, because we want to keep the CIO out of jail". Then you should agree that most versions of documentation that have been produced in the past were hard to use and expensive to update (they were; trust me on this)
One of the twelve principles of the Agile Manifest is "Continuous attention to technical excellence and good design enhances agility" and I agree with that. Who would not want that? Part of good design is understand the costs, benefits and risks of why certain design choices were made. Or what use case requires that "extra" table. Or which product owner is responsible for this pieces of data. Or which columns must be encrypted as specified by the organizations security officer. Or which data is covered under HIPPA or constitutes PII. All of this is important things that need to be written down, er, modeled, so that we don't make mistakes and we keep our CIO out of jail.
The great thing about having modeled these important things is that they can be published in ways that are targeted to different team roles. Users can get a non-technical view of data models with database specifics hidden. DBAs can see the technical implementation details. Developers can see what the data means and how it all fits together. A good data model delivers all those.
Models can also be published in a way that everyone can search, interact with and even contribute to. This is the modern data model, not the data models your grandmother produced. Trust me.
But Wait, There's More….
Having said all this, data modelers who insist on forcing a traditional, process-heavy, massive deliverable base approach to agile projects will be seen as violating the values of agile development. That does not mean, however, that data modeling cannot be useful to agile projects. It can, and so can agile data modelers.
Agile fundamentals are great things. The devil is in the details. It's very tempting to skip writing things down. But that's not agile; it's fragile.