Yes, it does mention these things. Perhaps not early enough? The "really happens"/disasters are towards the end of Part I, and there are few project cartoons giving hints.
There's so much to cover, I started out with the formal stuff first. It seemed like a good order, but perhaps it is a bit off-putting at the beginning of the book.
I'll argue that, as a book for students, it works better in the way of formality and then some informality/real examples/exceptions. it's necessary a base to compare ideas before explaining differences in a model. It becomes easier to understand, and therefore, study.
Why are "really happens" and "disasters" associated together? I assume by "really happens" you mean the ways reality departs from what's in the book -- but when process varies over time, adapts to different personnel, business circumstances, tech capabilities, etc., instead of remaining rigid, like ironically rigid adherence to Agile despite variation in the above-mentioned characteristics, that is what leads to disaster.
I'd see strict adherence to any sort of one-size-fits-all recipe for workflow management as a greater sign of disaster than healthy compromise, accommodation for individual working styles, and respect for the human need for autonomy and self-direction.
Right. I'm not talking about bad outcomes in the grandparent. Far from it. I'm more interested in the fact that project participants will for example fabricate a fake manifestation of a process (fake[1] project plans, fake task lists, fake design documents) for the benefit of external folks asking them to "follow process". Meanwhile they get on with building the product "The Way we Actually Do it[2]", successfully. This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.
[1] By fake I don't mean fraudulent but rather something that has as its only purpose to meet the needs of the process enforcement. For example a requirements document that nobody reads after it has been written, or a design document written before the manner in which the problem will be solved is well understood (and is therefore never read). Project plans that somehow turn out to have underestimated effort by 3X...
> This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.
See, I think this is actually intentional. The "process" itself exists to give management a surface area of metrics they can datamine for their own political needs, more or less independent from the actual success of the project or team.
I liken it to creating Dutch books. With each layer of management you go up, the pressure to create Dutch books that provide you with blame insurance and protect your bonus -- crucially, diversified across all different business outcomes -- gets more intense, and the people who pull this off get compensated hugely and can often make leaps into C-level executive teams.
Lower level managers might not consciously know about this, and on one hand may actually think there's some truly redeeming reason to care about the frivolous, irrelevant metrics (e.g. Agile burndown). But the higher up you go, the more directly and unabashedly people openly function honestly -- they know the metrics are bullshit; they know that you know that they know the metrics are bullshit ... they don't care ... they are just getting on with their own business of political games to diversify away bonus risk and arrange for metrics-based blame stories for scapegoats.
It's not that it's confusing where the credit lies. It's that people know the credit does not lie with the formalized process at all but that they need that excuse in order to politically manage how they get their share of the credit.
Unfortunately, I think despite the OP's strong efforts to present the topic in a useful, taxonomic way, the sad thing is that treating formalized process with this degree of veneration at all simply perpetuates the political system that needs inexperienced developers to roll over and play dead to the system.
This phenomenon can be confusing because outsiders might conclude that the process led to success when in fact it was the presence of people who knew how to build software successfully that led to success and the perception of process was a mirage.
Yes, was just an off the cuff remark, not completely accurate.
The book does take the time to provide alternates at many points. It should explain "what really happens," but it first does that for waterfall, then spiral, and agile, etc. If you are reading the waterfall part, for example, your "really happens" is going to be different if you are currently working under Agile. To avoid info-overload I've tried not to explain everything at once, but of course that means valid points have to wait until later.
There's so much to cover, I started out with the formal stuff first. It seemed like a good order, but perhaps it is a bit off-putting at the beginning of the book.