# Agile, Scrum & Kanban en Pratique

> 5 leçons · ~2h · Agile — SFM Academy (successfor-me.ch).
>
> Résumé public leçon par leçon. Le contenu pédagogique complet (hors 1re leçon gratuite) est réservé aux abonnés.

Fiche du cours : https://successfor-me.ch/academy/cours/fiche/PROJ-02

## Leçon 1 — L'Agilité : une façon de penser avant d'être une méthode

**À retenir :**

- L'Agile naît du constat que le waterfall échoue quand le contexte change plus vite que le plan.
- Les 4 valeurs agiles : individus > processus, logiciel fonctionnel > documentation, collaboration > contrat, adaptation > plan.
- L'agilité n'est pas pour tous : elle excelle pour les projets incertains et innovants, le waterfall pour les périmètres stables.
- "Faire de l'agile" sans discipline = chaos. L'agilité requiert des rituels précis et des rôles clairs.

**Plan de la leçon :** Pourquoi les méthodes traditionnelles montrent leurs limites · Les 12 principes agiles en pratique · Agile vs Traditionnel : quand utiliser quoi

_Leçon en accès libre._

### Pourquoi les méthodes traditionnelles montrent leurs limites

Pendant des décennies, les projets étaient gérés en "cascade" (waterfall) : on planifie tout, puis on exécute, puis on livre. Simple en théorie. Désastreux en pratique pour tout ce qui évolue vite.

**Le problème du waterfall dans un monde qui change :**
Tu passes 3 mois à planifier un logiciel. 6 mois à le développer. 3 mois à tester. Puis tu le livres — et le client dit "ce n'est plus ce dont j'ai besoin, le marché a changé."

Ce scenario n'est pas fictif. C'est ce qui a motivé 17 praticiens du développement logiciel à rédiger le Manifeste Agile en 2001.

**Les 4 valeurs du Manifeste Agile :**
1. Les individus et leurs interactions > les processus et les outils
2. Un logiciel fonctionnel > une documentation exhaustive
3. La collaboration avec le client > la négociation contractuelle
4. L'adaptation au changement > le suivi d'un plan

L'agile ne dit pas que la planification ou la documentation sont mauvaises. Il dit qu'elles sont secondaires face à la livraison de valeur réelle et à l'adaptation.

### Les 12 principes agiles en pratique

Les 12 principes du Manifeste Agile semblent abstraits. Voici leur traduction concrète pour une PME ou une startup.

**Principes clés traduits en actions :**

*"Livrer fréquemment un logiciel fonctionnel"*
→ Livrer des versions partielle toutes les 2-4 semaines plutôt que tout après 6 mois. Le client peut utiliser et donner du feedback avant que tout soit fini.

*"Les changements tardifs sont les bienvenus"*
→ Construire une architecture flexible, ne pas résister aux changements de priorités. L'agilité est une force, pas une faiblesse.

*"Collaboration quotidienne entre gens de métier et développeurs"*
→ Le client n'est pas seulement là au début et à la fin. Il est impliqué en permanence, valide des prototypes, répond aux questions.

*"La meilleure architecture émerge d'équipes auto-organisées"*
→ Les équipes agiles décident elles-mêmes comment elles travaillent, pas le manager. Plus d'autonomie = plus de motivation et de performance.

*"À intervalles réguliers, l'équipe réfléchit à comment devenir plus efficace"*
→ Les rétrospectives ne sont pas optionnelles. Elles sont le moteur d'amélioration continue.

### Agile vs Traditionnel : quand utiliser quoi

L'agilité n'est pas la solution à tous les problèmes. Chaque approche a son domaine d'excellence.

**Quand l'approche traditionnelle (waterfall) est préférable :**
- Projets avec périmètre fixe et bien défini
- Construction physique (bâtiment, infrastructure) — impossible de "livrer en sprint"
- Projets fortement réglementés nécessitant une documentation exhaustive
- Faible tolérance au changement en cours de projet

**Quand l'approche agile est préférable :**
- Projets innovants où le résultat final est incertain
- Développement de produit digital (logiciel, app, site web)
- Marchés qui évoluent rapidement (le besoin client peut changer en 3 mois)
- Équipes petites et collaboratives
- Clients impliqués et disponibles pour feedback régulier

**L'approche hybride :**
Beaucoup d'organisations combinent les deux. Phase de planification traditionnelle (3-4 semaines) pour cadrer le projet, puis exécution agile par sprints. C'est souvent la solution la plus pragmatique pour les PME.

**Un piège courant :**
"Nous faisons de l'agile" signifie trop souvent "nous n'avons pas de processus définis". L'agilité requiert de la discipline — des rituels précis, des rôles clairs, des engagements tenus. Sans structure, c'est du chaos, pas de l'agile.

## Leçon 2 — Scrum en pratique : sprints, backlog et cérémonies

**À retenir :**

- Les 3 rôles Scrum : PO (priorise la valeur), Scrum Master (facilite et lève les obstacles), Équipe (s'auto-organise).
- Le Sprint = période fixe (2 semaines) avec un objectif clair — on ne prolonge pas, on ne change pas l'objectif en cours.
- La Definition of Done est critique : sans elle, "presque fini" devient la norme et le produit n'est jamais vraiment livré.
- 4 cérémonies : Planning (4h) → Daily (15min) → Review (2h) → Rétrospective (1.5h) — chacune a un rôle précis.

**Plan de la leçon :** Les 3 rôles Scrum : Scrum Master, Product Owner, équipe · Le Sprint : le cœur du rythme Scrum · Les 4 cérémonies Scrum : quand et comment

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/PROJ-02)._

## Leçon 3 — Kanban : le flux continu pour une équipe qui ne s'arrête jamais

**À retenir :**

- Kanban = visualiser le travail + limiter le WIP + gérer le flux continu — idéal pour les équipes support, marketing ou maintenance.
- La limite de WIP force à finir avant de commencer : "Stop starting, start finishing" — accélère la livraison globale.
- Les goulots d'étranglement apparaissent dans les colonnes qui s'accumulent — les résoudre améliore le flux de tout le système.
- Parcourir le tableau de droite à gauche en standup : finir les tâches existantes avant d'en commencer de nouvelles.

**Plan de la leçon :** Kanban vs Scrum : deux approches pour deux contextes · Construire et utiliser un tableau Kanban · Amélioration continue avec Kanban : le flux parfait

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/PROJ-02)._

## Leçon 4 — Estimer avec l'agilité : story points et vélocité d'équipe

**À retenir :**

- Estimer en heures est trompeur : variabilité individuelle, fausse précision, pression sociale. Les story points mesurent la complexité relative.
- Le Planning Poker prévient le biais d'ancrage : votes simultanés, suite de Fibonacci, débat sur les divergences.
- La vélocité (points/sprint) est le seul indicateur fiable pour prédire les délais — basé sur la performance réelle de l'équipe.
- Ne jamais utiliser la vélocité comme objectif managérial — cela crée l'inflation des story points ou des livraisons de mauvaise qualité.

**Plan de la leçon :** Pourquoi estimer en heures est une mauvaise idée en agile · Le Planning Poker : estimer ensemble et mieux · La vélocité : prédire avec les données réelles

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/PROJ-02)._

## Leçon 5 — Passer à l'échelle : Scrum de Scrums et équipes distribuées

**À retenir :**

- Le Scrum de Scrums coordonne 2-4 équipes avec un méta-standup bi-hebdomadaire de 30-45 min — léger et efficace.
- Pour une PME, pas besoin de SAFe ou LeSS — le Scrum de Scrums suffit pour synchroniser plusieurs équipes.
- Équipes distribuées : outils de visualisation partagés (Jira/Linear), daily asynchrone (Loom/Slack), meetings synchrones pour Sprint Planning/Review/Rétro.
- Règle "remote first" : si quelqu'un est en télétravail, tout le monde utilise la vidéo pour éviter la fracture bureau/remote.

**Plan de la leçon :** Les défis des équipes agiles à grande échelle · Le Scrum de Scrums : coordonner plusieurs équipes sans bureaucratie · Gérer des équipes agiles distribuées et en télétravail

_Contenu complet réservé aux abonnés — [suivre ce cours](https://successfor-me.ch/academy/cours/fiche/PROJ-02)._