Quelques lectures récentes (2013)
Un petit moment que je n’avais pas fait de fiche de lecture, pourtant 2013 me semble une bonne année de lecture. La plupart de ces lectures sont en relation avec la keynote “la horde agile” que j’ai présenté à plusieurs Agile Tour cette année. Ces lectures m’ont porté jusqu’à ce sujet. Beaucoup de mes réflexions sont en relation avec le cerveau droit, l’émotion, notre culture, ce que nous sommes. Si quelqu’un à des références ou des suggestions, je suis très preneur.
Le code, le berceau de l'agilité
Beaucoup pensent que je n’aime pas le code ou les codeurs. Pas du tout. Grossière erreur. (au passage j’en fus un). Laissons ces gens s’exciter, et continuons sur le code. Oui le code ce n’est pas l’agile. On applique la culture agile dans des environnements où le code est essentiel. On pratique autour du code en rapport avec la culture agile. Mais si le code n’est pas l’agile, il en est le berceau et ce n’est pas une surprise.
La horde agile - les slides
Vous trouverez ci-joint les slides de la horde agile, session présentée récemment en keynote à l’Agile Tour Marseille, à l’Agile Tour Toulouse, et très bientôt à l’Agile Tour Montpellier. Les slides n’ont que peu d’intérêt en eux mêmes si ce n’est pour la liste de références en fin. Pour cela les voici. Pour préparer cette horde agile je me suis mis à travailler sur un texte (20-40 pages). Dès la fin de ce mois d’octobre je l’achèverai et le publierai.
Deux amis
A l’initiative de notre petite association : convergenc.es, Oana et moi-même avons profité de la venue de Dan Mezick au Scrum Gathering Paris pour lui proposer deux interventions supplémentaires à Paris et Montpellier sous la forme d’ateliers de demi-journées. Ceci n’a été possible que grâce à l’aide et la gentillesse de Dan Mezick, qui a bien voulu s’adapter à toutes nos contraintes. Sa présence était obligatoire pour la bonne marche des ateliers comme il le dirait lui-même, la notre restait optionnelle.
Entretien d'embauche agile
Hier suite à une conversation avec un copain qui est aussi un client et qui souhaite “embaucher agile”, une idée m’est venue, du genre “mais oui évidemment”. Je lui ai suggéré d’utiliser la scierie à pratiques pour connaître le positionnement, la lecture, l’approche, et la sensibilité agile de ses postulants. Mise en oeuvre Il faut proposer les cartes “pratiques” au candidat et lui laisser cinq minutes (ou plus) pour en extraire six qui lui paraissent les plus importantes.
Rentrée 2013, pourquoi j'ai mangé mon pair ?
En octobre j’aurais le plaisir de venir vous parler de la horde agile, que j’avais commencé à évoquer ici et qui a manifestement bien plus aux Agile Tour auxquels j’ai envoyé ma candidature puisqu’ils m’ont conviés, tous les trois, à vous proposer cette réflexion personnelle en tant que keynote (session plénière d’ouverture). Sachez que je suis touché, flatté et stressé à ce sujet. Pitch Qu’est ce qui fait de l’homme, l’homme ?
Affectation des tâches dans un projet scrum
Rapidement, une bafouille sur l’affectation des tâches dans une équipe Scrum. J’observe trop souvent des tâches avec des noms dessus. C’est une mauvaise pratique (dans ma compréhension et proposition concernant Scrum). Une équipe de dev Scrum (ne pas limiter “dev” à production de code, mais à développeur de tout ce qui est utile pour parvenir à “fini”), donc une équipe de dev Scrum est auto-organisée. Il faut l’appréhender comme un système global, comme un collectif.
Documentation agile
Non non non ! Je ne relance pas la discussion sur ce mythe selon lequel il n’y a pas de doc en agile. Je vous fait part d’un feedback de l’un des “technical writer” avec lequel j’ai pu travailler de long mois et avec plaisir (Christopher Nelmes pour ne pas le citer). Comme nous allions répandre la bonne parole auprès des autres “technical writer” (comment le traduire ? -un comble- les gens qui font la doc quoi), je lui ai demandé voilà deux ans un petit retour sur ses impressions et comment aborder l’agilité quand on est uniquement (et c’est beaucoup) responsable de la documentation (end user, utilisateur final).
Appelez cela comme vous voulez
J’entends beaucoup ces temps-ci : “l’agile c’est fini, c’est mort”, et je suis curieux : le monde serait-il devenu beaucoup plus prédictible durant mes vacances ? Aurait-on trouvé le moyen d’innover sans autoriser le droit à l’échec ? Serait-il finalement possible d’optimiser nos travaux avec des gens très malheureux ? Naturellement non. C’est juste que comme souvent on a apposé le mot “agile” sur une équipe, un département, etc sans vraiment prendre deux choses en compte.
Scrum 2013, le canevas
Dans le TGV, 3 heures devant moi avec la clim’, j’enfourne Roxy & Elsewhere de Frank Zappa dans les oreilles et je me lance dans une lecture du Scrum Guide nouveau (celui qui vient de sortir en juillet 2013). Avant de démarrer il me parait clair que si Ken Schwaber & Jeff Sutherland sont les créateurs de Scrum, ils ne maitrisent plus vraiment la créature. Le nom leur appartient, la consolidation du “toolkit” sous cette appelation aussi, les concepts et les idées derrière ont été libérées au délà de leurs espérances et hors de leur réelle emprise.