Methodology

The topic of Methodology is a recurring topic with current debate focusing on Agile versus traditional approaches. Firstly, what is a methodology?

A definition from Wikipedia is "the analysis of the principles of methods, rules, and postulates employed by a discipline". What does this mean?

In common use within IT, the concept usually means the set of activities, roles, artefacts, and techniques associated with the Software Development Lifecycle (SDLC). Emphasis is usually placed on the Work Breakdown Structure (WBS) – the set of tasks and assignment of tasks to roles, required to deliver a set of outcomes. The debate on Agile versus traditional approaches often focuses on the degree of formalism of the WBS and controls required to deliver the best outcomes. Agile approaches favour individuals and interactions over process and tools. (See the Agile Manifesto.) Overly prescriptive Work Breakdown Structures in a given project context can add significant time and expense to a project without necessarily helping experienced professionals. As a consequence, some development organisations prefer the use of checklists as an aid to professionals to ensure that tasks and dependencies are not forgotten. A pragmatic approach tailors the level of formalism for a given project context including factors such as contractual requirements, team experience and distribution, project size, etc.

This is all good; however, a dimension of methodology that is often glossed over is the content. Systems development is primarily concerned with progressive refinement of a model. The process starts with a model of the business - strategies, objectives, processes, roles, and requirements, which is refined to a model of the system – use cases, data, objects, workflow, etc. The system model is refined to increasing levels of granularity until code is produced, which is still an abstraction above the machine processing instructions.

The efficiency and effectiveness of the Software Development Lifecycle is driven by how quickly the model can be refined with a minimum amount of activity that is not directly related to model refinement, and while still maintaining a high degree of fidelity with the business environment and its needs. Yet how the model is exactly refined from analysis to design to implementation is a mystery to many developers, let alone project managers. This is where a methodology can play a key role in explaining how the models are refined and the linkages between project artefacts to ensure the right information is being captured and produced at each stage of the lifecycle.

A failing that I see with large methodologies such as the Rational Unified Process (RUP) is that because it attempts to support a wide range of project types, it describes a large set of artefacts, but doesn’t describe well how the artefacts support each other; e.g. how does a set of use cases transition to a set of service interface designs.

A useful methodology which supports both novice and experienced developers alike is one that describe the linkages and transitions between the minimum set of artefacts for a given project type. Novice developers benefit from explanations of how to produce a required artefact instead of a table of contents. Experienced developers benefit from agreeing how they will interface with each other to ensure convergence on a common solution without being told "how to suck eggs."

In later articles I will describe an approach I use to transition analysis models to design models.