PMI-ACP Promote Knowledge Sharing: Lessons Learned, Communities of Practice and Knowledge Assets

Promoting knowledge sharing means making sure that what one person or team learns reaches the people who need it, at the moment they need it, and changes how they work. The agile leader does not have to hold the knowledge. The leader's job is to build the conditions in which knowledge is captured, found, passed on and kept current as a normal part of delivery.

The PMI-ACP Examination Content Outline lists this as the third task under the Leadership domain, with three enablers that this lesson follows:

1. Create an environment to capture and share knowledge (for example, lessons learned for continuous improvement, retrospectives and communities of practice).
2. Leverage organizational knowledge assets (for example, from other similar initiatives, people and processes).
3. Allocate time for knowledge sharing and making required updates.

Neighbouring tasks share vocabulary but test different things. Turning a team's own retrospective findings into improvement actions belongs to the Mindset domain's collaborative-team task, and making learning visible on information radiators belongs to its transparency task. Encouraging and modelling cross skills (generalizing specialists) is an enabler of the Mindset domain's Embrace change task. Coaching and mentoring individuals belong to Empower teams, and finding a problem's root cause belongs to Facilitate problem resolution. This lesson is about the flow of knowledge between people, teams and initiatives.

Agile teams capture and act on lessons learned continuously, mainly in the retrospective at the end of every iteration, instead of collecting them once in a workshop when the project closes. A lesson is worth most while the team that learned it can still use it; collected at the end, it only helps the next project, if anyone reads it.

Three habits follow from this:

• Every iteration is a learning cycle. The retrospective asks what helped, what hurt and what the team will try next. Phase-end or mid-point workshops are still too infrequent for an agile cadence.
• Urgent knowledge does not wait for a ceremony. The retrospective is a regular checkpoint, not a gate. When someone finds a workaround that unblocks teammates today, they share it today (and the retrospective can still discuss whether it should become a lasting fix).
• Hybrid environments can feed a register as they go. When a PMO or a predictive part of the program asks for a lessons-learned register for future initiatives, the team does not need a separate closing workshop. It can add each retrospective's agreed lessons to the register every iteration. That meets the requirement with little extra effort, keeps the detail fresh, and keeps the raw retrospective discussion inside the team.

A lesson has only been learned when it changes what people do. Capturing it is the easy half. A lessons page or repository is passive: it helps only when someone consults it at the moment a decision is made, and teams under pressure rarely stop to search. When the same mistake repeats although it is already written down, polishing the record seldom helps. The problem is that the lesson never reaches the decision point.

Ways to bring lessons to where decisions happen:

• Review relevant lessons during planning. Release planning and iteration planning are where a lesson about underestimated stories or late environment requests can change the plan.
• Turn a lesson into visible work. If a lesson says test environments are always requested too late, a backlog item to book them at the start puts the lesson into the plan itself.
• Build recurring lessons into existing checklists and practices such as the release-planning checklist, the definition of ready or the definition of done, so that following the normal process applies the lesson.

Keep it inside the normal flow of work. A checkpoint that someone must tick adds overhead, turns learning into compliance and tends to be ticked rather than used. The test is simple: is the lesson in the room, in a form people act on, at the moment the plan is being formed?

Retrospectives are a knowledge-sharing tool as well as an improvement tool, and their learning often helps other teams. When several teams work on the same product, one team's fix for a shared problem (flaky tests, deployment failures, a defect pattern) can save the others weeks. A periodic cross-team retrospective (sometimes called a scaled or overall retrospective) brings the teams together to share what they have learned and to tackle problems that span teams. The value comes from teams hearing each other's reasoning and asking questions, which a circulated document cannot offer.

The constraint is psychological safety. A retrospective works because members speak openly, and they stop doing so if they believe the notes will reach management or be published. So the team owns what leaves the room:

• The team agrees which insights to share and in what form. Sharing too much breaks the safety that produced the insight, and sharing nothing wastes it, so the team curates.
• The most effective channel is often the team itself presenting its approach, for example at a cross-team session, a show-and-tell or a community of practice. The listeners can ask questions, which a published page does not allow.
• Insight spreads best by demonstration and conversation; instruction from above replaces learning with compliance. When it is needed soon, choose a channel that can happen soon.

A community of practice (CoP) is a group of people who share a craft or concern and get better at it by interacting regularly. The term comes from Jean Lave and Etienne Wenger's work on situated learning. In agile organisations, CoPs connect specialists (testers, front-end developers, security champions, scrum masters) who are spread across cross-functional teams, so that their craft stays connected even though their day-to-day team is not a functional department.

A healthy CoP has these traits:

• Voluntary membership based on interest, not nomination by line managers.
• A member-set agenda built from the problems members currently face.
• No authority over teams. It spreads practice through shared experience and influence. Once it starts governing or policing teams, it becomes another approval layer.
• Ongoing life. It exists as long as members find value in it, not until a deliverable is done.

When a CoP fades (attendance drops to a few people), the signal is that it has stopped serving members. Making it compulsory or monitored treats the symptom and kills the ownership that made it work. The fix is to ask members which problems would make the sessions worth their time and let them reshape it.

Measuring a CoP's value works the same way. Counting activity says little, and output targets push the community towards becoming a standards body. Better evidence is what members say the community helped them solve, for example a stuck problem fixed or a practice another team reused.

A community of practice is the right structure for ongoing peer learning in a craft; other cross-team structures fit other goals. The exam often offers them as near twins, so match the structure to the need:

Two distinctions decide most questions. If the standards already exist but practitioners apply them inconsistently and keep solving the same problems separately, connecting the practitioners in a CoP helps more than adding oversight or formal instruction. If teams must reach one binding decision by a deadline, an open-ended CoP is the wrong tool: a time-boxed working group with members from the affected teams fits: it brings the affected teams into one decision and then disbands.

Explicit knowledge can be written down (facts, steps, procedures, configuration); tacit knowledge lives in people's heads as judgement, intuition and know-how built from experience. They need different channels. Explicit knowledge transfers well through documents, guides and checklists. Tacit knowledge transfers mainly through shared work: pairing, shadowing, mob (ensemble) programming and working through real cases together. Ikujiro Nonaka and Hirotaka Takeuchi popularised this distinction in organisational learning.

That last row matters: when a team follows a handover document's steps correctly but keeps making poor calls the expert used to make by experience, the gap is not in the document at all. Judgement does not travel well on paper; it needed time working alongside the expert before she left.

Knowledge silos. When every item touching one component goes to the same person, because "it is faster that way", the team has a knowledge silo and a low bus factor (also called truck factor): delivery depends on one person being available. Queues behind that person on the board are the visible symptom. The remedy is to spread the knowledge deliberately:

• Change the expert's role from doer to guide: others pick up the work while the expert pairs with them or guides them. This spreads knowledge while protecting quality, because the expert stays involved in the work itself rather than at the end of it.
• Start small and make the trade-off explicit. Spreading work slows the next few items, so the scrum master agrees a few paired items with the product owner, making the cost visible and time-limited.
• Writing things down helps with the explicit steps, but it does not transfer judgement.

Organizational knowledge assets are what the organisation already knows from earlier work: records from similar initiatives, the people who did that work, and the processes and templates other teams built. (PMI's predictive vocabulary calls the documented part organizational process assets.) Leveraging them means using them early, preferring evidence of what actually happened, engaging the people, and tailoring what you reuse.

Use them early

Lessons and data from similar initiatives are most valuable before planning, while the plan can still change. Consulted once delivery is under way, they arrive after the plan has already formed without them.

Prefer actuals over plans

For forecasting, a similar initiative's actual results (throughput, cycle times for similar work items) are stronger evidence than any estimate. Plans show what someone hoped; actuals show what this organisation delivered. Earlier risk registers are useful input, and the team reviews them and tailors them to the new context.

People are knowledge assets

The people who did similar work are often the most valuable asset, especially when the written record is thin. A working session with them, or having them pair with the team on its first attempt, transfers both the explicit steps and the tacit judgement. Written handovers and formal training can capture the steps but lose the tacit part. Internal directories and communities of practice help find these people.

Adapt, don't adopt

Processes, checklists, definitions of done, working agreements and board designs from other teams are a starting point. They carry the assumptions of the team that built them: its size, location, product, regulation and type of work. The receiving team reviews them and keeps what fits, tailoring the rest. Adopting unchanged "for consistency" imports irrelevant steps (for example, regulatory checks that only another product needs) or practices that relied on conditions the new team does not share. Discarding them and starting from scratch throws away hard-won learning. Asking the original team why each practice was chosen helps the new team tailor sensibly, and the decisions stay with the team that will use the process.

The right knowledge-sharing format depends on the goal (awareness, skill or ongoing exchange), the audience, how often the content changes and whether the people are co-located. Common formats:

Use the stated constraints to choose. An idea someone wants to float informally, at almost no cost and without changing anyone's process, fits an optional lunch-and-learn open to all teams. Many people needing a working skill within weeks fits hands-on sessions run by the internal experts. Teams spread across time zones with fast-changing material fit short asynchronous content in a living guide that is cheap to keep current.

Knowledge sharing and keeping shared knowledge current must have time allocated in the team's capacity, just like delivery work; otherwise they are the first things dropped when delivery pressure rises. Repeated cancellations and a growing pile of out-of-date documents are the warning signs.

Reserve capacity, with the product owner

• Iteration-based teams reserve capacity for sharing when they plan each iteration, for example a fixed share of time, so the sessions are part of the plan rather than whatever is left over.
• Flow-based (Kanban) teams have no iteration plan, so they reserve capacity on the board, for example a lane or part of the WIP limit for learning, sharing and update items. Without that, the board never has a natural gap for it.
• Time for sharing comes out of delivery capacity, so it is agreed with the product owner. If the product owner objects, the scrum master brings evidence of what knowledge gaps have cost (for example, releases that slipped because one person understood a component) and proposes a trial allocation. That keeps the decision collaborative.
• An agreed allocation can flex for a genuine emergency, as an open, one-off trade-off between the team and product owner. What matters is that the trade-off is visible and agreed, and that the allocation returns afterwards.
• Time outside working hours is not an allocation; it shifts the cost onto people and rarely lasts.

Make required updates part of done

Required knowledge updates (runbooks, troubleshooting wikis, user guides, architecture decision records) stay current when they are part of the definition of done for each item, and when the team includes that effort in its estimates. Anything that moves the update to a later moment or a different person lets the knowledge fall behind the product and recreates a separate documentation phase.