Étiquette : agile

Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis

Le par addinquydans Notes de lectureLaisser un commentaire

Note : 3 ; L’agilité à mi-chemin.

Ce livre est une déception, je n’ai hélas pas d’hésitation à cet égard. Il est vrai que l’on manque souvent sur les projet agile à mesurer des choses alors que la collecte de faits tangibles est la base d’une démarche Lean ! L’origine de cet ouvrage est un système de collecte de mesures pensé et développé par l’auteur et déployé sur les équipes dont il était le manager. Ce système collecte des données depuis Jira, Github, Jenkins, la plateforme de déploiement et Google Analytics, pour ensuite consolider cela. Une idée tout à fait brillante. Malheureusement, comme nous allons le voir, le livre ne parvient pas à valoriser cela.

La structure de l’ouvrage suit en grande partie les 5 grandes « travées » que l’auteur voit dans le développement agile. Il est organisé en 10 chapitres format 3 parties, le tout totalisant 220 pages. A cela il faut ajouter les 2 annexes qui ajoutent près de 20 pages : celles-ci apportent quelques éclaircissements sur la chaine de collecte conçue par l’auteur. La première de ces parties ne compte qu’une trentaine de pages sur deux chapitres. Le premier d’entre-eux « Measuring Agile Performance » dresse sur près de 20 pages un tableau du problème que l’on s’efforce de résoudre. Je ne suis que partiellement d’accord avec l’auteur, par exemple quand il prétend que l’on a pas une vue claire de nombreux concepts comme celui de « bonne qualité » ou qu’il pointe du doigt le focus sur le produit plutôt que sur le projet comme un problème !

Continuer à lire « Note de lecture : Agile Metrics in Action, par Christopher W. H. Davis » →

Rendez-vous à l’Agile Vendée !

Le par addinquydans Compte-renduLaisser un commentaire

C’est toujours un grand plaisir d’assister à la naissance d’un mouvement local de notre communauté agile. En ce mois de Juin, c’est la vendée qui va poser la première pierre de sa communauté.

J’y serais, avec un plaisir d’autant plus grand que l’équipe organisatrice compte des personnes que j’apprécie vraiment beaucoup !

Pour vous inscrire ou vous régaler du programme, c’est ici !

Rendez-vous à l’Agile Vendée !

Taylorisme et travailleurs du savoir

Le par addinquydans Articles1 commentaire

Durant les formations, je me retrouve souvent en situation de devoir expliquer pourquoi (et en quoi) l’agilité est différente des processus classiques, mais pas seulement. Bien sûr on pense au bon vieux « cycle en V », la tarte à la crème des processus non-agiles, mais nous pouvons aussi évoquer les processus itératifs tels qu’Unified Process !

Unified Process est un cas intéressant, voir embarrassant. Certains le classent dans la limite basse des méthodes agiles [4] (après tout, on est loin du cycle en V), d’autres considèrent qu’il ne s’agit définitivement pas d’une approche agile. C’est mon cas. Je trouve par ailleurs intéressant de voir que Ken Schwaber lors de sa première présentation de Scrum en 1995 classait déjà ces approches (pourtant plutôt novatrices à l’époque) en dehors de ce que l’on appelait pas encore les « approches agiles » [1] !

Pour débuter notre reflexion, je vous propose de nous intéresser au modèle Cynefin.

Le modèle Cynefin

Le modèle Cynefin permet de classifier la complexité des contextes en fonction de la nature des relations de causalité entre problème et solution. Je simplifie un peu, pourtant cela doit sembler obscure. Ne vous en faites pas, cela deviendra plus clair lorsque nous expliquerons le modèle. Le voici.

image

Continuer à lire « Taylorisme et travailleurs du savoir » →

Open-Space des pratiques Agiles

Le par addinquydans Compte-renduLaisser un commentaire

Deux mois se sont écoulés depuis notre rendez-vous précédent chez Zenika. Nous voici de retour pour échanger sur les pratiques. Au menu : petit groupe, provisions de bouche en mode collaboratif, et des sujets qui restent à choisir !

SAFe, est plus que LESS ?

Premier sujet autour de SAFe, décidément, l’un des grands sujets du moment. Peut-être du fait de son adoption récente par JC Decaux ?

En dépit des retours très positifs de Lissa Adkins, je reste très dubitatif sur ce framework. Ce retour de formation SAFe correspond plus à l’idée que je m’en fais. Disons que je suis très dubitatif, mais j’entend aussi des choses positives de la part de gens que je respecte…

Yannick lui, voit un indiscutable avantage à SAFe : la possibilité qu’il ouvre de parler aux DSI ! Je suis hélas d’accord avec lui, mais pour une toute autre raison : C’est une sorte de perversion de l’agilité pour la transformer en un processus classique tel que l’apprécie nos vieilles DSI poussiéreuses (vous avez dit RUP ?). Pas étonnant qu’il gagne de l’attention.

image

Continuer à lire « Open-Space des pratiques Agiles » →

Le par addinquydans En images1 commentaire

Ma galerie de photo du Printemps Agile 2014

Je vous avais asséné il y a quelques temps deux posts (ici et ici) sur le Printemps Agile qui s’est déroulé à Caen le 20 Mars. Voici la galerie de toute les photos que j’ai prises durant cette journée. Ce n’est hélas pas la couverture photos dont je suis le plus satisfait, loin s’en faut.

Présentation Marshmallow Challenge (2/2)

Les équipes Marshmallow challenge (1/7)

Les équipes Marshmallow challenge (3/7)

Mon équipe !

printemps agile 2014, un album sur Flickr.

Note de lecture : Deal with It, par Gavin Davies

Le par addinquydans Notes de lectureLaisser un commentaire

Note 6 ; L’attitude avant l’aptitude et l’hygiène de vie du développeur

Ce livre est plutôt un « mini livre » car il ne totalise que 60 pages ! Cet essai se lit donc rapidement, il m’a pris moins de 2 heures. Car non seulement le nombre de pages est compté mais il n’est constitué que d’articles (qui ressemblent plutôt à des blog post qui tiennent tous sur une page, titre compris ! Et encore, on parle là d’une page pas bien grande.

C’est aussi la qualité de cet opuscule car il s’agit là en fait d’une contrainte de taille que s’est donné l’auteur lui-même. Chaque sujet devant alors être exposé avec le maximum d’efficacité. Une sorte de « lean » de l’écriture, si on veut bien.
Intéressons-nous maintenant au contenu. Ce mini-livre est découpé en 5 parties.

La première partie « overall attitude » regroupe 11 essais. L’auteur développe ici les question d’état d’esprit : être courageux, ne pas avoir honte de son ignorance, être curieux et savoir chercher, etc…

La seconde partie « tools, learning et techniques » concerne plus un savoir « tactique pour faire face aux différentes situations. On y parle tests, déploiement et … lire des livres ! Par exemple… Ce sont 13 essais qui forment cette partie

La troisième partie « wisdom for the Long Haul » comporte 7 essais. Il évoque les questions de relations entre personnes et d’hygiène de vie. En fait : comment tenir la distance !

La quatrième partie « communication is key » comporte juste 7 essais. Zut, justement un des essais nous apprend à ne pas utiliser le mot « juste » ! On y évoque la documentation, les emails et les relations entre les managers, mais finalement peu de choses sur les relations entre collègues. Donc c’est un peu décevant.

La cinquième partie « closing advices » ne compte que 5 essais. C’est un peu dans le style « allez en paix ».

L’auteur m’avait prévenu : je ne serais pas d’accord avec tout et ce serait même curieux que je le sois. Cela a bien été le cas, mais j’avoue être en accord avec une grande partie de ses positions. Ce livre s’adresse sans ambiguïté aux développeurs. Et pourtant, l’auteur focalise son propos sur les « savoir être » plutôt que sur les « savoir faire » ! A ce titre, il me rappelle un peu le « pragmatic programmeur » d’Andrew Hunt et Dave Thomas. Rappel justifié, car l’auteur y fait référence vers la fin de son texte.

Au final, il ne s’agit pas d’une lecture indispensable. Elle est juste intéressante : la concision de l’expression de l’auteur et la rapidité avec laquelle on avale le texte sont des plus. Je la classerais en lecture d’agrément en sus de textes plus solides tels que le Pragmatic Programmer suscité, ou encore les Clean Code / Clean Coder de Robert Martin et quelques autres.

image

Référence complète : Deal with It, attitude for coders – Gavin Davies – Leanpub 2012

Deal With It Attitude for Coders

https://www.goodreads.com/book/add_to_books_widget_frame/16190992?atmb_widget%5Bbutton%5D=atmb_widget_1.png

What is Agile ? Par Henrik Kniberg

Le par addinquydans PresentationLaisser un commentaire

Cette présentation de Kniberg est plutôt dédiée à ceux qui veulent découvrir l’agilité : développeurs et managers. Elle répond en terme simple au « pourquoi » et présente l’avènement des approches agiles par le manifeste: ses valeurs, ses principes et les approches logicielles sous-jacentes.

L’auteur présente le cycle agile comme hautement itératif et incrémental. Ce qui est vrai mais un peu réducteur.

C’est ensuite aux questions de planning, d’estimation et de vélocité que s’attaque Kniberg, avec des illustrations ma foi fort bien faites ! Cette partie me semble plutôt destinée aux managers. Elle joue en tout cas un rôle efficace d’introduction au « maximize value, not output ».
Le point suivant me semble clé : donner à l’équipe un problème à résoudre et non une solution à implémenter … ou comment revenir au « start with why » de Simon Sinek ! Cette résolution de problème s’alimente de feedback, qui lui-même permet de maximiser la valeur et de réduire les risques : la cohérence de ce cycle est bien mis en valeur dans cette présentation !

Une équipe agile c’est une équipe pluridisciplinaire, et Kniberg en profite pour rebondir sur le modèle Spotify et la culture « être agile » d’une organisation.

L’agilité ne se limite pas au développement, il va jusqu’à la mise en production, une occasion de mettre en lumière les principe de déliverie continue. En amont, il implique les vrais utilisateurs au jour le jour.

Au niveau de l’organisation, le présentateur expose le « portfolio level Kanban », qui n’est pas sans rappeler les éléments développés dans Lean From the Trenches.

En conclusion : il y a un prix à payer à la mise en place de l’agilité (organisation, environnement, etc.) et « big is bad », aussi bien pour les projets, les fonctionnalités, les cycles ou les équipes !

Open Space Agile de Mai

Le par addinquydans Compte-renduLaisser un commentaire

Yannick Ameur nous avait déjà convié à un open-space en Février dernier, sous la houlette de l’association Agile France. C’est en comité plus restreint que nous nous sommes retrouvés cette fois-ci. Réunis sous de bonnes auspices je dois dire : le buffet a été monté un peu au dernier moment en mode auto-organisé … et a remarquablement bien marché !

Au départ prévu sur 3 slots et 3 salles, nous nous sommes finalement restreints à 2 slots et 2 salles, avec un agile game pour terminer.

image

Transition vers la gestion de projet agile

Je me suis décidé vers ce sujet type « grand classique » pour ce premier slot. Avec des questions il faut bien le dire, assez récurrentes :

  • Par quoi commencer ?
  • Que faire si l’on rencontre de la résistance ?
image

Ici nous avons concrètement le cas d’un chef de projet faisant de la résistance active… mais aussi sur le départ. Oui, une transition réussie passe assez souvent par le changement d’un certain nombre de têtes. Comme l’évoque le Host Leadership (http://hostleadership.com/) : le passage à l’agilité est une invitation ; ne vous y rendez pas si vous n’avez pas l’intention d’en respecter les règles.

Le passage d’un projet à l’agilité pose aussi la question du fond et de le forme: il est assez tentant de se focaliser sur le décorum agile (les cérémonies, les post-it, etc…), mais plus difficile et pourtant plus important de porter l’attention sur le « mind set » agile: auto-organisation, amélioration continue, etc.

Lean vs Agile

Yannick nous a proposé ce sujet, suite à la discussion que j’avais eu la veille à la ScrumBeer avec David et Margerie !

image
  • Lean est-il complémentaire d’Agile et vice-versa ?
  • Qu’est-ce qui caractérise chacune des approche, ou les rend convergente ?

Tout d’abord il semble difficile à tout le monde de définir le Lean. C’est probablement l’une des raisons qui permet à de grands cabinets de déployer ce qu’ils prétendent être du Lean et s’avère extrêmement destructif sur le plan humain !

Nous avons demandé à Christophe Keromen, l’un des co-auteur du Petit guide de management Lean à l’usage des équipes agiles ce qu’il en pensait. Le point le plus important est pour lui :

  • L’emphase, dans le lean, sur l’amélioration continue, via le cycle PDCA et bien sûr certains outils (Kaisen, Kata, A3, etc.)
  • L’accent mis dans l’agile sur le facteur humain.

Enfin, quand on parle de Lean, il ne faut pas confondre celui-ci avec le Lean Software Development ou même avec le Lean Startup … des choses bien différentes !

Et quand on parle de convergences, on parle souvent d’emprunts de techniques Lean, comme le Kaban. Yannick lui, remarque l’utilité de s’inspirer de l’approche scientifique du Lean : mesurer la réalité et focaliser la résolution de problème par rapport à ses mesures.

Christophe nous affirme que « le lean n’a pas besoin de l’agile ». Il est certain que les deux courants vivent leur vie, bien que l’agile n’hésites pas à emprunter des pratqiues à droite et à gauche. Mais cette petite phrase me conforte sur ma perception un peu snob des praticiens du Lean, qui se voient parfois comme l’aristocratie de l’agilité…

Débrief et fin

Nous étions un peu pris au dépourvu par ces 10 minutes de débrief, mais les animateurs des sessions se sont quand même prêtés au jeu.

image

J’ai peu prétexter de ma foulure au poignet pour échapper au « SOS Titanic ». Je l’avais par ailleurs expérimenté à Agile Games France. Les joueurs n’ont pas été courronés de succès ici, en partie à cause de la pression du temps lors de cette animation. La limite de temps est peut-être nécessaire, mais si elle est trop forte, on perd l’intérêt du jeu !

image

Par ailleurs Dov a tranquilement viré la moitié des occupants du canot pour « sauver » quelques uns de ses occupants. Une manière inédite d’arriver à ses fins…

Enfin, ami lecteur, si tu te décides à animer ce jeu penses au moins à deux choses :

  • On ne brave pas l’eau froide et les requins en même temps. En tout cas, les requins eux ne bravent pas l’eau froide.
  • On ne peut pas mourir de froid et de faim. Il faut choisir…

Prochaines étapes: la soirée du FKUG et Agile France !