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.
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.)
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.)
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.)
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.)
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.)
If development needs are fluid, then instead of master planning, let Developers negotiate among themselves to develop short-term plans. (Section 4.1.14.)
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.)
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.
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.)
If distractions constantly interrupt your team’s progress, then whatever happens, ensure someone keeps moving toward your primary goal. (Section 4.1.20.)
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.)
If a smaller diversion hits your team, then assign just one person to resolve it. (Section 4.1.22.)
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.)
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.)
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.)
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.)
If you have difficulty retaining expertise, then grow expertise internally from existing employees or even new hires. (Section 4.2.4.)
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.)
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.)
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.)
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.)
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.)
If a team is beginning to work together, then make sure all members agree on the purpose of the team. (Section 4.2.12.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
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.)
If you want to improve the effectiveness of individual Developers, then have people develop in pairs. (Section 4.2.28.)
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.)
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.)
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.)
If a project is divided geographically, then begin the project by inviting everyone to a meeting at a single place. (Section 5.1.10.)
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.)
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.)
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.)
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.)