Patlets

This appendix of patlets—pattern summaries—might help you find a pattern that addresses some particular problem or context in your Scrum team, or might help you find a pattern you vaguely recall having heard of. The patlets are simple problem/solution pairs that summarize the core of each pattern. We encourage you to go back and read the original pattern to pick up important subtleties not covered here.

Patterns in the Product Organization Pattern Language

§ 1 The Spirit of the Game.: If team members believe they can “implement Scrum” by following its rules instead of acting on the deeper rationales behind them, then explicitly emphasize the spirit, not the rules of Scrum, as a foundation for the culture.
§ 2 The Mist.: Great works start with a vague longing across some community. Therefore, an individual, or a collective mind of several individuals, conceives a vision of how to improve quality-of-life.
§ 3 Fertile Soil.: Personal interaction qualities both reflect and define organization qualities. Therefore, demonstrate the values of Commitment, Focus, Openness, Respect, and Courage in your day-to-day behaviors and interactions.
§ 4 Conway’s Law.: An organization should partition itself to maximize its communication effectiveness. Therefore, structure the organization into Small Teams, each attuned to concerns that create the most value to the enterprise.
§ 5 Birds of a Feather.: Empowered teams that self-organize tend to isolate themselves from the enterprise, but people best develop core competencies across boundaries of diverse work. Therefore, form an ad hoc group for sharing expertise in each core competency.
§ 6 Involve the Managers.: If development efforts are languishing for lack of coordination across products or because administrative tasks displace development efforts, then enlist a small management staff as “über ScrumMasters” who can initiate radical change, remove impediments, provide administration and coordinate from a “big picture” position.
§ 7 Scrum Team.: Division of labor is inefficient at producing complex products. Therefore, form a team of people: Development Team, a Product Owner, and a ScrumMaster.
§ 8 Collocated Team.: If the complexity of collaborative development demands high-fidelity communication, then locate the team together within talking distance.
§ 9 Small Teams.: Having many people working on the same thing inflates communication overhead. Therefore, use small teams of people working on serialized work rather than striving for false parallelism.
§ 10 Cross-Functional Team.: Organizations often organize around areas of competence, but it is too slow to coordinate across these boundaries. Therefore, the team as a whole should embody all the talent necessary to deliver product.
§ 11 Product Owner.: You need a single, ordered Product Backlog. Therefore, get a Product Owner with deep business experience and domain knowledge to create the backlog.
§ 12 Product Owner Team.: For a large product, the Product Owner can get overwhelmed. Therefore, several people form a team to bridge the business concerns with development, led by the Chief Product Owner.
§ 13 Development Partnership.: Arbitrary organizational or political boundaries obstruct communication between the vendor and the client. This leads to requirement hand-offs, distrust, and eventually failure. Therefore, break down the barriers with a mutual agreement to collaborate frequently.
§ 14 Development Team.: Many hands make light work. Therefore, build a stable team to deliver successive increments of the Product Owner’s vision.
§ 15 Stable Teams.: If you need predictability, then keep teams stable and avoid shuffling people around between teams.
§ 16 Autonomous Team.: If policies and procedures applied across multiple contexts are dysfunctional, then the Scrum Team governs its work free from external control, and the Development Team manages its own work.
§ 17 Self-Organizing Teams.: Specialized skills can't accomplish work without coordination. Therefore, the Development Team organizes itself to get its work Done.
§ 18 Mitosis.: A Scrum Team should grow in an incremental, piecemeal fashion; but eventually, the team just becomes too large to be efficient. Therefore, after it gradually grows to the point of inefficiency (about seven people), split one large Development Team into two small ones.
§ 19 ScrumMaster.: A self-organizing team cannot objectively see itself. Therefore, select one member to be the ScrumMaster, who helps the team improve its effectiveness.
§ 20 Oyatsu Jinja.: Interruptions take focus away from product development. Therefore, create a snack shrine (Oyatsu Jinja) with snacks and drinks, where developers can entertain requests from the rest of the organization without interrupting their periods of flow.
§ 21 Small Red Phone.: If the whole team is dependent on select key members, then issue a cellular hotline to the key members, only for critical use.
§ 22 Scrum (Master) Coach.: If the ScrumMaster’s own shortcomings are limiting the team’s growth, then the ScrumMaster should periodically seek opportunities for reflection with a coach.
§ 23 Fixed Work.: The Product Owner must account for all work to use team velocity for release planning, yet not all development work can be time-boxed. Therefore, leave the fixed work of standard, recurring Scrum events out of the Production Episode time budget.
§ 24 Sprint Planning.: A Sprint aims to produce a potentially shippable product increment within a fixed time box. If the Scrum Team agrees on the Sprint Goal at the beginning of each Sprint, then they plan which PBIs to complete and how to do the work.
§ 25 Swarming: One-Piece Continuous Flow.: Working on too many things at once reduces velocity and the quality of work. Therefore, have the whole Development Team work together on one Product Backlog Item at a time.
§ 26 Kaizen Pulse.: It’s difficult to absorb improvement lessons continuously without careful observation. Therefore, alternate process improvement with periods of controlled velocity.
§ 27 Remove the Shade.: If a hero in a team starts to overshadow other members, then remove the hero so that the rest of the team can grow.
§ 28 Pop the Happy Bubble.: If teams get complacent when things go well, then burst the team's bubble by making them confront their deficiencies.
§ 29 Daily Scrum.: When delays and blockages happen in a Sprint, team dynamics require reshaping. But too much replanning wastes time. Therefore, have a short meeting every day to replan the Sprint.
§ 30 ScrumMaster Incognito.: At the Daily Scrum, the Development Team members report status to the ScrumMaster instead of interacting with each other. Therefore, the team addresses each other instead, with the ScrumMaster taking on a silent role.
§ 31 Norms of Conduct.: Members of a new Scrum Team bring different norms that could lead to misunderstanding and distrust. Therefore, establish norms of conduct to facilitate accountability and allow positive conflict.
§ 32 Emergency Procedure.: Inevitably, unanticipated problems arise and cause the Sprint Goal to slip out of reach, but waiting until the Sprint Review derails the whole Sprint. Therefore, reevaluate the work plan mid-Sprint and escalate the solution with a predefined procedure.
§ 33 Illegitimus Non Interruptus.: If various stakeholders and emergent requirements interrupt the team, crippling its progress, then explicitly allot time for interrupts and time-box unplanned work to that budget.
§ 34 Scrum of Scrums.: The Product Owner specifies goals that may be common across multiple Development Teams. Therefore, give the Development Teams the right and responsibility to coordinate their efforts to realize these common goals, jointly collaborating as a group of workers called the Scrum of Scrums.
§ 35 Sprint Review.: Business stakeholders do not intervene during the Production Episode time box, but they need to stay in sync with product development. Therefore, hold a meeting for the Product Owner and other stakeholders to discuss what the Development Team has produced.
§ 36 Sprint Retrospective.: Over time, without explicit attention, processes and discipline tend to decay. Therefore, hold a meeting at the end of each Sprint to reflect on the development process.
§ 37 MetaScrum.: Scrum Teams are in place in an enterprise, but legacy management interferes by trying to exercise control over products. Therefore, create a forum (the Meta Scrum) for the whole enterprise to give management a say in Product Owners’ portfolio decisions.
§ 38 Product Pride.: If team members need to know their work matters and to have a say in how it’s done, then create a climate that enables Autonomy, Mastery, and Purpose.

Patterns in the Value Stream Pattern Language

§ 39 Vision.: Overly specific constraints can turn contributors into subservient robots. Therefore, stakeholders and potential future coworkers rally to articulate and to refine together the Product Owner’s Vision.
§ 40 Impediment List.: Impediments to progress surface all the time, but addressing them immediately may not be practical. Therefore, make them visible on a list.
§ 41 Value Stream.: The development process and the path from conception to market are as important to product success as the product idea itself. Therefore, create an ecosystem to deliver ever-increasing value in an evolving product.
§ 42 Set-Based Design.: If tackling a problem with many dimensions, then explore multiple potential solutions where each one probes different regions of each dimension, so the team develops a broad intuition of the problem, leading to the best feasible current option.
§ 43 Sprint Burndown Chart.: Progress should be immediately visible to Development Team members. Therefore, publicly post a graph that plots estimated work remaining in the Sprint against the remaining time.
§ 44 Scrum Board.: There's a danger that the Development Team will lose its focus on the Sprint Goal. Therefore, create a Scrum Board that visualizes the Sprint Backlog and the current status of the work.
§ 45 Product Roadmap.: When the vision is clear and the market is ready, the team needs concrete steps to act on the opportunity. But a list cannot express the uncertainty ahead. Therefore, the Product Owner should lay out alternative paths, making the uncertainty visible. Only then a Product Backlog can take shape.
§ 46 Sprint.: The team needs to deliver Product Increments often enough to correct its course based on frequent feedback from the end user. Therefore: Organize development around recurring, frequent, fixed-length time-boxed intervals called Sprints.
§ 47 Organizational Sprint Pulse.: The Scrum Team and the rest of the organization are out-of-step, causing waiting time or interruptions. Therefore, synchronize the teams’ Sprints to the organization’s rhythm at least once a month.
§ 48 Release Plan.: If the stakeholders need to know which product increments are coming out and when, then create an ordered list of deliverables and forecast dates from the Product Backlog.
§ 49 Release Range.: Release dates inherently lack precision, but stakeholders tend to treat an estimated delivery date as a commitment. Therefore, make pessimistic and optimistic estimates for release dates based on Product Backlog Item estimates and a range of historic team velocities.
§ 50 ROI-Ordered Backlog.: The Product Backlog needs some order to drive the order of delivery. Therefore, Order PBIs in a way that generates the largest long-term ROI.
§ 51 High Value First.: Some PBIs are critical, while others are just nice to have. Therefore, deliver the highest-value product increment first.
§ 52 Change for Free.: The Scrum Team wants to respond to new client requirements while avoiding scope creep. Therefore, offer clients the option of exchanging an emergent requirement for any existing PBI that is of equal or lower value to them, as long as the development cost of the new item is no more than the cost of the original.
§ 53 Money for Nothing.: Spending time building a product increment that costs more than it’s worth is waste. Therefore, stop work when the product’s development costs begin to exceed its expected value.
§ 54 Product Backlog.: Even when everyone agrees to what product increments to deliver, the Development Team doesn’t know what it should deliver first. Therefore, create an ordered list of product increments arranged by their delivery date.
§ 55 Product Backlog Item.: The Product Backlog is composed of large, monolithic parts that impose unnecessary risk. Therefore, create Product Backlog Items (PBIs), distinct specifications of changes and additions to the product.
§ 56 Information Radiator.: Information flow is critical to the organization, but sharing through reports and meetings wastes effort, often discouraging communication. This results in sharing too little. Therefore, display information on a physical wall and keep it frequently updated.
§ 57 Pigs Estimate.: Estimates of effort should be based on what is known rather than on wrong assumptions and wishful thinking. Therefore, let the Development Team, whose members are committed to working on the product, estimate the work.
§ 58 Small Items.: When work items are too big, they become hard to understand and estimate. Therefore, decompose large items into smaller items that Developers can easily understand and build.
§ 59 Granularity Gradient.: Small Items are easiest to estimate, but breaking down larger work items is work in itself. Therefore, break down only the earliest Product Backlog Items into Small Items.
§ 60 Estimation Points.: It is important to easily make estimates that are reliable enough to confidently forecast the amount of work that the team can complete in a Sprint. Therefore, use unit-less relative numbers for effort estimation.
§ 61 Fixed-Date PBI.: Dependencies for the product often appear on their own time and cannot be scheduled by the Development Team—but the team must account for how it shifts the schedule.
§ 62 Vacation PBI.: Most corporate value systems honor vacations. But while they don’t create market value in the way that product increments do, the Product Owner should make their cost and value visible. Therefore, track the time and value of team members' absences as PBIs.
§ 63 Enabling Specification.: If the Development Team is uncertain about the product vision and the development process, then the Product Owner should specify the PBI for the Development Team in enough detail to leave no question unanswered.
§ 64 Refined Product Backlog.: Market volatility changes the relative value of PBIs. Therefore, the Scrum Team meets regularly to properly order, break down, and estimate the Product Backlog.
§ 65 Definition of Ready.: Improperly defined PBIs lead to waste in development effort in a Sprint, causing it to fail. But a common understanding of PBIs leads to focus in the team. Therefore, create an objective “Ready” standard before placing a PBI in a Sprint (i.e., estimated, testable, small items, discussed, and has customer value).
§ 66 Yesterday’s Weather.: If courage emboldens the team to set overoptimistic goals, then refer to the work Done in the last Sprint to forecast the work for the upcoming Sprint.
§ 67 Running Average Velocity.: The velocity should reflect the team’s current capacity, but velocity takes time to stabilize after a change. Therefore, use a running average of the most recent Sprints to estimate the velocity.
§ 68 Aggregate Velocity.: Multiple Scrum Teams working towards a single release date should estimate when they will deliver, but it makes no sense to sum unit-less velocities from different teams. Therefore, estimate PBIs together so there is a single velocity scale across teams.
§ 69 Specialized Velocities.: If the product grows to multiple teams, then each team estimating and delivering the product increments for the whole product is waste.
§ 70 Updated Velocity.: You want the velocity to reflect the team's current abilities, yet it takes time to monitor your improvements. Therefore, update the velocity only if the team sustains a new level for three Sprints in a row.
§ 71 Sprint Goal.: A Sprint that consists only of tasks is not enough to relate the team’s effort to Greatest Value. Therefore, create a concise goal to unify the team's achievements throughout the Sprint.
§ 72 Sprint Backlog.: The Development Team should understand the work needed for achieving the Sprint Goal. Therefore, create a work plan at the Sprint Planning Meeting for everything that the Development Team needs to do in that Sprint.
§ 73 Sprint Backlog Item.: A PBI clarifies what to build but does not specify how to build it. Therefore, during Sprint Planning, break down PBIs into smaller work items for the development plan.
§ 74 Teams That Finish Early Accelerate Faster.: Teams often take too much work into a Sprint and cannot finish it. Failure to attain the Sprint Goal prevents the team from improving. Therefore, take less work into a Sprint.
§ 75 Production Episode.: The collective flow of the team demands fewer disruptions and a sense of urgency. Therefore, time-box all development efforts, with participation limited to the Development Team.
§ 76 Developer-Ordered Work Plan.: The Scrum Team commits to a Sprint Goal, and there are multiple ways to achieve it. Therefore, let the developers decide the best ordering of the work in the Sprint Backlog to achieve the Sprint Goal.
§ 77 Follow the Moon.: Every culture acts in cadence to natural events, yet business cycles track the Gregorian calendar. Therefore, define Sprints with beginning and ending boundaries on the New Moon and the Full Moon.
§ 78 Visible Status.: Without a frame of reference, you can unknowingly drift. Therefore, create a status overview that demands action when statuses are outside acceptable tolerance.
§ 79 Dependencies First.: If dependencies remain halfway through the sprint, they may bring the rest of the Sprint to a halt. Therefore, make sure that all known dependencies are under control by mid-Sprint.
§ 80 Good Housekeeping.: Where there’s a mess, you lose time and energy finding where and what to start on. Therefore, maintain a completely clean product and work environment continuously, or clean at the end of each day.
§ 81 Whack the Mole.: Defects arise while adding new functionality. Postponing work on defects causes them to pile up, which further impedes development. Therefore, as soon as the team discovers defects, developers should drop what they are doing and mitigate them immediately
§ 82 Definition of Done.: Mismatched understanding of Done in the team will produce varying quality in tasks. Done means that there's no more work left for that task. Therefore, the Development Team agrees on what Done means beforehand.
§ 83 Team Sprint.: PBIs with smaller value never make it to a Sprint, even if the team cares deeply about them and they may contribute to long-term cost reduction. Therefore, on occasion, let the team choose which PBIs they want to include in the Sprint.
§ 84 Responsive Deployment.: If some PBI development finishes in the middle of a Sprint, then instead of waiting until the end of the Sprint, the Product Owner releases PBIs as soon as they’re Done.
§ 85 Regular Product Increment.: It's important to measure development progress by checking off completed work, but outcomes are more important than output. Therefore, mark progress every Sprint as a delivered Product Increment, and elicit feedback on how it matches end-user needs.
§ 86 Release Staging Layers.: We would like to receive stakeholder feedback as frequently as possible, but it is too risky to deploy to the whole market at once. Therefore, partition the market into multiple release groups, from beta testers to the whole market. Release every Sprint to the appropriate groups.
§ 87 Testable Improvements.: If you are working on a complex product, measures of value may vary for both planned and unplanned reasons, and it may be difficult to tie an increase to a planned kaizen. Therefore, monitor both the actions that a team takes to realize a kaizen, and the corresponding change in value.
§ 88 One Step at a Time.: If changing multiple things at once obscures which change led to an improvement, then make one process improvement at a time.
§ 89 Value Areas.: If teams work across more and more customer domains and start to approach the boundaries of what they can master, then organize the teams around areas of customer value.
§ 90 Value Stream Fork.: Product success needs a crisp market identity, but a growing product with divergent features dilutes the focus of a single Scrum Team. Therefore, split a large product and its Value Stream into multiple Value Streams, each with its own Product Backlog and Product Owner.
§ 91 Happiness Metric.: If a growing list of improvement activities dampens the team's passion for the work, then prioritize the items on the impediment list in order of the team’s passion to solve them.
§ 92 Scrumming the Scrum.: Scrum is more than just doing work; it’s also about improving the way we work. Therefore, resolve the most important impediment by putting one in the Product Backlog every Sprint.
§ 93 Greatest Value.: The team works to contribute to overall value, but short-term thinking leads to improving just the small things. Therefore, let the Vision direct the team’s attention to the greater scope.
§ 94 Product Wake.: Products can't last forever, and the organization shouldn't tie up talent to feed a dead Value Stream. Therefore, at the end of a product’s life, give it a decent burial.

Patterns from the Organizational Patterns Book

The following patlets describe patterns from the Organizational Patterns book, [1] 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.)

Patterns from Fearless Change

This patlet describes a pattern from [2] by Linda Rising and Mary Lynn Manns.

§ 135 Do Food.: If you want to draw people to an event in which they otherwise might hold only a neutral interest, then entice them with food and refreshments.

[1] James Coplien and Neil Harrison. Organizational Patterns of Agile Software Development. Pearson, 2005.

[2] Linda Rising and Mary Lynn Manns. Fearless Change. Addison-Wesley, 2004.