ACP Corporate cheat sheet

Agile values (from the Manifesto for Agile Software Development): individuals and interactions over processes and tools; working product over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The right-hand items still have value - the left items are weighted more heavily.

The twelve Agile principles include: satisfy the customer through early and continuous delivery of valuable work; welcome changing requirements even late in development; deliver working results frequently (weeks rather than months); business people and developers work together daily; build projects around motivated individuals; face-to-face conversation is the most efficient way to convey information; working results are the primary measure of progress; promote sustainable pace; continuous attention to technical excellence; simplicity (maximising the amount of work not done); self-organising teams; regular reflection and tuning of behaviour.

Shu-Ha-Ri describes skill acquisition in three stages: Shu (follow the rule - imitate the form), Ha (break the rule - understand why it works and adapt), Ri (be the rule - transcend the form and innovate). Useful for judging how much process prescription a team needs.

The ''Agile onion'' layers, from the outside in: tools, practices, principles, values, mindset. Changing tools without shifting mindset produces cargo-cult agility.

A command-and-control culture measures activity (hours, utilisation, lines of code); an agile culture measures outcomes (working software, customer behaviour change, cycle time, value delivered).

Theory X (people avoid work and need supervision) versus Theory Y (people are intrinsically motivated and seek responsibility). Agile team design assumes Theory Y; incentives built on Theory X assumptions (individual utilisation targets, ranking) undermine self-organisation.

Psychological safety (Edmondson) is a shared belief that the team is safe for interpersonal risk-taking. It is a precondition for the retrospective honesty and experimentation that continuous improvement depends on.

Cultural change levers: leader behaviour modelling, changing what is measured and rewarded, changing physical and virtual workspace, and changing hiring and onboarding. Changing the org chart alone rarely shifts culture.

MoSCoW categories: Must have (non-negotiable for this delivery), Should have (important but a workaround exists), Could have (nice to have, taken only if capacity allows), Won't have this time (explicitly out of scope for this increment). Must-haves should not exceed roughly 60% of effort to protect contingency.

Weighted Shortest Job First (WSJF) = Cost of Delay / Job Duration (or Job Size). Cost of Delay is often decomposed into user/business value + time criticality + risk reduction or opportunity enablement. Highest WSJF is scheduled first.

Kano model classifies features as Must-be (basic), Performance (more is better, linear), Attractive (delighters), Indifferent, and Reverse. Must-be and Attractive features are not linear in satisfaction; only Performance features reward ''more''.

Value stream mapping distinguishes process time from lead time; flow efficiency = value-added time / total lead time. Typical knowledge-work flow efficiency is well under 25%, so most improvement lies in wait time, not work time.

Prioritisation is not the same as sequencing: dependencies, risk, and learning value can reorder work even when WSJF ranks one item higher.

Story splitting patterns for value slicing: workflow steps, business rule variations, data entry variations, major effort (spike first), simple/complex, defer performance, and operations (CRUD).

Cost of Delay is expressed as money per unit time. A feature worth $50,000 per month of earlier delivery with a 2-month duration has WSJF = 25,000 per month of duration.

Minimum Marketable Feature (MMF) is the smallest slice that delivers value a customer would pay for or choose. Minimum Viable Product (MVP) is the smallest thing that produces validated learning about the business hypothesis - MVP is about learning, MMF about revenue.

Power/Interest grid quadrants and strategies: High power + high interest = manage closely; high power + low interest = keep satisfied; low power + high interest = keep informed; low power + low interest = monitor.

Stakeholder salience model (Mitchell, Agle, Wood) ranks stakeholders by power, legitimacy, and urgency. Stakeholders holding all three are definitive; those with two are expectant; those with one are latent.

Communication channel count for n people = n(n-1)/2. A 10-person team has 45 channels; adding one person adds 10 channels. This is the mathematical case for small teams.

Information radiators (burndown, burnup, Kanban board, cumulative flow diagram) push information without a meeting; they reduce the need for status reporting.

The ''show me'' principle: demonstrate working product rather than report on it. A sprint review is a working session with stakeholders, not a status presentation.

Feedback loops ordered by speed: pair programming (seconds), continuous integration (minutes), unit tests (minutes), daily scrum (1 day), sprint review (1-4 weeks), release retrospective (longer).

Communication planning inputs: stakeholder register, organisational process assets, and the delivery cadence. Outputs include who needs what information, in what format, at what frequency, and via which channel.

Escalation path should be defined before it is needed: team -> product owner -> delivery lead -> steering/governance board, with agreed thresholds (e.g., impediment unresolved after 2 days escalates).

Tuckman stages: Forming (polite, dependent), Storming (conflict, jockeying), Norming (agreements, cohesion), Performing (autonomous, high output), Adjourning (disbanding). Conflict in Storming is normal, not a failure.

Team size guidance: 3-9 members for a Scrum team; generally 5-9 for effective knowledge work. Each added member increases communication channels quadratically.

Facilitation arc for a workshop: clarify purpose and product, set ground rules, diverge (generate), converge (decide), confirm actions with owners and dates, close.

Liberating Structures and similar formats solve specific problems: 1-2-4-All for inclusive idea generation, Dot Voting for fast convergence, Fishbowl for contested topics, Troika Consulting for peer advice.

Retrospective structure (five steps): set the stage, gather data, generate insights, decide what to do, close. A retrospective without at least one owned action item is a meeting, not an improvement cycle.

Conflict resolution modes (Thomas-Kilmann): competing, collaborating, compromising, avoiding, accommodating. Collaborating is preferred for important issues with time available; avoiding is legitimate for trivial issues.

Team performance indicators that resist gaming: cycle time distribution, escaped defect rate, deployment frequency, and change failure rate. Velocity is a planning aid for one team only, never a cross-team comparison metric.

Servant-leadership behaviours: remove impediments, shield from interruption, coach rather than direct, make the team''s work visible, and let the team own its process.

Story points are a relative, unitless measure combining effort, complexity, and uncertainty. They are valid within a team and across time for that team; they are not convertible to hours across teams.

Velocity = story points completed per sprint, averaged over the last 3-5 sprints (a trailing average, not a target). Expected sprints for a backlog of N points = N / velocity.

Planning poker: each estimator privately selects a card, all reveal simultaneously, extremes explain their reasoning, then re-vote. Simultaneous reveal prevents anchoring.

The cone of uncertainty: estimates at project inception can vary by a factor of about 4x in either direction; the range narrows as work progresses and unknowns are retired.

Estimation scales: Fibonacci (1,2,3,5,8,13,21) reflects growing uncertainty at larger sizes; powers of two (1,2,4,8,16) is an alternative. Anything above ~13 points should be split.

Release planning inputs: velocity range, backlog order, dependencies, and fixed dates. Output is a probabilistic forecast (e.g., ''85% confidence of delivering scope X by date Y''), not a commitment.

Monte Carlo forecasting uses historical throughput samples to simulate completion dates; it requires no story-point estimation and works well with Kanban flow data.

Rolling-wave planning: detailed plans for the near term, coarse plans for the horizon. Sprint planning covers the sprint; release planning covers the next few months; roadmap covers quarters.

Cumulative Flow Diagram (CFD) diagnostics: widening vertical bands = work in progress growing faster than completion; a flat top band = intake stopped; a flat bottom band = delivery blocked.

Little''s Law: average lead time = average work in progress / average throughput. To halve lead time, halve WIP or double throughput.

Cycle time versus lead time: cycle time starts when work begins on an item; lead time starts when the item enters the system (including queue time). Customers experience lead time.

Control charts plot cycle time per item with mean and control limits (commonly ±3 sigma). Points outside the limits, or non-random patterns (runs, trends), signal special-cause variation worth investigating.

Root cause tools: 5 Whys (iterate ''why'' until the process cause emerges), Ishikawa/fishbone (categories: people, process, tools, environment, measurement, materials), and Pareto analysis (roughly 80% of effects from 20% of causes).

Waste in knowledge work (the eight Lean wastes adapted): partially done work, extra features, relearning, handoffs, task switching, delays, defects, and unused talent.

Definition of Done is a checklist that makes ''complete'' objective and prevents the accumulation of undeclared technical debt. It applies to every increment, not just releases.

Improvement cadence: retrospective actions should be few (1-3), owned, and time-boxed; track them on the same board as delivery work so they are visible and completed.

Agile governance shifts from stage gates to fitness functions: automated, continuously evaluated checks (test coverage thresholds, security scans, compliance rules) that keep the product inside acceptable bounds.

Risk exposure = probability × impact. Risk response options: avoid, mitigate, transfer (insurance, contract terms), accept, and exploit (for positive risks/opportunities).

Risk-adjusted backlog: high-value, high-risk items are pulled forward so that uncertainty is retired early; this is the same logic as WSJF''s risk-reduction component.

Regulated environments (financial services, healthcare, aerospace) typically require traceability from requirement to test to evidence. Agile delivery satisfies this through automated linking in the backlog tool and evidence captured at each increment, not through a separate documentation phase.

Separation of duties and audit independence can be preserved with agile teams by keeping the audit function outside the delivery team while making delivery data continuously available to it.

Contracts: fixed-price/fixed-scope transfers risk to the supplier and tends to suppress change; time-and-materials shifts risk to the buyer; incremental delivery with a capped budget and prioritised backlog shares risk and allows early termination on value.

Governance metrics that do not distort behaviour: lead time, change failure rate, escaped defects, and compliance evidence freshness. Metrics tied to individual output invite gaming.

Portfolio governance: fund persistent teams and value streams rather than projects; use quarterly review cycles to rebalance investment based on measured outcomes rather than plan conformance.