Iterations create milestone dates, milestone dates force trade off decisions to be made
TD:LR
Data teams struggle to not “boil the ocean” when doing data work.
Use milestones as a pattern to help the data team to focus on what really needs to be built and manage the trade-off decisions for what doesn’t.
Iterations create milestone dates, milestone dates force trade off decisions to be made.
After years of creating and delivering course content for data teams, I still fall into the same trap.
The voice in my head goes “you have most of the content already, you delivered a similar course multiple times before, how much time will it really take to put this one together?”
And the reality is always way more than I think.
It’s the same with data teams.
They always underestimate the time it will take to do the data work.
I once worked with somebody who was a real data geek.
They recorded the data over the years on how they estimated the amount of data work to be done, and how it compared to the actual time they ended up doing that work. They ended up with a ratio of 1 to 2.5. For every hour they estimated, they knew it would typically take them 2.5 hours to complete that work.
The amazing thing is while they knew this ratio, they still always provide the estimate of 1 hour.
Milestones force focus and tradeoffs to happen
One pattern I now use to regulate my constant underestimation is to set a number of milestones before the course is due, typically a dry run through with somebody I know to test out the content.
This way I have “homework” I have to complete before the course is actually due, and I get the extra benefit of being able to iterate the course based on the feedback.
I am using the pattern of iteration to force myself to make trade off decisions on what I have to add and what I can treat as “work that doesn’t need to be done”
Then of course the problem is I want to spend too much time iterating the course until it’s perfect.
But as they say the course will never survive its first engagement with a set of students.
So I get it to the stage where I can run it successfully, run it, and then use that experience to iterate it for next time.
Use milestones to help your data teams, not hinder
So when your data teams use an iteration pattern to manage their data work, remember its a pattern that forces fixed milestone dates and the reason for those milestone dates is to agree on the trade off of what doesn’t need to be done to hit that date.
It also enables the data team to get feedback on their progress to date and change their way of working in the next iteration.
Make sure your data teams do less to hit those dates, not work longer.
Keep making data simply magical
The AgileData Way of Working is our way of sharing our agile, product and data patterns with the world, as after all “sharing is caring”.
You can read more about these patterns over at:
Do more with less
We remove the need to build a large dedicated team of expensive data experts, by reducing the effort to do the data work and by doing the data work for you
Without AgileData
With AgileData
