Nesting Easter eggs show each layer of the process improvement architecture

One of my children owned a (Russian nesting doll) that is now somewhere in our attic.  I was always struck how one piece fit within the other and how getting the assembly out of order generated a mess. I think I learned more from the toy than my children did.  The matryoshka doll is a wonderful metaphor for models, frameworks, and methodologies. A model represents the outside shell into which a framework fits followed by the next doll representing a methodology placed inside the framework. Like models, frameworks, and methodologies, each individual doll is unique, but they are related to the whole group of dolls.


Models, the outside layer of our doll, are an abstraction that provides a rough definition of practices and inter-relationships needed by an organization to deliver a product or service. Models are valuable if they are theoretically consistent, fit the real world  and have predictive power. All firms or groups use a model as a pattern to generate a structure.  For example, the hierarchical corporation is a common model for commercial organizations (visualize an organization chart). The Capability Maturity Model Integration – Development (CMMI-DEV) is a model leveraged in many software development organizations. The CMMI provides a core set of practices that organizations have typically needed to deliver software. The CMMI defines an outline of what needs to be done but not how or in what order. The model that is chosen influences the models and methods that will be leveraged by different layers of the organization.  For example, an organization using a lean start-up model for their corporate governance model might not see the CMMI-DEV model a viable for their development organization (we will discuss this common misperception later on the blog).

Frameworks, the next inner layer in our process architecture matryoshka doll, provide the structure needed to implement a model (or some part of the a model).  Shifting the operational metaphor we are using for a moment to that of a skyscraper, the framework is the lattice like a frame that supports all of the components in the superstructure.  The Scaled Agile Framework Enterprise is a framework which leverages other frameworks and methods as tools to deliver value. SAFe defines the flow of work from an organization’s portfolio to the Agile teams that will develop and integrate the code. The Framework calls leverages other frameworks and methodologies such as DevOps, Scrum, Kanban and Extreme Programing. 

Methods, nestled inside of frameworks, provide an approach to achieve a specific goal.  In software development, methodologies define (or impose) a disciplined set of the processes so that developing software is more predictable and more efficient. The difference between Agile and heavier methods is the amount of structure that defined. Agile methods provide only just enough structure to allow the method embrace the principles stated in the Agile Manifesto. Extreme Programming is another software development methodology.   

Each layer of our process architecture matryoshka doll is a step closer to a core set of steps and tasks. The doll metaphor is not perfect.  Some small start-up organizations may not seem to need the structure of a framework or may even eschew a method until they grow. In an interview for the Software Process and Measurement Cast, Vinay Patankar, CEO of Process Street, said that as he and his partner began their start-up they used a code and fix approach, but growth forced the adoption of Agile as framework combined with Scrum and Extreme Programing (at least parts) as methodologies. A model provides an environment to implement a framework. You would not implement SAFe inside a waterfall model. Methodologies are the tools that translate a framework into something actionable. Without one or more or of the layers in our doll, what remains of the doll might make a better rattle than a tool to deliver software.