Values

In contrast to XP and Scrum, the UP does not make explicit a set of underlying values, although some can be inferred. And whereas the XP values emphasize human and communication qualities, the UP values emphasize a project-oriented rather than people-oriented focus. These include:

• It is important to apply the UP guidelines and best practices. Some UP values logically follow from this, such as iterative is better than waterfall, having a cohesive architecture is good, change control must be formalized, and so forth.

• Be risk- and value-driven. That is, in early iterations, identify and drive down the high risks and build elements deemed of highest value to the stakeholders.

• It is important to define a clear vision (in the UP Vision workproduct) for the project that summarizes the stakeholders' real needs.

• It is critical that the UP process be tailored to the unique needs of each project while still observing the best practices. Plus, be tailored to the minimal set of workproducts and activities that add value.

• It is useful to have a well-defined process that provides guidance on activities, on what artifacts to create, and on the tasks of individuals and the team.

UP as a Heavy, Defined Process versus an Agile UP Approach

It is this last value that is a point of contention in the UP compared to the classic agile methods. Some in the agile process community have dismissed off-handedly the idea that a defined process such as the UP is useful, and that it is too "heavyweight," but the issue is more nuanced.

for a discussion of defined vs. empirical methods

First, the UP creators did not intend the process to be applied or adopted in a rigid or heavyweight manner; they are experienced and practical software developers who also appreciate simplicity and agility. They view the UP as a suite of options to pick from, within the constraints of adopting its spirit and best practices.

Another perspective on this issue is offered by Cockburn, who describes three levels of behavior and listening as people mature in learning a subject [Cockburn02]: 1) following, 2) detaching, and 3) fluent. He relates this to literature and guidance for software methods by noting that Level-3 advice such as terse "work in a common project room and deliver usable software every four weeks" may be suitable for the fluent master, but not for the novice following developer. The detailed defined process aspects of the UP are aimed especially at a Level-1 audience, and in that context are of some value for learning, and as quality assurance checklists.

Level-2 and Level-3 developers may ignore the prescriptive and defined aspects of the UP, such as what tasks to do in what order, and instead focus more simply on choosing a set of UP workproducts to create, applying the best practices, and realizing these according to the creative judgment of the team in a more empirical process spirit.

A second issue in the value of defined processes is repeatability and avoiding re-invention. There are at least a few predictable, repeatable, useful steps in deploying a system to production, such as writing release notes. The UP makes explicit this advice (which is especially useful for the Level-1 audience), whereas the agile methods do not.

A third point in the value of defined processes is having a common vocabulary for artifacts, such as the UP Vision and Design Model. The UP provides such a vocabulary, which removes the need for each project to recreate one, and promotes communication across projects and organizations.

The issue of defined versus empirical processes for software projects boils down to a matter of balance and moderation. Certainly, rigid command-control sequencing of fine-grained, predefined activities is not skillful on most software projects, but on the other hand, some aspects of defined processes add value and can be applied in an agile and empirical spirit, as some activities are predictable for example, many related to deployment.

Given a set of iteration goals, a self-directed team doing daily Scrum meetings can be characterized as applying the UP if it creates a few UP workproducts and follows its best practices, but is driven by the dynamic and creative judgment of the team, rather than by following a UP recipe of ordered activities.

In summary, the UP although a semi-defined process can be and is applied by some in an agile style.