Quelles sont les principales différences entre les méthodes ?

When to use kanban vs scrum http://www.extremeuncertainty.com/when-to-use-kanban-vs-scrum/ par leontranter

Si Scrum est la méthodologie Agile la plus largement utilisée, Kanban devrait être en seconde place. Ça existe depuis longtemps, c’est élégant, c’est efficace, c’est simple et ça marche. Beaucoup de gens utilise Kanban en conjonction avec Scrum. Ils appellent parfois cette « Scrum-ban ». Quelques personnes utilisent juste quelques idées de Kanban, certaines un mélange à 50/50 des deux et d’autres uniquement Kanban. Pas de Scrum du tout. Cet article expliquera quand utiliser Kanban ou Scrum. Cela dépend vraiment de quel type de travail vous faites.

Cependant, beaucoup d’équipes utilise juste deux ou trois des idées de base de Kanban, plutôt que la totalité. Kanban est bien comme ça. Vous pouvez facilement ajouter, choisir les parties que vous aimez et laisser celles qui ne vous conviennent pas. Scrum ou la Programmation Extrême ne sont pas aussi flexibles. Elles n’ont pas tendance à bien fonctionner si vous n’en prenez que deux ou trois particules aléatoires. Elles sont un système logique. Kanban n’est pas vraiment un système logique, c’est juste un jeu de principes pour visualiser et améliorer le travail. Choisissez ceux que vous aimez. Ou utilisez-les tous!

D’abord, passons les différences principales entre les méthodes.

Scrum est avant tout itérations

Le focus principal dans Scrum est sur les itérations. Une itération est une courte unité fixe de temps. Scrum appelle ces itérations « des sprints ». Un sprint dure d’habitude deux, trois ou quatre semaines. Vos sprints doivent tous être de même durée. Vous ne pouvez pas avoir un sprint légèrement plus long ici et un sprint plus court là. Ce serait tricher. Le principe est d’entrer dans un modèle prévisible de livraison de travail. L’équipe exécute une planification fréquente et des revues et rétrospectives fréquentes. Cela permet à l’équipe de prévoir et planifier le travail qui sera fait sur les deux prochains sprints.

Kanban est avant tout états de travail

Dans Kanban, il n’y a aucun sprint. Il n’y a aucune itération. Il ne s’agit pas tellement de temps et de prévisibilité, il s’agit plutôt de travail. Le focus dans Kanban est dans le découpage et la visualisation de petits articles de travail. Vous dressez alors la carte des articles de travail sur des états spécifiques du travail. Essayer de placer peu d’articles de travail dans n’importe quel état particulier et aussi peu d’articles de travail possible comme bloqués. Vous pouvez aussi imposer des “limites WIP ” (nombre d’items « work in progress » donc de travail en cours) dans chaque état. Cela signifie que vous ne pouvez pas avoir plus qu’un certain nombre d’articles dans un état particulier. L’objectif est d’avoir un flux de travail lissé à travers tous ces états.

Scrum est bon pour suivre le progrès et planifier

Scrum est une bonne structure pour le travail de développement de fonctionnalités. Pour le travail où vous avez une pile de fonctionnalités à construire et vous devez planifier grossièrement combien de temps il faudra pour les construire et quand elles pourraient être finies. On utilise des sprints de durée fixe donc vous pouvez mesurer votre progrès comme vous avancez et déterminer votre vélocité. La vitesse vous aidera à projeter combien de temps il faudra pour finir tout le travail. Souvenez-vous, la vélocité est pour qu’une équipe pour fasse son propre planning, pas pour qu’un manager mesure la productivité.

Alors, en résumé, Scrum est bien adapté pour réaliser un travail de développement parce que :

• Le travail est composé de grosses parties vagues qui peuvent alors être décomposées en item de fonctionnalité spécifiques plus petits
• Le travail fait généralement partie d’une série encore plus grande de buts à long terme (« des releases » ou « des horizons »)
• Les délais fixes et limités, les timeboxes, vous laissent mesurer votre taux de progression
• Les délais fixes et limités et un taux de progression signifient que vous pouvez planifier vers les objectifs à long terme.

Kanban est bon pour le flux et la quantité livrée

Kanban est bien adapté à un travail où il n’y a pas de gros arriéré de fonctionnalités à développer. L’attention est plutôt sur livrer rapidement de petits items de travail comme ils arrivent. Un exemple usuel est celui d’une équipe assignée à résoudre des incidents de production. Kanban fonctionne vraiment bien ici parce que :

• Le travail surgit devant l’équipe (c’est-à-dire poussé vers elle, basé sur la fourniture) plutôt que tiré par l’équipe (c’est-à-dire basé sur la demande)
• Le travail est composé de petits composants distincts qui ne sont pas d’habitude connectés à d’autres composants de travail
• Il n’y a aucun objectif à long terme ou but à atteindre
• La planification est sans importance ou sans rapport.

Et si vous voulez utiliser les deux ?

Eh bien, bonne nouvelle, vous pouvez. En fait, la plupart des personnes le font. Les équipes de développement de logiciel les plus agiles utilisent Scrum et beaucoup d’entre elles utilisent au moins certaines (mais pas toutes) les idées de Kanban. La plus commune est celle des colonnes sur le tableau de visualisation Kanban. Elles sont si fréquemment utilisées que je les prends pour acquises et oublie souvent qu’elles ne sont mentionnés nulle part où dans Scrum ! C’est aussi une pratique commune que d’utiliser quelques autres idées des tableaux de visualisation Kanban comme des avatars et de marquer les histoires bloquées.

Alors, quand utiliser Kanban ou Scrum ?

En résumé, vous devriez :

• Utiliser Scrum (ou quelque chose de similaire) pour le travail de développement de fonctionnalités avec des gros objectifs de livraison ou des jalons importants
• Utiliser Kanban (ou similaire) pour les petites items de travail entrant dans l’équipe comme la réparation de bugs ou de petites demandes d’améliorations
• Mais ne pas hésiter à les combiner, en particulier en adoptant Scrum, mais en appliquant certaines grandes idées Kanban comme les tableaux de visualisation.

J’espère que cela aide à éclaircir les choses!

Une petite vidéo de 6 minutes en anglais pour exposer comment appliquer certains des principes de Kanban à Scrum.

Manifeste d’Agilité Personnelle

Personal Agility, http://www.derekhuether.com/2016/05/08/personal-agility par Derek Huether

Récemment, j’ai beaucoup réfléchi à comment augmenter l’agilité personnelle. Non, je ne parle d’exécuter des sauts périlleux ou autres folles poses de yoga. Je parle de la capacité à me concentrer sur la valeur et à être adaptable dans ce que je fais chaque jour. L’agilité telle que mentionnée dans les valeurs et principes du Manifeste pour le Développement Logiciel Agile. Quand le manifeste a été répondu en 2001, il y avait des représentants de Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming et autres. Aussi, quand je dis Agile, je ne veux pas nécessairement dire Scrum.

Scrum de Un ?

Dans ce billet, je veux mettre le focus sur les personnes et pas les organisations. Étant un coach Agile et un consultant, j’ai appris beaucoup de stratégies qui m’ont aidé à manager des clients. En travaillant avec de grandes organisations complexes, j’ai vu des améliorations de productivité au niveau organisationnel en appliquant Lean et Kanban et au niveau de l’équipe avec Scrum et Kanban. Mais qu’en est-il de toutes les personnes qui travaillent pour ces organisations ou dans ces équipes Scrum ? Qu’en est-il des gens qui n’ont aucune idée de ce qu’est Scrum et ne s’en soucient pas ? Comment peuvent-ils améliorer leur productivité ?

Dans le billet Lifehack « Scrum for One« , Dustin Wax décrit combien des éléments de Scrum pourraient être adaptés à la productivité individuelle. En lisant l’article, je n’ai pas acheté l’idée. Scrum est une approche géniale pour des équipes mais c’est comme vouloir faire passer une pièce ronde dans un trou carré que de vouloir utiliser Scrum pour votre productivité quotidienne.

Dans Scrum, vous démontrez la valeur à votre client toutes les 2 à 4 semaines dans le cadre d’un sprint. Cela a-t-il du sens pour manager votre travail personnel ? Non.

Dans Scrum, vous avez les 3 rôles : ScrumMaster, Propriétaire de Produit et Équipe. À moins que vous n’ayez une double personnalité, il n’y a que vous !

La plupart des choses auxquelles je pense pour atteindre mes objectifs : l’alignement des activités sur les livrables, la décomposition du travail en morceaux exécutables, réitérer sur ce qui est créé pour pouvoir l’améliorer au fil du temps… la liste est longue.

Et ces composants ne sont pas des éléments exclusifs de Scrum. Alors, pourquoi vous limiter à Scrum ?

Manifeste d’Agilité Personnelle

Je crois que la productivité personnelle doit être repensée.

La productivité personnelle est-elle d’être tout le temps occupé ou de réaliser des choses ?

Pour être productif, cela signifie que vous devez produire. Sinon, vous êtes actifs. Il y a une différence! Pour aider à structurer mes pensées, j’ai écrit un Manifeste d’agilité personnelle.

Vous remarquerez que c’est proche du Manifeste Agile. Mais, il y a des différences clés.

D’abord, (tous) les résultats obtenus sont des mesures primaires de progrès. Ceci n’est pas du tout le cas pour le développement logiciel.

Deuxièmement, je me suis concentré sur des minutes, heures et jours pour réaliser des choses. Les équipes continueront à se concentrer sur des jours, semaines et mois pour obtenir le travail escompté et le livrer.

Je cherche à produire quelque chose que tout un chacun puisse utiliser. Quand vous entendez « Agile » c’est en réalité un groupe de niche de personnes concernées. Mais, quand vous parlez de productivité personnelle, la taille de l’audience explose. Comme avec Agile, je ne pense pas qu’il y ait une unique et meilleure voie. Alors, je regarde pour expérimenter et continue d’essayer pour améliorer.

Comme j’écris sur Personnel Kanban depuis 2010, vous pourriez penser que je devrais avoir tout compris à ce jour. Eh bien non, ce n’est pas encore le cas…

Aussi, si vous avez des trucs et astuces, j’aimerais les entendre.

Enregistrer

Enregistrer