I've been in professional development for about 17 years.  If you add in classroom and hobby development that number goes up to about 25.   That's a modest history in the industry, and not nearly as much as some people I've had the privilege of working with.  With my time, I've seen several fads come and go.  Developers or managers may consider the tool or process to be the greatest thing and implement it everywhere, even when it is counter productive.  These ideological strategies can be found in management formulas, languages, frameworks and include such concepts as object-oriented, functional programming, agile, scrum, story points, test driven development, lambdas, factories, micro-services, and pair programming.

Some of these are great ideas and represent some nuggets of wisdom accumulated over the years.  However, they also frequently have drawbacks.  Especially when used within a rigid dogmatic environment that does little self review or internal introspection when seeking for improvements.  You are also blind to the drawbacks when your available experience pool, including devs and management, does not understand when these tools are good and when they are not.  The result is often handing out hammers when we are trying to put in screws.  To make it even harder, even with excellent teams with broad and deep experience, the project can still be sufficiently new and unknown that mistakes are still made in selecting the baseline process and tools to move forward.

There are some general principles I try to use that help guide teams to customize their process as well as allow for fluid technology choices that provide higher development velocities and result in better systems.

Frequent Common Sense Reviews

This is the first cultural item to have present.  Review the usefulness of the processes followed.  Review the systems being build, the languages and frameworks being used.  Don't be afraid of a pivot if the cost/benefit ratio justifies it.  I do suggest that this be both formal, informal, and anonymous.  

Many details and struggles just don't come out in formal inquiry, especially from management.  There is an unstated expectation that performance be good, and devs like to look good.  There is also a vested interested in decisions already made.  Though some lines of questions do help this.  "If you could start this project over again with what you know now, what would you do differently?"

In informal settings.  "I really love that build system Frank put together, it's so slick.  What's your favorite bit of code?" and it's brother "I really dislike the release process of this framework, I find every update is a royal pain.  What part of the system do you least like to touch?"

These conversations should happen, and they should form the basis for some of the reviews of the potential problem areas.

Do the Hard Part First

I've been part of a lot of waterfall (successful and not) and agile (successful and not) designs, big projects and small projects.  I believe that this bit of wisdom is not widely shared or represented in the popular development methodologies today.  I've seen projects stall out with schedules that extend meeting after meeting with a customer upset, managers frustrated, devs shrugging with consistent reports along the lines of "we're trying, we're not sure..." as they struggle with the unknown.  Where as previously, the project was generally on track.

It can be tempting to dive into the funnest parts.  Or for those with more discipline what you consider the foundation of the system.  You may schedule it all out, and find it tempting to put that high risk stuff at the end.  I've done that myself!  And then I paid for it.  Experience can be a harsh teacher.

I have found it is worthwhile to dive into what will be the hardest or least understood part of the project first.  Leave all the well understood parts scaffolded or stubbed out and build that unknown piece first.  Eliminate your risk as your first development priority.  This is a pre-MVP trial run or proof of concept.  You may have to do it with a few disparate unconnected pieces.

Of course we make the best choices we can, and these choices are going to be the most costly to modify in the long run.  I believe that the more or larger the unknowns that are present in the system the more important it is to validate these choices while it is still within reach to change them.  If your choices will show themselves to be less than optimal - this is how you get to that revelation faster than if you start somewhere easy or fundamental.  "This isn't the best language choice for this problem..."  "This framework does NOT help us here, it's getting in the way..."  "This architecture is PAINFUL...".  After these choices are pounded into the wood by building the easy stuff, it's a lot harder to extract that bent screw.

Experience is important in this process.  The set of unknowns will be smaller when you have good senior level talent to guide you.  Especially with experience in building that system or a similar one.  With less space to explore you can finish the trial, then validate and pivot if necessary with less time and cost.

No Sacred Cows

The pros and cons must be weighed as objectively as possible.  Write it down, and be honest with yourself, acknowledge your preferences.  "I LOVE this pattern", "I hate non-OO languages", etc.  Pull extensively from your experience pool in this as well as the best industry voices you can find when reviewing the lists of tools.

Don't be afraid of some trial time and small projects to expand local experience and vet tools.  I believe that healthy tech organizations will be doing this reasonably regularly with many techs to create a broad base understanding of the tools in the industry and which ones would be most beneficial in certain circumstances.