Tiens, ça t'apprendras!
Valtech Toulouse recrute
Valtech Toulouse recrute.
Nous recherchons des consultants confirmés/seniors, 3 à 7 ans d’expérience. Plus particulièrement des personnes ayant une double compétence : mobilité + Java et/ou .Net
Envoyer moi vos CVs!
Release 0, Sprint 0
Dans les projets Agile, en Scrum notamment, nous démarrons par un sprint 0. D’une durée d’environ 1 à 2 mois, il s’agit de mettre en place l’environnement de travail, de construire le backlog et de préparer la montée en charge de l’équipe.
Dans le cadre d’un projet de grande ampleur, dit « large scale », (~100 personnes sur 3 ans) la durée du sprint 0 n’est pas suffisante, il faut plus de temps. Pour garder le coté inspection et adaptation, il ne faut pas augmenter la taille du sprint 0 mais plutôt faire une release 0 incluant plusieurs sprints.
Les premiers sprints sont consacrés aux activités plutôt techniques visant à couvrir les risques, c’est la « vision de départ ». Dans ce contexte, les équipes sont autonomes sur la création de leurs user stories. L’élaboration du premier backlog s’étant faite lors d’un atelier de démarrage du projet (détaillé dans un prochain billet)
En parallèle, il faut préparer le backlog côté « vision métier ». Le produit étant organisé autour de grands thèmes, le découpage des équipes s’effectue par « area » couvrant ces thèmes. Il y a un Product Owner et des Area Product Owners.
On retrouve en quelque sorte la branche en Y chère à Pascal Roques.
Tout cela piloté par les valeurs fonctionnelles et techniques édictées par le PO. Les approches Bottom-up et Top-down combinées, mais toujours priorisées par la plus value.
Au final, les deux visions se rejoignent. J’estime cette jointure autour de 3- 4 sprints, ce qui équivaut à une release : c’est la release 0.
Le RACI est ROTI
Cela faisait un bout de temps que j’avais ce billet en tête.
Le billet de Fabrice me pousse à le publier.
Effectivement, en Scrum, on parle plutôt d’atelier, où même de cérémonies plutôt que de réunions.
Au-delà de la terminologie, qu’est-ce qu’une réunion ?
C’est par définition « Action de réunir, de remettre ensemble des éléments épars. Action de réunir des personnes en un lieu à une fin déterminée ; fait de se rassembler ».
« Une fin déterminée », c’est souvent là que le bât blesse.
Une réunion doit donc avoir un objectif. Ce qui fait que l’agenda d’une réunion doit être simple :
- Rappel de l’objectif
- Traitement du sujet
- Synthèse de fin et compte rendu.
- En parallèle, une personne doit être identifiée pour vérifier que l’on ne diverge pas et contrôle le temps.
En Scrum, il n’y a qu’un seul objectif par atelier.
Pour vérifier le respect du traitement du sujet, j’ai vu une équipe utiliser une boite à meuh, c’est très efficace, suffisamment bref pour ne pas trop perturber, et tout le monde comprend bien le message.
L’objectif peut être de différente nature :
- Action et plan d’action
- Décision
- Statut
Le RACI
Pour le plan d’action, et pour chaque, j’utilise le RACI
- Réalise (Responsible), responsable de l’exécution.
- Acte (Accountable), responsable de l’approbation, responsable de l’avancement de l’action
- Consulté (Consulted), celles ou ceux qui peuvent être consultés
- Informé (Informed), celles ou ceux qui sont informées.
Le R et le A peuvent être identiques, mais « c’est le A qui assume ».
Ne pas oublié bien sûr qu’une action est un « événement », il y a donc une notion de temps. Une action doit avoir une date de début et de fin.
Le ROTI
Enfin, comme en Agile on aime bien l’amélioration continue, je propose un ROTI (Return On Time Invest) en fin d’atelier (pas tous). Une pratique toute simple et donc forcément efficace !
C’est un vote à main levée à 5 niveaux :
5 : Excellent
4 : Bon
3 : Juste moyen
2 : Utile
1 : Inutile
Et comme dit Jean-Claude Grosjean : « parce qu’à 5 doigts c’est plus facile »
Backlog Reboot
Il est des projets où même si le backlog est maintenu avec le plus de rigueur possible, un certain vieillissement de celui-ci s’opère avec le temps. Il n’est pas le seul, je sais, je vous vois venir.
Un backlog se construit dès la genèse du produit, et vit au même rythme que le produit lui-même.
Au fil des sprints, lors des affinages de backlog (backlog refinement), de nombreuses informations y sont ajoutées, modifiées, supprimées, etc, etc…
Tout comme le code, le backlog a donc besoin d’un peu de nettoyage.
En phase de transformation à l’Agilité, il est nécessaire de « rebooter » le backlog au bout de 5 à 7 sprints. Il est intéressant de voir que cela correspond aussi, mais en est-ce la cause, à la phase de stabilisation de la vélocité.
L’enjeu est :
- Revisiter les user stories restantes à faire
- Réévaluer si besoin
- Re-prioriser si besoin
- Nettoyer l’outil (Excel, IceScrum, ou autres ;-( )
- Avec une vision plus globale que ce que l’on fait en fin de sprint.
Et comme toute bonne chose arrive à temps, c’est le printemps, donc demain c’est Backlog Reboot !
Projets à releases parallèles : le Burn-Lot
Je travaille actuellement sur un produit mêlant software (SW) et hardware (HW).
L’application des méthodes agiles ne se limite pour l’instant qu’à la partie SW, mais les contraintes H/W sont tout de même à prendre en compte.
Et notamment la nécessité de releases plus longues qu’il faut anticiper côté SW.
Cela entraîne une roadmap produit à releases parallèles. Pour simplifier le projet SW, je n’ai préconisé qu’une seule release SW à la fois. Chaque release SW doit donc prendre en compte le développement de tout ou partie des releases produits. Dans ce cas, les burn-up et burn-down simples de produit ne sont pas suffisant pour évaluer la tenue des jalons.
Nous avons donc combiné dans une sorte de burn-up « croisé » d’un parking lot, les infos de la release SW et le cumul des restes à faire par release produit. Avec projection de ce qu'il faudrait sur chaque release en tant que vélocité envisagée.
Bon, ce n’est pas un vrai burn-up, puisqu’il ne cumule pas les points obtenus.
D’un côté nous avons une répartition de la production par type : user stories par release ainsi qu’un pool de bugs à corriger. Et de l’autre une projection de la vélocité attendue pour tenir des jalons.
Ce burn-lot apparaît en complément des burn-down et burn-up bien sûr.
Tout ça ne reste pas simple, mais nous donne un peu plus de visibilité !
Super Consultant
Mea culpa : Je suis désolé, mais Je ni la solution miracle, ni réponse à tout.
Chaque problème a sa solution. L’agilité me propose une boite à outils
Il faut voir l’agilité comme un méta-process outillé, il n’y a pas une solution toute faite, mais une liste de pratiques pouvant servir à corriger un ou l’autre des problèmes.
En bon mécano des projets, j’utilise la clé à molette, des écrous et des boulons, voire quelque fois même le marteau et la faucille (Social events).
Oui, je peux changer d’avis : Une solution est bonne à un moment donné, ne l’est peut être plus 2 semaines plus tard. Le contexte a pu changer, une autre solution existe ou même la première solution doit être adaptée.
L’agilité a été élaborée à partir d’expériences, dans d’autres contextes. Cela nous donne un canevas, un guide et chaque pratique peut être présentée comme une solution. En tant que coach Agile, j’aide l’équipe à découvrir ses problèmes, identifier quelles pratiques peuvent servir à les résoudre. Mais c’est à l’équipe de les adapter à son contexte propre. Les cycles courts (sprints) permettent de prendre la solution tel quel, de l’appréhender, puis de l’adapter.
Agile embarque un mécanisme d’auto-critique. Il ne faut pas voir Agile comme un dogme. Il faut aussi le remettre en question, et c’est, entre autre, bien l’intérêt de la rétrospective.
Je rejoins le discours de Thierry sur la stewardsheap, et le « manager con »
Je ne suis pas Super Consultant.
Inscription à :
Articles (Atom)
