In "Extreme Programming Explained", Kent Beck strongly advocates the use of oral communication over the written word:
Written communication is inherently more wasteful (...) it is a one-way communication. [p. 23]
Maintain only the code and the tests as permanent artifacts. Generate other documents from the code and tests. Rely on social mechanisms to keep alive important history of the project. [p. 66]
Should we strictly adhere to this? Or was he making such strict statements because at the time there was a ton of useless paperwork/documentation? What should we write and when? (e.g., Architecture Decision Records?)
One of the primary practices of XP is to continuously design just enough to make an implementation that would in turn give us feedback to reach another round of design (on and on...).
But, what is designing then? What is the process of design? Is there any process we should follow? Is it just refactoring or something else? Does this produce an artifact (e.g., a document) or just code?
And when do we do it? Before a sprint? Before a task? As we go along?
Finally, how do we socialize this practice? Does it make sense to do "pair/mob designing"? Is this just part of the regular "pair programming" practice?
Fortunately, Kent Beck didn't think "soldiers gonna soldier" (work just good enough not to be noticed because of low performance). This is extremely important in XP, because it believes that social dynamics and focusing on the collective outcome are the keys to success:
Without a change of heart, all the practices and principles in the world will produce only small, short-term gains. You and the rest of the team [business, product...] share a fate. [p. 154]
The Theory of Constraints shares with other theories of organizational change the assumption that the whole organization is focused on overall throughput, not on micro-optimization. [p. 99]
However, and in the own words of Kent Beck:
If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance? [p. 99]
The reward system and culture need to align with overall throughput instead of individual productivity.
Are we just in the hands of our own intrinsic motivations and culture? When hiring... is it as easy (or as hard) as finding people with the right attitude? What can we do ourselves to inspire/create such an environment? What can we do to make sure we work on things that are less visible and might get less individual recognition (a needed refactor vs. an additional feature)?