Devops for Growth

A quoi sert cet indicateur ?
Indicateur utilisé en daily

Il est intéressant de regarder celui de chaque élément non terminé et commencé du board. C’est une des recommandations du guide kanban pour le scrum.

En effet, cela permet de voir si cet élément ne reste pas trop longtemps dans le work in progress comparé au cycle time moyen que nous avons. L’intérêt de suivre cet indicateur reste cependant plutôt limité.
Comparable au SLE (Service Level Expectation) ?

Si à première vue cela peut sembler être le cas, il semble difficile de comparer les deux. Si le SLE propose un timing recommandé, il parle aussi du pourcentage de tickets qui doivent se terminer dans le timing recommandé.

En effet, si un grand nombre d’items dérivent, la comparaison est envisageable mais sinon la comparaison est plutôt inutile.
Conclusion

Cet indicateur qui est mis en avant par le guide kanban pour scrum, il reste cependant peu utilisé en kanban. Cependant certaines équipes kanban l’utilise vraiment comme un élément d’analyse important.

Voici souvent comment il est représenté sur un board kanban :
lead time et cycle time
lead time et cycle time

Les équipes mettent un point sur le post’it chaque jour afin de représenter :

le work item age -> tant qu’il est pas terminé
le cycle time -> quand il est terminé

Du point de vue du produit, ces modifications de WIP limits et de DOD ont eu des effets qui ont dépassé notre objectif initial. Non seulement nous avons augmenté la fréquence de nos MEP, mais nous avons également multiplié par 3 le nombre de tickets livrés par itération. C’est à dire que nous livrons plus d’US par itération et que nous avons diminué significativement notre stock de bugs.
Nous livrons donc plus de valeur, de manière plus régulière, et avons augmenté la qualité du produit.

Pour ce qui concerne l’équipe, tout ceci facilite la propriété collective du code et du flux, la montée en compétence des nouveaux, encourage la courtoisie dans les merges, rend plus immédiat le traitement des retours de revue de code et limite les ajustements détectés en Recette PO (le comportement est discuté et éventuellement amélioré lors des revues en pair).

Cette expérience nous a montré la puissance de la limitation de l’encours ; son impact sur l’efficacité d’une organisation.

La contrainte, lorsqu’elle est décidée et plébiscitée par une équipe, devient un levier remarquable pour canaliser l’énergie là où elle crée le plus de valeur.

Scrum and Kanban lead to the evolution of Scrumban. It combines the best of both worlds and shares several similarities with Scrum while borrowing cultural nuances from Kanban. It is a hybrid environment which is used for agile product lines with frequent interruptions. Scrumban uses fixed-size pieces of work for development and tracks work that is in queue, ready to be processed, and in process. Scrum and Kanban both are winners when it comes to continuous process improvement and self-organizing teams. The big question is, “Can the combination work?” If it does, what are its benefits? Benefits of Using Scrumban […]

Let's start with one of the core tool of the agile workflow. We use a Jira board for tracking and organizing all of our projects. We developed a custom board which uses the sprints concept of Scrum but in a more flexible way as in Kanban.

Cet article est la « suite » de l’article de l’année dernière sur le passage du Scrum au Kanban. Le projet continuant de vivre et l’équipe continuant à faire de l’amélioration continue (on ne peut pas être agile sans amélioration continue !), nous avons encore évolué !

Comme dit dans l’article précédent nous avons au début de la mise en place de la méthodologie Kanban éprouvé des difficultés afin de ne pas nous éparpiller. Ce problème a été résolu et nous avons réussi à avoir les avantages du Kanban en limitant cette dérive.

Néanmoins, en passant du Scrum au Kanban nous avons également quitté le « cadre » offert par le Scrum. Ce cadre s’est avéré à moyen terme un gros manque pour les membres de l’équipe.

Nous avons atteint une situation où l’estimation ne portait plus sur notre reste à faire (RAF) mais sur notre capacité à faire (CAF). À court ou moyen terme, le nombre d’US nécessaires pour couvrir un besoin est quasi certain.

Ajouter la logique de flux à une équipe qui fonctionne en Scrum apporte de nombreux avantages en terme de sérénité, prise de recul, stabilité du rythme de production et prédictibilité. Une fois ces améliorations intégrées, l’équipe est passée au Scrumban.

Il est important de noter en revanche que c’est une pratique “avancée” et qui peut être difficile à appliquer par une équipe pas encore à l’aise avec les rudiments de Scrum.

Le Scrumban semble un bon compromis qui apporte des avantages par rapport Scrum, et, si l’équipe se sent à l’aise, le scrumban peut être une bonne étape d’intermédiaire pour passer à du flux pur en arrêtant complètement les itérations.

L'approche Agile s'est imposée dans les entreprises avec deux méthodes répandues dans le développement de logiciel : Scrum et Kanban.
On se confronte aux problématiques du cycle de vie du produit : le mode projet et le mode RUN.
L'association des avantages de Scrum et du Kanban donnera naissance au Scrumban, une approche permettant de répondre à cette problématique organisationnelle.

Scrumban was developed by Corey Ladas, a Lean-Kanban practitioner as a way to transition from Scrum to a more evolved framework. Although Scrum and Kanban frameworks work well within many projects, each has some limitations. The Scrumban principles and practices create unique yet complementary Scrum and Kanban capabilities.

Because Scrumban systems are queuing systems, they enable us to apply Little’s Law to statistical data measured through their kanban systems. Little’s Law essentially correlates arrival rate, processing rate and work in progress. Its most basic level works with averages, and can be expressed as:

‘Ave. WIP (amount of resources) = Ave. Lead Time [ # of stories / total project time ]’

​This Smart Guide will help you win with more frequent releases. It will share what we learned at Assembla.

Pour la première fois de ma carrière, je travaille en Kanban sur un projet (Je l’avais déjà expérimenté pour de la résolution de bugs).

Nous, l’équipe agile, avons décidé de passer en Kanban notre projet qui fonctionnait très bien en Scrum avec des sprints de 2 semaines. Cette décision, ce risque, a été pris suite à certaines limitations que nous avons rencontrées avec la mise en service de notre application et donc, un changement de contexte.

Le Scrumban est un mélange des deux concepts « scrum » et « kanban ». On profitera des notions de backlogs, rôles et piliers du scrum tout en lui donnant la notion forte de flux tiré du kanban.

On considère que le scrumban répond plus à certaines équipes ayant de vraies contraintes de planification : support, infra, équipes TMA…