Agile Digest 35

Le meilleur des méthodes agiles

Cette semaine dans notre Agile Digest, on parle de prédictibilité; le rôle du Product Owner est à l’honneur ; d’autres que moi s’intéresse au kanban pour Startups; Et Jim Coplien pense que le flux c’est mieux que le kanban ! Claude fait le tour des frameworks pour passer Scrum à l’échelle. Côté startup, on parle du rôle de mentor, de l’avantage unique et des incubateurs. Bonne lecture,

La prédictibilité

La prédictibilité comme principe pour d’une bonne relation client, est-ce un objectif à part entière de l’agilité ? C’est une des réflexions abordées par Sébastien Delest cette semaine. Je partage le point de vue que l’on peut proposer une certaine forme de prédictibilité avec une approche agile (Scrum ou Kanban).C’est déjà une bonne nouvelle avec des approches qui permettent de piloter du changement ou un flux de travail. Mais qu’au-delà de la prédictibilité, c’est la confiance avec le client qu’il s’agit d’installer, par la collaboration, la transparence. La difficulté est que la confiance se construit, en montrant notamment que l’on tient nos engagements… Personnellement, j’irais un peu plus loin et je parlerais de confiance à établir entre les différents acteurs. On oublie souvent (également dans le mouvement #noestimates) que la prédictibilité, la vélocité, les estimations sont aussi demandées par l’équipe elle-même pour s’engager avec confiance sur le périmètre du sprint, ou par le Product Owner pour piloter son plan de release. Cela ne vient pas que de la part du client. N’oublions pas non plus que la prédictibilité n’est surtout pas une cible dans certains contextes où l’incertitude apporte de la valeur ajoutée (R&D, startups, innovations, …). La prédictibilité n’est pas une cible, mais plutôt un moyen pour établir la confiance.

Le coin des twittos Agiles

Pour appuyer la problématique des estimations Et pour les coaches    

Agile Digest – le meilleur de Scrum

Le Product Owner est à l’honneur

Dans cet article, le rôle du Product Owner est discuté au travers différents points de vue, avec notamment plusieurs anti-patterns liés à ce rôle. L’un de ces anti-patterns que je rencontre régulièrement, est un Product Owner seul référent fonctionnel de l’équipe. Il devient alors un homme-orchestre en cumulant beaucoup trop de postes et devient le goulot d’étranglement de l’équipe. Un bon pattern de Scrum est d’avoir un seul Product Owner pour une équipe. Cela ne veut pas dire que l’on a un seul sachant métier et connaisseur du fonctionnel dans l’équipe, qui fait face à une horde de développeurs / testeurs ! Non, il est le seul à prendre la responsabilité des priorisations, des arbitrages. Car ces décisions sont prises de manières réactives sur des cycles courts de quelques jours à quelques semaines, et qu’elles doivent être prises en connaissance de cause, en immersion dans l’équipe. Dans l’équipe Scrum, il est précisé d’avoir une équipe Scrum pluridisciplinaire. C’est à dire ayant toutes les compétences pour prendre une demande et en implémenter la solution. On peut donc retrouver des analystes métier qui aident le Product Owner sur différents aspects fonctionnels. D’ailleurs mon dernier post évoque ce sujet pour un cas particulier d’organisation Scrum. Le rôle du Product Owner est également évoqué par Claude Aubry, qui énumère les 3 frameworks permettant de passer Scrum à plus grande échelle.

Agile Digest – le meilleur du Kanban

Kanban pour startup

  Dans la série du Kanban appliquée aux startups, voici un retour d’honolulu ! Il propose pour commencer de répartir les différentes (et nombreuses) activités dans le quadrant urgent/important. C’est une première définition de classes de services. Puis il propose un tableau kanban, avec des colonnes très simples, à la mode Scrum. La différence vient des lignes d’eau (ou couloirs), découpées par activités (Sales, marketing, support, Produit). Cela va dans le sens de mon article qui propose au tout départ un tableau simple. Mais je le fais évoluer rapidement vers un tableau focalisé sur la validation qualitative et quantitative des expérimentations. Ce qui me parait bizarre dans son approche, c’est d’identifier des classes de services et de ne pas s’en servir dans son tableau Kanban. Plutôt que d’avoir des lignes sales ou Marketing, j’aurais plutôt vu une ligne urgent/important, une autre important / non urgent … Ensuite les limites sont exprimées en heures dans la colonne Doing. Pourquoi pas, l’idée est de se limiter à un nombre de tâches pour une journée dans son cas. Je ne trouve pas cela réaliste, pour différentes raisons, dans le cas d’une startup. Je reste sur des limites sur le nombre. Avez-vous déjà vu un startupper commençant sa journée en découpant bien ses tâches et en les estimant ? Bref, il y a encore du travail sur ce sujet.

Kanban et le flux continu

Dans la rubrique, la traduction de la semaine de Fabrice, un article intéressant de Jim Coplien sur Kanban vs le flux. Je n’en parle pas plus car je pense en faire un post car il y a pas mal à dire sur cet article.

Kanban personnel

Bonne nouvelle, le livre de Jim Benson sur le Kanban personnel a été traduit par Pascal Venier, et c’est pierre, alias ElPedroMajor, qui en parle et a pris des notes du livre pour nous.

Le coin des twittos Kanban

Une réponse possible aux frameworks de passage à l’échelle de l’agilité :  

 Agile Digest – le meilleur du Lean Startup

Rapidement, Guilhem nous fait un retour d’expérience de son rôle de mentor pour startup, à méditer. L’innovation des grands groupes passe par les startups. L’open innovation, les incubations corporates, les intrapreneurs et les extrapreneurs, autant de cas de figure qui nous intéressent au Shift.

Unfair advantages

Vous avez du mal à trouver quels sont vos avantages uniques pour le projet que vous êtes en train de porter? Rassurez-vous,  en tant qu’entrepreneur vous en avez déjà quelques-uns dans votre ADN, en dehors de l’idée elle-même : La passion, l’intellect, l’expérience, la volonté d’écouter, la curiosité, votre communauté, des objectifs réalistes, le 1er Mover, la flexibilité, l’exclusivité, les partenariats, les brevets, votre réseau, votre vitesse, l’emplacement…  

 

That’s all Folks !

Agile Digest 35