PMI-ACP Promote the Agile Mindset: Values Awareness, Kaizen, Continuous Improvement and Recognizing Agile Behaviour

Promoting the agile mindset means helping a team and the people around it understand why agile works, so that they live its values instead of only following its ceremonies, keep improving how they work, and see agile behaviour noticed and rewarded. It is a leadership task: the agile practitioner influences, coaches and models; it does not command compliance.

The PMI-ACP Examination Content Outline lists Promote agile mindset principles and practices as a task in the Leadership domain, with three enablers that this lesson follows:

1. Create awareness around the agile values and principles — for the team, managers, executives and other stakeholders.
2. Foster an environment for continuous improvement — small, frequent, team-owned change with real capacity behind it.
3. Recognize, celebrate and encourage agile behavior — reward collaboration, transparency, early feedback and sustainable pace, not individual output or heroics.

The outline's process-improvement tools support the second enabler: Kaizen, retrospectives and intraspectives. Its analysis and design tools include collaboration games, which serve the first enabler.

Several neighbouring tasks share vocabulary. Applying the Agile Manifesto and complexity models such as Cynefin to a decision belongs to the Mindset domain, as does recognising effort under a growth mindset and turning retrospective findings into actions. Motivation, trust and coaching versus mentoring belong to Empower teams; root cause tools to Facilitate problem resolution; measuring whether an improvement worked to the Delivery domain. This lesson is about the leader's job of spreading and sustaining the mindset itself.

Doing agile is performing the practices; being agile is holding the values and principles those practices exist to serve. A team can hold every event, keep every artifact and still not be agile, because a practice performed without its purpose becomes a ritual. This is often called cargo-cult agile: copying the visible form in the hope that the results follow.

Typical signs that practices have become rituals:

• Retrospectives end without any action the team intends to take.
• Reviews are demonstrations nobody comments on, so no feedback reaches the backlog.
• The daily meeting is a status report to the practitioner, and nobody changes plans afterwards.
• People explain an event with "the framework requires it" rather than what it does for them.

The first response is to reconnect each practice to its purpose with the team. Changes imposed from outside the team leave the purpose unexplained, and quoting the framework's rules back at people repeats the very cause of the problem.

When a team asks to drop a practice, treat the request as information. Self-organizing teams shape their own process, so the practitioner neither refuses by citing the rules nor simply agrees and loses what the practice provided. The useful move is to ask with the team what the practice should achieve for them, then redesign it so it does.

Stakeholders and managers learn agile values best when the practitioner speaks to their concerns and lets them see working product. Handing people theory changes little, and recreating the old predictive reporting keeps the old model alive.

Two misconceptions recur with senior stakeholders:

• Velocity as a target. Velocity is relative to a team's own estimates. It is a planning aid for that team, not a productivity measure, and cannot be compared across teams. Any target set on it invites estimate inflation rather than better results.
• Plan conformance as success. Judging agile by whether the original plan was hit measures it against the predictive model it replaces. Success is better described as value delivered early, learning from feedback and risk reduced.

Building awareness this way also keeps the stakeholder involved and supportive, which matters because a sceptical manager or specialist can stall an agile adoption.

Agile values are learned most durably by experience: a short simulation or collaboration game, a debrief that links what happened to the team's real work, and one small change the team then tries. Passive formats such as lectures and reading tend to be forgotten, especially by teams that have already sat through them.

A typical example is a batch-size game, such as passing coins or paper items through a line of people first in large batches and then one at a time. The team sees for itself that small batches deliver the first finished item sooner and expose problems earlier. Other games demonstrate work-in-progress limits, self-organization or the cost of handoffs.

The game alone is not enough. Each step has a job:

1. Experience — the simulation makes the principle felt rather than told.
2. Debrief — the team reflects on what happened and connects it to its own work. Without this reflection, whether anyone links the game to the principle is left to chance; more activity does not substitute for it.
3. Apply — the team chooses one small change to try in the next iteration. Learning that never reaches real work has stopped one step short, and a change ordered from above turns learning into compliance.

Leaders promote the agile mindset mainly through what they do, because people copy behaviour rather than instructions. When a leader's actions contradict the message — asking for transparency while keeping private records, praising experiments while criticising one that failed, inviting adaptation while still requiring sign-off — the team follows the action and the message loses credibility.

Practical forms of modelling:

• Transparency. A leader who wants others' work and impediments made visible makes their own visible in the same place. Pressing the team harder treats it as the problem when the contradiction is the leader's.
• Experimentation. A leader who wants teams to experiment can treat some of their own choices as trials: state the expected result, try it in a limited way, and report openly what was learned. Announcements and training leave the leader's own behaviour unchanged, and any gate in front of experiments keeps the old control.
• Repairing a say-do gap. When a leader's reaction has made experimenting feel unsafe, the repair is also visible behaviour: owning the reaction openly and valuing what the failed experiment taught. Words alone do not close a gap that an action opened.

When a team or someone around it slips into an anti-pattern, the agile practitioner makes the cost visible and coaches the underlying principle. Left alone, an anti-pattern settles in; ruled out by decree, it is replaced by compliance without understanding; and a workaround built around it makes it permanent.

The audience matters. When the person showing the anti-pattern sits outside the team and their support matters to the adoption, coach them one-to-one, linking self-organization to what they want to achieve. A public challenge can cost the relationship, and escalation is a later step for when coaching has failed.

Kaizen is the lean practice of continuous improvement through many small, frequent changes that are tried, reviewed and repeated, rather than a single large redesign. After a retrospective produces a long list of problems, a kaizen approach picks one or two small changes, tries them for an iteration, checks the effect and then chooses the next.

Big-bang approaches — a large redesign led from outside the team or a process copied wholesale — freeze improvement until the new process is ready and impose change the team does not own. Small changes start now and stick because the team chose them.

Improvement is owned by the team and can happen at any time. The retrospective is a regular checkpoint, not a gate:

• When someone spots a low-risk way to work better partway through an iteration, and it does not put the iteration goal at risk, they are free to try it once teammates agree, and then tell the team what happened. How the team works is the team's decision.
• An improvement board the team can add to at any time keeps ideas from being forgotten between retrospectives.
• An intraspective is a short reflection held during an iteration when a problem surfaces, instead of waiting for the next retrospective.

Moving ownership of improvement outside the team, or reflecting less often, works against kaizen.

Continuous improvement only happens when it has visible, planned capacity agreed with the product owner. If every iteration is filled with feature work, retrospective actions are never done, and the team soon decides retrospectives are pointless. Hoping for spare time, or batching improvement into rare dedicated blocks, makes it neither reliable nor continuous — and work done beyond normal hours breaks sustainable pace.

• Plan improvement like any other work. Put the most valuable improvement action into the next iteration's plan and capacity.
• Make the value visible to the product owner. The product owner decides trade-offs against features. When a recurring friction quietly costs capacity every iteration, quantifying that cost turns the improvement into a value trade-off the product owner can weigh. Hiding the work, or going over the product owner's head, undermines the role.
• Protect the agreement. When reserved capacity keeps getting crowded out, bring the evidence of what slipped back to the product owner and renegotiate its protection together.
• Work with governance, not around it. Where an organization requires approval for process changes, the practitioner seeks advance permission for a class of small, reversible, team-level trials, with governance kept informed, so each one does not wait for its own approval. Stalling every change and bypassing the controls both fail the organization.

Keep improving when things go well

A stable, high-performing team is at risk of complacency. If its retrospectives feel empty, change the format or angle of the retrospective rather than dropping it or holding it less often. If the message from above is to leave a working process alone, agree an ambitious improvement aim together with the team — a flow measure is a common choice — and pursue it in small steps that protect delivery. A target set for the team rather than with it removes ownership, and velocity is never a basis for comparing teams.

Recognition promotes the agile mindset when it rewards the behaviours that express agile values, and it undermines the mindset when it rewards individual output, hours or heroics. What gets recognized gets repeated, so the practitioner chooses carefully what to notice.

Specific, timely and from peers

Effective recognition names the specific behaviour and its effect and comes soon after it happens. It need not come only from a manager: peer-to-peer appreciation that anyone on the team can give makes recognition frequent and spreads it widely. Recognition saved for formal cycles arrives too late to reinforce anything. When peer recognition becomes vague or uneven, the practitioner improves it by example — thanks that names the behaviour and its effect, and that notices quieter contributors — because compulsion or competition would undermine it.

Don't reward heroics

Praising overtime spreads overtime. When a "hero" works through nights or a weekend, others copy it, quality falls and sustainable pace is lost. The better response acknowledges the effort, credits the team, and turns attention to the cause that made a rescue necessary so it gets fixed. When praise for overtime is already changing behaviour, the practitioner makes its cost (for example rising defects) visible to the team and the person giving the praise, and coaches sustainable pace.

Celebrating milestones and wins with the team and stakeholders reinforces agile behaviour and sustains motivation; organizational incentives must point the same way, or they cancel out everything the practitioner does inside the team.

Celebrate promptly, and celebrate learning

• When a team reaches a real milestone, take time with the team and stakeholders to celebrate it while it is fresh. Celebration that is delayed, or narrowed to one person, loses most of its effect.
• In an agile mindset, a fast negative result is a win: an experiment that disproves an assumption early saves the effort of building on it. Celebrating that learning with the whole team keeps experiments happening; treating it as a failure discourages the next one.

Align organizational incentives

Formal incentives outweigh informal praise. Individual rankings and rewards for personal output push people to work alone and pick easy items, even when the practitioner recognizes collaboration in every meeting. Because the reward system sits outside the team, the practitioner influences its owners — HR and managers — towards assessment that supports teamwork:

• make shared team results part of how each individual is assessed;
• bring colleagues' structured input into the review process.

Changes that keep assessment individual and competitive under agile labels do not resolve the conflict.

While the system is being changed, help the team protect its own behaviour through self-organization — for instance a team agreement to concentrate together on the most valuable work before starting more — rather than by adding control.