EasyTech #8 - les bases de l'agile, ton mini-cours de 5 minutes chrono
Salut salut 😃
Très heureux de te retrouver en cette fin (ou début) de semaine.
Aujourd'hui on va aborder les bases de l'agile !
Pourquoi c'est fondamental, l'agile
De quoi on parle ?
Pour la faire simple, l'agile est une méthode pour développer des logiciels de qualité. Elle se base sur les 4 grands principes suivants (dit le Manifeste Agile) :
Les individus et les interactions > process et outils
Un logiciel qui fonctionne > documentation exhaustive
Collaboration avec le consommateur > négociation contractuelle
Répondre au changement > suivre le plan
Elle est apparue dans les années 1990 puis on a trouvé le terme agile dans les années 2000. Ce terme très catchy a beaucoup contribué au développement de la pratique.
Ça sert quand l'agile ?
Pour comprendre ça, il faut d'abord se remettre en tête le cycle de vie du produit :
💡Framing
= je définis mon plan d'action avant de me lancer
🥚 Discovery
= je trouve le bon problème auquel répondre
🐣 Delivery
= je construis le produit pour résoudre ce problème
🐥 Growth
= je distribue ce produit au plus grand nombre
L'agile intervient dans la phase de delivery. C'est un moment important et charnière !
On passe d'une idée, qu'on a creusé et approfondi
... mais qui ne reste qu'une idée en phase de discovery
... à des lignes de code, un logiciel "en chair et en os".
C'est aussi à cette phase qu'on commence à commercialiser et à gagner de l'argent, avant d'enclencher sur la phase de Growth où on va démultiplier nos efforts en la matière.
Bref un moment important, à ne pas négliger.
Les activités clés de l'agile
Imaginons qu'on vient de démarrer notre phase de Delivery. On a passé un certain temps en phase de Framing et Discovery, à préparer ce moment. On se jette dans le bain.
Activité 1 : prioriser
On a une idée du logiciel qu'on veut développer. Mais on ne va pas pouvoir tout faire d'un coup. Il faut qu'on choisisse les éléments qu'on va développer d'abord. Puis ceux qui peuvent attendre un peu plus. On doit prioriser.
Pourquoi est-ce important de prioriser ?
Parce qu'on veut impliquer nos utilisateurs dans ce processus de construction. Pour ça, il faut les mettre dans la boucle petit à petit. On ne peut pas juste finaliser le logiciel et leur dire "c'est bon, tu en penses quoi ?". L'idée c'est d'avancer petit à petit, et de leur montrer à chaque fois ces petits bouts développés.
On va donc discuter tous ensemble, en équipe, pour choisir les éléments les plus importants, et ceux qui sont le moins. Ça peut prendre du temps mais c'est nécessaire de prendre du temps pour le faire.
Le backlog c'est quoi ?
En agile, on range les morceaux de fonctionnalités priorisés les uns par rapport aux autres dans une liste. C'est ça, le backlog. Pour avancer, on prend le premier item, c'est le plus prioritaire. Et ainsi de suite.
💡
Et une User Story alors ? Ça représente un morceau de fonctionnalité que tu veux développer. En général, ça représente un travail de quelques jours pour un développeur. Idéalement 2-3 jours max. On les rédige souvent de la manière suivante "en tant que user, je veux..." (d'où le terme User Story). Ça sécurise que les fonctionnalités développées le sont en ayant mis l'utilisateur au centre.
Quelques points d'attention sur la priorisation
Attention :
1️⃣ la priorisation des éléments n'est pas gravée dans le marbre ;
2️⃣ le backlog doit rester petit, pas trop d'éléments (idéalement <5 / 10).
Sinon c'est plus difficile d'ajuster en fonction des demandes des utilisateurs.
Activité 2 : planifier
Maintenant qu'on a priorisé, il faut décider de quand on développe concrètement ces fonctionnalités qui sont en haut du backlog ! Il faut planifier.
La priorisation ne suffit pas ?
Non elle ne suffit pas. On ne peut pas juste prendre le backlog et planifier de manière "mécanique" sur un planning. Pour deux raisons :
Premièrement, car la priorisation reste une activité assez théorique. Quand on planifie, l'équipe va se demander concrètement ce qu'elle est en mesure de délivrer. Par exemple, elle va réaliser des premières estimations, se demander combien de temps elle a besoin pour finaliser une fonctionnalité... voire également analyser de manière plus approfondie une fonctionnalité ce qui peut amener à reconsidérer son niveau de priorisation.
Deuxièmement, certains éléments bien que prioritaires peuvent ne pas être lancés tout de suite. Parfois, on a besoin d'une autre brique pour réaliser cet élément. On parle de "dépendance" dans ces cas là. Par exemple, s'il faut attendre la mise à jour d'une API externe avant de pouvoir développer notre fonctionnalité.
La priorisation répond à la question "quoi".
La planification répond à la question "comment".
Concrètement on fait comment ?
Comme on l'a vu, en agile on développe par itérations successives.
💡
Une itération, c'est une période de temps fixée, toujours la même, pendant laquelle on développe des fonctionnalités. La cadence et le rythme permettent de garder les équipes motivées, de solliciter les utilisateurs et d'avoir des réunions régulières. On parle de sprint en Scrum.
Pas de règle absolue pour la durée de ces itérations, pour autant on considère en général qu'il faut que les itérations durent entre 1 et 4 semaines.
Au démarrage de chaque itération (ou sprint), on va avoir une réunion de planification (sprint planning en Scrum). Toute l'équipe se met autour de la table et se demande ce qu'elle est en mesure de réaliser pendant la durée à venir.
⚠️ Attention, ce n'est pas parce que l'équipe a estimé au démarrage de l'itération qu'elle était en mesure de délivrer 5 fonctionnalités, qu'elle s'engage dans le marbre à le faire. Ni qu'il faut lui mettre la pression pour qu'elle y arrive coûte que coûte.
Si tu veux creuser le sujet de la priorisation, j'avais animé une conférence sur le sujet il y a quelques mois.
Activité 3 : développer
Voilà, on a choisi les fonctionnalités les plus importantes (en priorisant).
On en a planifié quelques unes pour la prochaine itération (en planifiant).
Il ne reste plus qu'à développer, écrire les lignes de code.
Qui développe ?
Pour comprendre cela, il faut savoir comment est composée une équipe agile. En général, il y a :
Un Product Owner - Manager pour coordonner les enjeux tech (avec le tech lead), design (avec le produc designer) et le business
Un Scrum Master pour faciliter les réunions et s'assurer qu'on est efficace et qu'on s'améliore en continu
Un Tech Lead pour gérer les sujets de conception technique et guider les développeurs
Les développeurs pour donner vie et développer l'application
💡
En termes d'ordre de grandeur, 1 PO/PM et 1 tech lead à plein temps pour 5-6 développeurs à plein temps, 1 product designer et un scrum master à 50%.
Donc ce sont les développeurs, accompagnés du Tech Lead qui écrivent les lignes de code et "développent" à proprement parler.
Et les autres alors ?
Les autres ont également des rôles très utiles. Notre but ce n'est pas juste d'écrire des lignes de code sans but ou objectif derrière la tête.
Notre enjeu, c'est avant tout de s'assurer qu'on apporte de la valeur à l'utilisateur. C'est ce à quoi sert le Product Manager.
Ensuite, comme toute l'équipe a le nez dans le guidon, c'est difficile de prendre du recul. Pas facile de repérer les axes d'amélioration. Et puis pas mal de réunions et beaucoup d'intensité. Bref c'est important d'avoir quelqu'un pour mettre de l'huile dans les rouages. C'est le rôle du Scrum Master.
Quelques derniers conseils
Collaborer avec les Product designers tout au long du cycle de vie du produit et notamment pendant ces phases de delivery agile. Les designers sont clés pour bien comprendre l'utilisateur et créer des interfaces les plus efficaces.
Inclure le marketing dès le tout début de la Discovery. Ça va te permettre d'affiner ton positionnement et ton univers très tôt. Avec au final, un message cohérent et clair pour tes utilisateurs.
Mesurer l'avancement et les progrès réalisés tout au long du processus. C'est la seule manière de s'assurer qu'on va dans la bonne direction. N'oublie jamais que "on ne peut pas améliorer ce qu'on ne mesure pas". J'en ai parlé dans cette édition sur la mesure du succès de son produit.
Conclusion
Voilà c'est tout pour ce mini cours !
Les coups de ❤️ de la semaine
📝 Le contenu de la semaine : ce fil twitter sur le Product Management, plein d'idées et de réflexions super intéressantes !
📰 L'actu de la semaine : hyper honoré et heureux d'être 77ème au classement Favikon des influenceurs LinkedIn français, ; le classement par catégorie sort cette semaine mais j'ai eu un mini spoil, apparement je suis 2ème IT&Tech 🥳
😂 Le rire de la semaine : ce super post de Jean Christophe Pagès, et son image qui m'a beaucoup faite rire.
À dimanche prochain !
Si tu es trop impatient pour attendre, tu peux :
M'envoyer des actus, contenus ou rires qui ont animé ta semaine et j'essayerai de les inclure dans l'édition de la semaine prochaine (en te citant bien sûr) 💪
Me contacter pour échanger sur l'agile par mail ou par message LinkedIn 💪
M'envoyer des feedbacks sur ce numéro, positifs... ou négatifs bien sûr ! C'est comme ça qu'on progresse 💪
Partager la newsletter à des personnes susceptibles d'être intéressées 💪
Bon courage pour la semaine (ça va, juste 4 jours et après, encore un week-end de 3 jours 🥳) !
Victor