Organizational Patterns: A catalyst for change in an Agile environment

These patterns are not finished designs or software components that can be plugged into or generated into actual code, but rather they are guidelines and best practices that display how the relationships between classes or objects interconnect and interact without actually specifying how to do so in some programming language.  This is left for the implementer to decide on.  This was famously published in “Design Patterns: Elements of Reusable Object-Oriented Software” (1994) which outlined 23 classic design patterns and is still referred to and read to this day.

 

This same principle has been applied to organizational design and specifically, how Agile software development projects can be seen and understood within the notion of recurring patterns that describe the “recurring structures of relationship, usually in a professional organization, that help the organization achieve its goals” [http://en.wikipedia.org/wiki/Organizational_patterns].  Utilization of these patterns can be an important inducer and catalyst for change management in an Agile environment.

 

A book by James O. Coplien and Neil B. Harrison, titled “Organizational Patterns of Agile Software Development” is one of the only reference books that attempts to apply organizational patterns within the context of Agile software development projects to identify more effective and re-usable solutions that can be used by a project manager in any solution that is worth a definite read.

 

 

The book is written with an academic style and is based on rigorous research results that comes from a well-executed research projects by the authors and others.  Part I, consisting of chapters 1-3, give an overview of patterns, explain how they were discovered, how the data was obtained, and how you might use the book.  I recommend you read this section even if you are familiar with patterns or at least skim it.

 

The heart of the book is in Part II. This section presents the patterns, organized in two major categories -- organization design and organization construction. There are about one hundred or so patterns in these sections that address most of the situations that organizations of almost any size will encounter as they try to improve their software development process. Some of the patterns are ones that should be very familiar, but are now named in the book.  By describing them at a high level of abstraction, we are provided more semantic context per word then if we were to explain them individually, which is the purpose of patterns in the first place.

 

Some patterns are common sense such as "Get On With It": You know what you need -- at least enough to get started -- so, as soon as you have enough information and some confidence, start developing areas that you have confidence in.  Others such as “Developer Controls Process” recognizes the centrality of the developer in the development of a feature and urges you to make the developer the focal point of process information.  Approaches like this might seem contrary to he way you manage projects, but by having a pattern outlined, it provides you a starting point to define your own patterns.

 

There are two more parts. Part III discusses organizational principles, with advice on how to prepare your organization for change. These are patterns in a different form, but they are an important cog in the machinery of organizational change. Part IV provides case studies that illustrate the application of the principles of Part III and the patterns of Part II.

 

This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions.  This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment.  Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations.  Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.

This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions.  This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment.  Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations.  Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.In the software engineering field, especially with regard to object oriented design and programming, there has been a drive within the past decade and a half to identify recurring patterns in OO design and code that will enable more re-usability and “abstractions”, which are very general descriptions or templates for how to solve a problem that can be used in multiple situations.

 

These patterns are not finished designs or software components that can be plugged into or generated into actual code, but rather they are guidelines and best practices that display how the relationships between classes or objects interconnect and interact without actually specifying how to do so in some programming language.  This is left for the implementer to decide on.  This was famously published in “Design Patterns: Elements of Reusable Object-Oriented Software” (1994) which outlined 23 classic design patterns and is still referred to and read to this day.

 

This same principle has been applied to organizational design and specifically, how Agile software development projects can be seen and understood within the notion of recurring patterns that describe the “recurring structures of relationship, usually in a professional organization, that help the organization achieve its goals” [http://en.wikipedia.org/wiki/Organizational_patterns].  Utilization of these patterns can be an important inducer and catalyst for change management in an Agile environment.

 

A book by James O. Coplien and Neil B. Harrison, titled “Organizational Patterns of Agile Software Development” is one of the only reference books that attempts to apply organizational patterns within the context of Agile software development projects to identify more effective and re-usable solutions that can be used by a project manager in any solution that is worth a definite read.

 

 

The book is written with an academic style and is based on rigorous research results that comes from a well-executed research projects by the authors and others.  Part I, consisting of chapters 1-3, give an overview of patterns, explain how they were discovered, how the data was obtained, and how you might use the book.  I recommend you read this section even if you are familiar with patterns or at least skim it.

 

The heart of the book is in Part II. This section presents the patterns, organized in two major categories -- organization design and organization construction. There are about one hundred or so patterns in these sections that address most of the situations that organizations of almost any size will encounter as they try to improve their software development process. Some of the patterns are ones that should be very familiar, but are now named in the book.  By describing them at a high level of abstraction, we are provided more semantic context per word then if we were to explain them individually, which is the purpose of patterns in the first place.

 

Some patterns are common sense such as "Get On With It": You know what you need -- at least enough to get started -- so, as soon as you have enough information and some confidence, start developing areas that you have confidence in.  Others such as “Developer Controls Process” recognizes the centrality of the developer in the development of a feature and urges you to make the developer the focal point of process information.  Approaches like this might seem contrary to he way you manage projects, but by having a pattern outlined, it provides you a starting point to define your own patterns.

 

There are two more parts. Part III discusses organizational principles, with advice on how to prepare your organization for change. These are patterns in a different form, but they are an important cog in the machinery of organizational change. Part IV provides case studies that illustrate the application of the principles of Part III and the patterns of Part II.

 

This notion of patterns was highly influenced by the architect and theorist Christopher Alexander in his book “A Pattern Language: Towns, Buildings, Construction” (1977), which illustrate how patterns describe a problem and then offer a solution by establishing a set of problems and documented solutions.  This provides a mechanism and metaphor for anyone in a community to improve their towns and cities to effect change and build a better living environment.  Therefore, organizational patterns can be organized into pattern languages: collections of patterns that build on each other providing general descriptions or templates for how to solve a problem that can be used in multiple situations.  Coplien and Harrison’s book provides the project manager an excellent starting point for identifying, building upon and utilizing patterns to act as a catalyst for change in an Agile environment.