Les 4 valeurs

Davantage l’interaction avec les personnes que les processus et les outils.

On arrête d'envoyer des mails de 20 pages pour savoir comment fonctionne le bouzin dans le cas où X=0 et Y=1
Les outils de bugs tracking sont des outils de suivi et PAS DES OUTILS DE COMMUNICATION
Cela veut aussi dire que l'on se fait confiance, que la mauvaise fois ou toutes les autres techniques n'aident pas l'avancement du projet
Inutile de garder votre messagerie ouverte : rien d'urgent ne va arriver, si c'est urgent quelqu'un viendra vous voir

Davantage un produit opérationnel qu’une documentation pléthorique.

Cela ne veut pas dire qu'il n'y a pas de doc !
Cela veut surtout dire qu'il faut des documentations simples qui présentent les règles de gestion visibles en un coup d'oeil
Cela veut aussi dire que le code est lisible simple et logique

Davantage la collaboration avec le client que la négociation de contrat.

C'est le client qui vous paie ;-)
On travaille en "bonne intelligence" : l'équipe cherche à fournir une application qui fonctionne et pas une application qui plante conformément aux spécifications

Davantage la réactivité face au changement que le suivi d'un plan.

On ne peut planifier que le contenu d'un Sprint : le contenu du sprint suivant sera planifié au sprint suivant !

Les 12 principes

Notre première priorité est de satisfaire le client en livrant tôt et régulièrement des logiciels utiles.

Les sprints sont "courts" : 2 à 4 semaines
A la fin d'un sprint, l'application est utilisable et présentable
Le Product Owner possède la dernière version de l'application et la présente à ces utilisateurs finaux
L'application est donc testée (techniquement et fonctionnellement)
On ne néglige pas la qualité

Le changement est accepté, même tardivement dans le développement. Les processus agiles exploitent le changement comme avantage compétitif pour le client.

Juste un bémol à destination des Products Owner : Changement ne veut pas dire que l'on casse tout et que l'on recommence depuis le début !

Livrer fréquemment une application fonctionnelle, toutes les deux semaines à deux mois, avec une tendance pour la période la plus courte.

Fonctionnelle = qui fonctionne sans bug
La meilleur preuve d'un reste à faire égale à 0 est la livraison de l'application

Les experts métier et les développeurs doivent collaborer quotidiennement au projet.

La collaboration se fait surtout dans les moments difficiles,
- quand le PO a du mal à alimenter le prochain Sprint, le Scrum Master (et l'équipe) peuvent présenter des évolutions (techniques ou fonctionnelles) à l'application
- quand le Scrum Master présente un retard le Product Owner prend acte et organise ces équipes en fonction.
Il est très facile de collaborer quand tout va bien, il est surtout intéressant de regarder ce qu'il se passe durant les périodes "chaudes" ;-)

Bâtissez le projet autour de personnes motivées. Donnez leur l'environnement et le soutien dont elles ont besoin, et croyez en leur capacité à faire le travail.

Plusieurs points
Les personnes non motivés ne sont pas intégrées dans l'équipe Scrum et "la mayonnaise" ne prend pas : AGISSEZ et/ou appuyez vous sur votre Coach Agile
L'environnement : technique mais aussi spacial, des machines "rapides", un openspace propre et calme (pas un hall de gare), des murs dégagés pour les radiateurs d'information. Travaillez aussi pour que votre équipe ne soit pas perturbée en permanence.
Croyez en leur capacité à faire le travail : faites confiance à votre équipe et constater les résultats. Les équipes agiles aiment leur projet et "se battent" pour qu'il réponde au besoin.

La méthode la plus efficace pour transmettre l'information est une conversation en face à face.

FACE à FACE ou tête à tête et PAS MAIL to MAIL ou Word to Word
Pour vous assurez que vous avez bien compris ce que l'on vous présente, représentez ce que l'on vient de vous dire et n'oubliez pas que la simplicité facilite la compréhension.

Un logiciel fonctionnel est la meilleure unité de mesure de la progression du projet.

Tous les indicateurs que vous pourrez présenter ne seront jamais aussi efficace que la livraison d'une application fonctionnelle pour prouver votre avancement.

Les processus agiles promeuvent un rythme de développement soutenable. Commanditaires, développeurs et utilisateurs devraient pouvoir maintenir le rythme indéfiniment.

Rythme soutenable, rythme durable = 40h par semaine
Inutile de se dire qu'en faisant travailler l'équipe 20% en plus (soit 48h) par semaine vous aurez 20% de productivité en plus, cela peut fonctionner la première semaine mais les suivantes vos équipes fatigues et vous obtenez une productivité inférieure à celle des 40h par semaine
Conclusion : ne faite pas de stratégie à court terme.

Une attention continue à l'excellence technique et à la qualité de la conception améliore l'agilité.

Pensez qu'un autre membre de l'équipe devra reprendre votre code un jour et qu'il est toujours agréable de lire du code de qualité, propre, commenté et cohérent.
L'un des pires scénarios est d'avoir un chiffrage d'une évolution multipliée par 2 car on reprend le code de "Brandon ou Brenda" !

La simplicité - l'art de maximiser la quantité de travail à ne pas faire - est essentielle.

Ce n'est pas parce que l'on ne modélise quelque chose de compliqué que l'on n'est pas intelligent ;-)
La difficulté est de simplifier tous les processus qui peuvent être complexes et de supprimer tout ce qui ne sert à rien

Les meilleures architectures, spécifications et conceptions sont issues d'équipes qui s'auto-organisent.

Chaque membre de l'équipe apporte sa vision sur ces 3 phases, l'équipe choisira la meilleur solution à chaque fois.

À intervalle régulier, l'équipe réfléchit aux moyens de devenir plus efficace, puis accorde et ajuste son comportement dans ce sens.

à la fin de chaque sprint par exemple !!!
Les questions à se poser avant de faire un rétrospective de Sprint :
Quels sont les difficultés que nous avons rencontré sur ce Sprint ?
Qu'est-ce que nous avons amélioré sur le sprint précédent ?
Comment être encore plus productif au prochain Sprint ?