Un organisme public m'a demandé de donner un atelier informel sur le développement agile en expliquant les termes et concepts de Scrum, Kanban, etc. Je travaille dans des environnements agiles depuis environ cinq ans maintenant, mais je ne me considère pas comme un évangéliste Scrum.

Après l'atelier, ils ont aimé l'idée. Cependant, ils ont expliqué que l'approche ne leur serait probablement pas appliquée, car ils doivent faire appel à des éditeurs de logiciels externes pour développer des logiciels pour eux (ils ne disposent que de peu de développeurs eux-mêmes). Cette activité doit être réalisée dans le cadre d’un processus d’appel d’offres public décrivant le résultat, le prix et le calendrier. C'est une obligation légale de demander un budget pour cette organisation (un institut de recherche public).

Ces contraintes semblent quelque peu contradictoires aux principes fondamentaux du développement agile, n'est-ce pas?

Scrum est-il simplement incompatible dans un tel environnement?

Que recommanderiez-vous à cette organisation?

Scrum n'est probablement pas approprié pour cette organisation.

Dans Scrum Guide, "Scrum est un cadre de développement, de fourniture et de maintenance de produits complexes". Il est également conçu pour une équipe de 3 à 9 membres d'une équipe de développement travaillant sur le produit, un responsable de produit et un Scrum Master (qui peut ou non faire partie de l'équipe de développement) pour un total de 4 à 11 personnes.

En ce qui concerne le développement interne, vous indiquez qu’ils n’ont que quelques développeurs. S'il n'y a pas une équipe assez nombreuse pour former une équipe Scrum, il n'est pas logique d'utiliser tout Scrum. Cependant, certaines pratiques Scrum peuvent être utiles à l’organisation.

Pour le développement sous contrat, il est possible qu'une des parties externes utilise Scrum. Dans ce cas, il est utile que l'institut de recherche connaisse les pratiques Scrum et comprenne les rôles et son fonctionnement. Ils auront peut-être encore besoin de comprendre les spécificités de la manière dont une organisation de développement externe utilise les pratiques Scrum ainsi que d'autres pratiques, mais cela peut les aider à comprendre son fonctionnement. Par exemple, comprendre la nécessité de participer aux revues de sprint ou de travailler avec l'organisation (probablement le responsable de produit) pour commander le backlog de produit.

18F, une agence de services numériques du gouvernement américain, a beaucoup travaillé sur la manière dont le gouvernement peut rédiger des contrats permettant l'utilisation de méthodes agiles d'une manière compatible avec la loi, spécifiant des résultats généraux plutôt que des exigences détaillées concernant la manière dont le travail est effectué. est à faire. Certaines de leurs ressources incluent:

• Améliorer les résultats du gouvernement grâce à un format de contrat agile
• Contrat d'achat global agile
• Modular Contracting (diviser de grands projets en projets modulaires plus petits avec un développement agile)
• Votre projet utilise-t-il «agilefall»?

Les méthodes de travail agiles présentent l’avantage de rechercher une solution à un problème après l’attribution du contrat, c’est-à-dire après l’exécution du contrat, plutôt que de spécifier la solution détaillée dès le début, comme dans la partie 15. Un contrat agile tente de: spécifier les problèmes nécessitant des solutions détaillées, souvent sous la forme d'éléments de backlog de produit décrivant les domaines de livraison de contrat de haut niveau.

Conscients de ce problème, le Bureau de la gestion et du budget et la Politique des marchés publics fédéraux ont ordonné aux agences de cesser d’utiliser les EDT et de passer à un énoncé de performance pour l’acquisition de services. Un PWS "devrait énoncer ses exigences en termes généraux sur ce que (le résultat) doit être fait, plutôt que sur la méthode (la méthode)", explique-t-il. De bons agents de négociation des contrats informent les agences qu'en achetant des services d'experts, cela signifie que vous n'êtes pas le plus informé dans "comment" le travail est fait. En tant que propriétaire de la mission, vous êtes un expert du «quoi», mais vous devez le faire, mais le fait de confondre ces deux éléments met votre mission en péril et rend plus difficile la création de valeur pour un contrat.

Fondamentalement, l'approche consiste davantage à faire appel à un prestataire de services pour travailler avec vous à la conception d'une solution, plutôt qu'à la liste préalable de pages de spécifications détaillées. L’institution n’engagerait pas un architecte pour concevoir un nouveau bâtiment en indiquant "le projet doit comporter quatre étages, avec une pente de toit de 37 °. Le troisième étage doit comporter une cuisine de 237 pieds carrés contenant quatre luminaires fluorescents, contrôlés par un -interrupteur sensible, dans un plafond suspendu. " Au lieu de cela, ils auraient un contrat avec l’architecte pour fournir des services de conception en consultation avec le client et compteraient sur leur fournisseur, expert dans le domaine, pour produire les produits livrables résultants.

Bien que les détails dépendent de l'institution et des politiques et lois en vigueur en matière de passation de marchés, cela montre que, malgré tous les échecs des grands projets informatiques du gouvernement, certains groupes s'efforcent de faire passer les appels d'offres publics pour le développement de logiciels à des méthodologies agiles plus modernes. suffisamment de volonté politique et de partenaires de développement dignes de confiance. Il faut un changement majeur dans la conception et la gestion de tels projets (y compris une longue période de temps pour fournir des commentaires aux utilisateurs tout au long du processus), ce que l’organisation peut ne pas avoir intérêt à poursuivre.

Cela semble typique. Une fois que l'appel d'offres a été rédigé, que les offres ont été reçues et que le contrat a été attribué à l'un des candidats. Pour ce qui est des représentants de l'organisme public, le projet est terminé.

C'est pourquoi tant de projets échouent. Après avoir dépassé largement le budget.

Le point qui leur manque (ou du moins qui ne les préoccupe pas du tout) est qu’il s’agit d’intervenants qui devraient assister à des réunions et à des démonstrations.

Il n’ya donc aucun conflit avec Agile ou Scrum. Ce sont les gens qui ne prennent pas leurs rôles en main. C'est la façon dont le gouvernement fonctionne qui est la cause.

Ce n'est pas comme "on aimerait avoir ce système et on est prêt à y mettre un effort et à voir jusqu'où on peut aller".

Non, c'est comme "notre démocratie a décidé que nous aurons ce système d'ici là". Ce qui ne laisse aucune place entre 100% de succès d’une part et 100% d’échec de l’autre. Doomed dès le début.

C'est également une invitation au marché à demander des taux ridicules. Ne pas faire le projet parce qu'il est trop cher n'est pas une option, la décision de le faire a déjà été prise avant la rédaction de l'appel d'offres.

Très bien, même si les parties prenantes assumaient leurs rôles, elles seraient totalement impuissantes. Aucun d'entre eux n'aurait un bâton crédible à prendre pour ces démos pour la même raison.

Non, SCRUM n'est pas incompatible avec des offres publiques. Vous devez indiquer explicitement ce que vous achetez dans un appel d'offres.

"L'acheteur cherche à acheter 10 sprints de développement de 2 semaines, d'une équipe expérimentée de SCRUM composée de 5 développeurs et d'un maître certifié de SCRUM (l'acheteur remplira le rôle d'intervenant). Les sprints se dérouleront de mars 2018 à juillet 2018" est assez raisonnable début de l'appel d'offres. Vous devrez bien sûr énumérer les compétences d’équipe nécessaires et donner une idée du projet sur lequel ils vont travailler, mais il est parfaitement acceptable de passer un appel d’offres pour pouvoir engager une équipe.

Bien sûr, vous abandonnez la "portée fixe" ici. C'est typique de SCRUM, après tout. Avec un peu plus de libellé dans l'appel d'offres (mais nous entrons dans le territoire légal), vous pouvez autoriser une petite extension de portée, c'est-à-dire un petit nombre de sprints supplémentaires. Mais si vous décidez que vous souhaitez 10 sprints supplémentaires après les 10 premiers sprints, vous devrez probablement repasser en appel d'offres.

C'est difficile.

Vous ne pouvez évidemment pas soumissionner avec un budget illimité. Vous devez donc déterminer ce qui doit être fait et les efforts nécessaires pour le faire.

Maintenant, la raison pour laquelle de nombreux projets logiciels échouent est due au fait que la réparation, le temps, les efforts et la portée à l’avance sont très sujettes aux erreurs. Par exemple, une spécification telle que donnée dans une offre aura presque toujours une certaine ambiguïté.

Il existe donc un problème fondamental, non seulement avec l'agile, mais avec le concept d'appels d'offres ouverts pour le développement de logiciels. Les chances que quelqu'un crée exactement ce que vous vouliez, dans le délai que vous avez spécifié, sont faibles.

Si vous permettez une certaine flexibilité, vous pouvez améliorer cela.

Il semble que le processus de mise au concours public ne soit pas flexible. Cependant, une fois le contrat remporté, vous constaterez peut-être qu'il reste une marge de manœuvre. Vous pouvez, par exemple, autoriser le travail agile, mais vous devez accepter (et obtenir une autorisation légale) que cela peut affecter la portée.

Maintenant, je pense que cela résulterait en un meilleur produit car vous pourrez voir ce qui se passe tôt et apporter des modifications avant que le produit ne soit cuit. Des boucles de rétroaction serrées et un développement itératif peuvent rendre les produits mieux adaptés aux exigences réelles (qui peuvent être ou ne pas être ce qui a été mis en adjudication).

Cela dépend, mais probablement oui.

Je suis prêt à parier que tous ceux qui ont déjà travaillé avec un gouvernement sur un projet informatique sauront que, dans la pratique, les «limites strictes» décrites dans l'appel d'offres ne sont jamais toutes respectées. Les choses ont tendance à dépasser le budget, à être retardées et / ou à changer de portée. Généralement multiple de ceux-ci. Si les gouvernements acceptent d'admettre que telle est la vérité et acceptent de les traiter comme leurs lignes directrices, alors Scrum peut fonctionner très bien.

Par expérience personnelle (à la fois dans mon propre réseau et dans celui de mon réseau professionnel), je sais que les exigences changent fréquemment dans la majorité des projets gouvernementaux. Les comités responsables ont également tendance à avoir beaucoup de réactions lorsqu'ils finissent par s'impliquer à la fin du projet. Ce sont des problèmes pour lesquels Scrum est bien adapté.

Cependant, cela nécessiterait un changement fondamental de la mentalité des gouvernements et de leurs agences. Dans la plupart des pays, il est très peu probable que ce changement se produise. Jusque-là, les offres publiques continueront d'être incompatibles avec Scrum. (D'ailleurs, à mon avis, les offres publiques continueront d'être incompatibles avec toute pratique de développement logiciel durable, mais c'est une autre affaire pour une autre fois ...)

Que recommanderiez-vous à cette organisation?

À ce stade rien.

Ce qui manque ici, c’est l’histoire des problèmes que leur cause actuellement leur cause. Scrum n'est pas quelque chose à recommander aveuglément. Il a un point. Ce n'est pas une taille unique.

Demandez-leur quels problèmes leur a causé le processus actuel. Écoute Ne recommande que des méthodes qui traitent de leurs vrais problèmes. Ils vont avoir un parti pris pour leur processus actuel. Les Tinders peuvent sembler imposer un processus de développement, mais ils ne le font pas. Ils dictent un processus de livraison. Mais c’est une distinction que cette équipe n’a probablement jamais eu à faire auparavant.

Agile fonctionne mieux lorsque les exigences changent de plus de 3% sur la durée de vie du projet. Sinon la cascade est toujours très efficace. Il est encore utilisé dans de nombreux endroits aujourd'hui. Et bien entendu, de nombreux développeurs performants ne formalisent jamais leur processus. Informel fonctionne bien lorsque les problèmes difficiles sont techniques, pas au sujet des personnes.

Parlez-leur donc de leur processus actuel et de ses problèmes. Dites-leur en quoi ces méthodes aident. Mais si ce n'est pas cassé ne le répare pas.