24 April 2010

The one methodology that works for all product development teams

... is unique, it is highly-context specific.

The conclusion that every product development organisation or project team should develop and follow a context-specific methodology is inescapable. The best we can do, is pay attention to deep context-specific knowledge, and to record this knowledge in modular methodology building blocks that are tied to a specific scope of applicability.

It is helpful to look at the value chain of an organisation from the perspective of a decision making process, and to think about the way in which decisions tend to be recorded, and the way in which decisions are implemented. This quickly leads to the familiar concept of a work product or artefact, and to the concepts of artefact producers and consumers.

In any non-trivial value chain there are roles and systems that produce template artefacts that are intended for completion by other roles and systems further downstream. A closer analysis of this observation leads to the conclusion that normal business operation encompasses a continuous extension and evolution of the organisational vocabulary. These vocabulary changes need to be fed back into the organisation's methodology; otherwise the methodology slowly but surely becomes less and less useful.

Distinguishing between software development and operational business is becoming more and more anachronistic. Many decisions are directly recorded in software, and they have a direct impact on the organisation and its operation.

Artefact producers routinely make the mistake of assuming that their work is done when an artefact has been handed over to downstream consumers. Communication and collaboration is never that simple.

The desired intent and the semantics of a vocabulary (and syntax)
 can only be aligned through 
extensive instantiation 
and semantic processing 
of example artefacts.

Any multi-step value chain directly leads to the need for a highly iterative product design and development process. The easier it is to
  1. define artefact templates,
  2. to instantiate artefacts,
  3. and to attach appropriate semantic processing,
the faster artefact producers and consumers are able to establish a shared understanding of the products that are being designed.

It is not uncommon for deep organisation-specific domain knowledge to be lacking. All knowledge regarding a particular process may for example be "encrypted" in programming languages, and none of the authors of the software may still be alive/available.

Attempting to reconstruct deep knowledge from old source code of a large software system can amount to economic suicide. Additionally, it is far from clear to what extent the encrypted decision making process (knowledge) is optimal or desirable in today's context. In this scenario organisations are desperate for a silver bullet methodology that can act as a substitute for lost knowledge.

Unfortunately the only medicine that can address the issue of lost or lacking knowledge head-on is a proper analysis of the context (value chain) in which the software must/should operate today.

The good news is that the required problem domain analysis techniques are available. The bad news is that there is no silver bullet that eliminates the need for having (or obtaining) an in-depth understanding of the value chain of an organisation.

No comments:

Post a Comment