The Risk of Fixing Time and Scope in Non-Lean Software Projects
fagnerbrack.com
fagnerbrack.com
Everything else is an explanation of the project management triangle, including using the image without ever mentioning the triangle directly.
https://en.wikipedia.org/wiki/Project_management_triangle
And it's filled with nonsense that nobody believed ever:
> It’s not worth waiting to learn from a failure that can’t be recovered from.
This seems to follow a pattern in the author's articles: ignore the obvious, show misunderstandings/straw men, and then appear to say something deep.
Consider the TDD article which represents TDD as writing tests after code:
> If you always create a test to justify the code you write, then you never have to worry about writing the code you don’t need.
https://itnext.io/you-dont-know-tdd-691efe670094
Consider the article on JavaScript's success that fails to mention the language being bundled with Netscape and then with all browsers, instead ret-conning reasons into place post facto. Here's a tasty WTF from that piece:
> As developers fluent in Java, C#, Python, and Ruby move into non-coding roles within organizations (see the Peter Principle), a new wave of JavaScript novices has risen to take their place.
https://fagnerbrack.com/the-reasons-behind-javascripts-succe...
In regards to TDD did you actually see the step by step coding doing inside out? You write the test to justify the code you write not the code you've written, which means it's not implying test after the code.
In regards to management triangle I've written so much about that with references that it should be obvious by now what I'm talking about. Besides, the triangle is the first image in the post, what do you mean by not referencing it? It even links to the damn concept. What's the problem of explaining it?
Also, lean is to avoid waste and agile is just too subjective to even mention anywhere as a "thing" other than just a set of principles and values.