Intro - The Who
About Me
I have been lucky enough to work with a number of data and analytics teams over the last decade to help them adopt agile ways for working in their data domain.
I have a semi technical background, having worked in the solution and enterprise architecture space for a couple of decades.
I have spent the last couple of years as the product lead for our start-up AgileData, furiously trying to learn the product craft, and all its language and nuances.
I am the co-host on the AgileData podcast where I have been lucky enough to talk to a bunch of data leaders on how they have combined agile and data ways of working and a bunch of agile data practitioners who have implemented agile data patterns.
I am also the co-host on the No Nonsense Agile Podcast, which started off talking about agile practices and has slowly morphed to chatting with a bunch of very knowledgeable people on the overlap (or lack of it) between agile and product ways of working.
Who this content is designed for
This content is designed to help anybody that is trying to combine agile ways of working in the data domain.
Whether you are a coach trying to help a team or your a team member trying to work out if there is a better way to get a data thing done.
It is aimed at agile and/or data practitioners, experts and coaches, people who are on the data field so to speak. If you are a bystander then I have no doubt you will learn some useful things, but you are not my target audience.
Throughout this content I describe and use patterns for personas and roles vs skills, so lets use those patterns to provide some context on who this content is aimed at and what is potentially in it for you if you spend your valuable time reading it.
Roles
Agile Coach
If you are an experienced agile coach who has spent their time in other domains such as software engineering then this content will give you guidance on how to apply your agile practises and patterns in the data domain. It will also give you data terminology you need to understand what the teams are talking about, as with all domains, the data domain has its own unique language and three letter acronyms (TLA’s).
The data domain is close enough to software engineering that a large number of agile patterns from that domain are usable, but data brings a unique challenge over software. The core difference is that with software engineering the team is in control of the end to end process for the applications they create. They are in control of how the data they rely on is generated by users and systems.
In the data domain the teams are ‘given’ the data and have no control on how it was generated, how it is structured or the quality of that data. That brings some challenges to the way they work.
Data Leader
If you are an experienced data leader who has spent their time leading a team of data and analytics specialists, then this content will give you an overview of the agile and product ways of working and patterns which can be leveraged by your team.
It will also give you the agile and product terminology you need to understand what the teams are talking about, as with all domains, the agile and product domains have their own unique language.
As a data leader who decides to empower a team by introducing an agile data way of working (WoW) , there is a massive set of challenges in that simple action. You are empowering a team to work in a very different way, and often in a way that is the polar opposite of the way your organisation typically operates. This step into the unknown introduces a lot of challenges.
<<< TBD >>>
Recommended chapters for you:
Agile Data Coach
<<<TBD>>>
Business Analyst
<<<TBD>>>
Data Analyst
<<<TBD>>>
Data Engineer
<<<TBD>>>
Product Owner
<<<TBD>>>
Scrum Coach
<<<TBD>>>
Photo by Austin Chan on Unsplash