De-Couple Stages

...a design and implementation process have been established for a well-understood domain. Well-understood, high-context domains have less need for patterns like BuildPrototypes and can actually proceed well according to a standard waterfall model. 

✥ ✥ ✥

Development stages should be independent to reduce coupling and promote autonomy of teams and developers. There is a tradition of decoupling architecture, design, and coding in a development process. While this doesn't make sense for most software development -- and is especially suspect for greenfield development -- it sometimes makes sense in mature, high-context development projects. But there is still a trade-off: while independence creates opportunities for parallelism, it also hampers information flow. 

Therefore: 

For known and mature domains, serialize the steps. Hand offs between steps should take place via well-defined interfaces. This makes it possible to automate one or more of the steps, or to create a pattern that lets inexpert staff carry out the step. 

✥ ✥ ✥

The new organization allows for specialization in carrying out parts of the process, rather than emphasizing specialization in solving the customer problem. 

This approach is "safe" only for well-understood domains, where the mapping from needs to implementation is straightforward. Domains that are well-understood are also good candidates for mechanization. For less mature domains, the process should build on the creativity of those involved at each stage of the process, and there should be more parallelism and interworking. 

You can afford to do this in high-context, mature areas because the patterns of work are repeatable and rarely bring surprises. That means that each stage can be carried out independently. That means less communication between stages, which means better efficiency. One can further raise the efficiency by building on specializations and domain knowledge pertinent to individual stages. Example domains include database administration (with steps such as database modeling, normalization, and query optimization), packaging, delivery and installation, and many administrative functions like bug tracking or the high-level business processes supporting field error report resolution. 

Though interfaces between process steps help insulate the steps from each other, these interfaces should also be effective and useful. These interfaces shouldn't exist for their own sake or empire-building, or even to establish formal organization boundaries. They should encapsulate well-understood domains of control that ease hand offs between stages. If the interfaces increase cost and latency, they are wrong: either they have been implemented improperly or they shouldn't be there at all.