Atelier Coaching – Approche Paradoxale

Qui n’a pas été confronté à une situation qui stagnaient sans trouver de réelles solutions à cause de non remise en question ?

blog ai3 approche-paradoxale Atelier Coaching - Approche Paradoxale

Le plus bel exemple qui nous ait été donné de faire, fût pour une société qui était en plein turnover et cherchait désespérément à garder ses collaborateurs.

Si l’on questionnait chaque Manager/Directeur la réponse était évidente « on fait tout comme il faut, je ne vois pas pourquoi ils partent ! « . Et pourtant, les collaborateurs partaient bel et bien …

Si à contrario on allait questionner les collaborateurs nous avions pleins de choses à mettre dans notre panier ! Mais tout le problème était de le faire comprendre aux supérieurs…

« L’approche Paradoxale » est un outil permettant de trouver des solutions à des situations qui stagnent en partant du pire pour trouver le meilleur ou comment tourner un sujet important à la dérision pour mettre le doigt sur des choses auxquelles nous n’aurions pas pensé sinon.

Dans l’exemple plus haut, la problématique de l’atelier n’était donc pas « Comment garder nos collaborateurs ? « , ça ils avaient déjà tous penché la dessus, mais au contraire « Comment faire partir ces p*** de collaborateurs ? « .

Déroulé

La première étape est d’annoncer la problématique. Gardez le ton du dérisoire et de l’amusement sur tout le long, il faut que les gens se sentent à l’aise et que l’ambiance soit présente pour faire un effet choc sur la fin de l’atelier.

Exemple : « Comment faire partir ces p*** de collaborateurs ?

Ils nous embêtent, on doit travailler plus et ils nous coûtent un max de blé ! Non mais franchement, comment on peut faire pour les pousser à la porte ???? Il faut que ça reste légal bien sûr, on ne veut pas mettre la clé sous la porte 🙂 » (imaginez la tête de la DRH quand on lui a dit ça :p).

Partie 1 : Réflexion

Chaque participant se verra munit de post-its et prendra le temps de la réflexion pour trouver ce qui ferait partir les collaborateurs au plus vite.

Après un temps défini, chacun son tour ira coller ses idées au tableau en les expliquant et en regroupant avec les post-its similaires.

Exemples à ce stade :

  • « Plus d’augmentation »
  • « Des heures sup le soir et weekend »
  • « On les forme pas »
  • « On ne les félicite jamais, on les enfonce même ! « 
  •  » Pas d’afterworks et moments d’équipe »

Partie 2 : Regroupement

Tous ensemble les participants réfléchissent et convergent sur ce qui peut être regroupé.

Partie 3 : Prise de conscience

C’est là, que tout va se jouer, vous allez poser la question qui fâche « Mais en fait, il n’y a pas des choses que vous faites déjà là-dedans avec vos collaborateurs ? ».

Généralement, les sourires s’effacent et c’est là que les participants prennent conscience qu’ils ne font pas si bien en fin de compte.

Chacun se verra distribué des gommettes et ils iront tous les déposer sans commenter sur les post-its sur lesquels ils se retrouvent.

Partie 4 : Améliorations

Pas de panique, on est là pour trouver justement les solutions aux vrais problèmes !

Demandez aux participants de trouver de solutions sur les idées contenant le plus de gommettes et tirez des améliorations à effectuer.

Exemple :

  • « On les forme pas  » => Octroyer une formation à chacun sur l’année.
  • « On ne les félicite jamais, on les enfonce même ! » => Mettre en place des façons collectives de se féliciter.
  • … (on parle pas de l’augmentation hein, ça c’est le directeur qui tranche :p)

Partie 5 : Actions concrètes

La dernière phase consiste à trouver les actions concrètes de ses actions d’améliorations avec Owner et date de mise en place.

Exemple :

  • « Octroyer une formation à chacun sur l’année » => Chaque manager fait un point avec ses collabs pour trouver une formation et contacte le service associé pour les inscrire, deadline dans 1 mois
  • « Mettre en place des façons collectives de se féliciter » => Tartenpion met en place les Kudo Cards dans son équipe, deadline dans 2 semaines

Conclusion

Très bon atelier de coaching à sortir dans de nombreuses situations. Vous pouvez également utiliser cet outil lorsqu’une équipe part à la dérive sans en rendre compte avec comme problématique par exemple « Comment faire échouer notre projet ? « .

Coaching – Les 5 pourquoi

Lorsque l’on est face à un problème, on a tendance à chercher la solution directement sans creuser et on se retrouve à mettre un pansement sur une hémorragie interne, donc cela ne sert à rien.

La méthode des « 5 pourquoi » est souvent utilisée en coaching afin de déterminer la cause exacte d’un problème en remontant petit à petit vers la source afin de trouver la solution adaptée qui en découle.

Origines

Cette méthode a été initiée dans les années 90 par Taiichi Ohno s’appuyant sur la catégorisation des causes possibles d’un problème suivant deux thématiques :

  • Les causes symptomatiques, celles qui paraissent évidentes et identifiables rapidement (exemple XX)
  • Les causes originelles, celles qui sont la sources des causes symptomatiques auxquelles on ne pense pas au premier abord (exemple XX)

L’ingénieur Japonais mise donc sur le simple fait de rechercher la source du problème afin que celui-ci ne se reproduise pas plutôt que d’en « soigner » les conséquences.

Démarche

La démarche est simple, il suffit de poser la question « Pourquoi? » 5 fois de suite afin de remonter à la source du problème (voir moins si on trouve avant et ne pouvons plus aller en amont).

Quelques Exemples

Problème : nous avons un retard sur la livraison de nos User Stories

1er pourquoi :
« Pourquoi les US ne sont pas livrées à temps dans le Sprint? « 
Réponse : « Les développeurs n’ont pas pu les terminer » (encore les devs, ce sont des faignants ! :D)

2eme pourquoi :
« Pourquoi les développeurs n’ont pas pu les terminer ? « 
Réponse : « Ils ont commencé, mais n’ont eu les retours du PO que très tard durant le sprint »

3eme pourquoi :
« Pourquoi le PO a-t-il attendu autant de temps à tester les US ? « 
Réponse : « Parce qu’il n’a pas eu le temps de le faire avant »

4eme pourquoi :
« Pourquoi n’a-t-il pas eu le temps de le faire avant ? « 
Réponse : « Parce qu’il passe tout son temps à écrire les nouvelles US, les règles métiers étant complexes et donc n’a pas le temps de faire la recette »

Solution : Engager un testeur qui sera affecter uniquement à la recette et pourra donc faire avancer les développeurs.

Problème : Ma copine est furieuse contre moi

1er pourquoi :
« Pourquoi est-elle furieuse contre toi ? « 
Réponse : « Parce que je suis arrivée en retard à notre rendez-vous »

2eme pourquoi :
« Pourquoi es-tu arrivé en retard ? « 
Réponse : « Parce que je me suis pas réveillé ce matin »

3eme pourquoi :
« Pourquoi ne t’es-tu pas réveillé ce matin ? « 
Réponse : « Parce que j’ai geeké toute la nuit »

Solution : Quand tu as un rendez-vous avec ta copine, ne joue pas la veille et couches-toi tôt si tu ne veux pas qu’elle te quitte !

Conclusion

Il s’agit d’un excellent outil de coaching qui permet à l’équipe de trouver elle-même ses solutions tout en restant nous-même neutres.

Petit bonus, vous pouvez même l’utiliser dans le cadre perso ;).

Kudo Cards

Issues du Management 3.0 (tout comme le Moving Motivators et le Delegation Poker ), les Kudo Cards sont un must have dans une entreprise (ou un projet) qui est centrée collaborateur.

Le principe

Le principe est simple, il s’agit de remercier les personnes de l’équipe pour leur travail, attitude ou tout ce que vous jugerez bon de pointer du doigt (de positif, bien entendu).

Pourquoi ? Parce que rien de mieux que la gratitude pour faire avancer un projet et se sentir bien.
Nous avons trop tendance à  pointer du doigt quand quelque chose ne va pas mais à ne rien dire si le travail est bon ce qui a tendance à accentuer une démotivation et perte de confiance.

Pour y remédier, il suffit de dire merci ;).

Les cartes

Les cartes se présentent sous ce format :
blog ai3 cartes Kudo Cards

Mode d’emploi

Il y a plusieurs façons de faire, le but étant que chacun distribue les cartes de remerciement /félicitations à autrui dès qu’il le juge nécessaire.

Méthode 1 : La boîte à remerciements (Kudo Box)


blog ai3 box Kudo Cards

On fait une jolie boite de ce style et on y dépose une Kudo Cards dès que le besoin s’en fait ressentir.

Une fois par mois, on procède a une cérémonie de dépouillements où tous les remerciements sont lus à tous.

Méthode 2 : Le mur des remerciements


blog ai3 kudo-wall Kudo Cards

Un mur visible de tous affiche l’ensemble des Kudo Cards et on en rajoute au fur et à mesure.

Un nettoyage du mur peut être fait fréquemment avec une petite cérémonie de remerciements.

Méthode 3 : Donner la carte à la personne

On peut très bien faire simple et tout juste donner la Kudo Cards à la personne concernée à l’instant T ;), cela fait plaisir et reste dans le privé.

Petit + :

Pour donner encore plus envie d’être remerciés, vous pouvez attribuer des prix pour les top receveurs (exemple un petit dej offert ;)). 

Delegation Poker

Le Delegation Poker fait parti du kit d’outils du Management 3.0 (tout comme le Moving Motivators ici). Il sert à partager les responsabilités dans l’équipe autour de discussions de confiance

L’un des fondements du Management 3.0 dit « La gestion est trop importante pour être laissée aux managers » ce qui implique de « déléguer », cela tombe bien on parle ici de Delegation poker ;).

Matériel

Le jeu de cartes du Delegation Poker se constitue comme suit :

blog ai3 delegationpoker Delegation Poker

1 – Tell : Le manager prend la décision et informe son équipe de celle-ci.

2 – Sell : Le manager prend la décision mais va convaincre l’équipe que c’est la bonne.

3 – Consult : Le manager prend la décision mais après avoir consulté son équipe pour être conseillé.

4 – Agree : Le manager et l’équipe prennent la décision d’égal à égal.

5 – Advise : Le manager conseille et peut influencer mais la décision revient à l’équipe.

6 – Inquire : L’équipe prend la décision et informe le manager de celle-ci.

7 – Delegate : L’équipe prend seule la décision, le manager n’a pas d’influence.

Déroulement

Tout le monde (équipe et manager) se voit attribuer un set de carte de Delegation Poker. L’animateur va ensuite proposer une situation qui peut avoir lieu, exemple :

  • Qui valide les congés ?
  • Qui est responsable de l’embauche d’une nouvelle recrue ?
  • Qui décide de la deadline des projets ?

Suite à cela, comme un « Planning Poker« , chaque personne va choisir une des cartes de son jeu correspondant à la personne qui prendra la décision pour la situation.

L’animateur compte jusqu’à 3 et l’ensemble des cartes est dévoilé.

L’équipe échange sur la situation et les opposés donnent leurs avis sur le pourquoi de leur choix jusqu’à se mettre d’accord sur la carte correspondante (soit par moyenne, nombre majoritaire… le but étant surtout de partager).

L’objectif n’est pas de tout déléguer (carte 7) mais de communiquer et de progresser au sein de l’équipe.

Une fois terminé, on passe à la prochaine situation. Chaque personne est libre d’en proposer une 😉

Quand utiliser des design pattern?

Tout développeur ,s’il veut respecter certains concepts du software craftmanship, a la possibilité d’utiliser des patterns.

Cet article va vous expliquer de manière simple dans quelles occasions certains patterns peuvent être utilisé.

Une boite à outils

blog ai3 image Quand utiliser des design pattern?

Lorsque vous êtes en train de bricoler chez vous avec votre boite à outils préférée, vous vous apercevez qu’une vis doit être retirée. Pour cela, vous ouvrez votre boite à outils et prenez l’outil permettant de résoudre cette problématique : à savoir un tournevis.

Un problème détecté a été résolu par l’utilisation d’un outil.

Et bien en terme de programmation, c’est exactement la même chose. Lorsque vous êtres confronté à un problème d’algorithmie, un design pattern peut être la solution pour résoudre votre soucis. Dans ce cas, si je veux faire une comparaison, le pattern que vous utiliserez est tout simplement votre tournevis.

Le gros avantage est que ces outils (en l’occurrence les design pattern) sont connus de tout développeur (provenant des Etats-Unis, d’Europe, de Chine…etc). Cela permet ainsi d’avoir du code standardisé, plus maintenable et surtout plus facile à reprendre pour le développeur qui passera derrière vous (car il faut toujours penser à la personne qui reprendra votre travail).

Des exemples…

J’imagine que vous êtes tous impatients de savoir quand utiliser ces patterns…Je précise juste que je ne vous expliquerai pas l’implémentation de chaque pattern (qui fera peut être l’objet d’un autre article de ma part) mais dans quels conditions l’utilisation de tel où tel pattern pourra résoudre votre problématique.

blog ai3 image Quand utiliser des design pattern?
Vu le nombre important de design pattern existant aujourd’hui, je ne vous détaillerai que ceux qui me semblent le plus important. Bien entendu, il est bien entendu possible de me contacter sur les autres patterns si vous souhaitez d’autres informations.
  • Vous êtes dans la nécessité de créer une instance unique de classe en session au niveau de votre code. Le pattern Singleton peut répondre à votre besoin
  • Vous souhaitez centraliser l’instanciation de vos objets, d’avoir une classe qui s’occupe uniquement de faire ce travail. Le pattern Factory peut répondre à votre besoin.
  • Vous travaillez sur une application développée en couches et vous souhaitez que celles-ci soient faiblement couplées. Le pattern Facade peut répondre à votre besoin.
  • Vous êtes dans la nécessité de rajouter des fonctionnalités à une classe. Le pattern Decorateur peut répondre à votre besoin. D’autant plus, qu’en utilisant ce pattern, on sera cohérent avec le O (Open) des paramètres SOLID qui préconise d’éviter le plus possible de modifier une classe existante mais de l’étendre.
  • Vous devez développer un algorithme et vous vous rendez compte que celui-ci doit être appelé plusieurs fois mais avec des paramètres différents à chaque fois. Le pattern Stratégie peut répondre à votre besoin. L’exemple typique du pattern stratégie est la météo (quand vous demandez dans une application Météo les prévisions pour demain, après demain, la semaine prochaine…d’un point de vue technique vous demandez toujours la même chose mais avec des paramètres différents).

BDD (Behavior Driven Developement)

Le BDD, qu’est ce que c’est ? 

Ce que l’on entend souvent, c’est que le BDD(Behavior Driven Developement) est un langage (Gherkin) permettant par la suite d’écrire les TDD (Test Behavior Developement) .

Faux ! Le BDD est une méthode de travail qui consiste avant tout  à mettre en forme des scénarios de tests dans un langage compréhensible par toutes les parties du projet (techniques ou non).

Oui, parfois (souvent), ces scénarios sont mis sous forme de Gherkin dans un outil comme SpecFlow pour ensuite aller vers du TDD mais il s’agit surtout de communiquer ensemble sur tous les cas possibles d’une fonctionnalité afin de couvrir (fonctionnellement) l’intégralité des possibilités.

« Three Amigos »

Ce que l’on appelle le « Three Amigos » lors d’un atelier BDD, c’est le fait de se mettre autour de la table avec à minima 3 personnes qui porteront une casquette différente pour répondre aux question suivantes :

  • Métier (souvent un BA ou PO): Quel problème essayons nous de résoudre ?
  • Développement (Dev) : Quelle solution pouvons-nous apporter ?
  • Test (QA): Doit trouver les défauts à cette solution pour creuser la totalité des cas et se poser la question du « Et si … ? ».

Exemple :

Métier : « Je veux que mon utilisateur puisse laisser des commentaires »

Développement : « Nous aurons un champs commentaire dans le formulaire »

Test : « Ok, et si l’utilisateur envoie un roman dans le champs ? »

Métier : « Ah mais non c’est logique, on ne veut pas de trop gros commentaires ! »

Développement : « Donc nous dirons 1000 caractères ? »

Métier : « Parfait »

Test : « Et qu’arrivera t-il s’il les dépasse ? »

Métier : « Un message d’erreur ? »

Développement : « Ok ! »

Donnera :

  • Étant donné (Given) qu’un utilisateur laisse un commentaire
  • Quand (When) le commentaire dépasse 1000 caractères
  • Alors (Then) le commentaire ne doit pas être sauvegardé
  • Et ( And) l’utilisateur doit voir un message d’erreur

On ne pense pas tous de la même manière, quelque chose qui paraît évident pour quelqu’un, ne l’est pas forcément pour un autre. Si le BDD n’avait pas eu lieu, le développeur aurait possiblement créé une zone de texte sans limite et le métier serait revenu vers lui plus tard pour la lui demander.

Le BDD permet donc de parer à tout éventualité et de pouvoir anticiper les retours possibles.

On pourrait s’arrêter là, vous avez compris le principe. En atelier, nous mettons sur papier tous ces scénarios afin de partir sur de bonnes bases pour les développements.

Cependant, il existe certains outils permettant d’intégrer ces BDD dans le code pour ensuite en faire des BDD comme « SpecFlow ».