Discover more from AgileData
AgileData Newsletter #2
A Data Engineer an Agile Coach and a Fish walk into a bar…
Stop me if you’ve heard this one before !
I’m a Data Engineer with a passion for all things cloud, in particular the Google Cloud Platform. Together with my co-founder Shane, who is as far from a Data Engineer as you can get, we embarked on a journey to democratize data and remove the friction that is inherent where data is involved.
We like to say “simply magical data” , because your data experience should be fun ... not scary, or expensive, or require large teams of specialists to ‘do technical stuff’ for you.
Along the way we adopted adi (short for agiledata.io) the fish to bring some saas to our platform (software as a service) 😉
Adding members to your agile team makes you slower
We love to share the learnings we have made when we work with teams that combine agile practise and patterns with data practises and patterns to find a simply magical way of working.
Have a read on our thoughts about adding more people to your team to try and make things go faster.
AgileData Product Feature
Colours of the Catalog
We believe colour is a great way to enable people to quickly differentiate things.
So we have embedded colour clues in the AgileData app.
Watch another AgileData Gone in 60 Seconds where ✨Shane Gibson highlights where we are using colour to remove complexity.
Analyst vs Analytics Engineer
Find the whole Analyst vs Analytics Engineer vs Data Engineer distinction confusing?
So we asked Benn Stancil onto the AgileData podcast to talk us through his views on the roles.
Have a listen or a read to see what he thought.
Lean Software Development
There are lots of learnings from the Software Development domain we can apply to the data domain. Mary and Tom talk about:
Organisations have queues because they don’t care about the customer;
The three rules of lean, customer focus, flow and highly efficient expert teams;
Scale your organisation like a micro services architecture;
Its not about doing the work right its about doing the right work;
Don’t focus on utilisation focus on the value we provide;
Don’t copy practices copy the principles behind the practices;
Don’t centralise processes;
Set goals and let teams develop their own processes.