Nos précédents articles avaient pour objectif de rappeler et présenter sous une nouvelle forme ce qu’est l’Agile. Vous pensez que l’agile est la solution aux problématiques de votre entreprise ou de votre projet ? Vous avez compris que l’agile n’est pas une fin en soi mais uniquement une façon de voir les chose ? Alors se pose alors la question de comment faire concrètement ! Comment travailler en agile ? Quel cadre de travail (framework agile) appliquer ?
Dans un premier temps vous devriez réfléchir à votre stratégie. Pensez à faire appel à un coach agile pour vous aider dans la démarche. Lancer un changement de la mauvaise manière peut avoir des conséquences désastreuses. En cas d’échec, vous dégoutterez vos équipes du changement, vous les rendrez plus méfiants et de moins bonne volonté face à vos démarches futures. Internet grouille d’avis de personnes qui détestent l’agile après des expériences similaires.
En attendant de discuter directement avec un coach (n’hésitez pas à nous contacter 😉), voici un panorama des principaux cadres de travail agiles.
Ces cadres de travail ou frameworks agile sont des modèles organisationnels qui permettent de respecter le manifeste agile. Il existe des frameworks pour s’organiser en équipe et d’autres pour organiser l’ensemble de l’entreprise.
Au niveau d’une équipe
Le plus répandu : SCRUM
SCRUM est un framework agile assez simple à aborder. Il permet à des équipes de 5 à 9 personnes de s’organiser pour livrer régulièrement de la valeur à leurs clients. Quasiment tous les frameworks à l’échelle (échelle de l’entreprise) s’inspirent de scrum et utilisent le vocabulaire scrum. C’est un bon point de départ dans votre voyage agile. Etant donné que c’est le plus connu, je vous propose un glossaire des différents termes que vous rencontrerez à propos de scrum.
Piliers de SCRUM :
- Transparence : envers son équipe, son client. La base dans agile et scrum c’est la communication transparente
- Inspection : inspecter ses livrables, son comportement, ses processus, ses actions afin de s’améliorer.
- Adaptation : s’adapter au contexte, aux changement de besoin, de marché de comportement des utilisateurs,…
Valeurs de SCRUM :
- Engagement : s’engager à réaliser des tâches, des fonctionnalités, auprès de son équipe et ses clients.
- Courage : de dire non, de tester des nouvelles pratiques, approches, courage de s’engager.
- Focus : focalisation sur ce que l’on réalise. Ne plus se disperser en activités inutiles. Ne pas démarrer plusieurs tâches en même temps au risque de ne rien finir.
- Ouverture : ouverture d’esprit, ouverture envers l’autre, ouverture pour exprimer ses difficultés, erreurs, et montrer son travail…
- Respect : respect de chacun, de l’autre, de ses engagements
Rôles :
- Product owner : responsable du produit, le product owner est celui qui connait le mieux le client et ses attentes. Il communique cela à l’équipe sous forme d’un backlog priorisé. Le product owner décide du quoi et quand.
- Scrum master : animateur, facilitateur de l’équipe. on parle également de servant-leader. Il facilite ce qu’il faut à l’équipe afin qu’ils puissent réaliser leur travail sans encombres. Le scrum master va également les aider à grandir et s’améliorer en tant que professionnels ainsi qu’en tant qu’équipe. Il facilitera également les fonctionnements entre l’équipe et son écosystème.
- Dev Team : équipe d’artisans (artistes). Ce sont eux qui connaissent le métier, comment réaliser les attentes du client. Ce sont eux qui décident du comment.
Instances :
- Sprint planning : réunion durant laquelle l’équipe décide de ce qu’elle peut ou pas faire pendant le sprint. A l’issue de cette réunion il y a un périmètre engagé.
- Daily stand up meeting : réunion quotidienne de l’équipe qui permet d’inspecter l’avancement. Se fait généralement debout pour qu’elle ne dure pas longtemps (15 minutes).
- Sprint review : réunion durant laquelle l’équipe scrum montre son travail aux clients et tous ceux qui sont intéressés.
- Sprint retrospective : réunion durant laquelle l’équipe reflète sur son sprint afin d’améliorer ses pratiques.
Artefacts :
- Product backlog : liste priorisée des besoins client.
- Sprint backlog : périmètre engagé par l’équipe dans le sprint. Le sprint backlog est sous forme de user stories priorisées et découpées en tâches.
- Product increment : produit global livré par l’équipe à la fin d’un sprint. Les product incrément sont des produits finis qui peuvent être mis à disposition des utilisateurs finaux.
En complément j’ajouterais :
- User stories : histoire utilisateur rédigée dans un formalisme particulier.
- Story points : unité d’évaluation des user stories. Il représente généralement la quantité de travail, la complexité, et la part d’inconnu.
- Définition of done : liste des critères essentiels pour qu’une user story soit considérée comme terminée.
- Sprint : période de temps : incrément.
KANBAN
KANBAN, qui nous vient du Lean, est un framework agile où l’équipe crée et fait vivre une liste priorisée de ses tâches. Voilà le workflow de ce framework :
- Les tâches sont au début au statut “A faire” ou “TO DO”
- Chaque membre ou sous-groupe de membres prend une tâche à faire et met à jour son statut à “EN COURS” ou “DOING”
- Lorsque la tâche est terminée il(s) mettent à jour le statut à “FINI” ou “DONE” et commencent une nouvelle tâche.
Habituellement, ce processus est géré par l’équipe de façon visuelle sur un tableau physique ou numérisé (Trello est un outil gratuit parfait pour commencer).
Afin de s’assurer que le travail avance bien il faut être vigilant sur 2 points :
- Limiter le travail en cours ou limiter le WIP (Work In Progress) : parce que plus l’équipe commence d’activités en parallèle moins elle en finit.
- Faire attention à bien finir les activités. Encore une fois, une activité à vérifier n’est pas une activité terminée. Et si tout est presque fini en fait rien n’est fini et on n’a rien à montrer à nos utilisateurs.
- Travailler en flux tiré : on n’affecte pas du travail aux gens mais ce sont eux qui s’engagent de façon auto-organisée.
Vu qu’une image vaut mille mots je vous propose de découvrir l’illustration en vidéo :
ScrumBan
C’est un mix entre scrum et kanban. Généralement adopté par les équipes qui ont adopté scrum et qui souhaitent y apporter des modifications.
En Scrumban les équipes conservent les rôles et la notion de rétrospective à réaliser régulièrement.
Cependant, si l’équipe ne sait pas anticiper l’intégralité de son backlog de sprint, elle fera un sprint planning partiel ou plus fréquemment.
Certaines équipes peuvent estimer communiquer beaucoup durant la journée et changer la fréquence des stand up meeting à tous les 2 ou 3 jours …
En fait chaque équipe apportera ses ajustements. Du moment que cela convient à son mode de travail et reste dans le respect de l’agile.
Au niveau de l’entreprise
Le plus répandu : SAFe
Le framework SAFe c’est l’équilibre entre agile et les structures pyramidales. Il permet une transition maitrisée pour les grandes entreprises. On ne déploie pas SAFe sur des programmes de moins de 50 personnes. J’ai personnellement coaché (avec d’autres collègues) un programme de 400+ personnes.
SAFe permet aux managements et directions de continuer à avoir de la visibilité sur l’ensemble de ce qui se passe. En parallèle les équipes gagnent en autonomie et en pouvoir de décision. Les cadrages et planifications sont réalisées par les personnes qui réalisent améliorant la fiabilité des prédictions qui étaient très aléatoires en cycle en V pour des aussi gros programmes. SAFe permet également d’anticiper et suivre les dépendances et donc les éventuels retard.
Je ne tenterai pas de faire un résumé de SAFe en 5 lignes. Si vous êtes intéressés, nous proposons un certain nombre de formations certifiantes SAFe chez CreaSila pour tous les rôles. N’hésitez pas à nous contacter.
Spotify
Spotify a une approche différente de SAFe. Il considère chaque équipe (5 à 10 personnes) comme un entreprise. Chaque quad (équipe) a toute autonomie sur sa partie : innovation, déploiement,… Cela est notamment rendu possible par l’aspect modulaire de leurs produits et le nombre très limité de dépendances entre les modules.
En parallèle aux squads, Spotify crée des groupes (guilds, chapters et des tribes) garantes de cohérence de la vision, de l’excellence, de la cohérence de leurs produits.
Le mot clé dans Spotify est l’amélioration continue. Les coach qui ont accompagné la création de cette organisation témoignent que jusqu’à aujourd’hui Spotify n’arrive pas à applique le framework Spotify théorique parfait. En même temps on est tous d’accord que la perfection n’existe pas.
Nexus
Ce framework agile est une extension naturelle de Scrum. Nexus promet une livraison de valeur accrue plus rapidement.
Les différentes équipes travaillent en scrum et se retrouvent au travers de représentants dans des sprint planning, daily stand up et rétrospective communs en plus des instances de chaque équipe. La revue de sprint est quand elle faite en commun permettant ainsi de présenter l’intégralité du produit au client.
LeSS
Très similaire à Nexus, LeSS est également basé sur scrum. En dehors de différences de terminologies, et l’addition de pratiques qui nécessitent un article dédié, LeSS promet une capacité d’adaptation accrue à moindre coût. Ce qui est un atout considérable dans un monde qui évolue très vite et dans les secteurs très concurrentiels.
Créer son propre cadre de travail
Renault, Thales, Spotify l’ont fait alors pourquoi pas vous ? Avec l’accompagnement de coachs agiles, vous pouvez également développer votre propre framework.
Cela passe par plusieurs étapes indispensables :
- Formez tout le monde sur les valeurs et principes agiles.
- Définissez une fréquence à laquelle vous souhaitez vous retrouver pour vous poser les bonnes questions et chercher des axes d’amélioration. La fréquence idéale est située entre toutes les 2 semaines et tous les 2 mois.
- Lancez des invitations pour des réunions (1 pour chaque équipe que ce soit une équipe de réalisation, de management ou de direction)
- Recueillez pour l’occasion un état des lieux de votre respect des valeurs et principes agiles
- Durant la réunion :
- Partagez l’état d’avancement des actions de la précédente itération
- Débriefez ce qui s’est bien ou moins bien passé durant la période (rétrospective)
- Choisissez 1 à 3 points sur lesquels vous souhaitez vous améliorer
- Définissez des actions SMART pour améliorer ces axes d’amélioration
- Intégrer ces actions dans les activités que vous réaliserez sur la période
En conclusion
Tous les frameworks qui permettent de s’organiser dans le respect des principes et valeurs agiles sont théoriques. Il sont super efficaces sur le papier mais demandent une rigueur et une connaissance parfaite pour les appliquer. En fait, toutes les entreprises qui s’organisent en agile finissent pas créer leur propre framework dérivé d’un de ceux décrits précédement.
Pourquoi ?
Parce que la transformation agile, pour fonctionner, doit ancrer les nouvelles valeurs et les nouveaux principes dans l’ADN et la culture de l’entreprise. Aucune entreprise ne travaille de la même manière, aucune équipe non plus. La vraie réussite de la transformation est d’ailleurs marquée par cette appropriation du framework.