Praktiker (till exempel review-rutiner, teststrategier, demo-rytm) förändras och trimmas över tid. Värderingar och principer gör inte det. Eller om de gör det är det en stor händelse, värd att uppmärksamma. Att fånga dem explicit ger ett gemensamt rotsystem som senare praktiker kan växa fram ur. Hamnar en praktik och en värdering i konflikt är det värderingen som vinner. Blir det tvärtom är det något som är fel.
Här beskriver du de värderingar och principer som är aktiva och överenskomna för det här initiativet. För stora initiativ kan det ibland behövas beskrivningar per team, men det är inte det vanligaste.
Precis som intentionsbeskrivningen i Strategy Briefing guidar vardagens alla mikrobeslut, så gör värderingar och principer det också.
Praktiker beskrivs typiskt på fliken Team, men inget hindrar att relevant information läggs in här också, om det fyller en funktion.
Som inspiration, här är det Kent Beck formulerade om värderingar och principer i Extreme Programming Explained:
Values
Communication: håll alla informerade. Problem går oftast att spåra till att någon inte visste något de borde ha fått veta.
Simplicity: gör det enklaste som kan tänkas fungera. Ta bort det som inte behövs.
Feedback: korta, täta återkopplingsslingor på varje nivå (test, build, demo, kund, pengar).
Courage: säg sanningen, kassera felaktig kod, gör om när det behövs.
Respect: respekt för arbetet, teamet och användarna. Grunden de övriga fyra värderingarna vilar på.
Principles
Humanity: mjukvara byggs av människor. Balansera personliga och kollektiva behov.
Economics: se till att det vi gör har affärsvärde. Skjut upp beslut till den tidpunkt då de faktiskt betyder något.
Mutual Benefit: varje förändring ska gagna alla inblandade, både nu och senare.
Self-Similarity: använd samma lösningsform i olika skalor.
Improvement: excellens är en strävan och en process. Leverera något bra, förbättra sedan.
Diversity: ta med olika perspektiv, kompetenser och åsikter till bordet.
Reflection: kombinera reflektion över arbetet med arbetet självt.
Flow: leverera en jämn ström av små värdesteg, snarare än stora batcher.
Opportunity: behandla problem som möjligheter att lära.
Redundancy: lös kritiska, svåra problem på flera olika sätt.
Failure: när du inte vet vad du ska göra, prova något. Misslyckande är information.
Quality: kvalitet är inte en styrvariabel. Offra inte kvalitet för hastighet, du kommer inte få den tillbaka senare.
Baby Steps: det minsta steg som kan tänkas fungera, taget nu.
Accepted Responsibility: ansvar följer med befogenhet. Tilldela det, påtvinga det inte.
Vidare läsning
Beck, K. Extreme Programming Explained: Embrace Change (2001)