There's a danger in taking best practices too far and applying them at the wrong time or in the wrong situation, and it's a big challenge for leaders who are struggling to advise teams--the leaders are also learning what works and what doesn't while the teams are learning.
As an example:
User stories are commonly used in Agile organizations, and they are often estimated in story points. A team estimates each story in its product backlog, and knowing the team's velocity, we can predict when the work reflected in the backlog will be done. At the beginning of a project, the team knows the least amount of information about the work itself--they will learn more as the project progresses. There is value in estimating the product backlog before the project starts and estimating the team's velocity as an initial estimate for the project, but it's just that: the initial estimate. It will be refined as the project progresses and the team learns more about the work. When estimating the stories at the beginning of the project, it's common for some of them to be epic in size--in fact, that's good. Epics can be broken down later when the team has more information, so they put a larger story point size on the epic for now as a high level estimate. But if estimating stories is good and breaking them down into smaller stories is good, wouldn't it be good to break down all of the epics from the start and estimate those?
Not necessarily. Are heads going to roll if the estimate is wrong? The team has to spend more time and effort trying to break down those epics at the beginning of the project, and remember, this is when they know the least information about the work itself. How likely is it that the stories will not change drastically by the time they get to those stories in the product backlog? Or that the stories will be needed at all? Epics help keep some of the details vague so the requirements can emerge later.
For every best practice, it's important to know why it is a best practice and when it is best applied. Some of that will come through trial and error, and some of it can come from reading and talking to others outside your organization.