Some observations...<p>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.<p>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.<p>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.
I would like to think that an MBA typically goes much deeper. This article instead is pretty shallow.<p>It might suffice to ramp up your knowledge in the direction of knowing enough to be dangerous, though.