taken from old online copy of
Organisational patterns book - James Coplien, Neil Harrison. images might be even older.. if any
A patlet is a short summary of the problem and
solution for a pattern.
Patlets are often used as an aid to discovering
patterns to solve a particular problem at hand.
Here, we use the patlets as a way for you to find
patterns you are looking for.
These patlets point to patterns for initial
organizational design.
You can find the patterns in
the section ProjectManagementPatternLanguage.
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.
If the schedule is too long, developers become complacent;
but if it is too short, they become overtaxed.
Therefore: reward meeting the schedule, and keep
two sets of books.
If you are starting a project and have enough information to
get started on parts of it,
Then: don't wait until you have a complete schedule before
starting to do parts of the project
If you want to balance stability with
progress,
Then: have a hierarchy of named stable
bases that people can work against.
If you want developers to be able to test changes before publishing them,
Then: allow developers to build the entire product code independently to allow testing with the very latest base (not the latest Named Stable Base).
If you want to isolate developers from the effects of changes,
Then: allow developers to have private work spaces containing the entire build environment.
If early acquired requirements are difficult to
validate without testing,
Then: build a prototype, whose purpose is to understand requirements.
If you are getting behind schedule and need
additional time resources,
Then: take one large planned slip instead of
allowing yourself to nickel and dime yourself to death
with small, unanticipated slips.
If
work is progressing against a set of hard dates,
Then:
make sure there is CompletionHeadroom between the completion
dates of the largest task and the hard delivery dates.
If people too close to the problem are escalating their problems,
either as a "pork barrel" issue or as something well-intentioned,
Then: split work into an urgent and deferred component, with
less than half of development work in the urgent half.
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
If deliverables are ill-defined, you need to allow time to do everything.
Therefore: produce a schedule with less output than you have input. Use the list of ImpliedRequirements (really just
names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority
items.
If developers need to do the most important thing now,
Then: let developers negotiate among themselves or
"just figure out the right thing to do" as regards short
term plans, instead of master planning.
If we overemphasize individual contributor skills, work suffers.
Therefore: approach all development as a group activity as if no one had anything else to do.
If you need a way to nail down
the functionality that needs to be covered,
Then: make a list of functional areas and domains instead of
breaking it down into traditional requirements.
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.
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 with
mind share to commit to concrete deliverables.
If Distractions constantly interrupt your team's progress,
Then: whatever happens, ensure someone keeps moving toward
your primary goal.
If a big diversion hits your team,
Then: let a sub-team handle the diversion, the main team keeps going.
If a smaller diversion hits your team,
Then: assign just one person to it until it gets handled.
If your experts are spending all their time mentoring novices,
Then: put one expert in charge of all the novices,
let the others develop the system.
If you want to keep documentation from
being a critical path roadblock for developers,
Then: hire a MercenaryAnalyst_.
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.
If you're in the middle of handling an
interrupt to keep the project from getting stuck,
and a new urgent need arises,
Then: continue handling the current issue
before moving on to the new one.
These patlets summarize patterns for the growth
of an organization once it is up and running.
You can find the patterns in
the section PiecemealGrowthPatternLanguage.
If an organization is too large, communications break
down, and 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.
If you can't always get the experts you need,
Then: grow new experts from new hires.
If you have difficulty retaining expertise,
Then: grow expertise internally from
existing employees or even new hires.
If a project is intellectually small,
then overstaffing it is a waste of
time and money.
Therefore: staff small projects with
SoloVirtuosos_.
If you want to manage an incremental process that
accommodates customer input, and if you want the
customer to feel loved,
Then: engage customers after Quality Assurance
and project management are prepared to serve them.
If you need answers from your customer, but no customer is available to answer your questions,
Then: create a surrogate customer role in your organization to play advocate for the customer.
If you want a good characterization of customer needs,
Then: use scenarios to define the problem.
If you want to keep your developers from
being interrupted by extraneous influences and
special interest groups,
Then: impose a Fire Wall, such as a manager,
who "keeps the pests away."
If you need to keep from being inbred,
Then: use a GateKeeper role to tie together
development with other projects, with research,
and the outside world.
If you appoint people to a team,
it doesn't come together as a team.
But people with outside interests
and who wish to joint a team make the
best team members.
Therefore: teams should be largely
self-selecting with limited screening on
the basis of track record and outside interests.
If a team is beginning to work together,
Then: make sure all members agree on the purpose of the team.
If a team needs to perform above and beyond the call of duty,
Then: instill a well-grounded sense of elitism in its members.
If a project innovates too much, then it increases its risk;
yet there is a place for innovation.
Therefore: give innovation
an organizational space and time.
If you need to insulate Developers so
DeveloperControlsProcess and provide some
organizational inertia at the strategic level,
Then: identify a patron to whom the project
has access, who can champion the cause of the project.
If everyone has similar views, you have a good team,
but too much normalization leaves important problem
areas unaddressed.
Therefore: assemble a diverse team, based on
different experiences, cultures, and genders.
If you need a catalyst to bring people together,
Then: recognize some roles as PublicCharacters_.
If your team needs ongoing care and feeding,
Then: include a Matron in the team who will naturally take care of social needs of the team.
If Development of a subsystem needs many skills, but people specialize,
Then: create a single team from multiple specialties.
If a key person will leave the organization soon,
Then: train a key replacement, and have them assume a role named after the key person.
If critical issues do not get aired easily,
Then: nurture a Wise Fool to say the things nobody else dares say.
If you need to staff all roles, it's difficult
to determine how to match people to roles to optimize
communication.
Therefore: match people to roles based on domain
expertise, and emphasize that people play those roles
in the organization.
If you need to organize subsystems for the long haul,
Then: divide them up by skills.
If you can't eliminate having a single point of failure in allocating
expertise to roles,
Then: spread expertise as far as possible, but not more so.
If enterprises are to succeed, they must reward
the behaviors that portend for success; but, these
behaviors are varied, and success is difficult to measure.
Therefore: establish a spectrum of reward mechanisms that
reward both teams and individuals.
If people have put their hearts and souls into a project, only to
have it canceled,
Then: celebrate its demise; hold a "wake" for it.
If you want to improve the effectiveness of
individual developers,
Then: have people develop in pairs.
If developers can't be counted on to test
beyond what they already anticipate what might
go wrong,
Then: engage Quality Assurance as an important
function.
If you want to organize the interworking between
test developers and software developers,
Then: organize the process so
ApplicationDesignIsBoundedByTestDesign_.
If you want to avoid being blindsided in quality assurance,
Then: EngageCustomers and DevelopingInPairs and others
to validate the system.
Good design lends a sense of style to anything we build.
Each great organization has its own style. These
patterns shape the "style" of an organization.
Different organizational styles fit different
needs, so these patterns provide a good foundation
for tailoring an organization to your business and
market.
The patterns can be found in the section
OrganizationalStylePatternLanguage.
If your organization has high communication overhead and latency,
Then: identify the roles in the organization, and keep the number of roles to sixteen or fewer.
If your organization has too many roles, but does not know which to eliminate,
Then: identify roles as Producers, Supporters, or Deadbeats; eliminate the Deadbeats, and combine some of the Supporters.
If your developers are somewhat lost,
Then: make sure the producer roles are at the center of all communication.
If you have to deal with project disruptions,
Then: keep people in their primary roles, and
deal with disruptions as temporary tasks.
If an organization is getting too large
for communications to be effective any more,
Then: try partitioning it along lines of
mutual interest and coupling, forming a separate
organization and process.
If organization structuring concerns are torn between
geography, expertise, politics, and other factors,
Then: align the primary organizational structuring with the
structure of the business domains, the structure that will be
reflected in the product architecture.
If you need to distribute work geographically,
communications suffer, but you can limit the
damage if work is partitionable.
Therefore: organize work at locations so
groups of people that work together are at the
same location.
If there is no clear organizational accountability to a market,
Then: make some organization accountable for the
market to assure that the market's needs will be met.
If a project is divided geographically,
Then: begin the project with a meeting of everyone in a single place.
If there is little specialization, and people don't
know where to turn for answers to technical questions,
Then: Create domains of expertise called roles
that cluster around artifacts or specialization.
If you need mechanisms to facilitate the
communication structures necessary for good
group formation,
Then: shape circulation realms.
If you want to optimize utilization of human resources,
Then: alleviate hot spots of overload on
specific groups and individuals in your organization
by Distributing Work Evenly
If central roles are overloaded but you don't want to take
them out of the communication loop
Then: intensify communication more among non-central
roles to lighten the load on the central roles
If developers tend to huddle around the organizational core
or supporting roles are inadequately engaged with each other,
Then: re-arrange responsibilities in a way that encourages less
isolation and more interworking among roles and people.
If stages are too interleaved for the
good of some high-context development where
phases can be separated to increase parallelism,
Then: serialize process steps, with well-defined
hand-offs between steps.
If you want to DecoupleStages? in a high-context
development process,
Then: orchestrate the process with a hub
role, and minimize coupling between other roles,
in a hub-spoke-and-rim geometry.
If you want to change coupling between roles
(particularly if you want to decouple roles),
Then: move responsibilities from one role
to another.
If the right skills and resources don't seem to be applied to a
particular aspect of the work,
Then: go beyond corporate structures to leverage teams in other
organizations (customer, partners, other internal organizations)
If you need more communication between
institutionalized organizations,
Then: leave space for everyday human activities
at the workplace that can provide more complete
and informal communication
If you want to even out communication,
Then: at least try to limit communication
to ThreeToSevenHelpersPerRole_, and to pull
up the outliers to the same level of engagement.
If you need a high throughput development process,
Then: increase coupling between roles to decrease latency.
People and code are the two most important
components of a software development organization.
Customers wouldn't exist without code to sell
to them, and code wouldn't exist without people.
People write code, and the structure of code
in turn affects how people organize.
These patlets point to patterns that help an
organization align the people and code structures
properly.
The patterns themselves can be found in the
section PeopleAndCodePatternLanguage.
If a project has a long life,
Then: use
the architect to carry the vision forward and serve as
the long-term keeper of architectural style.
If you are building a system too large or complex to be thoroughly understood by a single individual,
Then build a team that has both the responsibility and
the power to create the architecture.
If your team is struggling to come up with an architecture,
Then: isolate them physically for several days where they can work uninterrupted.
If you need to make a decision quickly and there are reasons
to exclude others,
Then: make the decision covertly so that
the rationale remains private, though the decision will be publicized.
If there are pockets of misinformation or people out of the loop:
Then: hold short daily meetings to socialize emerging developments.
If reuse is suffering from fragmentation of responsibilities
for an artifact,
Then: give people dedicated, long term
responsibility for a management piece of the system.
If an architect is on an ivory tower, they are out
of touch; yet someone needs to take the big and long
view and reconcile it with practice.
Therefore: the architect is materially involved
in day-to-day implementation.
If you have many new people,
Then: put the experienced people on generic parts of
the work, and give specific assignments to the new people.
If you have geographically separated development,
Then: use standards to link together parts of the architecture
that cross geographic boundaries.
If you need responsibility for code and want
to build on DomainExpertiseInRoles,
Then: give various individuals responsibility for the overall
quality of the code.
If you are trying to partition work in a large project,
Then: make assignments of features to people.
If more than one person is developing software, then
changes affect not only the code, but people as well.
Therefore:
create interfaces around predicted points of variation.
If you want to enable incremental changes without publishing them,
Then: set up a mechanism for developers to version code without checking it in to a public repository.
If you need to develop systems rapidly in an environment where communication is less than optimal,
Then: limit the number of explicit, static, interfaces. Use loose interfaces like callbacks.
If subsystem teams have different Design points,
Then: where two subsystems collide in one class,
assign them to different layers of the class hierarchy.
If you have a creational system which creates different products specified by different groups,
Then: set up factories in a hierarchical arrangement, where each knows about 1 level below only.
If you need you create objects based on type information in an input stream,
Then: use a parser builder which reads type information from the stream and builds the appropriate objects based on this information.
This book has been a team effort, incorporating
pattern material from many sources including
works by Alistair Cockburn, Ward Cunningham,
Steve Berczuk, and others.
Sometimes we have included other patterns
almost intact, and in other cases we have
updated or edited the patterns to fit into
the format or the context of the pattern languages
in this book.
For example, many of Alistair Cockburn's patterns
have essentially the same content here as in their
original publication, but have been radically
reformatted from their original form for the sake
of consistency.
Some patterns, while still relevant to the topic
of organizational structure, didn't quite fit in
the pattern languages here.
That might be because they describe process
instead of structure, or because they are idioms
sensitive to particular situations, or because
they are off-topic, or because they are proto-patterns
awaiting broad substantiation.
But we still refer to some of those patterns
and we commend them to you as great reading.
Here, we provide patlets for those patterns to
which we refer, but which didn't make it into the book.
Because these are often quotes from others, they do not
follow the patlet style we used in our own patlets.
Some of the patlets come verbatim from Linda Rising's
Pattern Almanac [BibRef-Rising2000]--which is
a great source of other organizational pattern
reference material.
Your established team is entering a transition period
where members are replaced by newcomers who
must quickly come to grips with large and
complex software modules.
People are territorial and
need to mark their intellectual
territory to establish a feeling
of ownership.
Newcomers should move in by
cosmetically arranging code.
This must be a background, incremental task
and should not be used as an excuse to trash
the backyard.
Verbatim from [BibRef-Rising2000], p. 27.
From [BibRef-Taylor1999], pp. 632-635.
Referenced in CodeOwnership.
It's difficult to keep documents up to date.
Keep a master hard copy of the design
accessible to the entire team.
Anyone who updates the design must
make corrections in the margin,
delete sections that no longer apply,
or write a description of the change.
Ultimately, one team member
should update on-line copies to reflect the
corrections.
(Verbatim from [BibRef-Rising2000], p. 119.)
From [BibRef-Weir1998].
Referenced in MercenaryAnalyst.
If your downstream implementation teams are ready to get started
even though requirements aren't ready,
Then let them go ahead and
make progress based on their instinct and information at hand.
[BibRef-Cockburn2003]
Referenced in GetOnWithIt.
You don't want the architecture to become convoluted, so
create a small team of resonating minds charged with the job of defining the initial architecture.
[BibRef-Meszaros1997]
Referenced in ArchitectureTeam.
Using teams of similar, like-minded individuals to develop
use cases can result in a set of limited, narrowly ranged use cases that do not satisfy everyone's needs.
Therefore:
Staff the team with people from different specialties to champion the interests of the stakeholders in the development process.
Make sure the team contains both developers and end users.
From [BibRef-Bramble2002], p. 39.
Referenced in DiverseGroups.
If you need to understand requirements and
business needs beyond the use cases,
Then:
-
-
Understand first the network of agents and
commitments that make up the business.
Specify the conversations that take place
at an appropriate level of abstraction,
so that they are stereotypes for actual
stories. Get people to tell these stories.
Ensure that you produce both 'before' and 'after'
business process models.
Eliminate conversations that do not correspond
to business objectives (or discover the missed objective).
Ensure every objective is supported by a conversation.
The solution is verbatim from [BibRef-Graham2003], p. 59.
Referenced in WorkSplit.
You don't know the issues well enough to put
together a sound plan, so deliver something.
This will tell you the real issues.
(Verbatim from [BibRef-Rising2000], p. 168.)
From [BibRef-Cockburn1998].
Referenced in BuildPrototypes and in
the patlet MicroCosm, below.
People make mistakes.
It's difficult to see problems and
errors in your own work.
When one or two designers are
producing a design, there is a strong
likelihood of undetected errors.
Have each designer produce a draft or
a complete design.
Each of one or more reviewers receives
a copy and provides feedback.
(Verbatim from [BibRef-Rising2000], p. 119.)
From [BibRef-Weir1998].
Referenced in GroupValidation.
This pattern language is a "preparation
for customer demonstrations"
([BibRef-Rising2000], p. 48).
The pattern language comprises seven patterns
named ElementIdentification,
CatalyticScenarios,
MutableCode,
PrototypingLanguages,
LightweightUserInterfaces?,
JudiciousFireworks, and
ArchiveScenarios.
From [BibRef-Coram1996].
Referenced in BuildPrototypes and
ScenariosDefineProblem.
How should testers work with designers?
Build rapport with designers.
Approach designers with the attitude
that the system has problems that require
cooperation to resolve.
Designers and testers have a common goal.
Use GetInvolvedEarly and DocumentTheProblem?.
(Verbatim from [BibRef-Rising2000], p. 126.)
From [BibRef-Delano1998].
Referenced in EngageQualityAssurance
and in the patlet GetInvolvedEarly, below.
You don't know what problems you will encounter
during development, so deliver
something early.
Discover what you don't know you don't know.
Deliver regularly and improve each time.
ClearTheFog is the general expression of this strategy.
(Verbatim from [BibRef-Rising2000], p. 168.)
From [BibRef-Cockburn1998].
Referenced in BuildPrototypes,
SizeTheSchedule, LooseInterfaces, and in the
full text of ClearTheFog, which is abstracted above.
People tend to over-emphasize Use
Cases as the final authority on requirements
at the expense of other considerations and
particularly of business needs.
Therefore:
-
-
Hold a workshop involving as many stakeholders as possible.
Make sure that potential users are represented by marketing
personnel or the results of focus groups, surveys, etc.
Find a good facilitator. Agree a mission statement.
Find measures for each objective.
Agree a numerical rank ordering of the priorities.
The solution is verbatim from [BibRef-Graham2003], p. 54.
Referenced in WorkSplit.
You're a system tester working on a large
software project.
To maximize support from the design community,
establish a working relationship with the designers
early in the project, for example, learn
the system and the features along with the designers
or attend reviews of requirements and design documentation.
Invite designers to reviews or test plans.
Use DesignersAreOurFriends.
Don't wait until you need to interact with a
designer; by that time it's too late.
Trust must be built over time.
(Verbatim from [BibRef-Rising2000], p. 126.)
From [BibRef-Delano1998].
Referenced in DesignersAreOurFriends, above,
and in EngageQualityAssurance.
-
-
The requirements and use cases may
evolve during the lifetime of the project.
How do you respond to such developments?
Should you adhere strictly to the original plan?
If not, what is fixed and what should be allowed to vary?
-
- Therefore:
-
-
A web site development project should start
with loose design but clear business objectives,
defined use cases and types and a sound project plan.
Allow the site structure to stiffen the design
only as the site unfolds and only completely
towards the end of the project.
The entire patlet is abstracted
verbatim from [BibRef-Graham2003], p. 77.
Referenced in WorkSplit.
A newly formed team is given a project
with a tight schedule, uncertain requirements,
uneven distribution of skills, and new technologies.
Let the most skilled and knowledgeable developer
drive the design and implement the critical pieces.
(Verbatim from [BibRef-Rising2000], p. 130.)
From [BibRef-Olson1998a], pages 153-154.
Referenced in ArchitectAlsoImplements.
When ProductInitiative has been followed,
hold a walkthrough of program and product
concepts with both the development and
business sides of an organization.
When this pattern has been followed,
use ImpliedRequirements.
(Verbatim from [BibRef-Rising2000], p. 52.)
From [BibRef-Cunningham1996], p. 375.
Referenced in ImpliedRequirements
and in ProductInitiative, below.
You need to partition the design work for a large system.
There must be a chief architect or small team
to provide design integrity.
Yet in a large development project,
it might be possible for this core team to do all the design work.
The core team should provide an overview of the
system architecture and divide
the system into independent components.
Journeymen architects then design the components
and act as chief architects for the components.
(Verbatim from [BibRef-Rising2000], p. 118.)
From [BibRef-Weir1998].
Referenced in ArchitectureTeam.
You have to create a plan but have never done this
sort of project, so run an 8- to 12-week instrumented
pilot to get productivity and throughput data
for your plan.
ClearTheFog is the general expression of this strategy.
(Verbatim from [BibRef-Rising2000], p. 168.)
From [BibRef-Cockburn1998].
Referenced in BuildPrototypes.
Be sure every deliverable has one and only one owner.
This is a general strategy with specializations:
DayCare, FunctionOwnerAndComponentOwner, and TeamPerTask.
(Adapted from [BibRef-Rising2000], p. 169.)
From ([BibRef-Cockburn1998], p. 220-221).
Widely referenced in many patterns, but
key to CodeOwnership,
FunctionOwnerAndComponentOwner,
SubclassPerTeam, and TeamPerTask.
You cannot satisfy stakeholders' needs without their
input and feedback.
Therefore:
Actively involve your customers and internal stakeholders in the
use case development process when possible.
From [BibRef-Bramble2002], p. 35. Referenced in EngageCustomers.
A peacemaker is a placeholder in an organization
who tries to calm and hold things together
until a leader can be found or a
reorganization is complete.
The peacemaker should be someone who is well liked
but who is not necessarily technically proficient.
Usually this individual has many years with
the company, knows the political ropes,
and can buy time for a team as well as
the team's management.
Usually PeaceMaker follows SacrificialLamb and
precedes CultOfPersonality or GuruDoesAll.
(Verbatim from [BibRef-Rising2000], p. 131.)
From [BibRef-Olson1998a], p. 168.
Referenced in MatronRole.
In this book,
SacrificeOnePerson is an alias for
SacrificialLamb.
When a wish list of features and functions is created for a product,
clearly define an initiative for product improvement and be sure
everyone understands the initiative.
When this pattern has been followed, use MarketWalk-through.
(Verbatim from [BibRef-Rising2000], p. 52.)
From [BibRef-Cunningham1996], pp. 374-375.
Referenced in ImpliedRequirements and in
MarketWalk-through, above.
To avoid the risk of commiting to production decisions prematurely
and the problems of long-term maintainability of code,
work with customers to initially build LoFidelityPrototypes? using paper widgets, drawings, paper stickies, and index cards.
If the skill and tools are present, build HighFidelityPrototypes?.
From ([BibRef-Whitenack1995], p. 288).
Referenced in BuildPrototypes.
You're using ReportObjects? and need to create
queries for reports at run-time.
Create objects that represent queries.
Define operations on these objects and
a method to return query results.
(Verbatim from [BibRef-Rising2000], p. 41.)
From [BibRef-BrantYoder1999].
Historically from [BibRef-BrownWhitenack1999].
Referenced by ParserBuilder.
The lack of a clear vision about a system can lead to indecision and
contrary opinions among the stakeholders and can quickly paralyze
the project.
Therefore:
Prepare a statement of purpose for the system that clearly describes
the objectives of the system and supports the mission of the organization. Freely distribute it to everyone involved in the project.
From [BibRef-Bramble2002], p. 80. Referenced in UnityOfPurpose.
Software systems cannot stand still,
but different components change at different rates.
Factor the system so that components
that change at similar rates are together.
(Verbatim from [BibRef-Rising2000], p. 21.)
From [BibRef-Foote2000].
Referenced by VariationBehindInterface.
Using too many people to write a use case is inefficient, and the
compromise made to align the many different points of view may result
in a less than satisfactory system.
Therefore:
Restrict the number of people refining any one work product to
just two or three people.
From [BibRef-Bramble2002], p. 31. Referenced in SizeTheOrganization.
When team membership is likely to change,
separate subsystems by staff skill requirements.
This allows specialists to work in their
area of expertise and enables successors
to see the results of these special abilities
in isolation.
(Verbatim from [BibRef-Rising2000], p. 135.)
From [BibRef-Cockburn1996].
Referenced by ConwaysLaw and DeployAlongTheGrain.
Work is not always assigned to right place, done at the right time and assigned to correct people. Go beyond the historical, organizational, financial or political barriers and allocate work to produce
the most effective outcome.
Unpublished; see [BibRef-Beedle2000].
Referenced in UpsideDownMatrixManagement.
