something that we advise our clients on all the time, and is a major portion that I think takes people by surprise sometimes, is that most organizations is that their default is to treat their data science projects like software engineering projects that they’re currently running at the organization

something that we advise our clients on all the time, and is a major portion that I think takes people by surprise sometimes, is that most organizations is that their default is to treat their data science projects like software engineering projects that they’re currently running at the organization. So if they want their data scientists to be filling out Jira tickets and have Sprints. Not only the data scientists, but data engineering is not a similar task like that either. And the platform architecture too, is similar. They all share something in common. in data science, data engineering, and platform architecture, it’s one of those things where you can spend forever on something and it won’t be done. So, it’s all about, “When do I feel like stopping?” Or, “When do I run out of money?” Rather than, “Okay, this application is done. I’ll ship it, it’s in a box. It’s all good to go. We release it to the world and we sell it. It’s great.” On the data science side it’s hard to tell how long something’s going to take until you do it. So there’s this chicken and egg problem. I can’t write the Jira ticket it’s going to take two weeks, until I actually spend the two weeks to do it, and realize it’s actually going to take four weeks. And so when you try to apply these traditional software engineering project management things on these projects it doesn’t work. It actually causes harm in a lot of cases….there’s actually a new discipline that needs to arise. — https://blog.dominodatalab.com/collaboration-data-science-data-engineering-true-false/