équipe

L'équipe PermaBio

L'équipe PermaBio

PermaBio est l’exemple qui sert de fil rouge dans L’art de devenir une équipe agile. Dans le premier chapitre, nous avions fait connaissance avec Pierre, le fondateur, qui nous avait donné sa vision, décrit le service et expliqué pourquoi l’agilité lui semblait la bonne approche. Nous allons maintenant faire connaissance avec cette équipe. Cet extrait se trouve pages 54 et 55, à la fin du deuxième chapitre, L’équipe dans son écosystème.

Agile Book Klub

Esprit d'équipe, es-tu là

Avec Anthony Cassaigne et Jean-Pascal Boignard, nous discutions du prochain klub de lecture, prévu début avril, qui allait se faire à distance à cause du confinement. C’est alors que nous est venue l’idée de proposer une formule adaptée au contexte actuel. En pensant aux agilistes confiné·es, nous nous sommes dit qu’ils ou elles pourraient prendre du plaisir à échanger, à côté de leur télétravail ou pendant leur chômage technique. Toujours une discussion sur de la lecture à propos de l’agilité, mais :
Nouveau livre !

Nouveau livre !

Nouveau et intéressant !

Cela fait presque 5 mois que je n’ai pas publié de billet. C’est ma plus longue période de silence depuis que j’ai commencé ce blog, voilà bientôt 13 ans. C’est que j’étais focalisé sur l’écriture d’un nouveau livre. Pas une nouvelle édition de Scrum, un nouveau livre ! Focalisation, c’est d’ailleurs un mot souvent utilisé dans ce livre, à propos de l’équipe en devenir agile.
Nouveau livre !

Nouveau livre !

Cela fait presque 5 mois que je n’ai pas publié de billet. C’est ma plus longue période de silence depuis que j’ai commencé ce blog, voilà bientôt 13 ans. C’est que j’étais focalisé sur l’écriture d’un nouveau livre. Pas une nouvelle édition de Scrum, un nouveau livre : Focalisation, c’est d’ailleurs un mot souvent utilisé dans ce livre, à propos de l’équipe en devenir agile.

Scrum, agilité & lecture

L’édition 5 de mon livre Scrum est sortie le 18 mai. Elle démarre aussi bien que la 4e (et mieux que les précédentes). Nous avons atteint les 1000 exemplaires vendus dès fin juillet. Écrire ça demande beaucoup d’efforts, mais une fois que c’est sorti c’est que du bonheur de voir qu’il y a des lecteurs. Et c’est un plaisir de partager avec quelques uns (j’assure le service après vente). En juillet, pour ne pas perdre la main, j’ai écrit un article pour Capterra : Agile ?
Collecter et stocker l'énergie

Collecter et stocker l'énergie

Faites les foins tant qu'il fait beau

On continue dans la permaculture et l’agilité, pour se préparer à la soirée du 21 mars. Aujourd’hui le 2e principe de la permaculture. Principe 2 : collecter et stocker l’énergie C’est un principe qui, à première vue, est éloigné de l’agilité. Quand on développe avec Scrum, on ne se préoccupe pas de collecter et stocker l’énergie. L’idée développée par David Holmgren est de collecter des énergies locales plutôt que de continuer à prélever des ressources à un niveau qui n’est plus soutenable.
TAPIS pour l'équipe Scrum

TAPIS pour l'équipe Scrum

Une équipe agile est TAPIS

Après le backlog PROUVÉ et DÉCOMPOSE la story, j’ai trouvé l’acronyme facile pour caractériser une équipe Scrum : T comme de bonne Taille (de 3 à 9 membres, avec une préférence de 5 à 7), A comme Auto-organisée (pas de chef), P comme Pluridisciplinaire (elle couvre, collectivement, toutes les disciplines requises pour procurer de la valeur), I comme possédant une Identité (il existe un sentiment d’appartenance de chacun·e à l’équipe), S comme Stable (les membres de l’équipe restent ensemble longtemps).

Bénéfices d'avoir des équipes pluridisciplinaires et autonomes

Un point essentiel pour éviter des dérives (du genre scrotum par ratatinement) est que les équipes soient réellement pluridisciplinaires et autonomes. Dans l’édition 4 de mon livre, j’ai ajouté le chapitre trois “Les gens de Scrum” pour mettre l’accent sur ce point fondamental de l’équipe. C’est encore plus important quand il y a plusieurs équipes dans une organisation. Voici les bénéfices qu’on peut en retirer : Meilleure compréhension des besoins des utilisateurs Avec une organisation en silos (par exemple commerce, marketing, technique, test, infra), la boucle de feedback est forcément longue et peu fiable, car chacun cherche son optimisation locale ce qui pousse à déformer les retours.

La quintessence de la passe

La semaine dernière, à la fin de ma keynote Scrum ? mon scrotum ! pour Agile Pays Basque, j’ai fait deviner un mot. J’ai donné 2 citations de Daniel Herrero, le chantre du rugby : Derrière une apparente simplicité, la passe cache le mystère des arts du lien. et …la passe est la quintessence du jeu collectif, un acte de vie. Ces deux belles citations sont extraites du Dictionnaire Amoureux du Rugby, qu’un ami bienveillant m’a gentiment offert.
Les experts, des parties prenantes qui aident l'équipe Scrum

Les experts, des parties prenantes qui aident l'équipe Scrum

Scrum étant construit sur la notion d’équipe, il est important de savoir qui est dedans et qui est dehors. On distingue ainsi les membres de l’équipe (PO, SM et DEV) des parties prenantes (PP). Dans un cadre idéal, l’équipe est pluridisciplinaire. Cependant, elle l’est rarement complétement. Apparaît alors un autre rôle, celui d’expert. Je le définis ainsi dans le glossaire de la 4e édition de mon livre : Un expert est une personne, à l’extérieur de l’équipe, qui possède des compétences nécessaires à l’équipe pour réaliser un travail d’un sprint.

Glossaire E-F

L’édition 4 de mon livre comporte, et c’est nouveau, un glossaire. Voici les entrées pour E et F : Epic ou story épique : story dont l’équipe considère qu’elle est trop grosse pour rentrer dans un sprint en l’état. Équipe auto-organisée : équipe qui possède le pouvoir de décider comment faire le travail. Équipe pluridisciplinaire : équipe qui possède, collectivement, toutes les compétences requises pour développer le produit. Équipe Scrum : groupe de gens auto-organisé et pluridisciplinaire qui réalise un incrément de produit à chaque sprint.
Le changement dans la stabilité

Le changement dans la stabilité

L’agilité accueille favorablement le changement. Les clients peuvent changer d’avis et la technologie évoluer. Mais l’équipe, elle ne doit pas changer pour être capable de prendre cela en compte. C’est grâce à sa stabilité qu’une équipe peut s’adapter à la situation et traiter les changements. Une équipe en recherche de stabilité (dessin de Patrice Courtiade pour #scrum4) Je constate que ce n’est pas le cas dans de nombreuses organisations. Indépendamment de la mise en place de Scrum et généralement bien avant, s’est développée une idée de l’agilité qui n’est que de la flexibilité imposée.

Co-localisation des équipes Scrum

Voici le résultat du sondage, auquel plus de 100 personnes ont répondu. La question était : “Votre équipe Scrum est ?", avec 5 réponses possibles. co-localisée : 46.73 % dans des bureaux proches : 10.28 % avec 1 ou 2 dév. en remote : 10.28 % dispersée, mais avec une culture commune : 10.28 % dispersée, sur plusieurs pays de culture différente : 22.43 % Ceux qui ont sélectionné la dernière réponse doivent avoir beaucoup de mal à bien pratiquer Scrum, à mon avis.

Le rythme dans Scrum, au service de la collaboration

Le rythme régulier des sprints est la base de Scrum. A quoi sert-il ? Plus largement, le rythme fonctionne selon 3 cycles dans Scrum : celui du scrum quotidien, tous les jours donc, celui du sprint, selon sa durée, celui de la release, si elle est aussi cadencée avec une durée constante. La réunion quotidienne sert à définir les points de synchronisation nécessaires dans la journée entre les membres de l’équipe.
Chapitre huit

Chapitre huit

Dans la série Suppléments en ligne à mon livre Scrum, voici le scrum quotidien, qui constitue le chapitre 8. On dit aussi “daily scrum” ou “standup”. Structure du chapitre Voici le plan de ce chapitre sur le scrum quotidien (clic pour agrandir). Scrum quotidien, le plan #### Le but du scrum quotidien Cette fois je ne mets pas le résumé de fin de chapitre, mais l’objectif de cette pratique, présenté page 116 :

Chapitre quatre

Dans la série Suppléments en ligne, voici ceux du chapitre “Le ScrumMaster et l’équipe”. Pendant les vacances, j’ai commencé une série de billets visant à apporter des informations additionnelles aux lecteurs de mon livre Scrum. Après le premier chapitre, le chapitre deux, le chapitre trois, voici le chapitre quatre. Ce chapitre a failli être divisé en deux, un pour le ScrumMaster et le deuxième pour l’équipe. En 2010, je m’étais d’abord dit que je parlais de l’équipe dans tout le livre et qu’il n’était pas nécessaire d’en faire un chapitre dédié.
Enquête sur la taille des équipes Scrum

Enquête sur la taille des équipes Scrum

Près de la moitié des équipes ont la taille idéale et près de 3 sur 4 sont dans la fourchette recommandée. Résultats Merci aux 139 participants. Les tailles de vos équipes Scrum, y compris le PO et le SM : de 1 à 3 personnes : 10.79 % de 4 à 6 personnes : 47.48 % de 7 à 9 : 30.94 % 10 et plus : 8.63 % ça dépend des sprints : 2.

Rugby, Scrum et Agilité

Patrice Lagisquet à l’Agile tour Toulouse mercredi prochain. Ma toute première présentation de Scrum dans une conférence, s’appelait : “Scrum, l’esprit d’équipe comme au rugby”. C’était avant même que je commence ce blog, il y a presque 6 ans -une éternité- dans le cadre des premiers Valtech Days. Je me souviens que j’étais très content de placer le rugby dans une présentation sur le développement de logiciel. Je pense que le fait que Scrum soit associé au rugby m’a poussé à m’y intéresser.
Scrum avec plusieurs équipes

Scrum avec plusieurs équipes

Vous avez plusieurs équipes qui font du Scrum et vous voulez garder une vue générale, plutôt que d’avoir des projets séparés. Voilà une façon simple de faire du “scrum de scrums”. Equipes et Features Constituez les équipes et associez à chacune une couleur. Identifiez les features, éventuellement à partir d’une vision. Rangez-les par priorité. Montrez quelle équipe va réaliser la feature en lui donnant sa couleur. Le “backlog” de features donne un aperçu du partage entre les équipes à haut niveau :

Historique d'iceScrum

Une nouvelle version d’iceScrum va bientôt être diffusée, avec une pré-release en août. L’équipe actuelle, portée par iceScrum Technologies, a réécrit toute l’application à l’occasion du changement sur la plateforme de développement agile Grails. Je profite de ce changement majeur pour revenir sur l’histoire d’iceScrum. L’histoire d’iceScrum a commencé en octobre 2005 à l’IUP ISI de l’Université Paul Sabatier de Toulouse. Les étudiants de cet IUP en génie logiciel ont un module d’enseignement qui consiste en des projets tutorés : des équipes sont constituées pour développer un produit en suivant les méthodes enseignées.