Some observations...

The section "Signs of a Dysfunctional Software Development Lifecycle" ignores a very common reason for "Your team is always in crunch mode" mainly that the stakeholders insist on unreasonable goals even though the team says it's not realistic because individual team members are not empowered to make decisions.

And under "Post-Mortems and Retrospectives" something doesn't seem right. I'm not sure how I feel about focussing on individual team members failings that way. You can't change who a person is as quick as you can change policy. I feel it is better to have the policy gently nudge John in a direction that discourages destructive overconfidence.

Edit: the appendix also seems a bit dangerous in that I'm now envisioning a bunch of MBAs going to their chief architect... we have data scaling issues? Why don't you just encode that field as a 0 or 1 instead of male/female.

Thanks for the observations.

Other people have made the same observation about the signs of the dysfunctional process table. When I wrote it, I was including stakeholders and managers as part of "team". So the scenario you describe would be the business side of the team not managing the scope properly. I'll need to update the table to be clearer.

I agree that people don't change quickly. In those cases, you need to adapt the process to guardrail them (e.g., add a check in the workflow) or put a different person in that role. If you don't, you're just going to get the same result again in the future.

For your edit -- is that a bad thing? Presumably a architect should be able to explain their decisions. The major theme of the guide is that communication is a good thing, especially when the different people are likely working with different information and expertise.

Thank you, great article. I enjoyed it and I wish all managers would read this.

Fair point, the manager should be considered under the team umbrella. The stakeholder isn't always a manager, though. Sometimes it's a client. And one of the hardest things to do is say no to a client.

I think all my criticism boils down to: guiding the discussion can be great, dictating the discussion is not. Some MBAs (any managers, really) have a hard time drawing that line.

One of the toughest things when you're starting a company is to let go and trust your team. You don't have to solve every issue personally if you hire smart people and empower them, which I don't think this article quite gets across. I'm not saying there aren't times you have to personally step in, because there certainly are.

One thing this does not touch on is prioritization. How do you decide what gets built and what doesn't? But there are countless article and books on that.

I would like to think that an MBA typically goes much deeper. This article instead is pretty shallow.

It might suffice to ramp up your knowledge in the direction of knowing enough to be dangerous, though.

You're correct that a class on software project management would go deeper into some of the topics.

This article is more aimed at getting a baseline conceptual understanding so that you can figure out where and when to dig deeper.