Scrum est-il incompatible avec des offres publiques?


43

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?



1
Si le résultat, le prix et le calendrier peuvent tous être définis dès le départ, pourquoi s’embêter avec un processus agile?
JeffO

3
Scrum est compatible avec tout, par définition. Le paradigme "L'équipe possède le processus" permet de modifier radicalement le processus, afin que Scrum devienne une cascade, si nécessaire. Être «agile» ne signifie PAS que vous deviez suivre un processus sans déviation. Cela signifie que le processus peut être adapté aux besoins. Notez que ce point est extrêmement impopulaire auprès de la direction - ils veulent des processus fixes, et ils appellent tout ce qui est "agile" s’ils ont été accrochés à Agile / Scrum / Whatever.
Klaws

3
FWIW, IME, je n’ai jamais rien vu de tel que Sebazzz le décrit. Le contrat stipule spécifiquement ce qui doit être livré. Si cela ne répond pas aux exigences, alors vous n'avez pas terminé. Et c'est tout le problème des méthodes agiles "délivrez ce que vous avez lorsque les fonds sont épuisés". Il est rare que vous puissiez livrer un produit ne représentant qu'un sous-ensemble de ce dont le client a besoin et qui a réellement une valeur pour le client. Habituellement c'est la même chose car ça ne marche pas du tout. Des écarts peuvent être demandés, mais si cet écart supprime des fonctionnalités, il est presque certainement combiné à moins de fonds
Dunk

2
@ CortAmmon-Ce que j'ai vu le gouvernement faire est "intelligent" mais pas vraiment agile. Ils suivent toujours essentiellement la cascade, ils attribuent le contrat par phases au lieu de l’effort de développement du cycle de vie complet comme ils l’ont fait par le passé. Ils sont également plus enclins à embaucher plus d'un contractant, en particulier au stade de l'ingénierie, car cela leur permet de sélectionner de manière compétitive la meilleure solution qu'ils souhaitent migrer vers un produit pouvant être fabriqué. Cette dernière phase est la plus chère. Ils veulent voir ce qu'ils obtiennent avant de décider de fabriquer. Un produit partiellement opérationnel ne gagnera pas.
Dunk

Réponses:


38

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.


Excellente réponse. Il est très difficile, mais pas impossible, d'amener des organisations comme celle décrite par le PO à adopter une approche agile.
Monsieur Positive

1
@MisterPositive Vous n'avez peut-être pas besoin de l'institut de recherche pour devenir agile. Cependant, ils devront probablement être en mesure d'interagir avec des entités externes agiles lors de la passation d'un contrat. Ils peuvent voir les avantages de l'agilité, à coup sûr.
Thomas Owens

La bonne chose à propos de cette réponse est IMHO qu'il ne tombe pas dans le piège d'argument à propos de Scrum qui ne convient pas parce que "le résultat, le prix et la période" sont fixes.
Doc Brown

1
@ DocBrown Peut-être parce que Scrum peut être utilisé lorsque le prix et la période sont fixes. D'après mon expérience, lorsque vous livrez rapidement et que vous démontrez des choses aux parties prenantes, elles se rendent compte que ce qu'elles pensaient à l'origine avoir besoin et ce dont elles ont vraiment besoin sont deux choses différentes. Et ensuite, ils modifieront le résultat souhaité dans les délais et le prix d'origine.
Thomas Owens

Se mettre d'accord. Le logiciel n'est pas comme si un architecte concevait un bâtiment. C’est une cible en mouvement, le sol glisse toujours sous vos pieds. L'année prochaine, les efforts de l'année dernière semblent vains.

22

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:

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.


3
C'est une excellente réponse, en particulier les deux derniers paragraphes. C'est vraiment une excellente façon de mettre en cohérence des choses que je n'ai pas pu rassembler.
Thomas Owens

1
Oui, c'est la réponse. Le contrat et comment il a été écrit est le problème. Je ne peux ni confirmer ni nier que j’ai, à un moment de ma vie, travaillé pour une organisation de ce type, ou une organisation similaire, et lorsqu’ils sont passés à un contrat davantage axé sur les résultats, le développement agile a commencé à se répandre comme une traînée de poudre.
Greg Burghardt

Il semble donc que «l'architecte» ait besoin de rédiger l'appel d'offres avant de pouvoir le budgéter et de lui donner un délai. Il s’agit d’un processus en deux phases, la deuxième phrase étant: "vous, construisez-le, le jour d’ouverture est ..."

12

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.


5
Ce n'est pas vraiment répondre à la question. Que recommanderiez-vous à cette organisation?
Philipp

9
N’est-ce pas un cliché contre des gouvernements qui seraient responsables de tous les échecs, plus qu’une réponse constructive? Je ne sais pas dans votre pays, mais dans mon pays, de nombreux projets gouvernementaux ont été couronnés de succès. Je ne pourrai pas changer d'avis, mais voici un article intéressant basé sur des faits objectifs et des observations indépendantes: mckinsey.com/industries/public-sector/our-insights/…
Christophe

6
"C'est pourquoi tant de projets échouent. Après avoir dépassé largement le budget imparti". Ce trope est réclamé tout le temps par des personnes poussant des processus agiles. Et pourtant, il y a une tonne de sociétés de développement réussies qui n'utilisent aucune des méthodes agiles proposées. Ils ont tendance à le faire sans problèmes. En réalité, le vrai problème est de recruter le soumissionnaire le moins cher et de ne pas mettre suffisamment l’accent sur les performances passées et l’expertise du domaine. Blâmer le processus est un fouillis rouge. Toute équipe compétente peut atteindre le succès en utilisant n’importe quel processus raisonnable avec lequel elle a des compétences.
Dunk

OK, je me suis un peu emporté. Je recommanderais toujours de surveiller les progrès et d'assumer le rôle d'intervenant après la signature du contrat, en supposant qu'il est dans l'intérêt de tous que les résultats soient atteints. Et je ne prétends pas qu'Agile est la clé, je prétends qu'il n'y a pas de conflit avec les principes Agiles et a souligné un problème sous-jacent commun.
Martin Maat

Re: "en supposant que ce soit dans l'intérêt de tous": là où je vis, nous avons échoué dans un projet à long terme (pour l'extension d'un service public), avec la faillite du constructeur (un méga siècle vieux de plusieurs siècles). entreprise) et l’agence de service public ayant fait adopter une législation potentiellement illégale, et les clients s’attendaient à ce que tout le monde soit renfloué. Au gouvernement, ce genre de choses ne sont pas censées se produire, il est dans l'intérêt de tous que toutes les parties restent viables, respectent l'éthique et tiennent ce qu'elles ont promis. Vous ne savez pas si les processus peuvent vous aider ou non.

12

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.


3
Exactement ! C'est une réponse excellente et précise. Dans ce webinaire, projectmanagement.com/videos/290684/…, un responsable du gouvernement américain explique en détail comment cela fonctionne. Le principe du transfert de l'objet de l'appel d'offres du produit final au service de développement peut également être organisé de manière similaire dans de nombreuses autres législations sur les marchés publics. La principale difficulté réside principalement dans l'attitude parfois conservatrice de certaines parties prenantes et non dans la prétendue incompatibilité.
Christophe

1
Ils embaucheraient donc l'équipe de scrum la moins chère qu'ils puissent trouver et, lorsque le projet nécessiterait plus d'heures, ils embaucheraient la deuxième équipe la moins chère pour prendre en charge le développement en cours? Cette approche suppose que le client évalue la qualité de l'équipe de logiciels qu'il embauche. S'ils ont une telle expertise, je me demande ce dont ils ont besoin pour externaliser le contrat?
Meriton - en grève

@meriton: la plupart des offres sont passées par le gouvernement, qui est généralement tenu d'utiliser l' offre de qualification la moins chère . SCRUM ne change pas cela. Cependant, SCRUM place le propriétaire du produit dans un rôle actif, ce qui aide ici.
MSalters

Toutefois, si cela est convenu comme vous le suggérez, SCRUM modifie les incitations offertes au fournisseur de services. Ils ne peuvent plus être tenus pour responsables du non-respect des exigences, leur seule motivation est de baisser le prix, tout en respectant la lettre des critères de qualification, mais pas nécessairement leur esprit. Il est plus facile pour l’acheteur de déterminer si le logiciel répond aux exigences plutôt que si l’équipe est susceptible de produire un logiciel qui le fera. Mais oui, votre approche est l’un des meilleurs moyens d’utiliser SCRUM dans le secteur public. Je voulais juste mentionner pourquoi les acheteurs pourraient ne pas vouloir l'adopter.
Meriton - en grève

9

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).


3
+1 Je ne peux pas compter le nombre de fois que le travail a été effectué parce qu'une personne a accepté un contrat manifestement médiocre, puis a utilisé cette connexion pour convertir le contrat en une offre plus proche de ce que le client voulait réellement.
Cort Ammon

1
Permettez-moi de souligner ce fait - cette réponse indique que Scrum n'est pas incompatible avec les marchés publics, mais que le développement de logiciels basé sur des contrats en général . Pas que je sois en désaccord.
Doc Brown

3

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 ...)


J'allais écrire un commentaire comme votre dernière déclaration entre parenthèses, mais je vous laisserai obtenir le crédit :)

3

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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.