Mot-clé - entreprise

Fil des billets - Fil des commentaires

Mémo pour le PO de plus tard

Quand nous arrivons quelque part, nous voyons assez bien ce qui ne va pas ou ce qui pourrait être améliorer. On a encore pas mal de recul. Puis très vite, on s'engloutit dans le quotidien et toutes ces bonnes idées s'envolent. D'habitude, je fais un rapport d'étonnement sur un cahier et/ou note les idées dans un trello. Pour plus tard.

Ou jamais.

J'ai un blog, alors autant m'engager un peu plus publiquement.

Lire la suite

Aller plus vite

kanban-symboles.png

Je n'aime pas me presser au moment de partir de chez moi. Quand je le fais, je dois souvent revenir quelques minutes plus tard parce que j'ai oublié quelque chose. Se dépêcher donne l'impression d'avancer, mais tout ce qu'il génère, c'est du rework. En développement logiciel, les reworks sont des corrections de bug.

L'inverse n'est pas garanti : ce n'est pas ce qu'on prend son temps que le résultat sera parfait.

Si on demande aux clients de l'IT quel est leur plus gros problème, la réponse fera partie de cette liste :

  • il y a trop de bugs
  • les délais de réalisation sont trop longs (souci le plus fréquent)

Mon job, c'est de faire que le produit livré ait une bonne qualité dans les délais impartis. Je ne veux pas en sacrifier un pour l'autre.

Lire la suite

Au secours, je vois des goulots d'etranglements partout

Olivier a raconté de façon détaillé le jeu du Bottleneck Game. Pendant cet atelier, Pascal nous a prévenu : "c'est un jeu dangereux, vous allez voir des goulots d'étranglement partout. Il avait raison :

  • aller à une conf alors qu'on a déjà plein de données à absorber et plein d'axes d'améliorations que l'on ne prend pas le temps d'implémenter
  • continuer à faire des rétros alors que l'équipe n'arrive pas à réaliser les actions engagées
  • développer en urgence alors que l'exploit n'a pas de disponibilité pour livrer
  • rédiger des spécifications de nouvelles user stories alors les développeurs sont archi full
  • parler à quelqu'un qui n'est pas disponible pour écouter
  • livrer une application dont l'offre commerciale n'est pas définie
  • continuer de manger alors qu'on n'a plus faim
  • emprunter 10 livres à la bibliothèque alors qu'on a du mal à en lire deux

Lire la suite

Pourquoi votre projet va dans le mur

crash-car.jpg

crash-car.jpg70% des projets sortent en retard ou jamais. Les raisons sont nombreuses. Certaines, comme la difficulté d'estimer, sont difficiles à éliminer. Je voudrais parler de celles qui sont "faciles" à anticiper.

  1. L'équipe n'était pas à 100% dessus
  2. La spec a changé
  3. Nous nous sommes mal compris
  4. L'exploit n'a pas préparé les machines à temps
  5. Les développeurs ont glandé
  6. C'était mal codé
  7. Le tech lead a eu une angine
  8. Le designer était en congés

Lire la suite

Session : abaisser les barrieres en 5 points

agileLogo.png J'ai présenté la session "Abaisser les barrières" à l'Agile France en 2012. agileLogo.png

Les obstacles se suivent et ne ressemblent pas. Pourtant, qu'ils soient techniques, organisationnels ou structurels, chaque solution à ces problèmes dépend des hommes et femmes qui l'actionneront. De la même façon, la meilleure idée du monde ne verra jamais le jour si les équipes n'arrivent pas à travailler ensemble.

L'humain est au centre plus que jamais. Je vous raconterai comment la confiance ne se décrète pas, ainsi que les pistes suivies pour que développeurs, marketing, production, product owners, scrum masters et direction évoluent dans un climat de collaboration plutôt que de défiance. Nous parlerons de one on one, d'ateliers, d'objectif commun, de confiance, de communautés de pratiques, de fun, d'humilité.

Loin d'être des solutions toutes faites, il s'agit plutôt de réflexions et de tentatives (plus ou moins réussies) pour que les équipes travaillent ensemble sur l'essentiel.

Lire la suite

Mon risotto est enfin agile... et bon

Quelque chose d'incroyable est arrivé hier : j'ai réussi un risotto. C'est peut être un détail pour vous mais pour moi ça veut dire beaucoup.

Qu'est ce qu'il s'est passé ? J'ai récolté du feedback plus tôt, tout le long de la cuisson. Tout simplement en goûtant. Ce geste super simple m'a évité le trop salé, le riz pas assez cuit, la sauce écœurante. D'autres éléments m'ont aidé mais s'il faut retenir une seule chose, c'est bien ce feedback.

Lire la suite

Aimez-vous le changement ?

peur-asterix.jpg

peur-asterix.jpgLa gestion du changement est un sujet à part entière dans le management. Pourtant, peu de gens ont conscience d'avoir un problème avec.

Vous pensez être différent ? Ne trouvez-vous pas que M.Dupont dans un autre bureau a souvent des idées farfelues ? Alors que les vôtres relèvent juste du bon sens... Que pensez-vous du nouveau système de classement que votre épouse a trouvé pour vos livres ? Et des décisions de votre N+3 ? Pourtant, sur le fond, en y réfléchissant bien bien, c'est parfois une idée que vous pourriez avoir eu quand vous écoutez ce qui a emmené la personne à lancer ce changement.

Lire la suite

Comment vous estimez-vous ?

Miroir déformant

Miroir déformantLes problèmes de délai sont récurrents dans les projets. La capacité des équipes à effectuer des estimations dépend beaucoup de la connaissance que l'équipe a du projet, ainsi que des technologies impliquées.

D'autres facteurs moins souvent évoqués entrent en jeu : le rapport à l'échec, l'humilité, l'intérêt du challenge et l'estime de soi.

J'aimerais évoquer avec vous ces trois façons si différentes que j'ai rencontré, de prédire ses capacités.

Lire la suite

Les tickets

Poster une lettre

Vu sur twitter :

Demander l'autorisation de faire des tests unitaires, c'est comme demander l'autorisation d'utiliser un débugguer

J'en ai d'autres cette semaine, sur les standards :

Ne pas donner les conditions d'apparition d'un bug, c'est comme envoyer une lettre sans mettre le code postal

Le facteur peut s'en sortir, le développeur aussi, parfois. Perso, je ne compterai pas trop dessus.

Lire la suite

Manager et/ou développer ?

Developer

DeveloperLe développeur d'une autre équipe m'a dit un jour : "Ah non, le scrum master n'est pas censé coder." Il avait l'air vraiment choqué. Je lui ai demandé pourquoi, et il m'a répondu que cela enlèverait de la responsabilité aux équipes. Que c'était intrusif' ? Oui.

Etonnée, je me suis tourné vers les personnes de mon équipe pour avoir leur avis. Elles ont répondu : "Bah... toi, tu veux coder ?"

Paradoxalement, quelques mois auparavant, j'évoquais lors d'un one on one [1] la difficulté que j'avais à récolter du feedback au quotidien. Pour le développeur, je (le scrumMaster) devais être totalement interchangeable avec un autre développeur et pouvoir faire une story de A à Z sans problème. Pour lui, un scrum master code quasiment aussi facilement et régulièrement qu'un développeur.

Lire la suite

Feedback de l'équipe

Feedback

FeedbackJ'ai compris récemment pourquoi j'avais autant aimé mes toutes premières rétrospectives et moins celles d'un autre projet. Plus que l'amélioration continue même, c'est ce qui permet cette dernière d'être qui m'a plu : le feedback.

J'apprends ce qui a saoulé mes coéquipiers, ce qu'ils ont adoré. Que certains commencent à glisser tout doucement. Et vice versa, je peux mieux me lâcher à ce moment là, je sais que j'aurai cette espace. Parce que j'ai cette possibilité, je peux pleinement me consacrer à éteindre le feu quand il y a un problème.

Pendant mes premières, un étrange sentiment de confort m'entourait. Normal, on souffle un peu (nous sommes entre deux itérations) et nous sommes entre nous. Des conditions top pour réfléchir à du moyen/long terme. Du lien se crée. Pour cette raison, j'aime bien inviter des extérieurs quand ils ont été impliqués dans l'itération.

Lire la suite

Agilité et carrière

homme_d_affaires.jpg

homme_d_affaires.jpgAu scrum day, j'ai assisté à deux sessions sur le management dans l'agilité : "De scrum master à coach agile" de Véronique Messager et "Pratiques et difficultés pour les managers d'équipes agiles", une table ronde animée par Damien Thouvenin. Si chaque membre de l'équipe peut déjà tout faire et a déjà des responsabilités, quelles progressions de carrière sont possibles ? Devenir scrum master, devenir indépendant ? Comment rétribuer individuellement un succès collectif ? Comment justifier des écarts de salaire quand nous sommes "tous" des développeurs agiles ? Ce billet compile quelques reflexions à ce sujet.

Lire la suite

Donner des cadres

cadre.jpg

cadre.jpgQuand nous avons un problème, nous cherchons une action qui permettra de le résoudre. Passer par un processus de Plan Do Act Check (PDCA) permet de vérifier que ladite solution est efficace.

  1. Plan : recherche des causes racines possibles et planification
  2. Do : mettre en œuvre
  3. Check : vérifier que l'action résoud bien le problème
  4. Act : Agir, ajuster, réagir (si on a testé à l'étape Do, on déploie lors de la phase Act). En cas d'échec, le processus continue sur le test d'une autre solution. Autrement, la pratique devient un standard et le processus peut se poursuivre sur la résolution d'un autre problème.

Le fait d'en faire un standard a beaucoup d'avantages mais aussi des limites. De temps en temps, une solution convient à un instant T, avec un certain contexte projet (client/équipe) et ne plus du tout être valide quelques mois après. Sans parler du fait qu'il faut du courage pour bousculer ce standard. Résultat : l'équipe se retrouve à maintenir une habitude qui ne lui apporte plus de valeur mais que l'on ne pense pas / ose pas contester. Nous nous retrouvons paradoxalement dans une situation anti-agile. Rajouter des standards se fait plus facilement qu'en supprimer.

Lire la suite

ROI des tests automatiques

dollar.jpg

dollar.jpgL'industrie du logiciel est encore loin d'avoir systématiquement des tests automatiques. Le coût est tout de suite visible et rédhibitoire, contrairement à son gain. Personnellement, j'en fais dans mon développement car il me donne de la confiance et m'aide à construire le produit. Pourtant, certaines personnes restent hermétiques à mon enthousiasme. Entre deux réponses à un appel d'offres, un client lambda privilégiera la plus "compétitive" (= la moins chère), quitte à en payer le prix plus tard.

Les clients les plus sensibles à la cause se demandent jusqu'où il faut aller. Est-ce qu'il faut absolument tout tester? Est-ce que la valeur apportée vaut son coût ? Il y a un pallier où la qualité supplémentaire n'a plus de ROI. Je peux fabriquer des biscuits parfaitement rectangulaires mais il n'est pas dit que ma fille de dix ans apprécie le geste outre mesure. Elle ne s'en rendra probablement même pas compte. Je ne sais pas non plus apprécier un couteau damassé 32 couches avec un manche imputrescible à 350 €. Il n'existe pas de ressources illimitées, qu'il s'agisse de temps ou d'argent. Nous ne souhaitons pas que nos produits soient parfaits à tous les niveaux, car cela couterait trop cher. Alors, où s'arrêter ?

Lire la suite

Des pratiques à reprendre

burndown_avsp.jpg

burndown_avsp.jpgJ'ai une demi heure pour parler de ma dernière mission. J'y ai vu des pratiques excellentes, dont je suis certaine de la valeur, et d'autres qui m'ont plus troublée.

Les pratiques extras

  • Les standards sont le bien. Il y a un tableau avec un post it par standard, construit peu à peu par l'équipe
  • L'auto gestion et le lead par l'équipe. Toutes les décisions sont prises par l'équipe, suite à un vote. Le processus de décision est plus lent et il peut y avoir des clashs mais au final, il y a plus de conviction. Un consensus mou ne permet pas de valider une décision. Par ailleurs, si le client a un lien plus régulier avec le scrum master, c'est à toute l'équipe que les mails sont envoyés et n'importe quel membre de l'équipe répond directement à ses questions. Quasiment tout le monde fait des propositions d'améliorations du coup.
  • Le binomage systématique. Meilleure qualité du produit, moins de rework, plus d'apprentissage et meilleure ambiance.

Lire la suite

Gérer les imprévus

orage.gif

orage.gifEn Scrum, le périmètre des stories engagées est figé une fois que l'itération a commencé. Dans la réalité, il y a toujours des tâches qui surgissent et qui trop critiques pour attendre l'itération suivante avant d'être traités.

En fonction de la place que prennent ces perturbations, les équipes s'organisent au coup par coup. Certaines les intègrent comme une story dans l'itération, d'autres les échangent contre une autre par exemple. Faisons un tour sur quelques pratiques.

Lire la suite

Pour qu'on éteigne notre ordi plus souvent

nuit.jpg

nuit.jpgQuand j'ai commencé à bosser, j'ai été assez choquée de voir qu'un des apprentis laissait son PC allumé tout le temps : la nuit, et même quand il était en congés. Est-ce que notre travail est si urgent ? Un peu moins pire, une autre personne le laissait allumé une fois par semaine, le jour où l'antivirus tournait pour ne pas subir le scan de disque franchement pénible.

Cinq ans plus tard, j'ai intégré une banque, où j'ai découvert la vraie vie : personne n'éteint son PC le soir.

Lire la suite

Suivre les ordres

bon_appetit_grd_mere.png

bon_appetit_grd_mere.pngJ'ai déjeuné chez ma grand-mère dernièrement, et ma mère avait préparé sa spécialité. Miam en perspective?

Hélas non. C'était trop salé par endroit, des morceaux étaient trop durs et les nouilles trop molles. Tout en mangeant un petit plus lentement que d'habitude, je me demandais pourquoi : est-ce que j'étais devenue plus exigeante ? Est-ce que parce que ma mère préparait ce plat souvent, il était devenu inévitable que je tombe de temps en temps sur un échec ? Est-ce qu'elle l'avait baclé car elle était pressée? Est ce que le pot de sel s'est renversé ? Bizarrement, ce jour là, je ne me suis pas resservie.

Quelques jours plus tard, j'ai appris qu'au moment de la préparation, ma grand-mère était derrière elle à lui donner des instructions, pour corriger son plat. Ca l'avait complètement perturbé. Le mélange des deux façons de faire, où ma mère a plus "obéi" aux ordres plutôt qu'écouter son instinct habituel avait été à l'origine de ce plat extra-terrestre.

Lire la suite

Agile France - Atelier d'Esther Derby

Cette année, le programme d'Agile France affichait le nombre de places maximum par session. Vingt-cinq places pour l'atelier d'Esther Derby, auteur éminent de Agile Retrospectives et Behind Closed Doors et membre fondateur de la Scrum Alliance, c'est peu. Je me suis donc précipitée à l'atelier "Lifting the veil : how visible and invisible structures drive organisational behavior". Je ne l'ai pas regretté.

Lire la suite

Agile France - Session d'Esther Derby par Esther Derby

... déjà en ligne ! Si vous faites partie des 20 personnes qui ont du quitter la salle faute de place, vous pouvez vous consoler avec le billet qu'Esther Derby a mis en ligne, avec une photo de l'atelier. Vous verrez que vous pouvez changer les choses avec une approche systémique. Je ferai un retour  […]

Lire la suite

Haut de page