Mon premier exemple de représentation systémique

systemique_scrum_master_planningRappel de l’épisode précédent…

Après quelques mois de partage de mon voyage en Systémique dans les Agile Tours ou ailleurs (voir ma présentation sur slideshare) et la création du groupe Meetup “Katas de représentations systémiques” pour s’entraîner à représenter des systèmes, je reprends ma suite de billets sur la systémique avec des exemples de représentations.

D’abord impuissant face à la complexité apparente, j’ai en effet commencé à utiliser les diagrammes systémiques proposés par Senge pour représenter les systèmes que j’accompagnais afin de mieux comprendre certains comportements observés.

Mais que faire concrètement de cet outil et de cette complexité apparente dans mes accompagnements ?

Un premier exemple : la posture du Scrum Master en Sprint Planning

La situation

J’assiste à un Sprint Planning d’une équipe Scrum.n-REUNION-TRAVAIL-SIESTE-large570

Lors de cette réunion, j’ai observé un Scrum Master très présent dès le départ, qui devenait de plus en plus présent au fur et à mesure que la réunion dérivait, en essayant de tenir la barque autant que possible, comme le font beaucoup de Scrum Masters dont l’objectif prioritaire est de tenir le cadre du meeting et remplir les objectifs tels que définis dans le Scrum Guide.

J’ai noté que plus il tenait le cadre plus ça partait en vrille, plus il tenait le cadre, plus ça partait en vrille, etc… Et j’y ai vu une belle boucle amplificatrice, chère à Peter Senge dans ses représentations, que je me suis amusé à représenter ! Lire la suite

Booksprint : la suite de mon expérience

Je continue le partage de mon expérience agile du booksprint Agile Rocket Guide à l’aide du Manifeste agile. Après un 1er article balayant les 3 premiers principes, je continue le voyage dans le manifeste.

Travailler en équipe

Communiquer avec les utilisateurs

Pendant ces 4 jours de booksprint, la durée des sprints varie entre 1 et 2 heures donc au plus toutes les 2 heures, nous nous synchronisons avec le reste de l’équipe et notamment Christophe qui est en quelque sorte le Product Owner, pour être sûr qu’on ne dérive pas sur le contenu.IMG_20161217_170732.jpg

Nous avons également le souci de communiquer le plus vite possible avec l’extérieur et certains de nos utilisateurs identifiés. Dès le début du 2ème jour, nous envoyons un mail à nos collègues de Goood! pour leur demander du feedback sur le contenu produit puisqu’ils sont représentés par nos personas Kouigna man le gooodien et Milouz le coach.

Lire la suite

Boooksprint : 4 jours d’une expérience agile

Du 17 au 20 décembre dernier, j’ai participé à Carnac à une super expérience agile comme je n’ai plus l’occasion d’en vivre, un booksprint : écrire un livre en 4 jours en équipe, avec 4 collègues de Goood!.

Le sujet, c’est l’Agile Rocket, une transformation agile modulaire et progressive et l’objectif de ces 4 jours est de produire un guide pour clients et coachs.

Le résultat de ces 4 jours a été publié quelques jours plus tard en PDF et nous avons prolongé l’expérience en janvier avec quelques améliorations, de forme essentiellement, nous amenant à la publication de l’Agile Rocket 1.1 maintenant ! Vous pouvez enfin accéder sur google drive au guide constamment à jour avec les dernières modifications, en déploiement continu.

4 jours, 5 cerveaux, 11 sprints, 25 standups, 11 rétrospectives, 125 pages écrites et un concentré d’une expérience agile avec ses changements, ses doutes, ses rebondissements, ses joies. Notre expérience de booksprint à 5, nous la raconterons le 31 janvier à 18h45 dans nos locaux (les places sont disponibles ici) et je vais commencer par vous raconter ici mon expérience, en quoi elle est agile, et en quoi l’agile, souvent, c’est pas facile !

Pour ce faire, je vais utiliser comme grille de lecture le manifeste agile et ses 12 principes et les 3 premiers pour commencer. Lire la suite

Impuissance face à la complexité

labyrinthe_redim_2

Rappel de l’épisode précédent…

C’est toujours la même chose… Dans mes missions de coach agile, quelque soit le contexte, je vois les mêmes patterns se reproduire et ils conduisent souvent à l’échec de la transformation.

Comme indiqué dans mon billet précédent, mes premières pérégrinations en systémique m’ont permis de mettre des mots sur ces phénomènes et de commencer à comprendre pourquoi c’était toujours pareil : système, complexité, homéostasie…

Ces transformations que j’accompagne ne permettent pas de vrais changements, et pire encore je semble renforcer la capacité de résistance  de ces systèmes (personnes, équipes, organisations).

Alors que faire avec cette nouvelle perspective ? Comment manipuler ces systèmes complexes ? Comment trouver les moyens d’agir et de changer ?

Entre impuissance et paralysie…

Dans mes missions de coach agile, j’essaie d’utiliser ce que m’apprennent ces voyages en systémique. Je jette un œil à la complexité et aux systèmes dans leur ensemble. J’ai l’impression de voir un peu partout des phénomènes homéostatiques qui empêchent le système d’évoluer, des comportements qui se répètent, des solutions qui ne règlent pas les problèmes…

Lire la suite

Pérégrinations en Systémique

IMG_20160428_111029.jpg

Constat d’échec : c’est toujours la même chose…

Depuis des années, j’accompagne des personnes, équipes et organisations dans leur transformation agile et mes missions ne sont jamais les mêmes : les contextes changent, les personnes changent, ma place en tant qu’accompagnateur change (Scrum Master dans l’équipe, coach agile “internalisé” ou présent ponctuellement), mais une sensation persiste : c’est toujours la même chose.

Combien de fois ai-je récupéré des équipes « Scrum » accompagnées par un coach quelques mois auparavant et qui ne faisaient pas de rétrospective ou un simulacre de planning ?

On change le coach (« il était trop comme ci, pas assez comme ça »), ou on change de méthode (« chez nous, Scrum ça ne marche pas, essayons Kanban »), ou on change les personnes (« ces personnes n’ont pas l’état d’esprit pour travailler en agile »).

Et on aboutit toujours au même résultat : “Agile ne fonctionne pas chez nous, alors on va le tordre”, pour surtout ne pas changer, et ça recommencera après mon départ…

absurdeLes contextes changent, les personnes changent, les méthodes changent, les coachs changent, et pourtant, les mêmes problèmes reviennent toujours et aboutissent souvent au même résultat : « Scrum, ou Agile, ça ne marche pas chez nous ! ».

Je vous avoue que ce constat m’a beaucoup chamboulé, au point de me demander quelle valeur j’avais vraiment dans ces « transformations agiles » et de remettre en cause mes compétences.

Initiation à la systémique : voir la complexité

Lire la suite

Scrum master dans une équipe auto-organisée, mais j’apporte quoi moi ?

Le monde idéal…

Dans une précédente mission, je suis arrivé dans une équipe auto-organisée, autonome, avec un Product Owner totalement intégré à l’équipe. Il participe aux daily meetings, est donc informé au plus tôt de l’avancée des itérations, l’équipe est mûre, élimine les obstacles qu’elle rencontre toute seule, la communication se fait bien avec toutes les équipes de l’entreprise. Le monde idéal en somme… Mais, je fais quoi moi ?

Mon rôle de Scrum master n’est jamais le même d’une équipe à l’autre, d’un produit à l’autre. Tantôt formateur, tantôt protecteur, tantôt leader, tantôt facilitateur, tantôt coach… Ce dont cette équipe avait besoin, c’était plutôt d’un facilitateur, animateur d’équipe, mais qui n’interfèrerait pas sur son fonctionnement, puisque « tout fonctionnait bien » a priori.

… oui, sur le post-it !

Mais ce que j’ai appris pendant mes 5 années dans ce rôle, c’est qu’une façade idéale cache toujours des problèmes et de multiples axes d’améliorations possibles. C’est ce qui fait tout l’intérêt des méthodes agiles : sur un projet Agile, il n’y a pas moins de problèmes que sur un projet classique, mais la méthode les met en évidence, les fait remonter à la surface, aux yeux de tous, pour qu’on les corrige. Vu de l’extérieur, on pourrait même avoir l’impression qu’un projet agile a plus de problèmes ! Non, ni plus ni moins, mais il les montre.

Dans cette équipe Agile, des problèmes étaient donc bien visibles, et ne demandaient plus qu’à être traités. 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

Consensus Workshop pour la rétrospective

Lors d’une mission de Scrum master chez vente-privee.com, j’animais les rétrospectives très simplement :

  • retour sur les actions décidées lors de l’itération précédente
  • tour de table, chacun dit ses + et ses – sur la dernière itération
  • consolidation des infos en catégories
  • choix des catégories (chacun a 3 points à donner à 1 ou plusieurs catégories)
  • plan d’actions

Un constat : une équipe lassée et moins productive

J’ai remarqué que c’était de plus en plus fouilli, brouillon… certaines personnes n’étaient plus intéressées par la réunion, pianotaient sur leur téléphone pendant que les autres parlaient, et j’avais du mal à leur faire partager leur opinion. En gros, ça tournait en rond…

Je cherchais quelque chose pour redynamiser la rétro et remotiver les gens, pour qu’elle ne perde pas tout son intérêt. Lire la suite