Coaching Agile

Agile, Scrum et autres pensées
Laurent Carbonnaux

Le 1er FailChat n'a pas échoué




Le premier FailChat en France s'est déroulé le 12 Juin dans les locaux d'ekito.

Pas moins de 30 personnes ont participé à l'échange avec les 5 startupers présents.

Marie Messina, Antoine Girard, Sylvain Wallez, Emmanuelle Parache et Rodolphe Vialles ont partagé dans un cadre intimiste et une ambiance conviviale leur histoire. 


De l'acte entrepreneurial à l'histoire personnelle. De la difficulté de licencier, des rencontres engageantes, pourquoi trop d'argent tue la créativité, de l'échec permettant de trouver son modèle économique, de la levée de fond qui n'est pas une fatalité et même de l'art contemporain.
Ce premier épisode FailChat n'a pas échoué!

Suivez cet événement et les suivants sur toulouse.theFailCon.com


Dette Technique : la poule aux oeufs d'or


From blog.crisp.se
Je viens juste de lire un article d'Henrik Kniberg sur la dette technique datant de Juillet 2013.


Dans les commentaires, George, un internaute rappelle à Henrik les conditions de pression dans lesquelles les développeurs sont au quotidien.
Henrik lui répond que dans le "monde réel" qu'il voit, les compagnies s'engouffrant dans la dette technique vont de moins en moins vite, perdent des développeurs, et finissent par regretter leur manque de discernement qui rend de plus en plus coûteuse la correction des anomalies à posteriori.

Il synthétise en disant que ne pas s'occuper de la qualité du code est un investissement court terme, bien que les compagnies cherchent à vivre longtemps.

C'est sur ce dernier point que je souhaite apporter mon point de vue.
"Les compagnies cherchent à vivre longtemps"
Oui, toutes, les compagnies clientes et les SSII! *

Hors pour que les SSII vivent longtemps, il faut qu'elles aient du travail pour longtemps. Vous voyez où je veux en venir.

Les SSI sont facturées à la journée, à la charge consommée ou  vendue  (au forfait ou en régie peu importe). Le développement des applications est découpé en projet de développement puis en projets de maintenance (Tierce Maintenance Applicative). Quel intérêt pour une SSII de faire que le produit qu'elle fournit soit trop exempt d'anomalies, que la dette ne soit pas trop réduite? De toute façon le client fera appel à elle (ou une autre, juste un échange entre SSII du marché) pour une TMA, et au final repayer pour corriger des bugs non vus avant et pour lesquels ils ont en plus déjà payé de la garantie souvent.

Même chez les clients. J'ai entendu chez un de mes clients, il y a fort longtemps, que le coût des tests automatisés, par exemple, étaient trop élevés pour le projet de développement et que ce n'était pas grave que ça coûte cher pour la maintenance, "ce sera un autre budget pour le département d'à côté". Là aussi problématique lié au découpage budgétaire et du cycle dev+maintenance.

Pour qu'une société vive longtemps, c'est sur la valeur qu'il faut se focaliser, le ratio valeur/coût.
Vérifier que vos équipes ou vos prestataires puissent vous garantir le maintien de l'apport de valeur au même coût et ce sur le long terme.
Et opter pour une vision produit, tout au long de la vie de celui-ci, de façon itérative et essayant sans cesse d'améliorer le coup suivant.
Comment va-elle traiter la dette technique? pas en balayant la poussière sous le tapis.

 Là aussi faut des tripes. SWCC ™

 (*) j'ai vu dans un article aujourd'hui qu'il fallait maintenant appeler les SSII les SSN, Société de Services en Numérique, bon.


Le manifeste Agile, une autre façon de le lire

Le manifeste Agile, vous connaissez!

Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan



le A plus que le B, le A prime sur le B, 

Je vous propose une autre lecture simple, et me semblant moins dogmatique:

Si vous avez un problème avec B, essayer de le corriger avec A

Par exemple, et ce n'en est qu'un:

Si vous avez un problème dans votre process ou avec vos outils, demander aux personnes l'utilisant de le résoudre ensemble.
Si votre documentation n'est pas à jour, regardez votre applications
Si vous ne tenez pas les délais ou les coûts, ne mélangez pas contractuel et opérationnel, essayer de laisser ça aux juristes et mettez vous autour d'un table avec votre client pour trouver une solution pratique
Si vous passez votre temps à remettre à jour le planning, essayer de prioriser votre backlog et jouer sur des itérations courtes.

Le Cochon Perdu : Artiste et spécifieur light

J'adore le jeu Artistes et Spécifieurs.
Il permet de démontrer, entre autre, l’intérêt de la communication directe dans les échanges entre intervenants d'un projet. Pour plus d'info sur le jeu, allez voir du côté d' Alex et Thierry.


Ce jeu est excellent lorsque l'on a le temps.




J'ai donc essayé d'en faire une version allégée pour pouvoir jouer le concept rapidement.
De concentrer l'objectif sur le côté téléphone arabe et montrer du doit les problèmes de compréhension, d'interprétation et de retranscription d'une personne à l'autre d'un besoin jusqu'à sa réalisation.
J'alterne le texte et le dessin pour simuler et accentuer le changement de mode d'expression. Finalement, comme entre les différents niveaux de spécifications informatiques.

Le déroulement est assez simple:
 - Avant le départ, j'ai écrit un texte descriptif (la spec du besoin) d'une scène que j'avais imaginée (le besoin)
 - Je demande à mon voisin de lire ce descriptif et de le dessiner, en 1 minute
 - Puis de donner le dessin à son voisin pour qu'il écrive ce qu'il voit, en 1 minute
 - Puis de donner ce qu'il a écrit à son voisin pour qu'il le dessine, en 1 minute
 - Et ainsi de suite...

Les personnes n'ont pas le droit de se parler! Eh oui forcément, comme dans un bon vrai projet quoi.

Je l'ai joué aujourd'hui à la maison et voilà ce que cela donne.

La spec:

Puis ma fille a dessiné ça:

Puis mon fils ça:

Puis une amie a fini avec ça:


L'idée que j'avais à l'origine était celle-là:



Et nous n'étions que 4 à jouer ;-)
Dommage que je n'avais pas de collègues offshores sous la main!
On s'est bien marré!

Agile ne veut pas (que) dire vite



Souvent les méthodes Agile sont utilisées (ou vendues!) pour délivrer rapidement, souvent, un produit ou un service.




Certaines conditions ne nécessitent pas ce besoin de vitesse. La recherche par exemple. Dans ce cadre, la vitesse peut aller à l'encontre du temps nécessaire à la réflexion.

Si la vitesse n'est pas un but visé, le monde de la recherche peut tout de même grandement profiter des autres aspects de l'agilité  :
 - Boucles d'expérimentation : itérations
 - Organisation collaborative : scrum teams
 - Fédération autour d'objectifs communs : vision, roadmap, releases, backlog
 - Transparence, synchronisation, échanges: cérémonies agiles
 - Visuels de pilotage : kanban, task board, impediment board

Bref, on peut être agile lentement!

PS : Bon pour l'image, c'était facile, désolé

Premier pas chez ekito



Je relaye ici mon premier billet chez ekito, "Petit Agilou et les flocons".




Pour ceux qui ne le savent pas encore, je viens de rejoindre la société ekito, depuis ce début de semaine.
Ekito est une société Toulousaine, basée sur des principes équitables et participatifs :
"La force du modèle ekito est de considérer l’équité et l’approche collective comme sources de valeur durables."

J'y apporte mon expérience en conduite de transformation Lean et Agile de grands comptes. Je vais mixer cette expérience avec celle de Nicolas Deverge et Laurent Meurisse sur le Lean Start-up. Ce mixage devrait fortement profiter à nos clients en cours et futurs je l’espère.

Ma première contribution fut un atelier d'élaboration de backlog, à l'aide d'un story mapping pour définir un outil de story boarding, notez l'idée! Fallait pas se mélanger les pinceaux.

A+ pour la suite





Agile Tour Clermont Ferrand, 12 dec 2013


La seconde édition de L'Agile Tour Clermont-Ferrand aura bien lieu cette année encore

Date

Le 12 décembre 2013 au Centre Diocésain de Clermont-Ferrand 
L'équipe de l'A-Cube est en cours de préparation de cette session 

Organisateurs

  • Pierrick Revol
  • Laurent Carbonnaux
  • Sébastien Favier
  • Laurent Dutheil
  • Marie-Laure Momplot
  • Françoise Constanty

Appel à Orateur

Vous désirez proposer une session, c'est par ici : Formulaire

Appel à Sponsors

Contact sponsors : a-cube-association@googlegroups.com
Télécharger l'offre de sponsoring