Table of contents
Dysfunctionalities
Letting dangerous gaps grow unnecessarily
Offline and online
A team should be eager to see their solution in the wild and working. The Offline and Online gap is one of the reasons that will make the offline stage of the project dangerous. In this sense, investing too much effort in the offline stage or working on top of what is only present on it, will increase the gap.
Analysis and production
We talked on the concept of confidence in the problem, speed and quality. Take care of members of the team opting for speed when we have confidence, which will likely create a gap between what the team is building and what we have in production: data, models and analysis generated in multiple messy notebooks is an example of something that won’t make sense in many cases.
One can usually work very closely to production-ready code since the beginning by making smart investments. The confidence on which kind of model we will use might be low and justify a notebook, but the confidence on using a certain group of features can be high and justify working with them following high standards.
Hiding risks and weird results
Analytics projects can branch a lot depending on partial results that come from the data. Everytime we face a number or plot, that’s an information worth sharing with developers. However, it gets even more important when these numbers and plots surprises us.
Getting lost into unimpactful details
One can keep investigation little details in the data and the solution endlessly. Trying to figure our the best way to encode a categorical variable will likely provide a low value. Or trying many approaches to deal with the null values. Notice how these two examples could also be critical for the given project, but as long as the team didn’t agree on it, spending time on it will likely delay it unnecessarily.
Lack of Skepticism
Most of the times, the performance of our times will let us down. But a few times, we get an amazing surprise: a great model, or overall result! Skepticism is crucial to avoid standing in a false stepping stone. Make sure the results are consistent, challenge them, double check.
Siloed developers
We have seen it is bad to have two developers talking directly. However, synchronous communication will happen with a part of the team. In these moments, they should share a summary of the discussion and possible decisions with the whole developers team in their common channel.
These small synchronous decisions can sound harmless, but they compound and will generate confusing conversations at some point.
Handovers
Suspect if only one functional area is working in the project at time. It means the team is not working together as a cross-functional group, but just sliced the project in terms of functions instead of using the principles based on Knowledge and Business value.