Comment Scrum peut-il être adapté à un environnement de bénévolat?

J'ai récemment rejoint un jeune hackerspace encore en cours de création. Nous avons de la chance parce que l'espace a quelques projets internes qui nécessitent d'être travaillés et aucune pénurie de bénévoles pour y travailler.

Il y a eu quelques discussions sur la façon d'organiser ces projets. Mon expérience professionnelle la plus récente a été avec Scrum, donc j'envisage de proposer une approche Scrum pour nos projets logiciels, mais je ne suis pas sûr que ce sera un bon choix.

Bien que j'ai vu Scrum bien fonctionner pour de petites équipes à temps plein, la nature de cette organisation est différente:

• Les membres sont bénévoles . Certains sont étudiants à plein temps. D'autres travaillent à plein temps. Nous ne pouvons pas nous attendre à un niveau constant de contribution de quiconque, car leur vie réelle est prioritaire.
• Alors que presque tout le monde a des années d'expérience dans l'écriture de logiciels, peu de membres l'ont fait de manière professionnelle ou en équipe.
• Il n'y a pas de Product Owner . Les exigences de ces projets sont déterminées par un comité. Les membres de ce comité travailleront également à la mise en œuvre. Cela signifie que nous n'aurons pas de propriétaire de produit unique et dédié.
• Nous n'avons pas de délais (doux ou dur). Les projets seront réalisés lorsqu'ils seront terminés.

Ce sont des différences assez importantes, mais je ne suis pas convaincu qu'ils entraveront l'application de Scrum. Je pense que quelques ajustements mineurs pourraient nous aider à surmonter cet obstacle:

• Si nous modifions les Sprints pour avoir une taille de point d'histoire fixe, mais une durée fluide (temps), nous pouvons toujours bénéficier de versions itératives sans exercer de pression de livraison irréaliste sur les développeurs volontaires.
• Nous pouvons abandonner les graphiques de combustion et le calcul de la vitesse . Si je comprends bien, ce sont des outils et des métriques qui fonctionnent comme un pont entre l'équipe de développement et la direction. Ils servent à rendre compte des progrès sous une forme qui soit significative à la fois pour les développeurs et les parties prenantes. Étant donné que nous n'avons personne à qui faire rapport (pas de chef de projet, pas de propriétaire de produit et pas d'intervenants externes), je pense que nous pouvons abandonner tout cela.

Des choses dont je pense que nous pourrions bénéficier et qui ne nécessiteront pas de modifications:

• Le rassemblement Exigences réunion (s). Où tout le monde est assis autour d'une table et discute des histoires d'utilisateurs, esquisse des simulations d'interface utilisateur et crée un backlog de produit.
• Rétrospectives Sprint . Ce sera une façon intéressante pour nous de converger vers un processus de développement qui fonctionne pour nous en tant qu'équipe de bénévoles.

Choses dont je ne suis pas sûr:

• Comment traiter les Stand-up quotidiens ? Je me demande s'ils auraient beaucoup de valeur dans notre cadre. Ma compréhension du rituel de stand-up est qu'il facilite la communication en diffusant naturellement des informations dans toute l'équipe. Compte tenu du fait que nos sprints fourniront probablement beaucoup moins de complexité qu'un sprint moyen, il pourrait être moins nécessaire d'être au courant des progrès / développements de tous les autres membres de l'équipe.
• Dois-je pousser pour des choses XP comme l'intégration continue, les revues de code et TDD? Je crains que cela demande beaucoup. Je serais plus tenté d'introduire ces concepts dans de futurs projets une fois que les gens seront plus familiers avec Scrum et travailleront en équipe.

Mes questions:

Scrum peut-il être adapté à un environnement basé sur le volontariat?
Et, mon approche prévue va-t-elle jusqu'à présent dans la bonne direction?

Regardez dans Kanban. Il est plus approprié que SCRUM pour vos contraintes.

Edit: SCRUM est (très grossièrement) un backlog ordonné avec des sprints et des cérémonies pour s'assurer que le volume de travail `` en cours '' reste sous contrôle et avoir quelque chose de solide à la fin de chaque sprint. Si vous abandonnez les cérémonies et la cadence des sprints, vous vous retrouvez avec Kanban: un carnet de commandes et un fort accent sur la limitation directe du travail «en cours» et en vous assurant que tout ce qui est marqué «fait» est fait plutôt qu'en imposant la stabilité à la fin de chaque sprint.

Vous bénéficiez toujours des avantages agiles: libération à tout moment, flexibilité, une certaine mesure de prévisibilité - bien que SCRUM puisse vous aider un peu plus loin sur cet aspect - et sans les cérémonies ou les aspects de SCRUM qui ne conviennent pas bien à une équipe lâche et distribuée sans engagement . Le hic? Abandonner les cérémonies nécessite plus de discipline, vous devez donc VRAIMENT faire attention aux tests, à la qualité du code, au travail en cours et vous assurer que le haut de l'arriéré (les choses prêtes à être ramassées par les gens) est suffisamment élaboré.

Vous pourriez avoir un arriéré basé sur le vote, bien que dans un cadre de bénévolat, certaines personnes travaillent simplement sur ce qu'elles veulent.

(Et oui, tous les TDD, CI, critiques et idées de programmation par les pairs sont de bonnes idées).

Pour corriger les différences que vous notez en premier:

• Que vos membres soient bénévoles ne signifie pas que vous ne pouvez pas leur demander un engagement. Surtout avec la durée relativement courte d'un sprint dans Scrum, il doit être possible pour chacun des membres de savoir combien de temps ils peuvent consacrer au projet pour les prochaines semaines. Avoir les membres de l'équipe disponibles pour une durée différente à chaque sprint rendra la planification un peu plus difficile, car il est plus difficile de déterminer combien de points de stockage sont réalistes, mais cela ne rend pas Scrum irréalisable.
• Le propriétaire du produit est responsable de consolider et de communiquer la vision (et les exigences) que les parties prenantes ont pour le produit à l'équipe de développement. La partie consolidante est probablement déjà couverte par le comité «directeur». Pour la partie communication, ils peuvent simplement déléguer un de leurs membres comme porte-parole principal. Celui-ci sera alors à toutes fins pratiques le propriétaire du produit.
• Ne pas avoir de date limite externe n'est pas vraiment un problème pour Scrum. Cela revient plus à la fierté de l'équipe dans le produit pour le terminer. Scrum lui-même a une date limite naturelle pour chaque sprint.

En ce qui concerne les adaptations que vous proposez, en particulier lorsque vous travaillez avec des volontaires, je vous recommande fortement de respecter la longueur de sprint fixe. De cette façon, les bénévoles savent définitivement pour quelle période ils donnent leur engagement.

Je ne voudrais pas non plus abandonner les graphiques de burndown immédiatement. Ils peuvent également être utiles à l'équipe elle-même pour voir comment elle s'en sort par rapport à son engagement. Je laisserais à l'équipe le soin de décider de les garder ou de les abandonner. Il en va de même pour les calculs de vitesse. en particulier avec la grande variation des heures de travail disponibles à chaque sprint, ils peuvent s'avérer très utiles (surtout si vous calculez le nombre de points terminés par heure de travail) pour estimer les futurs sprints.

En ce qui concerne les standups quotidiens, ils seront toujours utiles dans votre cadre, ne serait-ce que pour faire savoir ce que tout le monde fait ou a des problèmes (et cela est indépendant de la complexité). Mais il peut être plus difficile de réaliser un standup quotidien, vous devrez donc peut-être faire des compromis.

Les pratiques XP que vous mentionnez peuvent être introduites ou non indépendamment de l'utilisation de Scrum et pourraient également être proposées lors d'une rétrospective.

Cela m'étonne que personne ne l'ait signalé, mais votre projet ressemble à la plupart des projets open source. Si vous consultez des projets open source plus populaires, vous pourriez trouver de l'inspiration. Et je pense que vous devriez oublier SCRUM et y penser du point de vue de l'agilité générale.

Agile, c'est tout sur la communication et la collaboration. Il y a une raison pour laquelle 2 points sur 4 dans le Manifeste Agile en parlent.

Individus et interactions sur les processus et les outils

Collaboration client sur négociation de contrat

Et la façon dont vous décrivez votre projet, il serait difficile d'avoir une communication en face-à-face avec tous ceux qui travaillent sur le projet, quelque chose qu'Agile et SCRUM encouragent. Donc, la première chose sur laquelle je voudrais me concentrer est d'établir des canaux de communication pour toute l'équipe (les bénévoles et le comité produit). Des choses comme le wiki, les forums, les vidéoconférences et un système adéquat de backlog, de tâche et de suivi des bogues sont d'excellents moyens de s'assurer que tout le monde sait ce qui se passe et ce qui doit être fait.

La deuxième chose que je noterais n'est pas de simplement balayer les parties technologiques de l'agile. Beaucoup croient (moi y compris) que ce sont eux qui font le travail agile, pas le côté processus des choses. La révision du code est un travail important et le plus open-source en demandant à quelqu'un qui connaît le projet de réviser les validations / push pour garantir une qualité suffisamment élevée est maintenue. TDD est pratiquement donné pour tout projet agile. Cela garantit que toute modification du code ne casse pas la fonctionnalité précédente, ce qui est encore plus important dans votre cas lorsque les volontaires ne peuvent pas être dérangés pour corriger les erreurs et les erreurs des autres. Cela facilite également la révision du code car le réviseur peut voir dans les tests quelles fonctionnalités ont été ajoutées et en les exécutant, il s'assure que les fonctionnalités fonctionnent réellement comme prévu. L'intégration continue est identique à TDD.

La dernière chose est que je pense que vous devriez avoir au moins quelques personnes travaillant à temps plein sur le projet. Ces personnes devraient avoir des rôles spécifiques:

• Product Owner : Bien qu'il soit agréable que vous ayez tout un comité dédié à cela, il devrait y avoir une personne chargée d'interpréter les mots de ce comité dans les spécifications ou les histoires d'utilisateurs et de s'assurer qu'ils sont correctement mis en œuvre.
• Coordinateur et Scrum Master : Cette personne doit être responsable de l'ensemble du processus et s'assurer que tout le monde est au courant des choses importantes qui se passent dans le projet. Il maintient également le wiki et les outils de suivi des tâches et des bogues. Si quelqu'un a une question sur le projet, c'est la première personne à poser.
• Développeur principal et architecte : la personne qui connaît le mieux le code. Il fait les revues de code et s'assure que la qualité du code est suffisamment bonne pour un développement agile.

Vous ne pouvez pas l'adapter comme vous le décrivez et l'appeler SCRUM. mais à mon avis, vous pouvez utiliser Scrum comme suit pour la configuration que vous avez décrite.

1. Ont une itération fixe. Pour que vous puissiez mesurer vos progrès. Ce n'est pas seulement pour la direction, mais aussi pour l'équipe de «savoir» comment ils fonctionnent.
2. Demandez aux volontaires de partager les capacités au début de l'itération. Toute l'équipe a besoin de ce que les membres s'engagent, sinon certains membres peuvent quitter l'équipe pour un travail plus professionnel.
3. Ne pas avoir de date limite, c'est bien. Scrum n'oblige pas à ce que ce que vous faites à la fin de chaque itération soit potentiellement livrable. Cela vous permettra de décider quoi faire ensuite en fonction de ce que vous avez fait jusque-là (qui fonctionne).
4. Le fait de ne pas avoir de propriétaire de produit peut également fonctionner. Vous pouvez avoir une sorte de système de vote pour empiler le carnet de commandes et accepter / rejeter le travail effectué.
5. La collecte des exigences ne fait pas partie de Scrum. Vous pouvez le faire comme vous le souhaitez. Mais ne l'incluez pas dans la portée de l'itération. Avoir une capacité distincte pour cela. Donc, pour une itération, ne planifiez que le travail pour lequel les exigences sont claires, par exemple l'équipe connaît les critères d'acceptation.
6. La rétrospective est bonne. Alors lancez Scrum tel quel, mais en utilisant rétrospectivement, voyez ce qui fonctionne et ce qui ne fonctionne pas.
7. Le statut quotidien est indispensable. Cela donne à l'équipe la possibilité de se synchroniser, c'est-à-dire qu'elle alignera ses efforts afin qu'aucune tâche ne soit inutilement bloquée en raison de l'indisponibilité du livrable d'un autre membre.
8. XP est bon. Ayez une définition stricte de done basée sur XP, par exemple, aucun code ne rentre à moins qu'il ne soit revu. Faites moins pour en faire plus ..

Je pourrais suggérer une approche différente. Puisque vous avez affaire à des bénévoles, vous devez tenir compte de quelques éléments. Votre équipe aura probablement un roulement élevé, la vie se mettra en travers et les gens seront distraits. Parmi ceux qui restent, quelques-uns contribueront de manière cohérente mais pas très importante, enfin, vous aurez ce groupe hardcore qui s'enracinera vraiment dans le projet. Je fais beaucoup d'hypothèses sur votre main-d'œuvre ici et si vous pensez que mon évaluation ne reflète pas les personnes avec lesquelles vous travaillez, n'hésitez pas à ignorer le reste.

Maintenant, vous avez besoin d'une stratégie qui permettra aux gens qui ne font pas beaucoup de travail de travailler de manière assez autonome, ils n'ont que trop de temps à consacrer à cela et vous ne voulez pas leur faire dépenser la majorité de cela en communication. Les personnes les plus impliquées devraient être responsables de l'intégration et de l'élimination de certaines des idées les plus complexes.

Cela m'amène à penser à un processus de développement plus axé sur les armatures et les prototypes.

Vous pouvez avoir un ensemble d'éléments de travail disponibles et encourager les gens à écrire des cadres de fil pour ceux-ci. Vous pouvez les utiliser comme Tracer Bullets (terminologie empruntée au programmeur Pragmatic) pour affiner l'idée et inspirer les gens sur lesquels s'appuyer. De là, vous pouvez transformer les idées réussies en prototypes, encore une fois ce sont de très petits projets conçus pour aider les gens à en savoir plus sur les projets. Après cela, vous avez maintenant une petite section d'idées solides qui ont été construites par une multitude de personnes que vous pouvez transmettre à une partie de l'équipe qui est un peu plus active et qui peut travailler pour intégrer ces idées dans votre système.

Je pense que Kanban conviendrait mieux à cette situation.

Scrum a quelques choses qui ne correspondent pas. Les mesures de calendrier ou de portée ne sont pas nécessaires et chaque personne en développement a la même vision du produit lors des réunions. La responsabilité et le respect d'un plan court avec cohérence sont des objectifs commerciaux.

Kanban offre pas mal des mêmes avantages que Scrum sans ses inconvénients. Il peut vous donner un prototypage rapide. Les protypes peuvent être exécutés avant les réunions. Il donne également TDD pour le code modifiable et les tests de régression. La programmation en binôme peut aider les nouveaux arrivants et les non-habitués à la base de code en transférant les connaissances.

Kanban présente également des avantages uniques. Si la vision de ce que font les utilisateurs se développe en parallèle, Kanban fonctionne bien. La preuve en est le succès des programmes pour les petites entreprises. De plus, pour les jours avec peu de bénévoles tels que trois personnes, Kanban fonctionnerait toujours bien. Scrum, malgré sa légèreté serait trop de ruban jaune.