Agile Manifesto: 4 values and 12 principles for the PMP
The Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The items on the right still have value; the items on the left are valued more.
The four values
Each value is a preference, not a ban. A team that revises its plan when it learns users need a different feature, while still keeping a plan to guide its work, is showing responding to change over following a plan. It has not dropped planning.
PMP questions often describe behavior and ask which value or principle it reflects. Match the behavior to the left-hand item it favors.
The twelve principles
Customer and delivery: satisfy the customer through early and continuous delivery of valuable software; welcome changing requirements, even late; deliver working software frequently, from a couple of weeks to a couple of months, preferring the shorter timescale; working software is the primary measure of progress.
People: business people and developers must work together daily throughout the project; build projects around motivated individuals, give them the environment and support they need, and trust them to get the job done; face-to-face conversation is the most efficient and effective way to convey information to and within a development team.
Way of working: sustainable development, where sponsors, developers and users can keep a constant pace indefinitely; continuous attention to technical excellence and good design; simplicity, the art of maximizing the amount of work not done; the best architectures, requirements and designs emerge from self-organizing teams; and at regular intervals the team reflects on how to become more effective and adjusts its behavior.
Applying them to scenarios
A team in one office settling design questions in email threads that take days should talk them through face to face. A project manager who gives a capable team the support it asks for and then trusts it without close supervision is building the project around motivated individuals. A sponsor asking what proves progress should hear: working software, not hours spent or percent of plan complete.
Where the exam catches people
Believing the Manifesto rejects plans, documentation, contracts or tools: it says there is value in those items, but values the others more.
Believing story points or percent complete is the main progress measure: the principles name working software.
Believing a wiki or response-time rule is the fix for slow communication in a co-located team: the principle points to face-to-face conversation.
Believing designs should be fixed before an agile team starts: the principles say the best designs emerge from self-organizing teams.