or, How to Fail with the Unified Process
There are internal IT organizations, books, Web pages, articles, consulting organizations, and speakers that demonstrate these misunderstandings. Be cautious in receiving UP advice or hiring consultants, and apply the tests in the "Signs the UP "Expert" Is Not an Iterative Expert" section on page 198.
Superimposing Waterfall Ideas
The most common of the significant UP misunderstandings, and a quick sign that the UP "expert" actually is not, is to describe the four phases akin to the waterfall phases (requirements, design, implementation, test):
This incorrect description of the UP phases illustrates the most common misunderstanding: superimposition of waterfall phases onto the UP. A corollary of misapplying the waterfall phases includes other common waterfall mistakes in UP adoption:
Other Common Misunderstandings
Error: Iterations too long It is usually a misunderstanding to define iterations of several months long. The UP recommends an iteration length between two and six weeks, excluding massive projects involving hundreds of people and many subteams. Skilled iterative project leaders strive towards shorter timeboxed iterations in the two to four-week range, all other things being equal. One project may be composed of dozens of short iterations.
Error: Iterations aren't timeboxed It is a misunderstanding to let the iteration length expand when it appears the goals can't be met within the original timeframe. Rather, the usual expert strategy is to remove or simplify goals for the iteration.
Error: Iteration doesn't end in an integrated and tested baseline An iteration is not properly complete unless all the software, across all or most subteams, has been integrated, tested, and baselined. It is a misunderstanding to think an iteration simply ends arbitrarily on the end date; the goal is to pull everything together.
Error: Each iteration ends in a production release It is a misunderstanding to think each iteration must end in a production release. Although this is possible (especially during maintenance) it is less common than requiring many iterations before a production release.
Error: Elaboration phase goal is to create a throwaway prototype Prototypes are perfectly acceptable in the UP (usually during inception), but the goal of elaboration is not a throwaway prototype but rather a production subset of the final system. Some have misunderstood this (and some UP books have misadvised on this point) because the original UP and RUP literature itself used the unfortunate choice of phrase "architectural prototype" in a few places to describe the output of elaboration. This confusing term was meant to imply "architectural subset of the final production system" but many interpreted "prototype" to invariably mean throwaway code.
Error: Development Case too complex; too many workproducts It is a misunderstanding to define a Development Case with dozens of UP workproducts, when fewer will suffice. The guideline is "less is better." This is not advice to avoid demonstrably useful documentation, or the forethought that accompanies its creation; the UP recommends creating workproducts that really add value, and abandon make-work or low-value document or model creation.
Error: Predictive planning It is a misunderstanding to create, near the start of the project, a believable plan laying out exactly how many iterations there will be for a long project, their lengths, and what will occur in each.
Error: The team should do lots of modeling and UML diagrams, and use a CASE tool The UP contains several optional models, with many opportunities to apply the UML for diagramming speculative designs before programming. However, these are optional, and if a team can successfully and easily develop software with little or no prior diagramming, they may. Modeling and UML diagramming in the UP are aids to help with complexity and creativity, no more. And it is certainly not necessary to use a CASE or UML drawing tool while modeling on a UP project. The Agile Modeling approach that recommends the simplest possible tool perhaps whiteboard hand sketches and digital cameras is perfectly suitable.
Error: Need many tools It is a misunderstanding to think many software tools need to be applied on an UP project. Rather, it can be run as low-tech, high-touch as paper cards, wall posters, and whiteboards, combined with a sprinkling of CVS, Anthill (for continuous integration), and Bugzilla (for issue and defect tracking).
Error: Software Architecture Document (SAD) "finished" before end of elaboration The UP SAD is a learning aid that summarizes the big ideas and motivation in the architecture. It is a misunderstanding to create the final SAD before the end of elaboration, as that would imply major up-front design, and speculative definition of the architecture without programming. In the UP, the architecture evolves iteration by iteration through an interplay of some educated guesses combined with programming and testing. The architecture is not stabilized until the end of elaboration, after significant programming to build and prove it. Thus, the SAD, which summarizes the architecture, cannot be finished until elaboration is over.
Error: Not conforming to the official UP workproduct names or phase names One purpose of the UP is to establish a common vocabulary, both within an organization and globally across UP-conforming teams, for workproducts and major lifecycle phases. For an organization that is adopting the UP to replace a prior process, it is a misunderstanding to rename the UP workproduct to the older familiar names, rather than surrender to the new terms.
You Know You Didn't Understand the UP When...
Some of the key misunderstandings expressed as a checklist:
Signs the UP "Expert" Is Not an Iterative Expert
UP consultants, authors, and speakers from both major well-known consulting organizations and small shops may exhibit a misunderstanding of the UP and iterative development. Here are some of the key ones illustrated in the behavior of a UP "expert":