The iron triangle has been redefined several times in the past few years.
There's Jurgen Appelo's Iron Square, Jim Highsmith's Agile Triangle, Max Pool's Iron Line, and any number of other variations. At first glance, these seem like good models which allow us to balance needs.
But There Is a Flaw.
The traditional Iron Triangle concerns itself with things which are quantitative: cost, time to deliver, number of features, etc; while most of the agile permutations have moved to qualitative measurements like value and quality. All of a sudden we are mixing something objective, like time, with something subjective, like value.
So... How Does This Break Things?
By comparing objective and subjective attributes we no longer have the iron nature of the iron triangle. An example: it is possible to increase the amount of value created by doing the most valuable work first. This increases value created while potentially decreasing the amount of time it takes to produce that value! We've "bent iron" so to speak.
We may also introduce practices which decrease time to complete while increasing costs; such as bringing in a domain expert to pair or mob program with us or using test driven design to improve the changeability of our software.
In software and other creative work, adding cost normally means adding people, however Brooks's Law states as we add people to a late project, time to complete increases. This is an instance where the traditional Iron Triangle appears flawed.
So what should we do when trying to apply a triangle to agile practices:
Use Triangles (Iron or Otherwise) as Mental Models.
Triangles help us observe, not control. Find their limits; such as where, when, and why they break down. Challenge assumptions they make and learn what systems they were initially conceived to explain.
Remember: There are no best practices. Only practices with varying degrees of effectiveness depending on the environment in which they are applied.