If you are a regular reader of my columns on ITWeb, it should come as no surprise by now that I am a serious fan of agile delivery principles. When I first started leveraging on agile models, it took me a while to work out how to design large-scale data models using agile. Although it was a very challenging experience at the time, it was also very rewarding.
I learned a lot during this process, and I have embodied these learnings into a few key points. I like to think of them as the ‘10 commandments’ of agile data modelling, and I would like to share a distilled version of these here.
(1) Model with purpose
Designing data solutions can be an expensive and time-consuming exercise. We owe it to the client to keep a very clear focus and therefore, we must have a set purpose, and a clear goal to achieve. We always need to be ruthless in adhering to this purpose and goal.
(2) Maximise stakeholder ROI
This one should be obvious; however, it is sad how often it is not adhered to. We don’t want to waste time on things that are not immediately relevant, and that don’t add value to the client. It says a lot about the current state of our industry that we must often remind ourselves of this. Always ask yourself the question: how does this add value to the product owner?
(3) Travel light
This one might be my favourite. The fact is that every artefact that we create needs maintenance. There is an initial cost of build, and a long running cost to maintain. It should be obvious right? The lighter your load, the easier your travelling experience, and the faster you get to where you want to go! So, travel light, and only pack and carry what you need to.
(4) Know when to break the rules
This one can be tricky. I am always going on about how important it is to be consistent. Standards, policies, procedures, etc, are all worthless if they are not adhered to. It is one of my pet hates when I see standards that are not followed.
Change is a way of life in this generation of IT. We cannot stop it, nor should we try to.
However, a key component of agile is knowing when to break the rules. To remain true to agile, you need to keep the flexibility of mind and the agility to know when you need to step out the box.
(5) Rapid feedback
In agile data modelling, we want to fail fast. In traditional modelling, no one would see the data model for months, before a “big reveal”. That sets us up to fail. Instead, what we want to do is share our designs and our progress with our stakeholders as often as possible along the journey. If there is a problem with the data model, we want to know about it immediately to take the necessary action to correct it.
Regular feedback, throughout the software development life cycle, reduces the risk of unexpected design issues.
(6) Assume simplicity
I know it is a cliché, but simple is very often better. We do not always have to build a shiny new toy. The preferred solution is one that combines relevance, efficiency and affordability.
Very often, we spend a great deal of time trying to make our models future-proof, to stand the test of time. But what is the cost of this? We do this, only to then find out that the solution is being replaced, or deprecated. Very often, the work that we put into future-proofing our solution became unnecessary. So, keep it simple and do not over-engineer.
(7) Embrace change
A lot of project management aims at trying to prevent change from affecting the project. I do not believe this is possible anymore. Change is a way of life in this generation of IT. We cannot stop it, nor should we try to. The moment we stifle change, we become redundant, and we stop supporting our product owner’s needs.
The fact is, in the data world, change happens all the time and is no one person’s fault. Stifling this change inhibits the resulting system and prevents us from adding value. Therefore, don't isolate yourself from change; rather focus your energies on channelling the change.
(8) Incremental change
Having embraced change, we must adopt a culture of incremental change. We do not need to get it right the first time and we do not need all the detail the first time either. It is ok to get an initial stake in the ground and refine and evolve the model over time. This concept speaks to the Agile principles of “just-enough”, “just-in-time” and minimum viable product.
(9) Information is the primary goal
It is important to ask, “why are we here?” and “what are we doing?” Never forget − the goal is not to design solutions. The solution is not the goal; it is a by-product of requirement. The goal is to get critical information to people (or applications), at the right time.
This point is more subtle than you realise and it should change how you think on a fundamental level.
(10) Enabling the next effort is the secondary goal
We also need to prepare the model for the next release, or delivery. It is important to keep a narrow build focus in agile. However, in data modelling, it is also important to know what is around the next corner. This helps you to lay the ground for upcoming requirements.
These commandments do not speak to a technical modelling approach, but more to an ethos and way of work when it comes to agile data modelling. I have found that staying true to these practices helps me to BEagile, instead of only acting agile. This results in a more natural implementation of agile delivery and value.
Share