XP Is Simplistic

Managers might say that XP glosses over complexity, or that it replaces thinking
ahead with simplistic naiveté.
They are assuming that your existing approaches handle complexity better and
let you think far enough ahead. Most approaches we have used other than XP simply
don't. They deal with complexity by trying to figure it all out up front. You draw
pictures, create documents, try to cover all the bases and anticipate everything. The
problem is that you're guessing. Pretty pictures are no substitute for experience.
XP is simple, not simplistic. It recognizes the reality that things change. You
cannot predict the future with any degree of accuracy. You cannot plan for
everything. You might guess right, but that's all it is. XP says, "Don't even try."
Instead, do things in a way that lets you respond quickly and well to emergent
reality. What does that look like?
The Planning Game helps to identify items with the biggest risk. We tackle these
first. Planning is so important that we do it daily, based on real experience and a
working system, not once based on our best guess when all we have is theory. Two
sets of eyes see all production code, which minimizes the number of sides that are
"blind." Because there is no code ownership, and we have tests for everything, we
are able to move our best developers to the problem areas that need their expertise,
without leaving the rest of the project in the lurch. And so on.
XP forces a team to find real problems sooner, without having to guess at what
they are. It reduces the number of blind spots. Its rapid feedback allows it to be
simple without being simplistic.
Before assuming too much, ask the manager why he thinks it is simplistic, and
what additional practices he thinks are necessary to make up for the simplicity. If
they can supply them, ask what it is about those practices will help you accomplish
that the other twelve practices do not. In particular as why they think it will get him
the results he wants faster. Often it is a misunderstanding of what the practices are.
We find the biggest objections in this category are that more documentation is
needed to help current and future developers understand the system. See the
sections on Communication and Testing to provide fodder for your argument.