• Save
Principe d'une organisation agile
Upcoming SlideShare
Loading in...5
×
 

Principe d'une organisation agile

on

  • 1,944 views

 

Statistics

Views

Total Views
1,944
Views on SlideShare
1,944
Embed Views
0

Actions

Likes
0
Downloads
20
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Principe d'une organisation agile Principe d'une organisation agile Presentation Transcript

  • FormationPrincipe d’organisation Agile Mathieu Gandin
  • Agenda Posture du Scrum Master Comprendre une organisation complexe par l’approche systémique Résolution de conflit© OCTO 201Z 2
  • Agenda Posture du Scrum Master Comprendre une organisation complexe par l’approche systémique Résolution de conflit© OCTO 2012 3
  • Objectif du Scrum Master En tant que Scrum Master  je veille à ce que léquipe délivre le maximum de valeur maintenant et dans le futur  je suis là pour aider à chaque membre de léquipe à atteindre leur pleine capacité© OCTO 2012 4
  • Responsabilités du Scrum Master Le Scrum Master est un membre de léquipe, et il applique les valeurs agiles tout le temps. Le Scrum Master applique les principes et bonnes pratiques dingénierie issues des méthodes agiles Le Scrum Master est un facilitateur, un animateur, et permet de développer et renforcer la communication entre les membres de léquipe Le Scrum Master a une expérience des projets Agiles Le Scrum Master propose du coaching en 1-2-1 aux membres de léquipe© OCTO 2012 5
  • Responsabilités du Scrum Master Le Scrum Master identifie les risques et freins de léquipe et laide à les lever Le Scrum Master communique à léquipe de lavancement de son travail Le Scrum Master croit en lintelligence collective de léquipe : Léquipe est la seule à même de prendre la meilleure décision en regard de linformation dont elle a à sa disposition Le Scrum Master priorise son travail pour apporter le maximum de valeur à léquipe Le Scrum Master est sensibilisé à la notion damélioration continue© OCTO 2012 6
  • Style de management Directif Explicatif Adaptatif Délégatif Participatif© OCTO 2012 7
  • Agenda Posture du Scrum Master Comprendre une organisation complexe par l’approche systémique Résolution de conflit© OCTO 2012 8
  • Un changement ça prend du temps Idée transformatrice Ancien Statu quo Chaos Apprentissage Nouveau Statu quo© OCTO 2012 9
  • Complexité des organisations Système non-linéaire Changement paradigme « Plus de … », « moins de … » Une action peut découler de plusieurs causes différentes et une action peut engendrer plusieurs conséquence différentes© OCTO 2012 10
  • Approche systémique Dans une approche systémique, un système est un ensemble de composants qui sont interdépendants les uns des autres L’approche systémique s’oppose souvent à une approche scientifique plus classique qui fait l’hypothèse que tout problème complexe peut être décomposé en problème plus simple et indépendant Cette hypothèse négligeant les interdépendances, qui vont se révéler très importantes si on prend l’hypothèse d’une organisation où chaque personne qui en font partie sont en relation Relire une seconde fois, plus lentement© OCTO 2012 11
  • Approche systémique Leader Feedbacks ressources Résultats Système aléatoire Autres Planifier son plan d’action en se posant les questions suivantes : qu’est- ce que je veux voir arriver ? Comment est-ce que je peux l’obtenir ? Puis observer ce qui se passe réellement. Est-ce que ce que j’observe est stable ? Visible ? Explicite ? Comparer ce que j’ai observé avec ce qui était planifié et adapter mon plan d’action© OCTO 2012
  • Atelier #1Le jeu duFrigo© OCTO 2012 13
  • Approche systémique Variable mesurée© OCTO 2012 14
  • Approche systémique Variable Mesurable© OCTO 2012 15
  • Approche systémique Relationd’influence© OCTO 2012 16
  • Approche systémiqueInfluence négative© OCTO 2012 17
  • Approche systémique Boucle derenforcement © OCTO 2012 18
  • Approche systémique Equilibre© OCTO 2012 19
  • Approche systémique Effet de retard© OCTO 2012 20
  • Approche systémique Limite pour une boucle[limite=...]© OCTO 2012 21
  • Atelier #2Représentation dediagrammesystémique sur dessituations© OCTO 2012 22
  • Jérome, chef de projetNous travaillons sur un projet stratégique pour une banque en ligne. Daniel (duMarketing) est le client de ce produit.Le projet a commencé en mars 2010 avec trois développeurs: Alex, Bruno etChristian, plus un chef de projet (moi).On a livré en juin la première version, qui tourne en production. Le client était supercontent du résultat.Il a plein de nouvelles idées et nous a demandé de les implémenter pour la fin delannée.Au vu du nombre de fonctionnalités demandées, jai décidé avec mon manager defaire rentrer cinq développeurs de plus.Mais maintenant ça fait huit personnes à gérer, et je nai plus le temps. On a doncdécidé avec mon manager de faire passer Christian, le tech lead, dans un rôle dechef de projet (à ma place). Aujourdhui tout le monde est super occupé: entre lesréunions de coordination et la formation de nouveaux tech leads, Christian me ditque ça fait déjà trois samedis où il a du réécrire du code. Les nouveaux ne parlentbeaucoup, je ne sais pas sils sont très motivés. On est déjà en octobre et pourtanton est loin davoir implémenté la moitié des fonctions demandées Daniel. Il est déjàrevenu à la charge trois fois pour valider le plan de comm du produit pour la fin delannée, mais je ne sais pas si ça va le faire. Help !© OCTO 2012 23
  • Ghislaine, responsable support du département relation client pour un site web B2B B2CMoi je moccupe du "service après vente" en quelque sorte: avec mon équipe on reçoitles appels clients et on les enregistre et en fonction de la qualification du problème onles redispatche via le bugtracker :- chez nous avec un expert produit qui va assister le client,- chez les développeurs si cest un bug,- chez la prod si cest un problème dinfrastructure technique,- ou au marketing si cest une demande de nouvelle fonctionnalité.Je ne sais pas ce qui se passe en ce moment, mais on a de plus en plus de demandes, etbeaucoup dappels réentrants, cest à dire quand un client nous relance pour unproblème quil a déjà signalé. Mon objectif, cest quun appel client soit résolu le plusvite possible. Quand jappelle la prod à propos dune fiche que leur ai transmise, ils medisent quils nont pas le temps, parce quils sont occupés à ouvrir de nouveauxservices, et ils me demandent de rediriger la fiche vers léquipe de développement. Avecles développeurs, cest devenu lenfer; je suis obligé dattendre une voire deux itérationspour avoir simplement des nouvelles de ma fiche incident ! Et le scrum master merecommande daller en parler au Marketing. Franchement, lagile, je suis pas sûre quecétait une bonne idée. Pouvez-vous maider à atteindre mon objectif ? Si vous avez uneidée je pourrais en parler à Gérard, le DSI (cest un copain) mais il lui faut des arguments"béton »© OCTO 2012 24
  • Francis, tech lead sur le projet CRM temps réelCest Henri qui vous envoie ? Henri cest le manager du service et depuisquelque temps, il fait pas bon le croiser quand il est en colère.Le problème quon a, cest quon est débordé. Henri vient chaque matinau stand up meeting et nous demande des comptes sur les bugs encours de correction. Il faut dire quon en a de plus en plus. Depuis unmois, Henri nous met la pression pour que chaque bug soit corrigé dansla journée. Je lai prévenu que si on doit corriger plus il faudra quonteste moins, mais il ne veut rien savoir. Du coup, on se retrouve avec deserreurs dûes à des corrections vite fait-mal fait, ou bien des problèmesquon a déja vu plusieurs fois. En voyant ça, Henri a demandé un récapde chaque heure passées par les développeurs. En cemoment, lambiance est pourrie. Personne ne parle plus au café, et lesgens font les heures minimums, vu quon est tous "presta". Si vouspouvez maider à parler à Henri, ça marrangerait.© OCTO 2012 25
  • Paradoxe et résolution de problème
  • Problème  Premiers développements  Solutions ! Ca marche  Prenons une solution déjà utilisé  « Plus de la même chose »  Situation d’échec  Crise …© OCTO 2012 27
  • Exemple de résolution de problème « On a des difficultés pour tester mais on a toujours utilisé des frameworks pour corriger nos problèmes, alors on teste avec des frameworks de mocks » « Plus je mock, plus le code de mes tests sont complexes » « Plus le code des tests sont complexes, plus j’ai des difficultés à tester » « Plus j’ai des difficultés pour tester, plus j’utilise des frameworks … » Dans ce cas, essayons de tester avec moins de frameworks PcRessource pcRessource = new PcRessource() { @Override protected URI createURI(RegistredPc pcToRegister) { try { return new URI(""); } catch (URISyntaxException e) { throw new RuntimeException(e); } } };© OCTO 2012 28
  • Vélocité On corrige beaucoup de bugs Augmentation du pendant l’itération rythme Retour à un rythme soutenable Première étape : Deuxième étape : Ralentir et arrêter d’accumuler de la Diminution de la dette dette technique et apports de plus de valeur métier Temps Faire moins de la même chose
  • Agenda Posture du Scrum Master Comprendre une organisation complexe par l’approche systémique Résolution de conflit© OCTO 2012 30
  • Vers la dynamique d’équipe Dans les équipes agiles, nous retrouvons un ensemble de rôles prédéfinies (PO, Scrum Master, Développeurs, managers, tech- lead …) Nous observons aussi certains comportements  L’équipe résiste à de nombreux changements, et continue de fonctionner comme avant, tout en étant labélisé « équipe agile ».  Des personnes sont sur la défensive, et évitent certaines conversations  Certaines personnes peuvent se révéler agressives envers d’autres  L’équipe rencontre des difficultés pour prendre une décision afin de résoudre un problème  Certaines personnes manquent de confiance dans leur travail  L’équipe recherche de nouveaux objectifs  … L’équipe se forme, trouve ses marques, devient performante … Ces étapes sont sources de conflits (qui sont nécessaires)© OCTO 2012 31
  • Congruence LesSoi autres Le contexte
  • « Le blâmeur » LesSoi autres Le contexte
  • « La carpette » LesSoi autres Le contexte
  • « Le superordinateur » LesSoi autres Le contexte
  • « Le distrait » LesSoi autres Le contexte
  • Congruence et incongruence Reconnaître l’incongruence en soi Quatre émotions de base  Joie, Colère, Tristesse et Peur  Quelle émotion m’est la plus familière ? Celle avec qui je vis le plus souvent ?  Laquelle m’est la plus étrangère ? Celle que je ne connais pas ou peu ?  Et les deux autres qui restent ? Comment je vis avec ?  Et pour chacune d’elles : Ca se passe comment dans mon corps ? Quelle sensation ?© OCTO 2012 37
  • Pour revenir vers de la congruence Fait, Interprétation, Sentiment, Conseil  « Quand tu dis … »  « J’interprète … »  « Je me sens … »  « Je souhaites … »  « Peux-tu … ? » Exemple :  «Je viens de voir que le code que tu viens de commiter ne compile pas et nous devons livrer ce soir et j’ai peur que nous rations cette livraison. Je souhaiterais que tu arrêtes de développer cette User Story pour corriger l’erreur de compilation. Peux-tu t’en occuper maintenant ? »© OCTO 2012 38
  • © OCTO 2012 39