Having followed the process as described, i'd agree. If a project runs for more than a few months, you forget why decisions were made. I don't think XP in general has a great story about how to deal with this.

I'd be less worried about "forgetting" and forever worried about a manager just saying "you obviously forgot (something I just decided)". I mean it happens even when there's documentation I can pull up and say "well actually..", I'd hate to imagine otherwise.

I love email for this. That way I can always pull up the email and say, "this is what we decided." I follow up all meetings with email(s).

Yes, this is one of my pet peeves.

Pivotal R&D has struggled with maintaining context. For multi-megaSLOC codebases with many moving parts, organic memory begins to fall a bit short.

Different teams deal with this differently. Some write design notes, some keep architecture design records. But IMO it's one of our weaknesses.

An answer there would likely be smaller teams. For context, when I was at Pivotal (on the consulting side, years ago) a team of 4-5 pairs would be considered quite large.

Also a problem that's solved by the combination of pairing and frequent communication. You don't need full context on anything yourself, as long as the combination of you, your pair, and anyone you can grab within arms reach can fill in the blanks.

We invented books because human memory storage is phenomenally expensive. Why throw them awaym

"The dimmest ink is superior to the brightest memory" - so said Benjamin Franklin or maybe someone else.

I find requirements start changing as soon as there is a conversation about them or a user interacts with a feature.

This practice is just saving time writing down behaviour that won't be implemented.

But if you don't have a few paragraphs of your assumptions written down, how do you keep the 3 other people aligned on your basic assumptions and direction?

What do you do when people forget things?

4) Requirements are conveyed verbally, not through written documents. Stories are short "reminders to hold a conversation," not fully-fleshed out.

There's still something written down, just not massive amounts.

Personally i try break stories down smaller to avoid the need for large tasks which helps. I also try minimise the time between story creation and story development.

Otherwise I just communicate a lot.

Things get differently from what I invisioned, sometimes they're worse sometimes they're better.

You artfully interrupt them and always keep watch on what other people are doing!