Quelle est la meilleure méthode pour les projets digitaux ?
Ça serait pratique si la réponse était universelle, mais évidemment elle ne l’est pas. Il existe probablement une infinité de méthodes mais aujourd’hui 3 d’entre elles sont un peu plus visibles que les autres. Il s’agit de Kanban, Scrum et SAFe. Vous avez également pu entendre parler de Spotify (issue du service de streaming du même nom) ou de Scrumban (savant mélange de Scrum et Kanban) mais nous ne rentrerons pas ici dans le détail des spécificités de ces méthodes.
Avant de rentrer plus en détail dans les spécificités de ces frameworks ou méthodes, rappelons tout de même qu’il n’y a absolument pas besoin d’eux pour être Agile. En particulier sur ce point, je me permets de vous renvoyer vers le Manifeste Agile disponible en ligne et dont voici l’extrait des 4 valeurs Agile.
Les individus et leurs interactions plus que les processus et les outils
https://agilemanifesto.org/iso/fr/manifesto.html
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
Alors avant d’aller plus loin, posez vous bien la question de savoir si vous avez déjà un embryon de méthode en place. Et si cet embryon méthodologique respecte ces 4 valeurs, pourquoi ne pas chercher à l’améliorer plutôt qu’en choisir un sur étagère ? En effet, il sera probablement plus adapté à votre culture d’entreprise et fera probablement la fierté des collaborateurs qui participeront à son développement.
Quels sont les points communs et les différences entre Kanban, Scrum et SAFe ?
Points communs
- Management visuel disponible
- Respect des valeurs Agile possible
- Ajustement progressif de la cible
- Amélioration continue intégrée
- Équipe de développement au cœur de la méthode
- Échanges directs entre business et dev
- Livraisons régulières de la solution
- Priorité au client via la solution
Différences
| Kanban | Scrum | SAFe | |
|---|---|---|---|
| Périmètre | 1 Equipe | 1 Equipe | Organisation complète |
| Poids du Framework | Léger | Moyen | Lourd |
| Rythme | Continu | Sprints de 2 semaines (moyenne) | Sprints de 2 semaines et Incrément tous les 5 Sprints (moyenne) |
| Rôles en dehors de l’équipe de dev | Aucun | Scrum Master + Product Owner | Scrum Master + Product Owner + RTE + Product Manager + … |
| Point fort | Capacité d’adaptation | Rassurant sur l’engagement de l’équipe | Rassurant sur l’engagement de toute l’organisation |
| Point faible | Fait peur aux dirigeants car engagement non formalisé | Rigidité + Déresponsabilisation des acteurs | Temps consommé par la méthode à tous les niveaux (y compris business) |
Mais c’est quoi la conclusion du coup ?
Comme vous l’avez compris, on ne tranchera pas en faveur d’une méthodologie/d’un framework car cela n’aurait aucun sens sans contexte. Une chose est sûre cependant, ne perdez jamais de vue que les frameworks sont là pour vous faire gagner du temps, alors si vous passez votre temps à retravailler votre framework… vous avez peut-être un soucis !
Heureusement, nous sommes là pour vous aider. En particulier, 2 solutions possibles :