Adoption Strategies

As always, coaching by an experienced method expert on the first project is recommended. UP adoption is meant to be iterative, incremental, and adaptive. "Big bang" process adoption, where many people are trained near the same time, and/or many UP projects start at once, should be avoided.

First, executive management will benefit from education in some UP concepts (for example, through a short seminar). An executive sponsor should be identified, and discussion of a suitable pilot project initiated.

Then, a pilot project starts. The project should be large enough to be meaningful and interesting, yet not bet-the-bank risky. For example, a 10-person, six-month project.

A UP coach should be responsible for leading the definition of the Development Case, and its refinement during the elaboration phase. Ideally, the coach should be a hands-on developer during the pilot, so that eating their own dogfood is strongly experienced, and the process is realistically refined.

See "Signs the UP "Expert" Is Not an Iterative Expert"

To contrast that, a worst practice is if a "Methods and Practices" group within the organization defines how the organization or a project should adopt the UP. "Armchair process engineers" are not helpful, should be avoided, and often superimpose waterfall values on to the UP, or promote excessive workproduct creation. Take advice on what to do or adopt in the UP from hands-on developers and managers doing early UP projects, in collaboration with a UP coach participating and developing as well. If corporate process engineers are involved in UP adoption recommendations, they should discover and refine recommendations by serving as hands-on developers during pilot projects, rather than by speculation.

A related worst practice is to attempt to fit the UP into the organization's existing concepts and workproduct vocabulary. For example, taking the organization's current lifecycle phases, and believing the UP phases fit within them, or are equal to them. They won't be, and it usually leads to waterfall superimposition. It is a similar mistake to rename the UP artifacts (Vision, etc.) to the old names used by the organization. In short, UP adoption is best done by incremental surrender to a new set of ideas and terms, not by dressing up an old horse in new clothes.

There are many possible practices in the UP. Thus, it is useful in the early iterations assuming a prior culture of low software engineering maturity to start simple and add some practices as the iterations proceed.

After project completion, assuming it was successful and positive, "in-selling" of the UP practices by the project members or customers themselves to others in the organization is better than promotion by outside consultants or management. For example, a lunch-time session where team members share their experiences, pros and cons, with a wider audience.

Assuming there will be a second generation of UP projects, some of the members from the first generation project will ideally move into process engineering roles, and help coach these new projects. The Development Case from the prior projects should be carried forward as a starting point. Therefore, the adoption spreads incrementally.

Another useful activity is a project retrospective that looks at the refined Development Case and ensures it accurately reflects what worked well, and what didn't.