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.
The next layer of our process architecture matryoshka doll is procedures. A procedure provides depth to a process by defining the detail needed to execute the process. I recently was using the bathroom at a client and on mirror had a sticker that provided a procedure to wash my hands (first moisten your hands, apply soap . . . ) . Procedures capture the responsibilities, objectives and tasks needed to accomplish the business goal of a process. Processes may require the execution of multiple procedures in order to deliver value.
Processes and procedures are often conflated. In simple processes, they can be the same, yet for more complex operations the difference is obvious. When my dental hygienist cleans my teeth (process) she uses multiple procedures to complete the cleaning. The first procedure uses the ultrasonic tool to remove the larger pieces of plaque and tartar. The second procedure uses a pick and hand tools for fine cleaning. In this case, the complexity of the process requires several detailed procedures to accomplish the high-level goal of cleaning teeth. In general, processes define breadth and scope while procedures deliver the depth needed to execute.
The final level of our process architecture, the innermost doll, is techniques. Techniques define specific ways to do something and are often tool or material specific. The technique for documenting a user story would be unique for a person using Jira, Version One or Rally. Techniques focus on the lowest level of detail in this architecture.
Developing software, whether to enhance an existing product or to develop something new, is complex. In order to combat complexity, organizations need to simplify the process of delivering value. The pressure to simplify exists even if what is being done no more intrinsically complex than mowing the lawn or brushing our teeth. In order to deliver value on a consistent, repeatable basis we need to agree upon a process architecture that is fit for use. For that architecture to be fit for use each layer of our process architecture matryoshka doll needs to be in harmony. For example, it would be messy to leverage a waterfall framework with Extreme Programing (xP) as the methodology. Sorting out the collision between big upfront designs with a sign-off gate with the iterative planning identified in xP’s planning game would require massive hybridization to both the framework and methodology. Some practitioners hear the words methods, processes and procedure and immediately become apoplectic. The visions are of processes with rigid rules that restrict experimentation or stop teams from making the needed to decisions. Effective teams require a process architecture that makes sure the team has the information and empowerment needed to deliver value. Agile process architectures provide just enough guidance but they necessary to teams to deliver consistently and to work with other teams.