It's a bit a "yet another article" about estimates. Still there are a few good points in there, they're harder to apply than it sounds though.

Interesting train of thoughts. Indeed we should keep in mind that large scale software is almost always a complex adaptative system, even more so if we don't forget the people developing it and not just focusing on the code. This can give us guidelines on how to organize the development.

Also does a good recap about what a complex system is and how it behaves. Definitely worth a read at least for this.

Very good advice: stop, status, selection, focus, finish, next. If it feels like "stop starting and start finishing", it's probably no surprise.

Technical debt was an interesting metaphor to kickstart the conversation but has been overused. It can still be useful, especially with the proposed approach here to make it intentional and explicit. This can be factored in how to drive the project.

This is a good summary of the most important points in the PMI body of knowledge. If you dabble in project management it's worth looking at it.

Definitely this. Having "heroes" brings obscurity and hide the problems, this prevents management from knowing and handling the issues. This also create lots of missed opportunities for collective learning and improvements.

Interesting to see the beginning of Kent Beck's thinking about scaling Extreme Programming. This was clearly missing. First by looking at dependencies which are definitely a problem which arises quickly at scale.

This can indeed quickly become a problem. This slows down everything and can bring with ot a silent killer: context switching. It is avoidable though, there are good strategies to prevent WIP to go out of control.

Interesting points about agile and lean approaches. In my view they tend to complete each other, that said the diagnostic of Scrum as practiced in most places today is not Agile is very true. So beware about what you're doing, is it folklore? is it dogmatic? or do you really apply values and principles?

Interesting approach regarding estimates. Might especially make sense combined with kanban like project management.

It's coming from the job interview domain... but I wonder if it could be more largely useful due to how simple it is (but not easy mind you). I guess I'll experiment with it for my next project postmortem.

It's clearly a choice in management style. For such choices, always keep in mind the trade offs this create, maybe it'll push you to revise your choice.

Nice list of things to keep in mind when working on projects, even small personal ones. This greatly improve maintainability in the long run.

A bit heavy handed in the way it tries to paint Root Cause Analysis as evil. Still it has good points about its shortcomings. In particular I appreciate the emphasis on complexity which indeed points to have contributing factors and unexpected outcomes. Definitely things to keep in mind for any postmortem efforts.

Interesting story on how power plays can sometimes completely hide the fate of a project until it's too late. Definitely a cautionary tale.

Very important points. This can easily turn a project into a death march with rampant undue complexity. Also the proposed guidelines are simple and seem efficient.

This is an interesting way to frame it. I generally talk with people about making sure you got vision and horizon in your product backlog (which then requires adequate grooming). Still this sounds like a simpler to grasp wording here. Probably good for a first approach.

Interesting way to highlight Goodhart's Law. Indeed you can be corrupted by the very system you put in place if if it's mainly driven by metrics. As much as possible, think qualitative, not quantitative.

Lots of truth in there. Indeed the proposed "practices" when they get in just kill the promises of things like Scrum.

Good explanations on why trading quality for speed is always a bad idea. It also goes on about how to avoid sacrificing quality through the definition of done and proper estimates.