Archive

Posts Tagged ‘Team’

Oubliez Scrum !

14 juillet 2011 2 commentaires

Joe: Nous sommes une équipe distribuée sur plusieurs fuseaux horaires. Il est impossible de trouver 15 minutes en commun pour faire un Daily Scrum. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Est-ce difficile de se rencontrer rapidement dans la journée lorsque vous en avez subitement besoin ? Le Daily Scrum vous permet de vous entraîner à cela pour que cela ne soit jamais un problème dans la journée.

Dan: Chez nous il y a deux personnes différentes qui gèrent les priorités et le budget. Il est impossible de trouver un Product Owner. Scrum ne marche pas chez nous, il faut l’adapter.

Oubliez Scrum ! Sur quels critères décidez-vous (de continuer) d’investir dans un développement ? Sur quels critères décidez-vous d’arrêter un développement ? Sur quels critères décidez-vous de libérer une version au marché ? Le Product Owner vous permet de vous entraîner à ces questions en se les posant à chaque itération.

Jude: Notre système est extrêmement complexe, inclus des dizaines de modules qui gèrent des centaines de millions de dollars. Il est impossible de livrer chaque itération un incrément potentiellement prêt pour la production. Scrum ne marche pas pour nous, il faut l’adapter.

Oubliez Scrum ! Combien de temps se passe-t-il entre le moment où votre client préféré à une idée géniale et le moment où vous lui livrer un (morceau de) logiciel qui lui permet de tirer profit de son idée ? Que faudrait-il faire pour diviser ce temps par 2 ? La livraison d’incréments terminés à chaque itération vous permet de vous entraîner à diminuer ce temps pour pouvoir être opportuniste, pour pouvoir saisir facilement les opportunités marché.

Oubliez Scrum ! L’objectif n’est pas Scrum. L’objectif est l’amélioration. Scrum vous propose plusieurs axes d’amélioration. Chaque outils de Scrum – Sprint, Product Owner, Equipe, Done, Retro, Revue, Planning, Vision, Product Backlog, etc – se concentre sur un thème précis. Ils sont conçus pour fonctionner ensemble. Ils sont difficiles à comprendre. Votre Scrum Master est là pour vous les enseigner.

Catégories :Journal, Scrum Étiquettes : , , , ,

commitment and #scrum

14 juin 2011 1 commentaire

PM: I get angry when the team does not deliver its commitment because it breaks my plan.

PO: what do you call commitment?

PM: the features they commit to deliver.

PO: how does this understanding of commitment help you?

PM: well actually it doesn’t…

PM: what do you call commitment?

PO: the Team and myself we commit to be transparent.

PM: what do you expect from this commitment?

PO: from the Team, typically two things. First, the Team will ask me if it needs help to clarify requirements. Second, the Team will only deliver done increments.

PM: what if the Team does not deliver anything?

PO: it means we failed to express my vision into product backlog items that the Team can turn into potentially shippable increments

PM: … and it breaks your plan!

PO: my plan is never broken, I change it to maximize the value of my product.

PM: what if you don’t find a better plan?

PO: I’m accountable for maximizing the return on investment. Sometimes the best business decision is to stop investing in a product.

Catégories :Journal, Scrum Étiquettes : , , ,

Après #scrum

Quiconque ayant une idée
peut engager une équipe qui lui livre un logiciel en un mois
pour l’aider à tirer le meilleur de cette idée

Qu’est-ce que tu vois après Scrum ?

De mon expérience, lorsque quelqu’un me pose cette question, il s’attend à ce que l’on parle de la prochaine méthode, de la prochaine approche, du prochain outil. Il a souvent envie d’avoir un avis comparé sur toutes les méthodes ou techniques du moment. Je me souviens par exemple que c’est de cette manière qu’était posé le thème d’une table pendant un world-café Scrum avec l’intention d’étudier le buzz de l’époque sur le Kanban.

Aujourd’hui, ce n’est pas cet aspet de la question qui m’interpelle. Considérant Scrum comme un outil que l’on utilise pour découvrir ce que l’on a besoin de changer pour devenir meilleurs à développer des logiciels, la question de l’après Scrum m’incite à imaginer le monde lorsqu’effectivement nous serons devenus meilleurs à développer des logiciels.

Est-ce que tu imagines qu’alors nous n’aurons plus besoin de Scrum ?

Non car d’une part on peut toujours progresser, et d’autre part il faudra toujours former la relève.

Cette question de la formation des jeunes m’amène à considérer l’intégration de Scrum à l’enseignement universitaire non pas comme l’outil à apprendre mais comme un outil à utiliser au cours de la formation pour construire des équipes performantes. Ces universités, ou plutôt ces académies du logiciel, ne formeront plus des individus mais des équipes complètes capable de livrer un logiciel utile en un mois.

Le mouvement du software craftmanship qui étudie des modèles autour du compagnonnage nous donne des pistes pour repenser la formation continue autour du parrainage actif de ces nouvelles équipes par des professionnels d’expérience.

De son côté le lean startup explore des modèles de recherche de valeur en se basant sur des cycles d’apprentissage très rapide.

Plusieurs questions se bousculent. Que veux-tu dire par livrer un logiciel utile en un mois ? Pourquoi un mois ? J’ai en tête des systèmes qui ont mis des années à être construits, imagines-tu pouvoir les construire en un seul mois ?

Lol. Allons-y doucement.

Plusieurs pièces du même puzzle s’emboîtent pour moi très naturellement.

Une première pièce concerne la formation que l’on vient d’évoquer. Une autre concerne le mode de financement.

Le passage du Waterfall à Scrum a des impacts importants sur de nombreux aspects. Néanmoins, sur le terrain, le mode de financement est souvent resté le même. Je rencontre de nombreux cas dans lesquels des projets démarrent pour 12 ou 18 mois tout en disant qu’ils vont utiliser Scrum. Plusieurs éléments m’interpellent dans ces situations. Par exemple on parle alors souvent de projets, et non de produits. Ou encore, plus évident, on a déjà un plan et un financement pour plusieurs mois, ce qui me semble contradictoire avec une approche empirique, c’est à dire une approche qui considère que l’humain ne sait pas identifier ce qui sera une bonne idée dans 6 mois.

Imaginons maintenant une rupture plus nette. Un mois, un seul.

Cela nous invite à considerer un mode de financement différent. Dans ce mode, je ne finance que le premier mois et je mets en production l’incrément construit. Cet incrément ensuite génère lui même les bénéfices pour financer un autre incrément.

Cela suppose que l’on sache trouver de la valeur en un seul mois.

Oui. Et que l’on sache livrer un incrément terminé en un mois. C’est une invitation à aller au delà du potentially shippable, c’est une invitation à shipper.

Scrum est un outil pour être meilleur. Un outil pour s’entraîner à livrer un logiciel utile en un mois. S’entraîner à trouver la fonctionnalité utile. S’entraîner à construire un incrément terminé. Les deux.

Shipper plutôt que potentially shippable me semble puissant car dans sa recherche de ROI, le Product Owner doit mettre en production pour effectivement avoir accès au ROI. Sinon, ce ROI n’est que potentiel.

N’as-tu pas peur de perdre les avantages de l’empirisme dans cette idée de faire des itérations d’un mois ?

Je n’ai pas dit ça.

Vous vous rappelez sans doute que dans la première description de Scrum, Ken et Jeff parlaient de sprints d’un mois, plus exactement de 30 jours. On a tous interprété cela comme des itérations d’un mois. Et on continue d’ailleurs à traduire sprint par itérations et de parler de sprints ayant des tailles comprises entre 1 et 4 semaines. Il faut dire que cela a des côtés pratiques dans nos calendriers.

Si on cantonne la notion de sprint au container de 30 jours dans lequel l’équipe se dote d’un objectif de sprint, le sprint goal, et s’impose un niveau de qualité production, rien n’empêche l’équipe de faire des itérations à l’intérieur de ce sprint, par exemple d’une semaine.

Cela ouvre l’idée de livrer un logiciel en un mois, puis de s’arrêter pour attendre d’avoir de nouvelles idées. Ne penses-tu pas que les clients continueront à avoir envie d’ajouter immédiatement d’autres fonctionnalités ?

On parle de clients dans un futur avec des équipes capables de leur livrer en un mois un logiciel pour les aider à tirer profit de leur idée. Ce ne sont pas les clients que l’on connait aujourd’hui. Leurs états d’esprit n’est plus le même. Ils valorisent le feedback d’utilisateurs qui ont utilisé le logiciel en situation réelle. Parfois plusieurs semaines, plusieurs mois peut être seront nécessaires pour un feedback pertinent. Pour ceux qui sont dans ce cas, s’ils ont envie d’ajouter une fonctionnalité, ils ne voudront certainement pas l’ajouter immédiatement, ce serait trop risqué.

Reprendre un développement plus tard représente un risque, comment être sûr que l’on trouvera une équipe capable d’ajouter une fonctionnalité ?

Aujourd’hui on est déjà dans cette situation. Il n’y a pas de raison de penser que le monde va devenir plus simple. Il y aura toujours des incertitudes, elles ne feront que changer et probablement que nous ne pouvons pas aujourd’hui anticiper de quelles natures elles seraient dans ce futur.

On peut néanmoins anticiper que les équipes continueront à avoir des spécialités. Certaines choisiront par exemple les énormes systèmes à modifier en un mois pour ajouter une fonctionnalité clef. D’autres se spécialiseront sur les nouveaux logiciels sans héritage à inspecter et un nouveau domaine à explorer.

L’industrie continuera à progresser. Les techniques et les outils continueront à s’améliorer et les prochaines promotions feront en une semaine ce qui prenait un mois aux précédentes. Le parrainage permettra d’enrichir mutuellement les mondes universitaires et professionnels.

Le point clef est d’apprendre à livrer un logiciel utile en un mois. Les équipes ont l’embarras du choix pour s’entraîner. Le monde regorge d’associations caritatives qui pourraient bénéficier de leur travail. Un seul critère d’évaluation : que le logiciel soit utilisé.

Tu parles d’académies, de mettre au placard les développements de plus d’un mois, mais tu vois ça pour quand ?

Les progrès accomplis dans les 10 dernières années tels que je les comprends me font penser que cela mettra plus de 10 ans. J’aimerais que cela prenne moins de 20 ans pour pouvoir en profiter.

Cela semble ambitieux. Par où commencer ?

C’est la troisième pièce de mon puzzle : le chemin pour nous y rendre. Pour l’instant je n’en connais que le début bien sûr. Et encore, un début qui fait du sens pour moi.

Evidemment il faut continuer à s’entraîner car nous sommes loin de ce monde. Cela veut dire enseigner tout ce qui peut aider une équipe à livrer un logiciel utile en un mois. Je contribue à cette effort en donnant des formations sur les pratiques agiles.

S’entraîner cela veut dire aussi aider les équipes à mettre en place ce qui fonctionne pour nous et que nous enseignons. Je me concentre aujourd’hui sur deux activités clefs qui maximisent selon moi cette transmission. D’une part l’animation de dojos dans les équipes. D’autre part l’immersion dans ces équipes : un mois avec une équipe avec l’objectif de lui transmettre le plus de savoir-faire et savoir-être possible.

S’entraîner enfin c’est livrer des logiciels utiles en un mois. De nombreuses personnes ont des idées et voudraient trouver une équipe pour leur livrer un logiciel rapidement pour tirer profit de leur idée.

Donc si je comprend bien, ils n’ont qu’à te contacter.

Exactement :).

Catégories :Journal, Scrum Étiquettes : ,

Professionnal Scrum Foundations

Salut,

Nous (Vincent et moi) venons de donner deux sessions de la nouvelle formation PSF de scrum.org. Et je voulais partager avec vous ce que j’ai appris.

Les participants aiment les exercices de simulation pendant lesquels ils construisent du logiciel. J’ai donné des formations pendant lesquelles les participants construisent des prototypes papier. J’ai ressenti qu’ils préfèrent le logiciel. Cela améliore visiblement leur compréhension de comment utiliser Scrum dans leur projet. Cela augmente aussi la participation ; ils sont plus motivés à faire les exercices.

La mise en pratique d’un Scrum avec plusieurs équipes a beaucoup de valeur pour les participants. Pendant la PSF, la quatrième itération – pendant la seconde après-midi – impose aux participants de mettre en commun leur travail pour construire un site internet portail de leurs différents produits. Les échanges sur les différentes stratégies d’intégration sont beaucoup plus profonds que dans une formation théorique car les participants sont riches de cette mise en pratique.

La PSF est plus pertinente que la PSM pour les équipes qui débutent avec Scrum. J’ai donné beaucoup de PSM. Elle n’est pas faite pour les débutants. La PSM se concentre sur la compréhension de Scrum nécessaire à un Scrum Master. La PSF aborde tous les rôles de Scrum de façon plus équilibrée. Les Product Owner, Team et Scrum Master ainsi que toute personne qui est ou sera en contact avec une équipe Scrum trouveront dans la PSF ce dont ils ont besoin pour commencer: des réponses à leurs questions commençant par « comment ».

Catégories :Journal, Scrum Étiquettes : , , ,

Backlog avec Excel

On me demande souvent « Quels outils faut-il pour faire du Scrum ? ». Parfois un mur et des post-it peuvent faire l’affaire. D’autres fois l’Equipe et le Product Owner ne sont pas sur le même site ; au moins pas tout le temps. Alors on a envie d’avoir un outil pour partager les backlogs.

Et pourquoi et pas commencer avec quelque chose de simple : une feuille Excel. Et pourquoi ne pas partager cette information simplement : avec google docs. Google docs nous offre le minimum vital pour nous lancer : Product Backlog, Sprint Backlog, Burndown Charts.

Voici un exemple simple.

Catégories :Journal Étiquettes : , ,