Scrum est-il incompatible avec les appels d'offres publics?
Un organisme public m'a demandé de donner un atelier informel sur le 101 du développement agile expliquant les termes et les 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 s'appliquerait probablement pas à eux, car ils doivent charger des sociétés de logiciels externes de développer des logiciels pour eux (ils n'ont que peu de développeurs eux-mêmes). Cette activité doit être effectuée dans le cadre d'un appel d'offres public qui décrit le résultat, le prix et le calendrier. Il s'agit d'une obligation légale de demander un budget pour cet organisme (un institut de recherche public).
Ces contraintes semblent quelque peu contradictoires avec les principes fondamentaux du développement agile, n'est-ce pas?
Scrum est-il juste incompatible dans un tel environnement?
Que recommanderiez-vous à cette organisation?
Scrum n'est probablement pas approprié pour cette organisation.
D'après le Guide Scrum, "Scrum est un cadre pour développer, livrer et maintenir des 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 propriétaire de produit et un Scrum Master (qui peuvent 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 mentionnez qu'ils n'ont que quelques développeurs. S'il n'y a pas une équipe suffisamment grande 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 pour l'une des parties externes d'utiliser Scrum. Dans ce cas, il est utile pour l'institut de recherche de connaître les pratiques Scrum et de comprendre les rôles et leur fonctionnement. Ils peuvent encore avoir besoin de comprendre les détails de la façon dont l'organisation de développement externe utilise les pratiques Scrum ainsi que d'autres pratiques, mais cela peut les aider à comprendre comment cela fonctionne. Par exemple, comprendre la nécessité de participer à des revues Sprint ou travailler avec l'organisation (probablement leur Product Owner) pour commander le Product Backlog.
18F, une agence de services numériques au sein du gouvernement américain, a fait beaucoup de travail sur la façon dont le gouvernement peut rédiger des contrats pour permettre l'utilisation de méthodologies agiles d'une manière conforme à la loi, en spécifiant des résultats généraux plutôt que des exigences détaillées sur la façon dont le travail doit être fait. Certaines de leurs ressources comprennent:
- Amélioration des résultats du gouvernement grâce à un format de contrat agile
- Contrat d'achat de couverture agile
- Modular Contracting (décomposition de grands projets en projets modulaires plus petits avec développement agile)
- Votre projet utilise-t-il "agilefall"?
Un avantage des méthodes de travail agiles est qu'elles se concentrent sur la découverte d'une solution à un problème après l'attribution du contrat, c'est-à-dire pendant l'exécution post-attribution, plutôt que de spécifier la solution détaillée à l'avance comme dans la partie 15. Un contrat agile essaie de spécifiez les problèmes nécessitant des solutions détaillées, souvent sous forme d'éléments de backlog de produit qui décrivent des zones de livraison de contrat de haut niveau.
Comprenant ce problème, le Bureau de la gestion et du budget et le Bureau de la politique fédérale des achats ont ordonné aux agences de cesser d'utiliser les EDT et de passer à l'utilisation d'un énoncé de travail sur la performance (PWS) pour acquérir des services. Un PWS "devrait énoncer les exigences en termes généraux de ce qui (résultat) doit être fait, plutôt que comment (méthode) il est fait". Les bons agents de négociation des contrats indiquent aux agences qu'en achetant des services d'experts, cela implique que vous n'êtes pas le plus compétent dans "comment" le travail est fait. En tant que propriétaire de la mission, vous êtes l'expert du "quoi", doit être accompli, mais la combinaison des deux met votre mission en danger et rend plus difficile pour un contrat de fournir de la valeur.
Fondamentalement, l'approche ressemble plus à l'embauche d'un fournisseur de services pour travailler avec vous pour concevoir une solution, plutôt que de lister à l'avance des pages de spécifications détaillées. L'institution n'embaucherait pas un architecte pour concevoir un nouveau bâtiment en énumérant "le design doit être de quatre étages, avec une pente de toit de 37 °. Le troisième étage doit avoir une cuisine de 237 pieds carrés contenant quatre luminaires fluorescents, contrôlée par un mouvement -interrupteur d'éclairage sensible, dans un plafond suspendu. " Au lieu de cela, ils auraient un contrat pour que l'architecte fournisse des services de conception en consultation avec le client et s'appuieraient sur leur fournisseur, un expert dans le domaine, pour produire les livrables résultants.
Bien que les détails dépendent de l'institution et des politiques et lois d'approvisionnement applicables, cela montre que, parmi tous les échecs des grands projets informatiques du gouvernement, il existe des groupes qui travaillent pour déplacer les appels d'offres publics pour le développement de logiciels vers des méthodologies agiles plus modernes, une volonté politique suffisante et des partenaires de développement dignes de confiance. Cela nécessite un changement majeur dans la façon dont ces projets sont conçus et gérés (y compris beaucoup de temps continu à fournir des commentaires des utilisateurs tout au long du processus), que l'organisation peut ou non avoir intérêt à poursuivre.
Non, SCRUM n'est pas incompatible avec les appels d'offres publics. Vous devez indiquer explicitement ce que vous achetez dans un appel d'offres public.
"L'acheteur cherche à acheter 10 sprints de développement de 2 semaines, auprès d'une équipe SCRUM expérimentée comprenant 5 développeurs et un maître SCRUM certifié (l'acheteur remplira le rôle de partie prenante). 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 lister les compétences nécessaires en équipe et donner une idée du projet sur lequel ils vont travailler, mais il est parfaitement acceptable d'avoir un appel d'offres pour embaucher 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'offre (mais nous entrons dans le territoire légal ici), 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 sprints initiaux, vous devrez probablement procéder à un nouvel appel d'offres.
Cela semble typique. Une fois l'appel d'offres rédigé, les offres sont reçues et l'un des candidats a obtenu le contrat ... pour les représentants de l'organisation publique, le projet est terminé.
C'est pourquoi tant de ces projets échouent. Après avoir dépassé le budget.
Le point qui leur manque (ou du moins ne pense pas que cela les préoccupe) est qu'ils sont des parties prenantes qui devraient assister aux réunions et aux démonstrations.
Il n'y a donc aucun conflit avec Agile ou Scrum. Ce sont des gens qui ne prennent pas leurs rôles. C'est la façon dont le gouvernement fonctionne qui en est la cause.
Ce n'est pas comme "nous aimerions avoir ce système et nous sommes prêts à y mettre un peu d'efforts et à voir jusqu'où nous pouvons 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 d'autre part. Condamné depuis le début.
C'est aussi une invitation au marché à demander des tarifs 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'offre.
Assez juste, même si les parties prenantes reprenaient 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.
C'est difficile.
Vous ne pouvez évidemment pas soumissionner le travail avec un budget ouvert. Vous devez donc regarder ce qui devra être fait et combien d'efforts seront nécessaires pour y parvenir.
Maintenant, la raison pour laquelle de nombreux projets logiciels échouent est due au fait que la réparation, le temps, l'effort et la portée à l'avance sont très sujets aux erreurs. Par exemple, une spécification telle que donnée dans un appel d'offres aura presque toujours une certaine ambiguïté.
Il y a donc un problème fondamental non seulement avec l'agilité, mais avec le concept d'appels d'offres ouverts pour le développement de logiciels. Les chances que quelqu'un s'en aille et crée exactement ce que vous vouliez, dans le temps que vous avez spécifié, sont faibles.
Si vous autorisez une certaine flexibilité, vous pouvez l'améliorer.
Il semble que le processus de soumission des travaux aux appels d'offres publics ne soit pas flexible. Cependant, une fois le contrat remporté, vous trouverez peut-être une marge de manœuvre. Vous pouvez, par exemple, autoriser le travail agile, mais vous devez accepter (et obtenir l'autorisation légale) que cela pourrait affecter la portée.
Maintenant, je crois que cela aboutirait à un meilleur produit car vous pourrez voir ce qui se passe tôt et apporter des modifications avant qu'elles ne soient intégrées au produit. 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 ou non être celles qui ont été mises 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 qu'en 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 la portée est modifiée. Habituellement, plusieurs d'entre eux. Si les gouvernements sont prêts à admettre que c'est la vérité et à vouloir les traiter comme les directives qu'ils sont, alors la mêlée peut très bien fonctionner.
Par expérience personnelle (à la fois personnelle et dans mon réseau professionnel), je sais que les exigences changent fréquemment dans la majorité des projets gouvernementaux. Les commissions responsables ont également tendance à avoir beaucoup de retours lorsqu'elles finissent par s'impliquer à la fin d'un projet. Ce sont des problèmes pour lesquels Scrum est bien adapté.
Cependant, cela nécessiterait un changement fondamental de mentalité de la part des gouvernements et de leurs agences. Dans la plupart des pays, il est très peu probable que ce changement ait lieu. Jusque-là, les appels d'offres publics seront toujours incompatibles avec le travail avec Scrum. (D'ailleurs, à mon avis, les appels d'offres publics continueront d'être incompatibles avec tout les pratiques de développement de logiciels durables, mais c'est une autre question 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 processus actuel 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 processus actuel leur a causés. Ecoutez. Ne recommandez que des méthodes qui répondent à leurs problèmes réels. Ils vont être partisan de leur processus actuel. Les Tinders peuvent sembler dicter un processus de développement, mais ce n'est pas le cas. 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% pendant la durée du projet. Sinon, la cascade est toujours très efficace. Il est encore utilisé dans de nombreux endroits aujourd'hui. Et bien sûr, de nombreux développeurs qui réussissent ne formalisent jamais leur processus de toute façon. L'informel fonctionne bien lorsque les problèmes difficiles sont techniques, pas pour les gens.
Alors, parlez-leur de leur processus actuel et de ses problèmes. Expliquez-leur en quoi ces méthodes aident. Mais si ce n'est pas cassé, ne le réparez pas.