1481963246_fc8d418e34_o

Similar, but not the same.

Models, frameworks, methods, processes, procedures, and the list goes on and on.  Whether we are discussing Agile or plan based software development, works like methods, models, frameworks, processes and others are often used.  The people that use these terms in polite conversation often assume or imply a hierarchy in these terms.  For example, a model might include one or more frameworks and be instantiated in several methods. Each layer in the hierarchy breaks down into one or more items at the next level. Words and their definitions are an important tool to help understand how all the pieces and parts fit together and how to interpret the conversations about how software is developed and maintained in the lunch room or in hallways at conferences like Agile 2016. The unfortunate part is that few people agree on the hierarchy of models, methods, and frameworks.  These words are often used synonymously sowing seeds of confusion and mass hysteria (ok , that might be a teeny tiny overstatement). 

A proposed process hierarchy or architecture is as follows:

Components focused on defining “what” steps or tasks needed to build or deliver a product. This level of a component often encompasses many patterns of work. For example, the Scaled Agile Framework (SAFe) includes tracks for both software and systems engineering and includes optional paths for very large value streams as well as programs.  Each path is a different combination of lower level components to deliver a type of specific product.

The outer levels of the hierarchy that define what needs to be done include:

  1. Model – Abstractions of complex ideas and concepts that we find useful to explain the world around us. The CMMI is a model.
  2. Framework – A logical structure for organizing a set of processes, procedures, techniques and tools for delivering products. SAFe is a framework
  3. Methodology – An approach (usually documented and often branded) for performing activities consistently and repeatability to achieve a particular goal. Extreme Programming, as defined by Kent Beck, is a methodology.

Components focused on defining “how” to do a specific task or group of tasks.  The inner levels of the hierarchy translate the “whats” so they can be accomplished on a repeatable basis.  They explain how to accomplish work.  As the how components are decomposed they become more granular. A process, as defined in ISO, would be a group of steps to generate an outcome. For example, an organisation might define a process for continuous integration which would include many procedures (nightly code builds and smoke testing might be two procedures). At the lowest level, we might include specific techniques that could be used when executing the procedure. 

The inner levels of the hierarchy that define how to accomplish what needs to be done and include:

  1. Process – A defined set of steps for delivering a specific outcome. The activity triggered by pushing the garage door opener is a process.  
  2. Procedure – A defined set of actions conducted in a specific order to achieve a specific step (or subgroup of steps) within a process. The set of instructions packed in the Ikea box for assembling the table in my living room is a procedure.
  3. Technique – A way of accomplishing a specific task or step in a procedure. The three questions is a technique for holding a stand-up meeting.
  4. Template – A pattern used provide guidance or standardization for a specific deliverable.  The famous “persona-goal-benefit” format is a template for user stories.

When discussing the adoption of Agile or process improvement the discussion invariably drifts into a discussion of the models, methodologies and processes that the organisation will leverage.  Often the first round of  these discussions includes a lot of confusion because not everyone using the same set of words or at least not in the same way.  Just to make sure this confusion was not mine alone, I asked several people, including methodologist, developers, testers, scrum masters and testers, how they would structure the process architecture or hierarchy without providing definitional guidance.  The responses varied widely, although the “what” and the “how” components clustered together. Words matter because they affect how we understand and react when we hear them (assuming we are listening). Unless we have a common set of definitions it is hard to have a valuable conversation. 

Next articles in this theme include:

  1. The differences between models, frameworks, and methodologies
  2. The differences between processes, procedures, and techniques
  3. Process hierarchies: Is there a simpler way?