Java Bien!

In Agile, there’s a never ending debate between the “Keep track of your estimates, compare them to actuals, use the deviaiton to improve your future estimates” family and the “DON’T track actuals” family.

I’m feel much more in the “don’t do it” family, however, as a coach or Scrum Master, my approach is :

“Do what you feel is the right thing. If you choose to keep track of the actual vs original estimates, do it well. If after a few iterations, I realize that you don’t use this data to improve the estimates, I’ll remind you to at least try. Then you’ll tell me if this improved anything and is worth the time spent.”

60% of the teams decide not to track the actuals, 20% don’t track the actuals in a usable way, 19% don’t use actuals during the planning meeting, 1% find it useful.

What is your experience ?

…ou plutôt à l’Université du SI les 2 et 3 juillet 2008 à Paris.

OCTO Technology organise les 2 et 3 juillet 2008 un séminaire à l’attention “des geeks et des boss” du Système d’Information, sous le nom “Université du SI“.

J’aurais le plaisir d’animer une présentation : Le facilitateur. Un rôle encore méconnu”

Si les DSI ont la culture de l’audit, peu s’appuient sur un facilitateur. L’auditeur pose des questions, en tire des constats et propose des améliorations. Le facilitateur, lui, s’assure que les équipes prennent des décisions de groupe, en explorant ensemble les problèmes, leurs causes et les actions correctives.

Le facilitateur met en place un cadre propice à la communication, s’assure que les impacts de chaque option seront explorés et que des décisions seront prises. Il est tantôt animateur, tantôt modérateur, il est à l’écoute et cherche à faire sortir des idées qui n’auraient pu émerger individuellement.

Un exemple de facilitation est apporté par la méthode Scrum. Au sein d’un projet, le Scrum Master s’assure que l’équipe est de plus en plus performante. La pratique mise en place est la “rétrospective d’équipe” qui permet d’améliorer le travail collectif, de résoudre les conflits et de mettre en place de nouvelles pratiques.
Nous explorerons un panel de techniques : Analyse “Plus/Delta”, “Is/Is Not”, “Timeline Mad/Sad/Glad”. Nous verrons que ces mêmes pratiques peuvent être utilisées pour rendre un classique audit plus efficace.

Au delà de Scrum, le facilitateur utilise des outils comme les brainstormings, les jeux de rôle ou encore les formations. Nous aborderons le principe du Forum Ouvert à travers un retour d’expérience de forum regroupant 200 personnes et qui permit de mettre en oeuvre des techniques comme le “dot-voting” ou le brainstorming avec des cartes hexagonales. Nous verrons que ces mêmes pratiques peuvent être utilisées lors d’un steering commity pour s’assurer que choix business et contraintes terrain sont alignées.

Par sa créativité et son expertise, le facilitateur pousse une organisation à être plus innovante et plus efficace. Il travaille autant avec les “boss” qu’avec les “geeks” et s’assure souvent que les “boss” et les “geeks” se parlent et se comprennent.

J’espère vous retrouver nombreux à cette occasion !

Presque un an que je donne des formations Scrum pour le compte de Valtech Training. Chaque formation, je tente d’améliorer le contenu et la forme afin que les stagiaires puissent mettre en oeuvre dès le lendemain.

Doux rêve du formateur…

Il est clair que deux jours de formation, en dehors de tout contexte projet, ne remplacent pas l’apprentissage, à la dure, sur le terrain. Toutefois, si l’on compare une équipe qui a suivi la formation, à une équipe qui a pris connaissance de Scrum “Just In Time”, l’impact positif de la formation est flagrant.

A condition de passer “les” bons messages. Ou plutôt les messages qui, avec toute ma subjectivité, doivent faire partie de la mallette qu’un stagiaire ramène dans la vraie vie.

Laissez moi partager quelques messages avec vous (les critiques sont les bienvenues) :

1/ Mettre en place Scrum, c’est tenter l’aventure de l’amélioration continue. Sprint après Sprint l’équipe sera plus performante. A une condition : viser haut, être idéaliste.
Je m’explique : Scrum offre un cadre méthodologique difficile à adapter totalement à nos organisations sédimentarisées. Pourtant, l’important est de viser continuellement ce cadre idéal plutôt que de vite s’arrêter en cours de chemin à une mise en oeuvre partielle de Scrum. Le risque est de mettre en place le plus facile et de laisser tomber le plus important.

Je constate par exemple que la rétrospective est souvent vite abandonnée. J’insiste donc en formation sur le fait que si l’on doit ne garder qu’un principe, cela doit être “Inspect and Adapt”, donc les rétrospectives. La dernière heure de la formation prend d’ailleurs la forme d’une rétrospective.

2/ La complexité de la plupart des projets de développement logiciel n’est pas technique. Les problèmes viennent de notre incapacité à travailler de ensemble dans un but commun. Les compromis et les consensus sont pénibles et la transparence de Scrum ne pardonne pas les erreurs individuelles. Il faut transcender cet état de fait si l’on veut s’améliorer. Cela ne se fait pas sans douleur et le binômage, par exemple, est un choc pour presque tout le monde.

En formation, les exercices démontrent que la collaboration en timebox est ultra efficace. L’excellence individuelle est la bienvenue au service d’une équipe.

Je viens de démarrer un nouveau projet en tant que Scrum Master. Je me trouve au sein d’une équipe éditique. Nous devons produire une batteries de documents destinés à des clients (courriers, contrats, …). La qualité des documents est notre préoccupation première.

Pour valider le contenu et la forme de nos documetns, Scrum va nous permettre de vite avoir du feedback. Par contre, il existe de nombreuses règles à respecter pour qu’un document soit complet et satisfaisant. Par exemple, nous sommes limités à une liste de polices et à certaines couleurs. Nous devons vérifier que les blocs de texte ne se chevauchent pas dans des cas limites. Les marques de pliage et les adresses postales doivent être positionnées très précisément… Dans ce domaine, il n’est pas certain qu’un oeil humain puisse nous aider. Plus le nombre de règles est important, plus difficile il sera de valider un document.

Mes réflexes de développeur Java me poussent à chercher des outils de tests automatisés. Un peu comme un checkstyle permet de vérifier le respect de quelques normes de codage, il faudrait un outil capable de décortiquer un document pdf et à même de vérifier certaines règles communes à tous les documents.

Mes recherches sur Google n’ont rien donné pour l’instant. Il semble exister un marché pour les outils vérifiant si un pdf respecte les normes d’accessibilité mais rien pour le domaine éditique pur. On doit se contenter d’un outil qui prend un fichier xml en entrée, lance la génération de pdf et compare avec un document cible. Cela permet juste d’évacuer la plupart des régressions.

Si l’on parvient à lire le contenu d’un pdf en Java (peut-être avec iText), il est théoriquement possible de coder certaines de ces règles, mais cela reste complexe.

 Avez-vous des expériences similaires ou de idées à me soumettre ?