Agilité à l'échelle : Fast & Scrum

Communauté Scrum Life
,
1

Bonjour à tous !

Je reviens vers vous avec un nouveau un sujet.

Je suis lead dev/ scrum master d’une équipe de développement logiciel de 5 personnes au départ.
On a une grande attente client, il faut qu’on délivre plus de choses et plus vite. Réel risque lié au marché.

Bon, la solution est d’agrandir l’équipe R&D ( on va pas y revenir :slight_smile: )

On est passé à 7 et maintenant à 9 !!! ( Ça chauffe déjà ) Surtout sur des sprints de 3 semaines !!! ( Je demande à passer à 2 semaines)

Je me suis basée sur la vidéo de la chaîne Youtube : https://youtu.be/A0alM2OovFk?si=lIO7RsRrrQ4ULTnQ
Que je trouve au passage juste excellente !!!

L’objectif est d’agrandir l’équipe à 15 développeurs dans les les mois à venir ( là encore, ce n’est pas le sujet :frowning: )

Aujourd’hui, j’applique la méthode Scrum avec un sprint de 3 semaines.

La méthode agile Fast me plait bien sûr le principe, car elle va nous permettre d’avoir une seule et grande équipe, on constitue des petites équipes pour prendre en charge des sujets à pas plus de 3 jours ( cycle ).

Je ne maîtrise pas encore cette méthode, je suis en veille la dessus.
Cette méthode a été décrite aussi dans la vidéo au dessus.

J’aimerais savoir si vous l’avez déjà pratiqué ? Si oui, vous en pensez quoi ? Qui sont les points positifs ? Les limitations ?

J’aimerais faire un mix de scrum / Fast.
C’est à dire un scrum qui englobe du Fast.

Je garde des sprint un peu plus importants (3 semaines) pour partager au directeurs et faire les rituels du fin du sprint.

Puis pour la gestion des us, des petits cycles Fast avec des minis équipes, un seul objectif par équipe, et dès que c’est done, on repart dans un nouveau cycle fast avec la constitution des nouveaux mini équipes…

Je ne suis pas si c’est clair :sweat_smile:
Je brainstorm en même temps.

Hâte de lire vos retours la dessus.
Merci d’avance à la communauté :muscle:

2

Hum… Je suis curieux de pourquoi tu souhaites garder une dynamique telle que celle de Scrum dans un projet comme celui que tu proposes. Peur de l’inconnu ou tu penses réellement que les patterns présent ont un bénéfice dans ton cas ?

Je vais même allez plus loin : Dans une approche qui pousse autant la co-création et le « savoir de la masse », pourquoi ne pas laisser ces considérations à la main de tous ?

3

Merci Samuel,
Et bien vue.
Je veux créer effectivement 2 phases qui vont répondre aux besoins de chaque équipe. C’est aussi pour la conduite au changement.

Je m’explique, déjà ya 1 an et demi, j’ai mis en place scrum dans cette équipe. Sachant que le PO et le PM, avaient plus l’habitude de travailler en cycle en V avec des cahiers de charges dune 20 de pages.

Maintenant, on a scrum, mais un scrum qui n’est pas très agile encore dans la vision du PM, qui a encore et toujours besoin d’avoir un plan de release, un plan de charge, des estimations, la date de sortie… Ce qui est agile c’est que le backlog ( on ajoute et on enlève souvent des choses).

Je me disais, que je peux mettre le Fast qui va permettre à mon équipe et mes minis équipes de rester focus sur un seul sujet sur un cycle très court. Cela va dynamiser l’équipe, va réduire la charge cognitive, va me permettre de faire un meilleur suivi et booom on peut même livrer régulièrement des us done de meilleures qualités.

Le scrum je le garde plus pour le sprint preview avec la grande équipe R&D, comme ça tout le monde verra le travail des autres.
Puis le PM et PO sont présents, ça va les rassurer et nous on récupère les feedbacks.

Je veux garder les dailys mais chaque équipe un représentant qui partage l’avancement.

Je veux garder les rétrospectives aussi pour qu’on se remettent en question…

Je ne sais pas trop comment Fast prévoit ces événements :thinking:

L’idée c’est de gagner leur confiance et peut être même finir par supprimer certains rituels Scrum.

Voilou !

4

Il n’y a pas besoin d’un moment prédéterminé pour faire une rétro, il faut le faire dès que le besoin s’en fait sentir.

Petit conseil pour la découpe des mini équipes: les organiser autour de capacités métier. C’est lié à la notion de « Bounded Context » en Domain-Driven Design.

J’approuve le fait de diminuer progressivement la taille des sprints (l’idéal pour moi étant d’arriver à du Kanban / Continuous Delivery). Il faut juste savoir le vendre, en expliquant que ça donne une meilleure réactivité par rapport à ce qui se passe sur le marché.

5

Tous les acteurs sont réellement conscient du lâcher prise qu’un tel changement de paradigme demande ? J’ai personnellement peur que le passage d’un model à l’autre soit assez brutal si mal amené, mais ce n’est que de la projection de ma part.

Si c’est ça que tu recherches, peut être que tu trouveras plus ton compte du côté du mobbing et du swarming qui vont favoriser l’émergence des comportements que tu décris. Tu connais déjà ces approches ?

La fin d’un cycle en FAST sert exactement à ça, donc je ne suis pas sûr de pourquoi la review est nécessaire selon toi. Tu pourrais nous éclaircir ?

A moins qu’il existe des dépendances fortes (et je ferais confiance à l’intelligence collective pour les gérer de la meilleure façon), quel serait l’intérêt d’un daily vu qu’une fin de cycle accompli le même travail de resynchronisation ?

Une micro-équipe peut très bien partir sur un sujet « amélioration continue mise en application immédiate ». En gros, on pourrait envisager une équipe qui se poserait pour deux jours sur le fonctionnement de toute la tribu, qui irait prendre du feedback si besoin et qui organiserait et mettrait en place des actions de manières pro-actives. Qu’est ce que tu penses d’une approche telle que celle là ?

Leur ? Tu parles des PO et PM ?

1 « J'aime »
6

Les équipes à allocation ouverte se créent et s’arrangent à leur convenance et selon ce qu’elles pensent être le mieux pour elle. C’est la base du model.

7

Réel risque lié au marché.

C’est à dire ?

Incertitude ? Concurrence ? Deadline ? Je préconise de faire une minute de sense-making avant d’aller mettre en place des méthodes.

R&D

Quel type de R&D ? FaST, et plus généralement l’agilité, ne convient pas à l’innovation de rupture ou aux fortes incertitudes.