Comment tester une chaine d’applications ?

Il y a deux ans, on m’a proposé la mission suivante : réduire le temps d’intégration des composants d’une chaîne d’application à un mois, ce qui sous-entend disposer d’une capacité à tester efficacement l’ensemble de cette chaine. Je prends enfin le temps de vous parler de cette expérience, de l’organisation et outils des utilisés. Lire la suite

Comment définir la priorité des vos fonctionnalités ?

Voici un atelier que j’utilise très souvent avec des équipes pour co-construire la priorité des fonctionnalités qu’elles comptent réaliser sur les deux ou trois prochains mois. J’aime beaucoup cet atelier car il dure moins d’une heure, offre une discussion facile entre les participants, qu’ils soient IT ou métier et permet de définir l’ordre dans lequel réaliser les fonctionnalités. Lire la suite

Des feature teams dans mes component teams

Vous avez des équipes agiles mais n’êtes toujours pas satisfait de votre Time To Market ? Peut être que ces équipes contribuent aux mêmes fonctionnalités mais ont des difficultés à se synchroniser. Je vous livre dans cet article, non pas la réponse “il vous faut des feature teams”, mais plutôt ce que vous pouvez faire avec vos équipes applicatives / composants pour les orienter “fonctionnalités” et les aider à mieux interagir. Le contenu proposé ici est basé sur un retour d’expérience d’un an dans un grand groupe. Le succès de cette expérimentation a donné lieu à plusieurs communications internes. Lire la suite

Comment créer des communautés au sein de votre organisation

Les organisations dans lesquelles j’ai travaillé ces trois dernières années se sont posés la même question sur la nécessité d’avoir des communautés. Elles les voyaient comme une réponse à la transmission du savoir, des pratiques agiles, d’informations opérationnelles, etc. Elles se sont alors demandés comment mettre en place ces communautés. Dans cet article, j’aborde les deux types d’accompagnement que j’ai réalisé avec des communautés et partage mes réflexions sur leur mise en place en général. Lire la suite

Comment je suis devenu coach agile ?

Ces derniers mois, j’ai croisé plusieurs personnes qui s’intéressaient au métier de coach agile. En plus des compétences à acquérir, leurs questions portaient souvent sur la manière dont on en vient à exercer auprès d’équipes et de managers. Les discussions que nous avons eu ensemble m’ont donné envie de partager le chemin que j’ai suivi pour devenir coach agile. Lire la suite

Sculptez vos user stories et critères d’acceptance à l’aide de questions

5047534162_4332d7305d_z

Une idée de fonctionnalité est comme un matériau brut que l’on peut s’amuser à sculpter. Je l’ai remarqué lors d’ateliers en questionnant les équipes que j’accompagne sur les fonctionnalités qu’elles veulent développer et la manière dont elles comptent les valider. J’utilise les trames “User story” et BDD (Behaviour Driven Development) pour capturer l’essence du besoin et la manière dont la réponse pourra être observée une fois la fonctionnalité développée. Je trouve beaucoup de valeur à ce type d’atelier car, d’une part, il permet aux équipes de se former aux user stories et aux scénarios BDD en utilisant leur propres sujets et d’autre part, de s’imprégner du format de l’atelier qu’elles peuvent réutiliser.
Lire la suite

Et si vous essayiez Scrumban ?

Chaque année, je m’éloigne un peu plus du Scrum traditionnel. J’observe un décalage entre certaines pratiques et les attentes des équipes que j’accompagne. Je me questionne sur certains concepts comme l’estimation, la notion de sprint, la priorisation, etc. J’ai trouvé dans Kanban d’excellentes idées qui ont altéré ma manière de pratiquer Scrum. De plus en plus de personnes se tournent vers Scrumban, une évolution de Scrum, qui combine le meilleur de Scrum et Kanban. Depuis deux ans, j’ai moi aussi franchi le pas et aide des équipes à s’approprier cette approche. Voici comment elles s’essaient à Scrumban. Lire la suite

Le VSM, un excellent outil de cadrage de coaching agile

Le cadrage est une étape indispensable au lancement d’une transformation agile. Elle permet à chaque membre de l’équipe de donner du sens à la transformation, de partager un objectif tout en prenant connaissance du futur format de l’accompagnement. C’est également l’occasion de créer la confiance avec l’équipe et de casser l’image de l’hurluberlu qui débarque pour changer les choses à sa manière. Lors de cette phase de cadrage, j’aime bien utiliser un VSM (Value Stream Mapping) pour amener l’équipe à constituer son propre kanban board de transformation. Il contient les premiers sujets sur lesquels l’équipe a envie de travailler, la matière pour amorcer pour l’amélioration continue.
Lire la suite

Le Time To Market, un bon indicateur pour une transformation agile ?

J’ai très souvent lu ou entendu que l’agilité permettait d’avoir un meilleur Time To Market (TTM) que les traditionnelles méthodes orientées cycles en V. C’est un bon argument commercial auquel les décideurs peuvent être sensibles. C’est aussi quelque chose que je crois dans le sens où l’agilité nous donne des clés pour livrer rapidement et fréquemment de la valeur aux clients. Une transformation agile est souvent motivée par une amélioration du TTM. Dans ce cas, comment peut-on mesurer la progression vers cet objectif, peut-on considérer le TTM comme indicateur à revoir régulièrement pour vérifier la distance à la cible? Pas si simple.

12239377734_ee77ec423e

Lire la suite

La fréquence de livraison comme indicateur de performance d’une transformation agile ?

3697317390_32c6490b8b

La fréquence de livraison indique le rythme auquel une application est mise à jour pour intégrer des changements fonctionnels et techniques. La valeur délivrée peut prendre plusieurs formes comme de nouvelles fonctionnalités, de meilleures performances, une optimisation de l’utilisabilité, de l’évolutivité ou de la maintenabilité. La fréquence de livraison apparaît comme un indicateur plutôt révélateur de l’interaction entre les acteurs de la chaîne de valeur et de l’efficacité de l’outillage de test et de déploiement, mais attention à ne pas tirer de conclusion hâtive. Une équipe peut par exemple être en capacité de livrer tous les jours, mais ne réalise des déploiements qu’une fois par mois à la demande de son client. Est-ce que la fréquence de livraison est un bon indicateur de performance d’une transformation agile ? Est-il suffisant ou complémentaire à d’autres ? Examinons ce qu’il cache. Lire la suite