Organizational Patterns: Building on the Agile Pattern Foundations

Agile Project Management

Vol. 6, No. 6 Organizational Patterns: Building on the Agile Pattern Foundations

by James O. Coplien, Neil B. Harrison, and Gertrud Bjørnvig

What really works in software development management?

Practices and deep organizational structures — what the

authors refer to as organizational patterns — that result in

customer satisfaction and lay the foundation for organizational

adaptability and agility. The following Executive Report

discusses the top 10 patterns that successful organizations and

teams have used and provides a framework within which you

can customize these practices for your own enterprise. Cutter Business Technology Council

Rob Austin Tom DeMarco Christine Davis Lynne Ellyn Jim Highsmith Tim Lister Ken Orr Lou Mazzucchelli Ed Yourdon

Access to the About Cutter Consortium

Experts Cutter Consortium is a truly unique IT advisory firm, comprising a group of more than 100 internationally recognized experts who have come together to offer content, consulting, and training to our clients. These experts are committed to delivering top-level, critical, and objective advice. They have done, and are doing, groundbreaking work in organizations worldwide, helping companies deal with issues in the core areas of software development and agile project management, enterprise architecture, business technology trends and strategies, enterprise risk management, metrics, and sourcing.

Cutter offers a different value proposition than other IT research firms: We give you Access to the Experts. You get practitioners’ points of view, derived from hands-on experience with the same critical issues you are facing, not the perspective of a desk-bound analyst who can only make predictions and observations on what’s happening in the marketplace. With Cutter Consortium, you get the best practices and lessons learned from the world’s leading experts; experts who are implementing these techniques at companies like yours right now.

Cutter’s clients are able to tap into its expertise in a variety of formats including content via online advisory services and journals, mentoring, workshops, training, and consulting. And by customizing our information products and training/ consulting services, you get the solutions you need, while staying within your budget.

Cutter Consortium’s philosophy is that there is no single right solution for all enterprises, or all departments within one enterprise, or even all projects within a department. Cutter believes that the complexity of the business-technology issues confronting corporations today demands multiple detailed perspectives from which a company can view its opportunities and risks in order to make the right strategic and tactical decisions. The simplistic pronouncements other analyst firms make do not take into account the unique situation of each organization. This is another reason to present the several sides to each issue: to enable clients to determine the course of action that best fits their unique situation.

For more information, contact Cutter Consortium at +1 781 648 8700 or [email protected]. Organizational Patterns: Building on the Agile Pattern Foundations AGILE PROJECT MANAGEMENT ADVISORY SERVICE Executive Report, Vol. 6, No. 6

by James O. Coplien, Neil B. Harrison, and Gertrud Bjørnvig

INTRODUCTION got excited about it and brought productivity and quality can be the solution in the door. But now redressed. You’re a project manager, an you’re not sure whether you’re executive, a line manager, or following the technique correctly, Organization and management maybe even a developer, and you or even if you did, whether the are about people. We know have more than a hunch that you technique would save you. You Conway’s Law, a heuristic that could deliver high-quality software don’t know whether it might suggests a close tie between the faster. You believe that you really be the technique itself that is technical issues of architecture could meet those schedules and strangling you. and the human issues of organiza- that you really could meet require- tional structure. Conway’s Law ments regularly, if only … The answers aren’t trivial, but holds that the structure of any IT there are answers. It’s impossible system reflects the structure of the But it’s difficult to put your finger to manage a healthy, successful organization that builds it. This on the “if only.” Once in a while, software project without manag- principle works at human scale: it you get a glimpse of an improve- ing the organization itself. And addresses relationships, software ment opportunity: after a chance unless you shape the patterns of structures, organizational struc- meeting with a customer or a relationship, communication, and tures, and processes that people particularly good or bad group software assembly in an organiza- deal with at a deep level through- meeting, you get a glimpse of a tion, you aren’t really managing out their workday. There are other breakthrough. Yes, you’re already the organization. It is at these celebrated principles of organiza- following this or that management foundations of organization and tion and management at the book, methodology, or fad. And management where the systemic, enterprise level. While they have it sounds good — or at least it long-term problems of software their place in an overall corporate sounded good when the group framework, they are rarely of 2 AGILE PROJECT MANAGEMENT ADVISORY SERVICE direct value to software managers coauthor of Agile Software moment but a form of project and developers and, in fact, are Development with SCRUM [23], management that shapes your often detrimental. The principles writes: organization for the future while of agile and the patterns of soft- honoring short-term project goals. ware development organizations Although “agile develop- Each pattern individually achieves ment” perhaps was first operate at human scale, at the practiced by LISP pro- a small improvement. The pat- center of the concerns of the grammers in the 1960’s, terns are designed to amplify one project manager, product man- Organizational Patterns is another so that, over time, you ager, and the other roles that perhaps the first documenta- reap the benefits of major restruc- touch the bits and bytes that tion that ever existed on true turing with the low risk of local agile development. No one, delight your customers and to my knowledge, had incremental change. Patterns are sustain your business. done so before. (Not Scrum, unlike many process improve- which started in 1993, nor ment programs that touch only Over a period of more than 10 XP which started much later, the symptoms of software devel- years, we have studied hundreds etc.). [3] opment failure or are limited to of software development teams to simple cause-and-effect analyses While all 100 patterns have a role answer the question “What really that fail to redress systemic prob- in making organizations strong, a works in software development lems. This Executive Report helps remarkably small number of pat- management?” As time went on, to repair, grow, and revitalize terns form the successful core it became clear which practices your organization by shaping structures of agile organizations. and organizational structures its foundations in small steps. In this Executive Report, we pre- result in customer satisfaction and Furthermore, it puts structures sent the top 10 patterns from our lay the foundation for organiza- in place that help keep your orga- extensive research over the past tional adaptability and agility. We nization agile. found, researched, validated, and 12 years. These top 10 patterns documented about 100 of these might be all you need to turn your A New Twist on Old Ideas configurations. We call them organization around. They cer- The patterns of successful organi- “organizational patterns,” or deep tainly lay a broad foundation for zations are well established. Many structures that define the culture powerful software process of them have long been known as of a software development organi- improvement. This report is a hallmarks of great organizations, zation. Our results are collected in primer and get-started-quick pack- and you will recognize many from the work Organizational Patterns age on organizational patterns. the literature or your own experi- of Agile Software Development Deeper Than Processes ence. Our work on patterns of [10]. This work captures the struc- software agility adds two compo- tural foundations of agile software Patterns are a crucial tool of orga- nents to this mature body of litera- development practice, and as nizational design because they go ture. First, it defines and fills in the such, it is one of the best practical deeper than processes or an orga- broad spectrum that ranges from starting points for agile process nizational chart. They are not just managerial practices all the way improvement. Mike Beedle, project management for the down to software implementation

The Agile Project Management Advisory Service Executive Report is published by the Cutter Consortium, 37 Broadway, Suite 1, Arlington, MA 02474-5552, USA. Client Services: Tel: +1 781 641 9876 or, within North America, +1 800 492 1650; Fax: +1 781 648 1950 or, within North America, +1 800 888 1816; E-mail: [email protected]; Web site: www.cutter.com. Managing Editor: Cindy Swain, E-mail: [email protected]. Group Publisher: Kara Letourneau, E-mail: [email protected]. Production Editor: Lauren S. Horwitz, E-mail: [email protected]. ISSN: 1536-2981. ©2005 by Cutter Consortium. All rights reserved. Unauthorized reproduction in any form, including photocopying, faxing, and image scanning, is against the law. Reprints make an excellent training tool. For more information about reprints and/or back issues of Cutter Consortium publications, call +1 781 648 8700 or e-mail [email protected].

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 3 and the practices of those who system problems, guiding archi- went beyond software architec- create it. These two ends of the tectural structure, and solving the ture to explore the realm of project management spectrum problems germane to software human behavior. In the following are much more closely connected development. The Pasteur project year, Cutter Consortium Senior than either a manager or software was an applied research project Consultant Alistair Cockburn engineer might realize. Without that explored how to extend exist- published “Prioritizing Forces in tying together these two perspec- ing approaches to reach the more Software Design” [7], and Ward tives — and many others — it’s fundamental, recurring problems Cunningham published his difficult to attack the system con- of software development. Unlike EPISODES pattern language [13]. cerns that are the most serious many process improvement The former would become threats to a software enterprise. efforts, it was based on empirical one of the foundations of the studies and, thus, an understand- AgileAlliance, and the latter lent Second, it ties together these pat- ing of what works in the real major structure to XP. All these terns according to how they build world. The empirical groundings works had a pattern focus and on one another. Instead of being are a perfect match for a disci- emanated from the pattern com- a list or partitioning of individual pline grounded in empiricism: munity. In the meantime, Scrum rules, these patterns are linked software patterns. also drew on the roots of the to one another so that you can Pasteur project and in particular assemble them into a structure In August 1993, the software pat- on one of the Pasteur case studies that repairs and strengthens your tern discipline was born at a published in Dr. Dobb’s Journal, organization incrementally workshop in Colorado, USA. It a study on the Quattro Pro for through a process guided by was at this meeting that some of Windows development project both experience and feedback. the early structural findings of the at Borland [9]. Pasteur project found their way The Patterns and Agile into pattern form. A collection of Most branches of the agile move- All major agile disciplines have organizational patterns grew; and ment trace back to these original their roots in the work that under- by the fall of 1994, a collection of organizational patterns. It took lies these patterns. These patterns about 40 organizational patterns several years to refine these have their origins in a project at existed. Coauthor James Coplien patterns, understand how they Bell Laboratories that was affec- presented these patterns at the worked together in practice, and tionately called the Pasteur project first pattern conference in Allerton combine them into sequences — a pun on the “cultural” nature Park, Illinois, where Cutter that would generate successful of Petri dishes one might associ- Consortium Senior Consultant software development organiza- ate with the pioneer Louis Kent Beck helped to shepherd the tions. The branches were brought Pasteur. The goal of the project work, providing feedback on the back together in the 2004 book was to analyze the culture of conference paper. Beck would Organizational Patterns. The col- software development organiza- later cite Coplien as one of three lection was edited by two of the tions using techniques from the influences in his work on Extreme coauthors of this report, James social sciences. At the time, most Programming (XP) [2]. Coplien and Neil Harrison, into software improvement work a cohesive and broad work built Other organizational pattern was grounded either in ISO 9000 on the original core patterns but works soon followed, including efforts or the SEI’s Capability that drew heavily on patterns — papers presented at the same Maturity Model (CMM®). Each whether in “pattern form” or conference by Norman Kerth [18] had its shortcomings in addressing not — from the branches of the and Bruce Whitenack [25] that agile movement.

Agility and Adaptiveness organizational structures, tools, history, and staff that make it principles, and processes. unique. Each pattern must be fit To be agile means to have the to the context where it applies. ability to ride out the unexpected As envisioned by Cutter Different organizations require dif- and to capitalize on flexibility. An Consortium Agile Project ferent combinations of patterns organization is a living thing: it Management Practice Director for healing and growth. grows and shrinks, reorganizes Jim Highsmith or by Alistair itself according to its environment, Cockburn, the agile discipline — Organizational patterns provide a and responds to its environment. or organizational patterns — isn’t kit of organizational structures that It never stands still. A good organi- only about agility in the develop- you can assemble according to zation isn’t rigid but can bend with ment organization; it’s also about the needs of your business, adapt- the winds of change. Taken to an agility in the principles them- ing each pattern to your organiza- extreme, however, flexibility selves. One doesn’t follow a tion as you go. You and your becomes a weakness. Strength method to be agile; rather, agile organization, rather than the pat- comes from structure. With struc- encompasses a management style terns themselves, are in charge. ture, an organization can coordi- that is responsive to its environ- Each organization follows its own nate its members to do things that ment. Agile patterns build not only path to evolve with these patterns no single member can do. on the responsiveness that comes and is unique in the world at each from feedback but also on the stage of development. Extreme Programming suggests a empirical evidence that provides structure based on programmers, managers with the assurance that PRINCIPLES OF a coach, a team of a certain size, an individual improvement has ORGANIZATIONAL CHANGE and — in its foundations — the low risk. Smalltalk programming language. Systems Thinking Also in its foundations are strong A Kit, Not a Religion To move beyond individual Band- admonitions against free combi- Aids that attempt cause-and-effect Organizations have their own nations of the principles and prac- attacks on problems, and to com- culture. The earth sustains innu- tices; the structure is relatively bine small patterns to bring about merable human cultures, each fixed. This structure gives XP proj- emergent change, is a powerful one of which is “successful” in ects a degree of agility in a certain form of systems thinking. Most the sense that it has evolved over context, most notably in small, process-based approaches are decades, centuries, or even mil- single-thread Smalltalk program- locked in cause-and-effect mod- lennia to adapt to the climate, his- ming projects. els, which lead to the belief that tory, and makeup of the area. A you can be in control. To change a book on organizations can no However, the foundations of XP system requires subtle changes at more describe how to build an cannot easily adapt to projects a level deeper than process; you ideal organization than a book on outside this context; rather than must change its structure. One anthropology can describe how adapting to you, it asks that you reason that agile approaches have to form an ideal culture. Just as adapt to it. Such adaptation too promise is that they are grounded there is no single ideal culture, often discards the gems of insight in the deepest foundations of sys- there is no single ideal organiza- that are the core competencies of tems thinking: those of principles tion. What makes an organization an enterprise. Good organizational and values. Principles and values ideal in its context is that it meets improvement builds on the give rise to the structure of an the business’s needs that define strengths of the existing orga- organization. We can communi- that context. Each organization nization, which include its cate the structure of a system as has its own business climate,

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 5 patterns of relationship between the change is transitory, because have an empirical basis, and we its parts, and the parts themselves the structure will eventually win have taken great care to find the can reflect patterns of recurring out. On the other hand, if you try proper ordering that allows them structure. The structure of a sys- to go too deeply too quickly, you to amplify one another. tem generates its processes as we increase risk. Changing the value consider in process improvement system or principles of an organi- Why Use Patterns? approaches such as ISO 9001. zation takes time, often cannot Patterns are about structure, and Figure 1 shows how patterns fit be done directly, and in any case lasting organizational change can in systems thinking in the domain cannot be done without making happen at no more shallow a of software development. structural changes. As structural level than that of the organiza- changes, patterns provide a tional structure. Perhaps more For example, consider the process good balance between the important, the pattern approach of pair programming or code process level and the level of is a systems thinking approach inspections in your organization. values and principles. that embodies many key elements Why do you have these proc- of a philosophy of organizational esses? They come about because Patterns also provide a unifying growth. Among these principles of a relationship between one set formalism with wide applicability. are systems thinking, piecemeal of individuals (the coders or dri- A pattern can change the organi- growth and local repair of an vers) and another set of individu- zational structure by adding a organization, feedback, and als (the reviewers or observers), role, adding a relationship human comfort. each of which bring different per- between existing roles, constrain- spectives to a design problem. ing size, changing communica- The best way to understand a These relationships come about tions paths, or through numerous pattern is as a structure-preserving from the structure of the organiza- other restructurings. All of these transformation of an organization tion. Why does the structure exist structural changes combine to structure. A pattern adds local as it does? The structure owes improve the organization. All the structure to a system while retain- much to the organizational princi- patterns we discuss in this report ing the overall major rhythms of ples and values by which the organization came together. We have reviewers and observers because we value the diverse skills necessary to build a quality product. We Code Recommitment Unit Inspection Meeting Test Processes have managers and developers both because we want a desig- nated position that supports the coders as they produce the artifact Developer Function Owner Architect Engage for which customers will pay Controls and Component Also Structure Customers Owner Process Implements (Patterns) money and because we don’t want developers to be sidetracked by common management issues.

One mistake is to effect organiza- Individuals Customer Product Embrace Agile Values tional change at too shallow a and Interactions Contact Focus Change and Principles level. If you try to change process without changing the structure, Figure 1 — Systems thinking in software development.

©2005 CUTTER CONSORTIUM VOL. 6, NO. 6 6 AGILE PROJECT MANAGEMENT ADVISORY SERVICE the system to which it is applied. making change possible. After developers combine their knowl- A pattern makes it possible to you apply a few patterns — per- edge of their code with the knowl- effect change while maintaining haps with very little noticeable edge of customer needs that you continuity. Pattern-based change improvement from individual convey to them that they are able is incremental change, and incre- steps — the patterns start to to use the pattern DEVELOPER mental change is low-risk. work together to attack system CONTROLS PROCESS. Now you problems. notice that productivity starts 1 Complex Things Are Complicated taking off. It couldn’t happen if For example, your problem may One reason that organizational developers were overloaded; it be that developer productivity change is so difficult is that orga- couldn’t happen if their flow was is low. You encourage developers, nizations are complex. A single distracted by outsiders. All three even buy them tools, and it simple change to an organization patterns work closely together. doesn’t seem to help. You might can influence only one thread of try spreading their work more The order of pattern introduction interactions or one facet of orga- evenly so that underutilized peo- is important. Later in this report, nizational structure, and that ple get more work and saturated we discuss a pattern language, single fix is likely to go unnoticed people have time to recharge. which is a grammar of sorts that in light of the myriad other inter- Now morale is a bit better, but guides you through a sequence of actions and other facets of orga- productivity doesn’t change. They patterns to build and repair your nizational structure. A local have good contact with cus- organization. change can make things better tomers: you may have been flying locally, but unless there is an the customers to your site once a THE TOP 10 PATTERNS ongoing process of change — week to meet with developers through the application of other The book Organizational Patterns for two days. You might read the patterns — to make room for of Agile Software Development FIREWALLS pattern and decide that pattern to grow throughout contains approximately 100 pat- that these developers’ exposure to the organization, the global struc- terns divided into four pattern customers is too much of a good ture will eventually silence the languages. Some of these patterns thing, so as a manager, you start individual local change. are fundamental because they filtering some of the interactions establish the common broad foun- between customers and develop- One can’t bring about large dations of almost all software ers. You convey key notions gener- organizational impact by making development organizations, while ated by customers to developers a large organizational change; other patterns are either germane but also free up developers’ time instead, one has to combine to specific kinds of software spent interacting with customers, multiple small changes that development or describe the fine which gives developers 20 more are applied in a process of local structures found only in the most hours a week to produce code. adaptation and piecemeal growth. mature organizations. These changes eventually make This also gives you more time room for one another to have with developers, and you try to However, the scale of the pattern impact, and things start to fall into guide them so that their work isn’t always the best indicator of place. Don’t think of patterns as best meets project needs. Still, success. As the architect Mies changing your organization, but as the efforts don’t quite seem to van der Rohe noted, God is in get off the ground. The two pat- the details. An organization can’t 1 This idea is not a tautology but an insight that terns DISTRIBUTE WORK EVENLY really fly until its rough edges bears deep consideration — think about it. and FIREWALLS remove some Many thanks to Dave Vlack for this apparent become a bit polished. It is likely Yogiism. obstacles, but it’s not until the

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 7 that a small number of these together. Often, people have and surpass them, respectively. As patterns provide most of the foun- different ideas about what the time goes on, UNITY OF PURPOSE dations for success in most soft- final product should be. In fact, continues to emerge from ongo- ware development organizations. the final product may well be a ing dialogue within the team and This section describes 10 critical pretty fuzzy concept. Yet people with customers and other stake- organizational patterns. All other must have a consistent view of holders. While the team leader patterns not described in detail in the product if there is any hope of primes the pump, team dynamics this report are discussed at greater completing it. Each person is take over and give a project length in Organizational Patterns. different and has different views momentum. and opinions. They come with 1. UNITY OF PURPOSE different backgrounds and experi- 2. ENGAGE CUSTOMERS ences, and they must learn to work together. It is important The obvious result is that the team 3. DOMAIN EXPERTISE IN ROLES to get off to a good start; initial works together rather than at cross-purposes. A more subtle yet 4. ARCHITECT CONTROLS impressions, good or bad, tend probably more powerful effect is PRODUCT to be lasting. what healthy team dynamics can 5. DISTRIBUTE WORK EVENLY Therefore: The leader of the do for the morale of the team. The best teams tend to believe 6. FUNCTION OWNER AND project must instill a common that they are somehow better COMPONENT OWNER vision and purpose in all members of the team. This “leader,” than others — and they work to 7. MERCENARY ANALYST whether a manager, a worker prove it! This pattern relates to some deep-seated principles and 8. ARCHITECT ALSO IMPLEMENTS installed in the PATRON ROLE, or a customer advocate, should be values of organizational health. 9. FIREWALLS someone who has the team’s There may be no more important property of an organization than 10. DEVELOPER CONTROLS respect and influence over the PROCESS team’s thinking. Gaining respect that its members have a shared and influence requires overt vision that they are motivated to UNITY OF PURPOSE2 action; you can’t count on it hap- achieve. Communication — … The team is beginning to pening automatically. The leader which receives the bulk of the come together. Team mem- should ensure that everyone attention in this report — is just bers may come from differ- agrees on the following questions: a means to achieve that shared ent backgrounds and may What is the product supposed to vision. Thus, UNITY OF PURPOSE bring with them many differ- is a deeper principle than even ent experiences. do? Who are the customers, and how will the product help them? effective communication; com- What is the schedule? Does every- munication is just a means to the end — UNITY OF PURPOSE. Many projects have rocky begin- one feel committed to the sched- nings as people struggle to work ule? Who is the competition? An important component of these … team unification exercises is to ENGAGE CUSTOMERS 2With the exception of FUNCTION OWNER identify the strengths of the team AND COMPONENT OWNER, these patterns are and to use these strengths as … An organization is in adapted from Organizational Patterns and are rallying points. The team thus place, and its QA function reproduced with the gracious permission of has been generally shaped Prentice Hall publishers. Some section cross- identifies the challenges and com- references and passages within the book have and chartered. The QA func- been omitted. petition and unites to overcome tion needs input to drive its

work. Many people in the in turn, must understand how Two elements are necessary enterprise are concerned people will use the product in a to allow this interaction to about quality issues. way that creates value for them. happen: opportunity and culture. Good value sometimes leads to Developers must have the oppor- good market potential, but mar- tunity (and the means) to com- It’s important that the develop- keting usually looks at other municate with customers. They ment organization ensures and factors (e.g., brand-name recogni- should meet customers personally maintains customer satisfaction tion, product name, and posturing to establish trust and a free flow by encouraging communication in the market) that designers care of communication. between customers and key little about. But if the organizational culture development organization roles. Missing customer requirements is builds walls between customers This communication isn’t the a serious problem; in fact, most and developers, these visits will responsibility of any single cus- problems in software systems can be superficial. In particular, if tomer satisfaction group; instead, be traced to requirements prob- system requirements must go the need pervades the entire orga- lems [5, 14]. Yet it seems like so through a lengthy formal process nizational structure. Most organi- much effort to elicit these require- to be approved, the developer will zations hesitate to allow direct ments, especially when the work be hamstrung, unable to respond contact between developers and does not directly produce a mar- to customer requests. Therefore, customers, fearing that the devel- ketable artifact. It seems like the organization must develop a opers are loose cannons who will make-work. culture in which developers promise to deliver things that have some latitude to respond to exceed the scope of a job. Customers are traditionally not customers. We’re not saying, how- part of the mainstream develop- Yet you can’t know all of the ever, that all control of require- ment effort, which makes it diffi- requirements up front, so devel- ments should be given to the cult to discover and incorporate opers constantly need to go back developer. Order is necessary. their insights. Yet customer con- to customers for more informa- tact correlates with project suc- As Hugh Beyer and Karen tion. In turn, customers constantly cess [17]. Trust relationships Holtzblatt note, “Many common need to come back to developers between managers and coders ways of working with customers with their insights, particularly are often strained, so you don’t remove [designers] from their when developers BUILD PROTO- want them to be the sole interme- work” [4]. One way to solve this TYPES. After all, requirements diaries between developers and problem is by “putting designers changes occur even after design customers. and engineers directly in the cus- reviews are complete and coding tomer’s work context” [4], a par- has begun. Therefore: Closely couple the ticularly important activity if you customer role with the devel- Many organizations depend on use customer engagement to cre- oper and architect roles, not their marketing units to provide ate wholly new market directions just with QA or marketing roles. requirements data, but marketing for the enterprise rather than sim- In short, developers and archi- doesn’t provide design data [4]. ply to refine existing work. Putting tects must talk freely and often The best that marketing can — or developers in the customer’s with customers. When possible, should — do is understand what work environment also trains engage customers in their own will sell and why people will buy developers’ intuition about good environment rather than bring- what you want to sell. Designers, design and human interfaces, ing them into yours. and this intuition can fill in when

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 9 specific detailed requirements A good understanding of customer case modeling (see [4]). The pat- are unavailable [4]. needs can help you avoid rework tern is called ENGAGE CUSTOMERS after implementation is done. (note the plural) to support a Language is a key element of While it is also important to con- domain view and to avoid the culture that can ensure a smooth tinuously engage customers possibility of being blindsided by customer engagement if treated through each development a single customer. properly and can smother it if episode of iteration, early under- treated badly. Don’t make your standing helps launch the effort in The project must be careful to customers learn UML or other the right direction. For example, a temper interactions between cus- technical notations; instead, do Navision team in Copenhagen, tomers and developers, using your best to learn their language Denmark, believes that improve- FIREWALLS, GATEKEEPER, and the and to communicate with them in ments in customer engagement QA organizational presence, as the terms of their culture. helped save time on its develop- in ENGAGE QUALITY ASSURANCE. ment schedule. A major part of interacting with The QA team can monitor the customers involves learning how relationship to keep the direction Some processes and methods are they want to interact with the within contractual business limits founded on customer engage- project as the unfolding software while allowing a free flow of ment, such as IBM’s joint applica- uncovers problems in require- insights back and forth between tion development (JAD). Other ments and systems engineering developers and customers. Such methods are conducive to cus- (APPLICATION DESIGN IS BOUNDED communication can often flow tomer engagement, such as BY TEST DESIGN). unimpeded; at other times, how- Cunningham and Beck’s class ever, it cannot (see the GATE- responsibility collaborator (CRC) Note that maintenance of product KEEPER pattern). Note that the design technique. Other methods, quality is not the problem being GATEKEEPER pattern is all about and especially most CASE-based solved here. Product quality is relationships and culture. It is methods, are indifferent or harm- only one component of customer the culture of respect for and ful to customer engagement. satisfaction. One study shows that interaction with customers that 20% of customers will leave a makes the communication effec- Even some of the best customer company for another when they tive, such as during the writing engagement techniques tend to believe that they are being of use cases, which is described end once the parties achieve ignored and that 50% of cus- in PARTICIPATING AUDIENCE [6]. some level of contractual agree- tomers will defect when the ment about what is to be deliv- attention they receive is rude or ered. Customer engagement in unhelpful [26]. If customers agile processes, however, goes experience software problems ENGAGE CUSTOMERS supports far beyond this traditional stopping that cost more than US $100 to fix, requirements discovery from the point. Developers need to assimi- and if the company does not fix customer, as dictated by the pat- late the context in which their these problems, only 9% of the terns SCENARIOS DEFINE PROBLEM product will be used; this proc- customers would continue to and BUILD PROTOTYPES. Other ess is called contextual design. do business with the company; patterns like FIREWALLS also Contextual design means 82% would do business with the build on this pattern. The pattern gathering data on customers’ company again if the problems RECOMMITMENT MEETING is a more models of how they do their work were quickly resolved following formal derivative of this pattern in rather than on how the program the company’s receipt of a different context. will solve the problem, as in use complaint [26].

… Spreading expertise across roles becoming overly dependent on complicates communication a small number of individuals. DOMAIN EXPERTISE IN ROLES patterns. It makes it difficult for … You know the key atomic a developer or other project … process roles (FORM FOLLOWS member to know whom to turn FUNCTION), including a char- to for answers to domain-specific ARCHITECT CONTROLS PRODUCT acterization of the developer requirements and design … An organization of devel- role. questions. opers needs strategic technical direction. Therefore: Hire domain experts Matching staff with roles with proven track records, and staff the project with the exper- is one of the most difficult Even though a product is tise embodied in their roles. challenges of a growing and designed by many individuals, Teams and groups tend to form dynamic organization. All roles a project must strive to give the around areas of common domain must be staffed with qualified product elegance and cohesive- interest and focus. As mentioned, individuals. Just as in a play, ness. One might achieve this end any actor may fill several roles, several actors may be assigned by centralizing control, but most and in many cases, multiple to a single role, and any actor development teams view such actors can fill a given role. may play several roles. control as a draconian measure. One person can’t do everything, Domain training is more important You’d like to use domain- and no one has perfect foresight. than process training. Organi- nonspecific qualification criteria However, the right information zations can benefit from having like college grades or years of must flow through the right roles, local gurus in all areas from appli- experience to qualify people for and individual areas of compe- cation expertise to expertise in jobs. Such an approach gives the tency and expertise must still be methods and language. project flexibility in staff alloca- engaged. Furthermore, there tion, and it helps it avoid being needs to be some level of archi- overly dependent on individual tectural vision. While some skill sets and experience. In short, DOMAIN EXPERTISE IN ROLES domain expertise is distributed the hope that such criteria might is a tool that helps ensure that through the ranks of the develop- work provides project managers roles can be successfully carried ment team (DOMAIN EXPERTISE IN with a basis for keeping the proj- out. It also helps make roles ROLES), the system view — and, ect from becoming overly depen- autonomous. Empirically, highly in particular, the design principles dent on certain individuals who productive projects hire deeply that create a common culture for may leave or who may hold the specialized experts. dialogue and construction — usu- organization hostage to gain ally benefits from the conceptual higher salaries or to see their own … integrity we associate with a sin- policies implemented unilaterally. gle mind or small group. Nonetheless, successful projects If expertise becomes too narrow, tend to be staffed not with the organization is at risk of losing Therefore: Create an architect employees who possess textbook key expertise in the event that a role as an embodiment of the qualifications but with those who single person leaves, is promoted, principles that define an archi- have already worked on success- and so on. Temper this pattern tectural style for the project ful projects. with MODERATE TRUCK NUMBER, and of the broad domain exper- which prevents the project from tise that legitimizes such a style.

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 11

The architect role should advise, We have no designer role, result (MODERATE TRUCK NUM- influence, and communicate because design is really the whole BER). Also, if there is a conscious closely with developer roles. task. Managers fill a supporting plan for architects to review The architect doesn’t dictate inter- role; empirically, they are rarely everything, they — in their capac- faces (other than in cases necessi- seen as controlling a process ity as developers (ARCHITECT ALSO tating arbitration). Instead, the other than during crises. IMPLEMENTS) — may swoop down architect builds consensus with and fix things that are the respon- individual developers and devel- While the architect controls the sibility of others (CODE OWNER- oper subteams. architectural direction, the DEVEL- SHIP), which can be demoralizing OPER CONTROLS PROCESS, and for the original code author. The The architect is the principal there is still an OWNER PER DELIV- architect can review everything if bridge builder between develop- ERABLE. The architect is a chief the role still defers to the implement team members. The archi- developer (see ARCHITECT ALSO menter for execution as well as tect should also be in close touch IMPLEMENTS) or, as Christopher the decision about making the with customers to ensure that Alexander describes himself, a change (STAND-UP MEETING). the domain expertise is current, “master builder” [1]. The archi- detailed, and relevant. tect’s responsibilities include Architectural control must balance understanding requirements, developer authority and the role of framing the major system struc- keeper of the flame. Architects ture, and guiding the long-term should not tread on developers’ This pattern does for the architec- evolution of that structure. The sense of code ownership or own- ture what the PATRON ROLE pat- architect controls the product in ership of code development tern does for the organization: it the visualization process that processes. Architects intervene in provides technical focus and a ral- accompanies the pattern ENGAGE processes largely at the business lying point for both technical and QUALITY ASSURANCE. level and should meddle in imple- market-related work. The archi- mentation processes only in tect doesn’t control the product in Because ORGANIZATION FOLLOWS exceptional circumstances. any dictatorial sense; instead, the LOCATION and because of CON- architect provides inspirational WAY’S LAW, there should probably … guiding and leadership. We could be an architect at each location. have called this pattern ARCHITECT Architects can be the focus of DISTRIBUTE WORK EVENLY LEADS PRODUCT or ARCHITECT local allegiance, which is one of … An organization is working GUIDES PRODUCT, but these varia- the most powerful cultural forces to organize itself in a way tions have their own problematic in geographically distributed that makes the environment as enjoyable as possible and connotations. development. that makes the most effective use of human resources. Resentment can build against a A more passive way of imple- totalitarian architect, so patterns menting this pattern is to have like STAND-UP MEETING should the architect review everything. be used to prevent this from We have seen this process work It is easy to depend on just a occurring. on several projects. However, the few people to carry most of “truck number” — that is the the organization’s burdens. Intellectually large projects can number of employees with knowl- Managers like to rely on a few build an ARCHITECTURE TEAM. edge and expertise — was in dan- key people in order to minimize ger on most of these projects as a the number of interfaces they

©2005 CUTTER CONSORTIUM VOL. 6, NO. 6 12 AGILE PROJECT MANAGEMENT ADVISORY SERVICE need to manage. And some Some of this communication over- polarize the positions of each, employees strive to do all they head isn’t very subtle, and these and a form of “schismogenesis” can out of a misplaced sense of cases are easy to identify. In may set in: the rise of factions monumental responsibility. In many cases, you can eliminate in the organization (THE OPEN/ fact, we find that PRODUCER redundant or misdirected commu- CLOSED PRINCIPLE OF TEAMS). ROLES tend to have stronger nication using simple and direct Insecure subgroups may withdraw communication networks than methods without delving into the from the rest of the team or even other support roles. deep structure or principles of the try to hijack the project by strong- organization. Other situations arming people into doing their But if this uneven distribution require more finesse and genera- bidding. Such behaviors may of work continues, it becomes tivity, building on other patterns in be accompanied by some of difficult for a heavily loaded role this pattern language. the dynamics of burnout (e.g., to sustain the communication shutting down communication networks necessary to the healthy with “outsiders”). Patterns like functioning of the enterprise as GATEKEEPER, WISE FOOL, and a whole. Resentment may build As we’ve discussed, if an organi- PATRON can help avoid the cre- among employees who don’t zation becomes sufficiently out of ation of unhealthy factions. feel central to the action. And balance that the work is concen- those who are central may easily trated in the hands of only a few In any of these dysfunctional burn out. people, those people are likely to situations, it is the job of the experience burnout. Such uneven- manager to counsel the parties Define the communication inten- ness may also indicate deeper involved and to forcefully inter- sity ratio as the ratio of the num- organizational problems. For vene. Correcting the problem ber of communication paths of example, those carrying a lighter is often an intricate and time- the busiest role to the average load may not have the technical consuming process. This pattern number of communication paths skills or the human interaction follows PRODUCER ROLES and per role. Empirically, one finds skills needed to integrate into PRODUCERS IN THE MIDDLE, which that the organization has a prob- the larger team or organization. are prerequisites to SHAPING CIR- lem — some underlying unhealth- Personality differences can be CULATION REALMS. This pattern iness — if this ratio becomes too addressed with human effective- itself is a refinement of SHAPING large. ness training programs (e.g., CIRCULATION REALMS. FEW ROLES appreciating differences or giving makes this pattern happen. This Therefore: Try to keep the com- effective presentations). Skill pattern can be implemented and munication intensity ratio to two mismatches can be dealt with elaborated by using RESPONSIBILI- or less. (The authors have found by reassigning people or through TIES ENGAGE and THREE TO SEVEN that it’s difficult to get much skill training. HELPERS PER ROLE. below two.) The easiest way to keep this ratio low is to have FEW An imbalance may also point to Figure 2 shows the communica- ROLES. It also helps to identify the insecurity in the person or clique tion intensity ratio data gathered PRODUCER ROLES and eliminate that tries to take on all the work. from some of our early research any deadbeat roles. You can also Such insecurity may manifest as subjects. We find that successful identify all the communication lack of trust in others. Encounters organizations tend to be near the paths of the most central role and between the insecure parties origin point on the graph. see which are really necessary. and the rest of the project team

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 13

FUNCTION OWNER AND case, you ask the same question: every delivered function has a COMPONENT OWNER “What happens when two people responsible owner. The compo- … The functions in your proj- need to program the same nent owner answers for the ect tend to cut across the function?” integrity and quality of the components of your project. component. The function owner You recognize the importance You want ownership and consis- ensures that the function gets of organizing according to the tency in these functions as well as architecture of the project delivered. If the component (CONWAY’SLAW), but things in the components. And the com- owners all refuse to incorporate aren’t simple. ponents must be shared across something needed to deliver end the teams. If you just assign func- functionality, the function owner tion owners, the components sees that the missing code is put become shared and lose their in a function-specific place. If you organize teams by com- identity and integrity. But if you ponents, functions suffer, and have only component owners, the vice versa. functions become orphans. Who ensures that they get done? There may be friction between You may be organized by function component owners and function or use case, with no component Therefore: Ensure that every owners. You may find the need ownership. On the other hand, function has an owner and that for the ENVY/Developer model you may be organized by class or every component has an owner. of ownership, where there is a component, with no function or Make sure that every component common part and an application- use case ownership. In either has a responsible owner and that specific part to each component

15 Number of roles 10

0 1234567 Communication intensity ratio

Figure 2 — The relationship between the communication intensity ratio and an organization’s number of roles.

©2005 CUTTER CONSORTIUM VOL. 6, NO. 6 14 AGILE PROJECT MANAGEMENT ADVISORY SERVICE or class. No conflict resolution is defer until there is time to do it. in the margin. One team member needed in this strategy since the But often, the time never comes, is assigned to periodically update component owner has right of and an organization without good the document. refusal to any request, and the internal technical documentation function owner has recourse by of its system has a serious handi- The success of this pattern working with others to get the cap. Nonetheless, much internal depends on the ability to find a job done. documentation is often write-only; suitably skilled agent to fill the it is rarely read after it is written. role of mercenary analyst. If the … Further, engineers often lack good pattern succeeds, the new context communication skills. defines a project whose progress 3 MERCENARY ANALYST can be reviewed (STAND-UP MEET- … You are assembling the Many projects use tools like IBM’s ING) and monitored by commu- roles for the organization. Rational Rose for design. These nity experts outside the project. The organization exists in tools produce pretty pictures. A a context where external good picture, however, is not nec- If the MERCENARY ANALYST really reviewers, customers, and internal developers expect to essarily a good design, and archi- is a “mercenary” who, as Paul use project documentation tects can become victims of the Chisholm describes, “rides into to understand the system elegance of their own drawings. town, gets the early stuff docu- architecture and its internal mented, kisses his horse, saddles workings. (User documenta- Therefore: Hire a technical up his girl, and rides off into the tion is considered separately.) Supporting both a writer who is proficient in the sunset” [12], then it’s good to design notation and the necessary domains but who retain some of the expertise by related project documenta- does not have a stake in the combining MERCENARY ANALYST tion is too tedious a job for design itself. This person will with DEVELOPING IN PAIRS. those who are directly con- capture the design using a suit- tributing to product artifacts. able notation and will format and This pattern, uncommon though empirically grounded and effec- publish the design for reviews and for use by the organization itself. tive, is found in Borland’s Quattro Technical documentation is the Pro for Windows and in many dirty work required in every AT&T projects (e.g., a joint venture project. It’s important to create — based in New Jersey, a formative The documentation itself should and even more, to maintain — organization in switching support, be maintained online if possible. It good documentation for the proj- and others). It is difficult to find must be kept up to date (there- ect team’s subsequent use. But people with the necessary skills fore, MERCENARY ANALYST is a who writes these documents? to fill this role. full-time job), and it should relate If developers create their own to customer scenarios (SCENARIOS Witold Rybczynski writes the fol- documentation, “real” work is DEFINE PROBLEM). Note, however, lowing regarding the difficulties hampered. Meeting software that all team members need to associated with architecture: deadlines means money for the provide input to keep the documentation current. The AD HOC Here is another liability: organization, and technical docu- beautiful drawings can mentation is one of those things CORRECTIONS pattern [24] sug- become ends in them- we tell ourselves that we can gests that a master copy of the selves. Often, if the drawing documentation be kept and that deceives, it is not only the

3 team members write corrections viewer who is enchanted but A version of this pattern first appeared in [8]. also the maker, who is the

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 15

victim of his own artifice. design: I want to make sure architectural vision from Alberti understood this dan- it’s elegant, consistent, and conception to implementa- ger and pointed out that clean. The architect has tion if it is to have conceptual architects should not try to primary responsibility, of integrity. imitate painters and produce course, but I also suggest lifelike drawings. The pur- places in which the design pose of architectural draw- conflicts with itself or may ings, according to him, was lead to future misunder- A software project must merely to illustrate the rela- standings. As I see it, a soft- broaden the scope of leader- tionship of the various parts. ware architecture is an idea. … Alberti understood, as The designer/implementers ship without sacrificing depth many architects of today are responsible for express- and attention to pragmatics. do not, that the rules of ing that idea (or those ideas) Though developers are good at drawing and the rules of as code; I express it/them as making individual design and building are not one and prose. Both are projections the same, and mastery of of the idea into a particular implementation decisions, a proj- the former does not ensure plane. When there’s a con- ect needs an overall guiding success in the latter. [22] flict, the code is probably strategic technical direction. This correct. [20] direction usually comes from the … architect. However, too many soft- Many projects put faith in tools ware architects limit their thinking In e-mail correspondence with and notations such as UML to and direction to abstractions, and one of the coauthors, Richard improve quality. But as Perry abstraction is a disciplined form of Gabriel noted the following points out, tools largely provide ignorance. Too many projects fail important traits that distinguish the forum and opportunity for a to capture the “details” of perfor- this role [16]: human being to engage in the mance, subtleties of APIs, and processes and convey the insights interworking of components — or Strong skills as a meeting that contribute to quality. For doc- facilitator at best, they discover such prob- umentation to have added value lems too late. An inclination for organization as a quality tool, the documentation process must proceed in the It’s possible that this problem Attentiveness to detail spirit of this admonition. could be solved with totalitarian Possesses written instructional control if one had a perfect plan. material (for software) … But as we’ve mentioned previously, even if that were possible, A lack of ego investment in the ARCHITECT ALSO IMPLEMENTS most development teams view material being documented … An organization is being this level of control as excessive. Intelligence and a high level of built to serve an identified market or markets (ORGANI- The right information must flow education ZATION FOLLOWS MARKET). Going forward, the project through the right roles. In particu- In exceptional cases, the MERCE- needs the necessary archi- lar, developers must latch onto the NARY ANALYST can actually have tectural breadth to cover strategic vision and carry respon- a stake in the design. its markets and to ensure sibility for implementation. The smooth evolution, but it can’t architect, and to some degree the Elizabeth Hanes Perry writes be blindsided by pragmatic engineering and implemen- developers, must also understand about filling this role: tation concerns. Further- the application needs and be more, the project needs to able to portend the long-term When I fill this role, I most carry through a singular definitely have a stake in the structure of the system. But a

©2005 CUTTER CONSORTIUM VOL. 6, NO. 6 16 AGILE PROJECT MANAGEMENT ADVISORY SERVICE more centralized locus of strategic Though general architectural DOES ALL from the collection of direction should keep the project responsibilities were identified Don Olson [19], which states from floundering, ensure that the and the roles were staffed, one the following: necessary details are addressed, group expected architects also to and track the emerging fit of implement code, whereas the A newly formed team is given a project with a tight all the pieces into a whole. other did not. schedule, uncertain require- Sometimes, understanding how ments, uneven distribution of these pieces fit together requires a One manager suggests that, on skills, and new technologies. corresponding understanding of some projects, architects should Let the most skilled and low-level details of component focus only on the implementation knowledgeable developer of a common infrastructure; the drive the design and imple- interaction, protocols, APIs, per- ment the critical pieces. This formance, or reliability concerns. implementation of noncore code can be an antipattern. [21] should thus be left solely to the Therefore: Beyond advising developer role. This division of The key element of this pattern and communicating with devel- responsibilities may work on is to give the critical pieces of opers, architects should also some projects; however, the the project to the most skilled participate in implementation. architect must have a strong feel and knowledgeable practitioners The architect should be organi- for recurring application needs in (DOMAIN EXPERTISE IN ROLES). zationally engaged with develop- order to build long-term robust ers and should write code. The frameworks. If architects work … architect may implement along only on infrastructural concerns with a developer using DEVELOP- and lack an engaged appreciation FIREWALLS ING IN PAIRS. of application needs, a disconnect ... An organization of devel- results between the infrastructure opers has formed in a corpo- (framework and middleware) and rate or social context where they are scrutinized by peers the application. If the architect implements, the and by funders, customers, and other “outsiders.” development organization per- … Project implementers are ceives buy-in from the guiding often distracted by outsiders architects, and that perception Though the architect should be who feel a need to offer can avail itself of architectural able to understand the minutiae input and criticism. expertise directly. The architects of development, it is not neces- also learn by seeing the firsthand sarily the architect’s business to results of their decisions and deal with such details day in It’s important to placate stake- designs, thus providing feedback and day out. The architect is the holders who feel a need to on the development process. keeper of the flame, the owner “help” by giving them access of the principles that the project to low levels of the project, with- In a project one of the coauthors follows. These principles in turn out distracting developers and worked on recently, the impor- shape structure. Much of the others who are moving toward tance of making this pattern structure can emerge from a project completion. explicit became clear. The archi- consensus-driven process guided tecture team was being assem- by the architect; in fact, in practice Isolationism doesn’t work bled from dispersed geographic much of what architects do because information flow is locations with narrow communi- involves such high-level guidance important. But communication cation bandwidth between them. [11]. A related pattern is GURU overhead increases nonlinearly

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 17 with the number of external The necessary roles have place the developer role at a hub collaborators. been defined and initially of the process for a given feature. staffed. A feature is a unit of system func- Many interruptions are noise. tionality (implemented largely in software) that can be separately Maturity and progress are more marketed and for which cus- highly correlated with being in Like any culture, a development culture can benefit from recog- tomers are willing to pay. Devel- control than with being effectively oper responsibilities include controlled. nizing a focal point of project direction and communication. understanding requirements, reviewing the solution structure Therefore: Create a manager Successful organizations work in and algorithm with peers, building role that shields other develop- an organic way with a minimum the implementation, and perform- ment personnel from interaction of centralized control. Yet impor- ing unit testing. with external roles. The responsi- tant points of focus, embodied in roles, tie together ideas, require- bility of this role is “to keep the … pests away.” ments, and constraints into an artifact ready for testing, packag- Note that other hubs, such as the ing, marketing, and delivery. manager role, may exist as well, though they are less central than The new organization isolates Most development teams view the developer role. developers from extraneous strict control as excessive and external interrupts. To avoid heavy-handed. The right informa- isolationism, this pattern must tion must flow through the right be tempered with others, such roles. You need to support infor- The developer who is at the hub as ENGAGE CUSTOMERS and mation flow across analysis, of a particular feature may be GATEKEEPER. design, and implementation. granted that position according to FEATURE ASSIGNMENT, but more This pattern was present in both Because developers contribute generally developers should be at the Borland Quattro Pro for directly to the end-user-visible the communication hub of what- Windows project [10, Chapter 8] artifact, they are in the best posi- ever process engages them in and in a hyperproductive deve- tion to have accountability for writing code for the customer. lopment team we studied [10, the product. Of all roles, they have This pattern encourages a struc- Chapter 9]. In addition, see the the largest stake in the largest ture that supports its prime infor- pattern ENGAGE CUSTOMERS, number of phases of product mation consumer. The developer which complements this pattern. development, and there should be can be moved toward the center no accountability without control. of the process using the patterns … A manager has some accountabil- WORK FLOWS INWARD and MOVE ity as well, to the extent that he or RESPONSIBILITIES. Though the DEVELOPER CONTROLS PROCESS she indirectly supports delivery of developer should be a key role, ... An organization has come the user-visible artifacts. These are care must be taken not to over- together to build software process issues. for a new market in an burden the role. This pattern should be balanced with MERCE- immature domain or in a Therefore: Make the developer domain that is unfamiliar to NARY ANALYST, FIREWALLS, and the focal point of process the development team. GATEKEEPER and more general information. In the spirit of Progress will be marked by load-balancing patterns like an INFORMAL LABOR PLAN. ORGANIZATION FOLLOWS MARKET,

RESPONSIBILITIES ENGAGE, HALL- And ensure that each process step the maintenance of an evolving WAY CHATTER, and MOVE RESPON- meets a need that you can tie to organization. Like a house, an SIBILITIES. The developer should your organization’s value proposi- organization wears and tears over enjoy particularly strong support tion. Most often, this value is or time. You notice where the organi- from the PATRON ROLE, and con- should be tied to the product you zation needs work and find the flicts can be escalated to the produce for a paying customer. If appropriate pattern to strengthen PATRON ROLE when consensus it isn’t obvious how the process it. However, to repair the organiza- breaks down. step helps to achieve what you tion, you have to understand its know the customer wants, then basic style, patterns of organiza- If the developer controls the do the right thing instead. tion, and principles of construc- process, it’s possible to imple- tion, just as you would in ment the pattern WORK FLOWS APPLYING THE PATTERNS remodeling your old house. For INWARD. Developers, of course, the new organization to retain the Patterns as Organizational don’t control the process unilater- Building Blocks core properties it strives to retain ally but as a collective group, start- over time, the patterns of the new ing with DEVELOPING IN PAIRS. Organizational patterns are a tool construction must match the old. for organizational change, growth, The new materials must be mal- As we’ve said previously, we don’t and repair. An organization is a leable to fit the old and to support have a designer role because system; that means changes to future growth and adaptation. design is really the whole task. one part of the organization affect Similarly, organizational mainte- Managers fill a supporting role; many other parts. As a system, nance must mesh with what is empirically, they rarely control a an organization has an intricate already present. You can choose process except during crises. And fabric that links it together. In a patterns that harmonize with one again, the developer controls the pattern language, patterns are the another and with your organiza- process, the architect controls the fabric of your organization. Any tion, since each pattern is flexible product. This communication is single pattern can be used to enough to adapt to your unique particularly important in domains patch that fabric, whether to grow circumstances. Of course, this that are not well understood, so the organization or to fix it when metaphor doesn’t always apply that iteration can take place to you notice something wrong. Even perfectly, and software develop- explore the domain with the growth should be viewed as an ment organizations have much customer. act of repair. Repair is a kind of richer structure than homes. But change that must be compatible this notion of mixing compatible In a mature domain, consider with what preceded the fix. So patterns is critical to solving your HUB, SPOKE, AND RIM — a pattern though each pattern should be organization’s system problems. that orchestrates the work of sev- applied incrementally, with local eral pipelined workers around a impact, it refines and comple- The Role of the Pattern Language centralized coordinator — as an ments the patterns that are We’ve mentioned several times alternative. already there in a way that makes that no pattern stands alone: pat- the entire organization more terns are meant to be used along- You can still write down your robust as a system. process as part of a process side one another to be effective. improvement program. But keep Let’s assume that you live in This emphasizes what you prob- the documentation light; many a charming old house. Let’s ably already know: there is no organizations have found that one compare the growth and single miracle cure for an organi- page per process is good enough. updating of the house with zation, no silver bullet to organizational success. You must do many

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 19 things right. And “doing things below it. Each pattern helps com- discussed in this report. Figure 4 right” differs from organization to plete those patterns above and on page 21 shows what this pat- organization: each pattern must below it in the language. tern language might look like. be tailored to its context. Each of these customized changes Figure 3 shows a pattern language You would start with the pattern produces a new and slightly better for project management, built UNITY OF PURPOSE as a foundation organization that ensuing patterns from organizational patterns that and then work your way down the can build on. have been collected and pub- figure. You confront a choice right lished over the past decade. As away. Which pattern should come Even though each pattern can be the figure shows, patterns from first — DOMAIN EXPERTISE IN customized, and each organiza- other pattern languages overlap ROLES, ARCHITECT CONTROLS tion reflects a slightly different set with project management and, as PRODUCT, or ENGAGE CUSTOMERS? of patterns, we can still make such, may appear in several pat- In many sectors, these three pat- strong claims about successful tern languages. terns are often independent: software development organiza- domain expertise, as embodied in tions in general. Most have the The language is taken from domain experts and experienced pattern ENGAGE CUSTOMERS; with- Organizational Patterns of Agile architects, depends more on the out it, you won’t know what to Software Development, as are core business than on the needs build. Most excellent software many other concepts in this of individual customers. Once you development organizations share report. As mentioned previously, have DOMAIN EXPERTISE IN ROLES a small number of common pat- it is one of four pattern languages and ARCHITECT CONTROLS PROD- terns. In many cases, the organi- described in the book. The UCT, your architecture team can zations grew in much the same four languages are Project begin an implementation: ARCHI- way: the patterns were applied in Management, Organizational Style, TECT ALSO IMPLEMENTS. And now a certain order. Piecemeal Growth, and People you can take the domain experts and Code. The patterns overlap you hired and divide the work Think of patterns as words in a somewhat across the pattern lan- among them, using customer dictionary, and think of your orga- guages; the “home” pattern lan- needs to guide project direction. nization as a sentence composed guage for each pattern is shown You need FIREWALLS to insulate from those words. We need a set in the graph. A pattern language developers from customer whims, of rules for how to combine the guides you through the evolution while still allowing for customer words in useful ways: that is, we of your organization. It is not a insights to reach developers. need a language of the words, a prescription but a suggestion Now you’re ready to start devel- language of the patterns. Based based on what has often worked opment in full swing with DEVEL- on this metaphor, a collection of before. Don’t be afraid to use your OPER CONTROLS PROCESS. patterns, together with rules for insight, intuition, and domain spe- assembling them in compatible cialization to fine-tune the pattern The Fundamental Process and useful ways, is called a pat- language. Think of organizational All systems grow through a tern language. We can depict repair as an almost playful activity fundamentally iterative process. the language visually, with the of discovery and adventure. Christopher Alexander has suggested partial ordering of described such a process for pattern application, with the most A Language of the the architecture of buildings and basic pattern at the top. Each pat- Top 10 Patterns of the fine craftsmanship that tern refines those above it and We can make a mini-pattern lan- “decorates” these buildings [1]. provides a foundation for those guage from the top 10 patterns His process draws heavily on the

©2005 CUTTER CONSORTIUM VOL. 6, NO. 6 20 AGILE PROJECT MANAGEMENT ADVISORY SERVICE processes that biologists have following process to be an effec- 1. Consider your organization come to understand as fundamen- tive way to introduce patterns one as a whole and find the weak- tal to autopoietic systems and life at a time, in a way that they fit est part: that is, the one with and on the processes that physi- with one another. Because it is the highest density of unre- cists understand as fundamental based on local adaptation and solved forces. If you are work- to the nature of matter and piecemeal growth, it minimizes ing your way through the existence. We have found the risk [10]: pattern language, look at the

Community of Trust

Size the Schedule

Get Early Work On Named Compensate and Phasing Queue with Stable Success Regular It In It Bases Delivery

Informal Build Incremental Take No Labor Prototypes Integration Small Slips Plan

Development Completion Developer Surrogate Episode Head Room Controls Customer Process

Work Someone Flows Implied Feature Programming Work Recommitment Always Inward Requirements Assignment Episode Split Meeting Makes Progress

Team Private per World Task

Developing in Pairs Interrupts Sacrifice Unjam One Blocking Person

Don’t Organizational Piecemeal Interrupt Mercenary Style Growth Firewalls Day Care an Analyst Interrupt People and Project Code Management

Scenarios Define Problem

Figure 3 — The Project Management pattern language.

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 21

areas touched by the next pat- Unity of terns in the language. If your Purpose business environment has changed, look at the areas touched by those changes. If Engage you have just applied another Customers pattern, look at the forces that Architect have been exposed or left Controls Product unbalanced by the application Domain Expertise of that pattern. in Roles

2. Calibrate the forces with Firewalls respect to your business and organizational goals. Pay Function Distribute attention to factors that recur Owner and Work Component Architect Evenly in the tradeoffs related to the Owner Also problem you are solving, treat Implements transients as transients, and then return your focus to the Mercenary Analyst long-term and systems issues. Developer Think about your personal and Controls corporate values and how they Process amplify some forces and dimin- ish others. Are you striving for Figure 4 — The top 10 patterns as a pattern language. profitability? If so, which foun- dational values in your organization underlie profitability? that derives from your experi- structure or other structure of And is profitability really your ence but that may have been the pattern. quieted by local management main concern right now, or is 6. Be attentive to feedback; practices or by exposure to a morale affecting productivity, if the pattern does not cookie-cutter management which is in turn affecting prof- strengthen the organization, technique adopted from a book itability? Dig deeper. then back it out. Do not try to or corporate training program. 3. Let the patterns inspire you fix it by adding another pattern. to find a way to balance the 4. Keep the big picture. Adjust Choosing a pattern is not a forces. You might find that an the pattern in a way that science; it is guided, informed existing organizational pattern increases the organization’s guesswork. Occasionally, you is ready-made for your situa- health at the next level in the will guess wrong. Patterns are tion. It is more often the case organizational structure or in the small enough that the cost of that an organizational pattern next larger context or scope. making a mistake is minor and almost always reversible. Be will inspire your instinct to rec- 5. Strive for balance. Most of open with your people that the ognize a customized path to a these patterns are commu- technique doesn’t work, and solution. Follow your instinct, nication patterns, and commu- enlist their support in trying not the pattern. In many ways, nication is always a two-way another solution. Keep in mind the main goal of a pattern is to street. Be attentive to both that people resist change and unleash the instinct within you sides of the communication

that sometimes a bit more time has benefited from considering organizational patterns literature or encouragement is enough to and tailoring these patterns to its and the book Organizational gain acceptance. To succeed, a organizational needs. Richard Patterns in particular are modern pattern must be adopted by the Gabriel explains the role of pat- examples of empirically grounded culture rather than being forced terns in turning around the organizational literature, they are onto the culture. Eventually, a ParcPlace Systems software team not without company. The writ- good pattern will lead you to a [15]. One of our organizational ings of Capers Jones, Gerald new context — and to a new interventions probably saved a Weinberg, and others are also set of forces to balance and large insurance company from grounded in experience. problems to address. demise; in another insurance company in Vienna (Alliance Experience is the best teacher, RESULTS YOU CAN EXPECT Elementar), the patterns helped and patterns are designed to provide an incremental, low-risk Of course, we cannot promise create connections between the path to process improvement. miracles. Most important perhaps engineering group and manage- One of the best ways to learn is to have patience; great change ment and sparked management- more about these patterns is to rarely happens overnight and level initiatives that led to try implementing them. If you usually comes about from the renewed organizational health are interested in learning about interaction between several pat- and growth. These patterns have how to start a pattern-based terns rather than from a single proven themselves in European, organizational improvement pattern. The most difficult aspect American, and Middle Eastern program inside your group or of organizational change is timing: companies. In some cases, the department, TietoEnator (www. to know when to give up on a benefits were local and modest; tietoenator/oap.dk) offers a pattern, back out, and try some- in other cases, the survival of the facilitation service under its thing else. Sometimes an organi- entire enterprise was at stake. Organizational Agility Program, zation proceeds step by step or you can contact the authors toward improved behavior; some- CONCLUSION directly. times organizations persist in bad What we have discussed here behavior until, one day, a precipi- will help heal the most common REFERENCES tous change happens. We offer no problems we have observed in magic solution to this dilemma recent software development 1. Alexander, Christopher, Sara but suggest that you should be efforts worldwide. However, Ishikawa, and Murray Silverstein, most attentive to the morale and organizational development is an with Max Jacobson, Ingrid feelings of your employees as an ongoing concern of great depth Fiksdahl-King, and Shlomo Angel. indicator of whether a pattern is and breadth, and we exhort you A Pattern Language: Towns, working. Keep in close touch with to broaden the tools available Buildings, Construction. Oxford the people affected by the current to you through other resources. University Press, 1977. pattern and carefully consider Remember that though there is a their sense of progress during lot of literature on management 2. Beck, Kent. “The Metaphor the adoption of a pattern by the theory, and while theory can be Metaphor.” Web page for OOPSLA organization. useful, it is very difficult to justify 2002 accessed 20 March 2005 any approach to improvement on (http://oopsla.acm.org/oopsla2002/ The Success Story a theoretical basis alone. The fp/files/spe-metahpor.html). Almost every one of the 100 best resources are those that 3. Beedle, Mike. Book review of organizations we have researched reflect empirical insight. While the Organizational Patterns of Agile

VOL. 6, NO. 6 www.cutter.com EXECUTIVE REPORT 23

Software Development on World Conference on Systemics, Coplien and Douglas C. Schmidt Amazon.com, 19 September 2004 Cybernetics and Informatics, (eds.). Addison-Wesley, 1995. (www.amazon.com/exec/obidos/ Orlando, Florida, USA, July 2000, ASIN/0131467409). pp. 737-742. 19. Olson, Don. S. “Pattern on the Fly.” The Patterns Handbook, 4. Beyer, Hugh, and Karen 12. Chisholm, Paul S.R. Personal 1998, pp. 141-170. Holtzblatt. Contextual Design: communication with James Defining Customer-Centered Coplien, 1994. 20. Perry, Elizabeth Hanes. Systems. Morgan Kaufmann, 1998. Personal communication with 13. Cunningham, Ward. James Coplien, 1997. 5. Boehm, Barry W. “Software “EPISODES: A Pattern Language Engineering.” IEEE Transactions of Competitive Development.” In 21. Rising, Linda. The Pattern on Computers, Vol. 25, No. 12, Pattern Languages of Program Almanac. Addison-Wesley, 2000. 1976, pp. 1226-1241. Design 2, John M. Vlissides, James O. Coplien, and Norman L. Kerth 22. Rybczynski, Witold. The Most 6. Bramble, Paul, Alistair (eds.). Addison-Wesley, 1996, Beautiful House in the World. Cockburn, Andy Pols, and Steve pp. 371-388. Penguin, 1989. Adolph. Patterns for Effective Use Cases. Addison-Wesley, 2002. 14. Daly, Edmund B. “Manage- 23. Schwaber, Ken, and Mike ment of Software Development.” Beedle. Agile Software 7. Cockburn, Alistair. “Prioritizing IEEE Transactions on Software Development with SCRUM. Forces in Software Design.” In Engineering, Vol. 3, No. 3, Prentice Hall, 2001. Pattern Languages of Program May 1997, pp. 229-242. Design 2, John M. Vlissides, James 24. Weir, Charles. “Patterns for O. Coplien, and Norman L. Kerth 15. Gabriel, Richard P. Designing in Teams.” In Pattern (eds.). Addison-Wesley, 1996. “Productivity: Is There a Silver Languages of Program Design 3, Bullet?” Journal of Object-Oriented Robert Martin, Dirk Riehle, 8. Cockburn, Alistair. Surviving Programming, Vol. 7, No. 1, and Frank Buschmann (eds.). Object-Oriented Projects: A March/April 1994, pp. 89-92. Addison-Wesley, 1998, Manager’s Guide. Addison-Wesley, pp. 496-499. 1998. 16. Gabriel, Richard. E-mail message to James Coplien, 25. Whitenack, Bruce. “RAPPeL: 9. Coplien, James O., and Jon 8 May 1995. A Requirements Analysis Process Erickson. “Examining the Software Pattern Language for Object- Development Process.” Dr. Dobb’s 17. Keil, Mark, and Erran Carmel. Oriented Development.” In Pattern Journal, Vol. 19, No. 11, October “Customer-Developer Links Languages of Program Design, 1994, pp. 88-95. in Software Development.” James O. Coplien and Douglas C. Communications of the ACM, Schmidt (eds.). Addison-Wesley, 10. Coplien, James O., and Neil B. Vol. 38, No. 5, May 1995, pp. 33-44. 1995, pp. 259-291. Harrison. Organizational Patterns of Agile Software Development. 18. Kerth, Norman L. “Caterpillar’s 26. Zuckerman, Marilyn R., Prentice Hall, 2005. Fate: A Pattern Language for and Lewis J. Hatala. Incredibly Transformation from Analysis to American: Releasing the Heart 11. Coplien, James O., and Design.” In Pattern Languages of Quality. American Society for Martine Devos. “Architecture as of Program Design, James O. Quality Press, 1992, pp. 81-83. Metaphor.” Proceedings of the

ABOUT THE AUTHORS Neil B. Harrison is a distinguished Gertrud Bjørnvig is a senior member of technical staff at Avaya consultant in TietoEnator in James O. Coplien is Object Labs, where he develops commu- Copenhagen, Denmark. She does Architect at DAFCA, Inc., an elec- nications software. He has been organizational work for clients tronic design automation firm in involved in software development based on organizational patterns Framingham, Massachusetts, USA. and research for more than 20 and uses these principles for orga- He has been a software profes- years as both a developer and nizational improvement in the sional for more than 30 years. His team leader. He has studied soft- Scandinavian countries, drawing career spans areas as broad as ware development organizations on more than 15 years of experi- telecommunications software for 10 years and is coauthor of ence in the industry. Her past development (at AT&T), software the critically acclaimed book organizational work includes research (at Bell Laboratories), Organizational Patterns of Agile interventions in multiple corporate academia (at Vrije Universiteit Software Development. mergers to align the development Brussel, where he held the 2003- processes while retaining the ben- 2004 Vloebergh Lehrstuhl), EDA Mr. Harrison has been a leader in efits of the highly effective work (at DAFCA), and international con- the software pattern community culture that was in place. She is sulting and lecturing. His book since 1994. He has taught pattern an accomplished project man- Advanced C++ shaped a genera- courses and published patterns, ager, focusing on on-time delivery tion of developers, and his two including patterns in Pattern using agile approaches. She is an subsequent books have set new Languages of Program Design, expert on use cases and devel- standards in software design and volumes 2 and 3. He was the lead oped the first patterns for the development. He is a founding editor of Pattern Languages of application of use cases in devel- member and member emeritus Program Design, volume 4. He is opment projects. She was a of the Hillside Group, which acknowledged as the world’s founding program committee founded software patterns. He leading expert on pattern shep- member for VikingPLoP and is is a coauthor or editor of three herding and has a shepherding one of the founders of the Danish major patterns books, including award named after him. He is a Agile User Group. She can be Organizational Patterns of Agile member of the board of directors reached at Gertrud.Bjornvig@ Software Development. He can be of the Hillside Group. He can tietoenator.com. reached at [email protected]. be reached at nbharrison@ avaya.com.

VOL. 6, NO. 6 www.cutter.com > Agile Project Management Advisory Service Indexof published issues

Upcoming Topics Executive Reports Vol. 6, No. 6 Organizational Patterns: Building on the Agile Pattern Foundations z Agile Estimating and by James O. Coplien, Neil B. Harrison, and Gertrud Bjørnvig Planing: Embracing Vol. 6, No. 5 Principle-Centered Agile Project Portfolio Management Change by Donna Fitzgerald by Mike Cohn Vol. 6, No. 4 The Politics of Design and Usability by Whitney Quesenbery Vol. 6, No. 3 The New World of Teams: Ad Hoc and Virtual by Rob Thomsett z Integrating Software Development and Project Vol. 6, No. 2 Industrial XP: Making XP Work in Large Organizations by Joshua Kerievsky Management Methods Vol. 6, No. 1 Agile for the Enterprise: From Agile Teams to Agile Organizations by Robert Wysocki by Jim Highsmith This index includes Agile Project Vol. 5, No. 12 Extreme Programming Practices: What’s on Top? by Laurie Williams Management Executive Reports Vol. 5, No. 11 Getting It Right, Getting It Done: Improving Team Productivity and Quality and Executive Updates that by Pamela Hager have been recently published, Vol. 5, No. 10 Usability and the Agile Project Management Process Framework plus upcoming Executive Report by Jonathan D. Addelston and Theresa A. O’Connell topics. Reports that have already Vol. 5, No. 9 Making Decisions Using Software Product Metrics by Khaled El Emam been published are available Vol. 5, No. 8 Leading Extreme Projects to Success by Doug DeCarlo electronically in the Online Vol. 5, No. 7 Pushing the Envelope: Managing Very Large Projects by Ken Orr Resource Center. The Resource Vol. 5, No. 6 The Usability Challenge by Larry L. Constantine Center includes the entire Agile Project Management Advisory Service archives plus Executive Updates additional articles authored Vol. 6, No. 9 Why Is Agile Development So Scary? by Preston G. Smith by Cutter Consortium Senior Vol. 6, No. 8 How Do Agile Teams Manage Risk by Laurent Bossavit Consultants on the topic of Vol. 6, No. 7 Measuring Up to Metrics: Part III — Overcoming Project Complexity project management. by E.M. Bennatan For information Vol. 6, No. 6 Donkeys and Carrots: Customer Collaboration and Helping Others by Ole Jepsen on beginning a subscription Vol. 6, No. 5 Mitigating Large Software Project Risk Through Organic Growth or upgrading your current Organization by Nick Christenson subscription to include access Vol. 6, No. 4 Measuring Up to Metrics: Part II — Are Software Organizations to the Online Resource Measuring by Data? by E.M. Bennatan Center, contact your account Vol. 6, No. 3 Measuring Up to Metrics: Part I — How I Became a Missourian representative directly or by E.M. Bennatan call +1 781 648 8700 or send e-mail to [email protected]. Vol. 6, No. 2 Agile: Changing the Organization by David Spann Vol. 6, No. 1 Using the Retrospective for Positive Change by Diana Larsen Vol. 5, No. 23 Absorbing Sarbanes-Oxley Within the Agile Community by Charles W. Butler and Gary L. Richardson Vol. 5, No. 22 A New Era of Software Project Management: Part III — Agile Project Management and the Stealth Fighter by E.M. Bennatan Vol. 5, No. 21 A New Era of Software Project Management: Part II — Are Agile Projects Filling the Void? by E.M. Bennatan Vol. 5, No. 20 Agile Development: Lessons Learned from the First Scrum by Dr. Jeff Sutherland ACCESS TO THE EXPERTS Vol. 5, No. 19 A New Era of Software Project Management: Part I — Are We Adjusting? by E.M. Bennatan About the Practice plus consulting and training services. consultingandtrainingservices. plus below. Eachofthesepracticesincludesasubscription-based periodicalservice, intotheninepractice areas Cutter Consortiumalignsitsproductsandservices Other CutterConsortiumPractices Practice AvailablefromtheAgileProject Management Products andServices with globallydisbursedsoftwareteams;andmore. conflictthatinevitably ariseswithinhigh-visibilityinitiatives;issuesassociated the requirements andmanagingchangingrequirements;productivitybenchmarking; issues ofmanaginghigh-profileprojects;adviceonhowtoelicitadequate Dynamic SystemsDevelopmentMethod,andLeanDevelopment;thepeopleware methodologies, includingAdaptiveSoftwareDevelopment,ExtremeProgramming, training theAgileProjectManagementPracticeoffers,clientsgetinsightinto Through thesubscription-basedpublicationsandconsulting,mentoring, bestforspecificprojects orteams. work traditional processesandmethodologiestohelpcompaniesdecidewhatwill movement. TheAgileProjectManagementPracticealsoconsidersthemore people who’vedevelopedthegroundbreakingpracticesofAgileMethodology component ofthispracticeanddotheconsultingmentoring—are service its SeniorConsultants—whowritethereportsandanalysesforinformation under thepressuresofthishighlyturbulenteconomy. Thepracticeisuniqueinthat Cutter Consortium’sAgileProjectManagementPracticehelpscompaniessucceed Management Practice Agile Project • • • • • • • • • • • • • • Sourcing andVendor Relationships Enterprise RiskManagementand Governance Measurement andBenchmarking Strategies IT Management Enterprise Architecture Business Technology Trends andImpacts Business-IT Strategies Business Intelligence Agile SoftwareDevelopmentandProjectManagement Research Reports Mentoring Inhouse Workshops Consulting Service The AgileSoftwareDevelopmentandProjectManagementAdvisory brain trustincludes: data analysisfrombest-in-classexperts.This cutting-edge tips,aswellcasestudiesand methodologies. You’ll getsoundadviceand those who’vedevelopedtoday’shottestAgile and motivatingsoftwareprofessionals,to theissuesofhiring,retaining, crystallize to who’ve writtenthetextbooksthatcontinue management/peopleware field,fromthose manyofthetrailblazersinproject includes Management SeniorConsultantTeam The CutterConsortiumAgileProject Team Senior Consultant Richard Zultner • Bob Wysocki • Colin Tully • RobThomsett • SuzanneRobertson • JamesRobertson • RogerPressman • Poppendieck Mary • KenOrr • Lynne Nix • MichaelC.Mah • Tim Lister • BrianLawrence • BartoszKiepuszewski • JoshuaKerievsky • RonJeffries • DavidHussman • MichaelHill • F. Kerry Gentry • DonnaFitzgerald • KhaledElEmam • Tom DeMarco • DougDeCarlo • KenCollier • MikeCohn • AlistairCockburn • RobertN.Charette • DavidR.Caruso • Tom Bragg • E.M.Bennatan • KentBeck • Paul G.Bassett • JamesBach • ChristopherM.Avery • ScottW. Ambler • JimHighsmith,Director •