Nourrir la dynamique de groupe

Le coach agile aide les managers à encourager l’intelligence collective. Il transmet pour cela quelques concepts et outils sur la dynamique de groupe.

Sans prétention à l’exhaustivité et sans entrer dans le détail de chaque item, ce court article rassemble quelques inspirations fréquemment utilisées dans nos coachings, en vous procurant les références pour approfondir chaque sujet…

Lire la suite

Outils du coach – Création du lien

On commence généralement une réunion, un atelier ou encore une formation par partager l’agenda, les règles de la réunion ou encore distribuer des rôles.

Aujourd’hui je suis coach Agile et mon rôle en tant que coach est de libérer le potentiel de la personne ou de l’équipe coachée afin qu’ils prennent conscience de leurs capacités. Pour y parvenir, il est important de créer un lien. Pas n’importe quel lien, un lien de confiance.

lien de confiance

Cet article présente différentes techniques de création de lien.

Watch5 min de lecture

Lire la suite

7±2 sera le nombre et le nombre sera 7±2 (deuxième partie)

Taille d’équipe, productivité et intelligence collective


Retrouvez la première partie de cet article : « 7±2 sera le nombre et le nombre sera 7±2 (première partie) »


Dans la première partie de cet article, nous avons vu que l’agilité présente 7±2 comme la taille idéale pour les équipes agiles. La psycho-socio parle pour sa part de groupes restreints en leur reconnaissant des caractéristiques particulières.

Dans cette deuxième partie, nous nous intéressons à l’influence de la taille sur les interactions ainsi qu’à l’effet Ringelmann. Nous dévoilerons également l’origine de ce mythique 7±2…

640px-Iss005e05022_interaction
« Iss005e05022 interaction » par NASA
Sous licence Public domain via Wikimedia Commons

Lire la suite

7±2 sera le nombre et le nombre sera 7±2 (première partie)

Taille d’équipe, productivité et intelligence collective


Retrouvez la suite de cet article :
« 7±2 sera le nombre et le nombre sera 7±2 (deuxième partie) « 


Question récurrente

Jackson_5_Jim_Nabors_Show_1970

Lors des formations à l’agilité ou à Scrum, une question revient toujours à un moment ou l’autre de la journée : « quelle est la taille conseillée pour une équipe agile ? » .

Et le formateur de répondre automatiquement : « Sept plus ou moins deux » . D’où vient cette réponse ? Est-ce un mythe ou existe-t-il des justifications ?
Pourquoi poser une limite à la taille d’une équipe ? Nous allons creuser cette question et peut-être trouverons-nous l’origine du nombre mystérieux « 7±2 »  ?

Lire la suite

Mise en place de Scrum dans une équipe désorganisée et démotivée

Etat des lieux

 

Problèmes de production

Je suis arrivé dans une équipe dépassée par les problèmes de production, qui ne parvenait pas à produire de la valeur sur le site.

Harcelés au téléphone tous les jours, les développeurs passaient leur temps à corriger la production.

 

Itérations à géométrie variable

Les itérations de développement avaient été prévues et planifiées au début du projet et constituaient des thématiques de fonctionnalités plutôt que des vraies itérations Scrum amenées à évoluer au fil des livraisons.

Les itérations prévues au départ n’étaient donc pas de taille égale, et pouvaient parfois être développées en 2 semaines, d’autres fois en 1 mois. La planification était donc impossible et l’équipe livrait une version le plus tôt possible, sans engagement possible.

 

2 semaines de développements pour 2 mois de validation/livraison

La livraison en environnement de recette d’une version développée prenait plusieurs semaines, et une fois livrée en recette, elle était testée par l’équipe de qualification. La phase de recette pouvait durer entre 2 et 3 semaines.

Enfin, la version qualifiée était déployée puis validée en environnement de préproduction.

Ainsi, une version développée partait en production après 1 mois minimum, et plutôt 2 ou 3 mois quand il y avait des problèmes. Lire la suite

Objectif Mars : la fusée a décollé !

Objectif MarsMardi dernier, Valtech organisait son AgileDay et m’avait fait le plaisir de m’inviter à présenter le jeu que nous avons créé avec Pierrick Revol: Objectif Mars.

Ce jeu met une équipe de 5 joueurs dans la peau d’une équipe pluridisciplinaire en charge du développement de sous-systèmes critiques dans une fusée, en mode Agile. Le client (le Product Owner de Scrum) a construit un backlog de fonctions à implémenter et l’équipe doit en délivrer le plus possible en 5 itérations de 10 jours, soit 250 jours-hommes de capacité de charge.

A chaque itération, l’équipe est invitée à choisir le temps qu’elle va consacrer à quatre activités : produire, se former, analyser les prochaines demandes ou réduire la dette technique. Les jours-hommes sont représentés par des jetons (de poker) tandis que les couleurs symbolisent le type d’activité. La formation permet de gagner en expertise dans une compétence et d’augmenter ses chances de produire plus et mieux, l’analyse réduit les mauvaises surprises sur les nouvelles tâches et la réduction de la dette technique (correction des bugs cachés et nettoyage du code) réduit le risque de voir les bugs restés dormants se réveiller.
Joueurs objectif MarsEnsuite on déroule les 10 journées du sprint en traitant la dette technique, en produisant (avec un dé de plus en plus