XP Is Too Informal

Managers may take issue with XP not having lots of documentation. They may
claim that XP is an excuse to code like a cowboy – it's hacking without
documenting. They might also think that Stories aren't formal enough to give
programmers enough information.
The most common source of the informality objection is a bad experience in the
past. Most managers have been burned before. They have no desire to repeat the
unpleasant experience. But they throw the baby out with the bathwater. They assume
that formality will increase their chances of winning. Nothing could be further from
the truth.
Lots of documents do not make software better. Clearer code does. The only
way to keep code clean is not to clutter it up with unnecessary stuff, and to scrub as
you go. XP lets you concentrate on doing both. Build only what the Stories for the
current iteration call for. Refactor mercilessly.
Using Stories instead of detailed specs is no excuse for being lazy. We still have
to get all of the requirements. We just don't need all of the details for ones thatwon't be implemented for a while. Experience tells us that these will be completely
different then anyway. Remember that a Story is a commitment to have a future
conversation to flesh out the details. You need to verify the details of any Story
before you implement it, so we defer the detail gathering until then. XP requires that
you produce all necessary documentation, but discourages production of
unnecessary wallpaper.
By the way, why is an approach that encourages us to write tests before we code
less formal than one that makes us write documentation before we code? It's often
important to question the value of formality and focus on what we really want…
results. If the formality we are familiar with gets us the results we want, why
change? The only reason to change is if the informality gets us the results we want
faster, cheaper, and/or more reliably. Call us crazy, but we'd go with running tests
over paper documentation anyday when we are looking for reliability. If reliability
doesn't matter, then all that's left is faster and cheaper. We're going out on a limb
here, but we'd venture to say that producing formal documentation does not make
the process faster or cheaper.
What you need to point out is that many of those skills are still needed. Their
ability to do "architecture" is still needed. They need to help find a Metaphor and
make sure people are focused on how the pieces fit together. They just need to do
more of it via verbal communication and interaction. Instead of being frustrated that
people don't understand their architecture and that they don't have time to make it
work, their time will be freed up to spend more time communicating the
architectural issues and assisting the other developers. As a bonus, their hands-on
technology skills will increase.