Patterns from the Organizational Patterns Book

The following patlets describe patterns from the Organizational Patterns book, Organizational Patterns of Agile Software Development [CH04] and the section number refers to the section number in that reference.

¶95 Community of Trust

If you are building any human organization, then you must have a foundation of trust and respect for effective communication at levels deep enough to sustain growth. (Section 4.1.1.)

¶96 Named Stable Bases

If you want to balance stability with progress, then have a hierarchy of named stable basis that people can work against. (Section 4.1.4.)

¶97 Take No Small Slips

If you are getting behind schedule and you need additional time resources, then take one large planned slip instead of creating project instability and low team morale with small, unanticipated slips. (Section 4.1.9.)

¶98 Completion Headroom

If work is progressing against a set of hard dates, then make sure there is Completion Headroom between the completion dates of the largest task and the hard delivery date. (Section 4.1.10.)

¶99 Recommitment Meeting

If the schedule can’t be met with simple adjustments to the work queue and staffing, then assemble Developers and interested managers to recommit to a new strategy based on doing the minimal amount of work to reach a satisfactory conclusion. (Section 4.1.12.)

¶100 Informal Labor Plan

If development needs are fluid, then instead of master planning, let Developers negotiate among themselves to develop short-term plans. (Section 4.1.14.)

¶101 Developer Controls Process

If you need to orchestrate the activities of a given location or feature, then put the Developer role in control of the succession of activities. (Section 4.1.17.)

¶102 Work Flows Inward

If you want information to flow to the producing roles in an organization, then put the Developer at the center and see that information flows toward the center, not from the center.

¶103 Programming Episodes

If you need to split up work across time, then do the work in discrete episodes that combine to create concrete deliverables. (Section 4.1.19.)

¶104 Someone Always Makes Progress

If distractions constantly interrupt your team’s progress, then whatever happens, ensure someone keeps moving toward your primary goal. (Section 4.1.20.)

¶105 Team per Task

If a big diversion hits your team, then let a subteam handle the diversion so the main team can keep going. (Section 4.1.21.)

¶106 Sacrifice One Person

If a smaller diversion hits your team, then assign just one person to resolve it. (Section 4.1.22.)

¶107 Day Care

If your experts are spending all their time mentoring novices, then put one expert in charge of all the novices and let the other experts develop the system. (Section 4.1.23.)

¶108 Interrupts Unjam Blocking

If you need to schedule urgent development activities according to some reasonable priority scheme, then use an interrupt scheme to keep individual problems from blocking the entire project. (Section 4.1.25.)

¶109 Don’t Interrupt an Interrupt

If a new urgent need arises while you’re already in the middle of handling an interrupt to keep the project from getting stuck, then continue handling the current issue before moving on to the new one. (Section 4.1.26.)

¶110 Size the Organization

If an organization is too large, communications break down. If it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore, start projects with a critical mass of about 10 people. (Section 4.2.2.)

¶111 Apprenticeship

If you have difficulty retaining expertise, then grow expertise internally from existing employees or even new hires. (Section 4.2.4.)

¶112 Solo Virtuoso

If a project is intellectually small, then overstaffing it is a waste of time and money. Therefore, staff small projects with Solo Virtuosi. (Section 4.2.5.)

¶113 Surrogate Customer

If you need answers from your customer, but no customer is available to answer your questions, then use scenarios to define the problem. (Section 4.2.7.)

¶114 Firewall

If you want to keep your Developers from being interrupted by extraneous influences and special interest groups, then impose a Firewall, such as a manager, to “keep the pests away.” (Section 4.2.9.)

¶115 Gatekeeper

If a team walls itself in and becomes overly incestuous, then use a Gatekeeper role to tie development to other projects, research, and the outside world. (Section 4.2.10.)

¶116 Self-Selecting Team

If you appoint people to a team, the people don’t come together as a team. People who share similar outside interests make the best team members. Therefore, teams should be largely self-selecting, performing limited screening of candidates based on their track record and outside interests. (Section 4.2.11.)

¶117 Unity of Purpose

If a team is beginning to work together, then make sure all members agree on the purpose of the team. (Section 4.2.12.)

¶118 Team Pride

If a team needs to perform above and beyond the call of duty, then instill a well-grounded sense of elitism in its members. (Section 4.2.13.)

¶119 Patron Role

If you need to insulate Developers so Developers Control the Process, and you must support organizational inertia at a strategic level, then identify a Patron accessible to the project who can champion the cause of the project. (Section 4.2.15.)

¶120 Matron Role

If your team needs ongoing care and feeding, then include a Matron Role on the team who will naturally attend to the team’s social needs. (Section 4.2.18.)

¶121 Wise Fool

If critical issues do not get aired easily, then nurture a Wise Fool to say the things nobody else dares say. (Section 4.2.21.)

¶122 Domain Expertise in Roles

If you need to staff all roles, it’s difficult to determine how to match people to roles in order to optimize communication. Therefore, match people to roles based on domain expertise, and emphasize that people play those roles in the organization. (Section 4.2.22.)

¶123 Moderate Truck Number

If you can’t eliminate having a single point of failure in allocating expertise to roles, then spread that expertise around as far as possible, but not more so. (Section 4.2.24.)

¶124 Compensate Success

If enterprises are to succeed, they must reward the behaviors that lead to success; however, these behaviors are varied, and success is difficult to measure. Therefore, establish a spectrum of reward mechanisms for both teams and individuals. (Section 4.2.25.)

¶125 Failed Project Wake

If people have put their hearts and souls into a project that subsequently is canceled, then celebrate the project’s demise and hold a “wake” for it. (Section 4.2.26.)

¶126 Developing in Pairs

If you want to improve the effectiveness of individual Developers, then have people develop in pairs. (Section 4.2.28.)

¶127 Engage Quality Assurance

If Developers can’t be counted on to test beyond what they already anticipate going wrong, then engage QA as an important function. (Section 4.2.29.)

¶128 Producer Roles

If your organization has too many roles, but does not know which to eliminate, then identify roles as Producers, Supporters, or Deadbeats and reduce the number of roles to sixteen or fewer. (Section 5.1.3.)

¶129 Organization Follows Market

If there is no clear organizational accountability to a market, then make some organization accountable for each market to ensure that the market’s needs will be met. (Section 5.1.9.)

¶130 Face-to-Face Before Working Remotely

If a project is divided geographically, then begin the project by inviting everyone to a meeting at a single place. (Section 5.1.10.)

¶131 Distribute Work Evenly

If you want to optimize team effectiveness and productivity, then alleviate overload on specific groups and individuals in your organization by Distributing Work Evenly. (Section 5.1.13.)

¶132 The Water Cooler

If you need more communication between institutionalized organizations, then leave space for everyday human activities that can provide more complete and informal communication. (Section 5.1.20.)

¶133 Smoke-Filled Room

If you need to make a decision quickly and you need both authoritative backing for the decision as well as expediency, then make the decision in the absence of broad engagement, publicizing the decision only afterwards. (Section 5.2.6.)

¶134 Stand-Up Meeting

If there are pockets of misinformation or if people are out of the loop, then hold short daily meetings to socialize emerging developments. (Section 5.2.7.)