AgileData Newsletter #13
Join Murray Robinson and Shane Gibson in a conversation about Software Metrics with Tom Gilb. Tom Gilb inspired the authors of the Agile manifesto with his innovative incremental and scientific approach to Software Engineering. In this podcast we talk about Evo and Value Agile. Defining your scope with objectives and success metrics. How to measure anything. Why feature backlogs are a waste of time. Being laser focused on outcomes. How to deliver as much value as possible in the time and budget available.
Who Should Attend Steering Committees?
Are you running a "Steering Committee" as part of your agile data way of working?
We suggest you rethink your agile governance process, as there are better ways.
Sometimes you just want to be able to export or import rules.
You might want to export all the rules from your AgileData tenancy and push them to git so you have a copy.
You might want to export them from one AgileData tenancy and import them to another tenancy as a formal release process.
You might be an expert and want to export them, update the rules logic and reimport them.
You may have some other reason that we haven't even thought about.
So we made it easy for you to export and import rules regardless of the reason you have.
The Art of Data Story Telling
Data Story telling is a real art. And Kat Greenbrook has been crafting the Data Story telling art for many years.
We were lucky enough to chat with Kat in 2019 as part of her journey, and the patterns she talks about are still as relevant today as they were back then.
ELT Without Persisted Watermarks Not a Problem
At AgileData we are fixated with the idea of patterns.
We think of them in terms of DORO (Define Once Reuse Often)
Some patterns in the data domain have been around for years, one of those is the watermarking of the latest load state for a table.
Reusing these patterns reduces the time to develop features in your data platform.
But sometimes these patterns need to be replaced with new ones, and for us the watermarking pattern was one we could replace with something better.