The Problem of Completeness
In terms of completeness, each process definition—large or small—wants to describe a complete process. Where the authors set out to describe a single area of the process, they inevitably end up trying to describe them all, typically in a tightly coupled and homogeneous fashion.
When processes are published, their creators often find it hard to resist describing every aspect of software development. Even when they do, the methodologists who follow in their footsteps generally try to fill in the gaps. The end result is that, as time passes, every process strives to be complete. But is this a problem?
For methodologists, it doesn't seem to be a problem. They happily "borrow" ideas from one another, adding spin, and in some cases, getting it wrong. If you speak to people using the processes—those who do real software development—this is a significant problem. By striving for completeness, the processes end up as brittle, all-or-nothing propositions. This makes it hard for teams to adopt just the good parts of the process and identify truly new ideas and techniques.
The desire to provide a complete process also makes the process heavier as more and more information is added to cover all of the disciplines involved. As the process evolves, no one ever takes anything out because someone somewhere might need it some day (a day that never seems to come). If a process is successful, then the desire to keep it up to date and extend its market leads it to become even heavier as more information is added to expand its scope, add new techniques, and address new challenges. This leads to the need for organizations, practitioners, and methodologists to start trimming to get a lighter, more-focused process. We don't think this is the way to go. You shouldn't need to spend time deselecting the things you don't want. You should be able to start from a small, useful kernel of information, then add the guidance you need.
The Problem of Adopting a Complete Process
When it comes to adopting a complete process, each software team has its own way of working (explicit or tacit). Changing everything is silly, changing one thing may be smart.
Adopting a new process presents teams with many challenges, especially as they will already have their own way of working. This may be expressed explicitly as a documented process or it may be more tacit. Within the team's way of working, there are always good practices that they will want to continue using. Other areas of the process will be weaker and lead to the desire for change. The problem with the branded processes is that they do not address this reality and require the team to change everything just to get the few new things that they want.
The same is true for organizations where, in addition to the many available processes, they have their own in-house processes that have evolved whilst developing their software. Generally, they might like to improve these processes, but adopting another (branded) process would be too big a change. You should be able to add and drop practices as needed.
