Table of Contents
ToggleIn “Organizational Patterns of Agile Software Development,” authors James O. Coplien and Neil B. Harrison provide an extensive examination of how patterns can enhance the structure and execution of software projects. These patterns are designed to establish organizational wholeness that aligns with and advances the organization’s objectives—improving profitability, increasing productivity, and elevating morale. Delve into this insightful work to uncover the strategies behind agile success.
In this review, I will share some key insights from the book. However, I will not go into detail about each pattern or the pattern languages so that you have a chance to uncover these gems as you read. Instead, my aim here is to give you my takeaways and understanding to help kickstart your journey should you decide to explore the value these organizational patterns have to offer.
What is a Pattern?
Before you can effectively utilize the book’s content, it’s essential to understand what a pattern is and its key elements.
Definition
A pattern is a recurring structural configuration that solves a problem within a specific context, contributing to the overall wholeness of a system—in this case, your organization.
Elements and Characteristics
A pattern is only a pattern if it has the three elements below.
- Small: Applies at a local, team level.
- Collaborative: Encourages teamwork and emergent structures that enhance organizational wholeness.
- Flexible: Can be applied independently or in combination with other patterns.
Pattern Language
The book dives deep into several pattern languages, each designed to tackle different aspects of organizational design and development. Patterns are organized in a certain order, called sequence, within a pattern language.
Pattern languages are structured ways to combine multiple patterns to address complex problems in the organization. They guide you in layering and sequencing patterns for maximum effectiveness.
Types of Pattern Languages in the Book
The book provides four pattern languages grouped based on their intent and purpose.
Design Patterns: Helps you understand the architecture and the relationships of the major parts of the organization.
- Project Management Pattern Language: Focuses on scheduling, process, tasks, and work progress.
- Piecemeal Growth Pattern Language: Describes growing the product and organizational collaboration.
Construction Patterns: Brings the organization to life by putting the design patterns into practice.
- Organization Style Pattern Language: Explores roles and relationships within different organizational styles.
- People and Code Pattern Language: Expands Conway’s Law, correlating organizational structure with the product they produce.
How to Use Pattern Languages
Each pattern language offers a sequence (of patterns)—a story—to guide you through its application. While the book is tailored to help organizations achieve their business objectives, these patterns can be adapted for tasks like constructing a house or designing systems. When constructing a house, Design Patterns lay the groundwork and define the architecture, while Construction Patterns bring these designs to life. Within an organization, these patterns are crafted to aid in structuring and executing actions to effectively tackle organizational challenges. Below are examples of the issues they address:
- Enhancing communication channels for individuals working in the same location or across different geographical areas.
- Managing disruptions while ensuring the team’s continuous progress.
- Achieving task completion by drawing on best practices such as prototyping and embracing an iterative approach.
How to Read and Apply Patterns
Understanding how to read and apply patterns from this book is crucial for maximizing their benefits. The authors recommend for the patterns to be initially read in order. The book is broken down into three main parts:
Part I. History and Introduction
- Overview of Patterns and Organizational Patterns – Defines what patterns are and the intricacies involved with their relationship with pattern languages and application in the organization.
- History and Background of the Patterns – Elaborates on how the authors identified the patterns based on real-life use cases and extensive consultation with practitioners.
- How to Use this Book – Explains the mechanics on how to read and apply the patterns
Part II. The Pattern Languages – Expands on each pattern and their relationships within the Organizational Design and Construction Pattern Languages.
Part III. Foundations and History – Explores the effective way to apply the patterns in the organization.
Part IV. Case Studies – Provides the details on actual use cases where the patterns were effectively used.
Each pattern within the Pattern Language has been written in this format. (See example of a pattern in the information box)
- Name: A descriptive label.
- Stars(*): The number of stars indicate the confidence level and frequency of use.
- Context: The situation where the pattern is applicable.
- Problem/Forces: Describes the crisis or disruption that threatens project progress.
- Solution (starting with ‘Therefore‘): The resolution provided by the pattern.
- Rationale and Examples: Explains why the pattern works and provides relevant examples and related patterns that expands or supports it.
Applying Patterns in Your Organization
The authors highlight that the patterns are not magic remedies for all organizational challenges but provide insightful guidelines for Agile practitioners, project managers, and transformation leaders. The patterns are based on principles that drive towards organizational wholeness that leads to consistent product delivery, balance of communication, higher revenues, and engaged team members. These benefits are only possible with a good understanding of the patterns and the context in which they are applicable.
Here are steps to effectively integrate patterns into your organization:
- Assess the Organization: Identify weak spots and recurring issues that need addressing.
- Focus on organizational wholeness: Patterns intend to support the accomplishment of the organization’s goals.
- Apply a strategic approach: Apply patterns where they can be most successful.
- Take a piecemeal approach: Think locally but aim to impact the whole system.
- Maintain Balance: Communicate clearly and openly.
- Reflect and Adapt: Continuously evaluate the effectiveness and relevance of the patterns.
For transformation leaders and agents responsible for applying these patterns to your organization, here are some key points to remember as you embark on your journey.
- Patterns are applied iteratively and results may take time.
- Multiple paths can be taken based on context and insight.
- Leave room for retrospection to ensure relevance and effectiveness.
- Minimize disruption by timing pattern application appropriately.
- Augment patterns based on organizational practices.
- Trust the process, but ensure patterns are relevant.
- Promote unity of purpose and involve management.
Conclusion
“Organizational Patterns of Agile Software Development” is an invaluable reference for transformation leaders and teams aiming to understand and promote productivity and consistent product delivery. Rather than following it as a prescriptive textbook, leverage the patterns as best practices combined with your insights into your organization’s readiness and maturity. Create a tailored action plan that helps your organization efficiently apply these patterns, driving toward organizational wholeness.
Blogger's note: Comparison with Other Literature
When I first picked up this book, I struggled to connect with it and understand its relationship to agile software development. Could it be the writing style? These days, most of the books I explore present concepts followed by real-world use cases and written in a storytelling style, whereas this one adopts a more textbook approach. As I delved deeper, everything started to click, and I saw how the patterns applied. There are numerous books and frameworks that share similar principles, but these ones stand out due to its relevance and familiarity. Isn’t it fascinating how certain approaches resonate more with us? It’s all about finding the right fit for your learning journey.
- The Big Red Book on Scrum by Jeff and JJ Sutherland emphasizes small teams for effective communication, akin to the “4.2.2 Size the Organization” pattern.
- Scaled Agile Framework (SAFe) focuses on optimizing value streams and team workspaces to establish flow, resonating with the Organizational Style pattern language, specifically the 5.1.12 Shaping the Circulation Realms Pattern*
Use this guide to really get the most out of “Organizational Patterns of Agile Software Development” and boost your organization’s agility and efficiency.
Example 1
Name | 5.1.12 Shaping the Circulation Lanes ** |
Context | Reshape the social network of the organization to move roles closer to or further from the center, more roles closer to or further from the customer, balance load, or otherwise support some pattern of communication structure in the organization. |
Delimiter | + + + |
Forces | Communication cannot happen spontaneously; nor would any configuration of communication to arise in an arbitrary social environment. |
Solution | Create structures in the organization (or work space) that encourage the communication connections that support other patterns. |
Delimiter | + + + |
Rationale | This pattern is a building block for other pattern in the organizational style pattern language, including Organization Follows Market, Developer Controls Process, etc. The goal is to produce an organization with higher overall cohesion, with subparts that are internally cohesive and externally decoupled as possible. |
Related Patterns | Move Responsibilities (5.1.18) Gatekeeper (4.2.10) |
Example 2
Name | 4.1.3 Get On With It ** |
Context | you have a good idea of a market need and you want to get started on part of the project. You want to proceed deliberately and by the path that will be both expedient and productive |
Delimiter | + + + |
Forces | You can't wait until you have every last requirement to get started. But this means that there will be resources who will be |
Solution | As soon as you have some confidence about project direction, start developing areas in which you have high confidence. This may mean working on hardware development ( or procurement), Database schema, algorithm development. |
Delimiter | + + + |
Rationale | Behavioral Requirements of a feature are usually the last things designers get right and are added very late into the code; it usually added to a robust stable base. There may be rework in applying this pattern, but it will be educational, promotes prototyping and exploration, and it's a process that does not constrain the overall system. |