Barbecue Recipe

A recipe is a form of procedure!

Models, frameworks, and methodologies are like the three outer layers of a matryoshka doll.  Once we have opened up the layers from models to frameworks and methodologies, components focused on defining “what” steps or tasks needed to build or deliver a product, the next set of layers shift to defining how to do a specific task or groups of tasks. The next three layers of our process architecture matryoshka doll are processes, procedures and techniques.  Each layer is more granular.

Processes are the workhorses of the most software departments. Processes define well-documented, repetitive groups of tasks and decisions needed to achieve an outcome. A simple example of a process is the steps needed to hold a standup meeting. A process provides a view of the main elements needed to meet the processes business goals.



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: (more…)