Faire face aux échecs de sprints et de délais

De nombreux ouvrages et articles de Scrum indiquent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du backlog de sprint) n'est pas si grave, il arrive de temps en temps et peut s'avérer utile si l'équipe apprend de ses erreurs. et améliore quelque chose dans les sprints suivants. Et l'équipe ne doit pas être punie pour ne pas avoir achevé le travail auquel elle s'est engagée.

Cela semble très bien du point de vue du développeur. Cependant, supposons que nous avons une société de logiciels " Scrum-Addicts LLC " qui développe quelque chose pour les clients sérieux (" Money-Bags Corporation "):

1. Les gestionnaires de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags
2. Ils s'accordent sur une liste de fonctionnalités et Money-Bags demande de fournir une date d'expédition
3. Les responsables de Scrum-Addicts consultent leur équipe de mêlée et celle-ci indique qu'il faudra 3 sprints d'une semaine pour compléter toutes les fonctionnalités.
4. Le responsable de Scrum-Addicts ajoute une semaine pour plus de sécurité, s’engage à expédier le logiciel dans un mois et signe un contrat avec Money-Bags
5. Après 4 sprints (délai d'expédition), l'équipe Scrum ne peut fournir que 80% des fonctionnalités (en raison de l'inexpérience avec le nouveau système, de la nécessité de corriger les bugs critiques des fonctionnalités précédentes dans l'environnement de production, etc.).
6. Comme le suggère Scrum, à ce stade, le produit est potentiellement livrable, mais Money-Bags a besoin de 100% des fonctionnalités, comme indiqué dans le contrat. Alors ils rompent le contrat et ne paient rien.
7. Scrum-Addicts est au bord de la faillite car Money-Bags ne leur a pas donné d'argent et les investisseurs ont été déçus des résultats et ne veulent plus aider la société.

De toute évidence, aucun éditeur de logiciel ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas à propos d’Agile et de Scrum, c’est la façon dont ils suggèrent aux équipes de gérer la planification et les délais afin d’éviter la situation décrite ci-dessus. Donc, pour résumer, j'ai 2 questions:

Qui est à blâmer?

1. Les gestionnaires, car c'est à eux de faire la planification appropriée
2. L'équipe, parce qu'ils se sont engagés à faire plus de travail qu'ils ne le pourraient
3. Quelqu'un d'autre

Qu'y a-t-il à faire?

1. Les gérants doivent déplacer l'échéance deux fois (ou trois fois) plus tard que l'estimation de l'équipe d'origine.
2. Les membres de l'équipe doivent être encouragés à faire tout le travail auquel ils se sont engagés, peu importe les circonstances (en infligeant des pénalités pour les sprints manqués).
3. L'équipe doit abandonner Scrum car cela ne correspond pas à la politique de l'entreprise en matière de délais
4. Nous devrions tous abandonner le développement de logiciels et rejoindre un monastère
5. ???

Je vois plusieurs problèmes de gestion fondamentaux dans votre exemple:

• si un responsable de Scrum-Addicts signe un contrat à "délai ferme", mais n’ajoute qu’une marge de sécurité de 33% dans une situation où "un nouveau système est impliqué", c’est assez téméraire.

• la possibilité de livrer au moins x% des fonctionnalités après un mois aurait pu être utilisée pour négocier un contrat dans lequel le client paie au moins partiellement l'argent alors qu'il ne reçoit que 80% des fonctionnalités à la date limite. Un contrat "tout ou rien" est quelque chose dont ni le fournisseur de logiciels ni le client ne bénéficieront. Cela signifie non seulement 0 dollar pour le fournisseur, mais également 0 fonctionnalités pour le client. Et une méthodologie de développement tout-ou-rien comme "Waterfall" ne vous laissera que rédiger de tels contrats; une approche agile offre des possibilités supplémentaires.

• En regardant les résultats du premier ou des deux premiers sprints, le manager aurait dû se rendre compte que l'équipe ne pouvait pas respecter l'échéance. Il aurait donc dû prendre des mesures plus tôt et redéfinir les priorités des tâches et fonctionnalités restantes, ou essayer de renégocier avec le client plus tôt. Par exemple, le responsable aurait pu essayer de réduire la portée de certaines des fonctionnalités restantes. L'équipe aurait donc pu fournir toutes les fonctionnalités mentionnées dans le contrat, mais chacune d'entre elles dans une portée réduite.

Si une tâche prend plus de temps que prévu, aucune méthodologie de développement ne vous épargnera. Cependant, une approche agile telle que Scrum offre aux responsables plus de possibilités pour contrôler ce qui se passe dans cette situation. S'ils n'utilisent pas ces opportunités, c'est clairement leur faute, pas celle de l'équipe, ni celle de "Scrum", ni celle du client car "il n'accepte pas l'agilité".

Un des énoncés de valeur du " Manifeste pour le développement logiciel agile " est le suivant:

Collaboration client sur négociation de contrat

Le fait que Scrum-Addicts LLC ait négocié un contrat au lieu d'établir une collaboration avec un client me fait douter de son agilité.

Une chose est claire: l’agilité doit être acceptée par tout le monde. L'agilité n'est pas seulement pour les développeurs. Les gestionnaires et les clients doivent également accepter les valeurs du Manifeste Agile. Si les clients n'acceptent pas l'agilité et exigent toujours des contrats rigides et une collaboration minimale, n'utilisez pas l'agilité ou ne trouvez pas de meilleurs clients.

C'est la faute du client, ils sont bloqués dans leur bulle de contrat avec un développement basé sur des délais.

Qui est à blâmer?

Gestionnaires, service juridique, comptables - faites votre choix ...

Je sais que l'exemple est quelque peu artificiel, mais le fait que la société puisse s'en aller sans payer un centime s'il n'était pas satisfait à 100% aurait dû sonner l'alarme immédiate, tout comme le mélange de réflexion agile et de réflexion agile.

Les clients veulent avoir leur gâteau et le manger - ils sont heureux d'accepter cascade, mini-cascade, agile, la-la-la-terre tant qu'ils obtiennent le produit X pour $ Y par date Z.

Le développement agile exige absolument que l'équipe de développement et le client soient sur la même page du point de vue de la méthodologie. Penser aux différences de culture ne fera que ressortir dans le lavis.

Les projets informatiques traitent des inconnus ; certaines de ces inconnues sont même inconnues . Qu'est-ce que ça veut dire?

Prenons par exemple un pont jouet pour votre modèle de chemin de fer. Il y a tous les paramètres que vous connaissez:

• Vous savez combien la vallée est grande

• Vous connaissez le matériau des montagnes, leur hauteur, leur stabilité, etc.

• Vous savez combien de matériel vous avez besoin

• Vous savez de précédents "projets" combien de temps il vous a fallu pour construire des choses similaires

De nombreuses variables interviennent dans votre calcul d’investissement de temps et d’argent. Mais vous pouvez dire sans réfléchir si c'est terminé le week-end prochain.

Prenons l'exemple un peu plus loin:

• Supposons que vous ne construisiez pas le pont pour votre propre modèle de chemin de fer, mais que vous le construisiez pour un étranger: votre travail consiste à construire un pont de chemin de fer entre deux montagnes.

• Supposons que vous ne disposiez d'aucune information à l'avance du paysage modèle

• L'information sur le paysage est, c'est-à-dire a deux montagnes, qui ne semblent pas trop grandes

• La consistance de la montagne est entre roche et gelée

• Le coût total a un maximum de 10 $

• Le lieu de travail est complètement noir et il n'y a aucune chance de lumière: vous avez seulement une boîte de 8 allumettes

• La date limite est de 3 heures

Ce serait l'analogie avec un projet informatique. Vous avez de l'expérience dans la construction de ponts et il est facile de marcher sur un terrain connu. Ce qui rend difficile, c'est l'obscurité . Il y a beaucoup de choses que vous pouvez à peine prédire: Les mesures des montagnes ne sont connues qu'après avoir passé du temps dans l'obscurité. La cohérence des montagnes l'est aussi. À partir de là, vous pourriez faire une estimation du temps que cela vous prendra et de son coût. Ici, les inconnues sont des choses que vous ne connaissez pas au début du projet, comme le terrain concret, etc. Mais il y a des choses que vous ne pouvez pas prévoir, même avec la plus grande expérience et les estimations les plus conservatrices. Ces choses sont les inconnues inconnues qui portent un peu de chaos.

Chaque entreprise informatique devrait le savoir. Ils doivent faire face aux risques du projet.

1) Il existe plusieurs façons de minimiser le risque (financier): l’accord peut inclure que le client paie pour chaque augmentation de travail. Donc, après que l'incrément 1 soit livré, un tarif partiel doit être payé. Tant que Scrum-Addicts LLC livre ses résultats, le risque financier est minime. Plus les objectifs de sprint à grain fin sont planifiés, plus le risque total de chaque sprint est faible. Cela signifie que, si Money-Bags Corporation a reçu 80% du contrat, elle devrait au moins payer 80% de la valeur du contrat. S'ils refusent de payer après un sprint raté, le risque n'est pas aussi élevé que le refus de payer à 100%.

2) Scrum-Addicts LLC a un problème avec leurs développeurs

Les responsables de Scrum-Addicts consultent leur équipe Scrum. Selon l'équipe, il faudra trois sprints d'une semaine pour compléter toutes les fonctionnalités. Le responsable de Scrum-Addicts ajoute une semaine pour être sûr, promet d'envoyer le logiciel dans un mois et signe un contrat. avec des sacs d'argent

Cela suggère que a) les développeurs n’ont pas d’expérience avec Scrum ou b) qu’ils ne font pas correctement Scrum. Plus les équipes travaillent longtemps avec Scrum, meilleures sont leurs estimations. Si les équipes font des estimations et que le manager ajoute un "tampon" comme "sécurité", le manager semble en savoir plus que l'équipe, ce qui est un mauvais signe . Si vous avez une équipe expérimentée, vous n'avez pas besoin d'un "managerbuffer", l'équipe l'a déjà inclus dans l'estimation. L’idée est que plus l’équipe a travaillé ensemble sur les sprints, plus elle connaît ses forces et ses faiblesses et dispose de certains paramètres pour faire des estimations réalistes. Bien sûr, il y a - comme déjà mentionné - les inconnues inconnuesqui ont tendance à rendre les estimations difficiles; ou du moins imprécis. Mais à long terme, les estimations devraient aller de mieux en mieux.

Qui est à blâmer?

1) gestion

Comme indiqué ci-dessus: il y a clairement un échec dans la gestion des risques. Si l'entreprise est au bord de la faillite, elle le mérite. Si vous travaillez dans une telle entreprise: partez!

2) l'équipe

Même si la direction est complètement stupide, l’équipe aurait dû s’opposer à un tel projet. Un bon manager devrait connaître les risques; mais un bon développeur doit signaler les risques. Et surtout: l’équipe doit se présenter tôt si quelque chose échoue.

Qu'y a-t-il à faire?

Maintenant: amenez vos valises à la cour

Pour l'avenir: ne faites pas de tels contrats

Scrum n'est pas à blâmer pour l'échec de la gestion. Scrum a été développé sur la base de l’expérience de nombreux projets informatiques en échec. Il ne peut empêcher l’échec, ni remédier à l’incompétence des équipes ou du management. L'idée de base est:

• structurer les moyens de communication (qui parle à qui, quand et de quoi)

• encourager les développeurs à signaler les échecs de manière précoce

• diviser les problèmes en tâches et sous-tâches

• structurer le temps et les capacités (qui travaille quand sur quoi)

• répartir les tâches sur les plages horaires

• rendre l'imprévisible un peu plus prévisible (planification du poker)

ou globalement: pour minimiser les risques.

Scrum est un outil comme un marteau. Que ce soit un bon outil dépend de votre connaissance de l’utiliser. Mais parfois, un tournevis convient mieux. C'est à vous.

Tout d'abord, "qui est à blâmer?" est la mauvaise question à poser. Assigner le blâme est amusant et tout, et fera probablement que tout le monde sauf le (s) responsable (s) se sente soulagé (dans un "hé, ce n'est pas de ma faute, le patron l'a dit!"), Mais ce n'est pas une utilisation productive de votre temps , et peut effectivement être contre-productif et provoquer une baisse du moral des employés.

Une meilleure façon de voir les choses est "Quelle est la cause du retard?". Était-ce un manque d'expérience dans la technologie? Bugs critiques non détectés lors des tests / assurance qualité? Manque de test / QA? Trop optimiste dans l'estimation? Ne pas prendre en compte les estimations pas si optimistes de l'équipe? Quelqu'un a été frappé par un bus? Quelle que soit la cause, la question suivante est "Comment faire en sorte que cela ne se reproduise plus?". Dans certains cas (espérons-le rares), la réponse à cette question pourrait être "se débarrasser de tel ou tel", mais si vous partez de "je dois punir le responsable", il est peu probable que vous voyiez la majorité des cas où ce n'est pas la bonne solution.

Dans le projet, vous êtes déjà coulé. La date butoir étant passée, vous avez prévenu le client dès qu'il était évident qu'il allait glisser (parce que vous l'avez fait, non? Si non, c'est une partie du problème), et il faut maintenant le gérer comme il était précisé dans le contrat (il est en fait précisé dans le contrat, non?). De manière générale, cela devrait impliquer de négocier avec le client la manière dont vous allez livrer ce qui manque. Beaucoup de gens aiment penser à un contrat comme quelque chose qui ne peut pas être changé, mais devant soit: a) le laisser tomber et ne pas avoir ce que vous avez acheté, b) poursuivre la société en justice pour rupture de contrat et dépenser beaucoup d'argent devant les tribunaux, et c) en négociant comment obtenir leur produit avec le moins de problèmes possible, la plupart des entreprises choisissent c.

Avant de proposer un prix / une date limite à un client, vous devez analyser les risques liés à une échéance décalée ou à un dépassement des coûts (quelles en sont les causes possibles? Quelles causes pouvez-vous atténuer d'une manière ou d'une autre et que vous ne pouvez pas juste planifier et utiliser ces informations pour vous aider à décider de ce que vous allez promettre. Si c'est un cas où c'est 100% ou rien, vous indiquerez évidemment des prix plus élevés et des délais plus longs, car le risque est plus élevé.

Vous remarquerez que je n'ai pas parlé d'Agile dans toute cette réponse. C'est parce que (je vais oublier une seconde la participation du client à Scrum, bien que ce soit très, très important), à ce stade, cela n'a pas vraiment d'importance. Vous serez confronté à ce problème dans Agile, Waterfall ou tout autre processus de développement que vous utilisez. Oui, Agile est censé vous aider à mieux gérer les risques, en vous permettant de voir s'ils sont devenus des problèmes réels plus tôt, et d'impliquer le client dans le processus lui-même afin qu'il soit toujours informé, mais ce n'est pas une panacée.

Tout d’abord, c’est un problème de méthodologie de développement. Au moins avec un système de développement itératif, vous avez quelque chose à montrer au client à la fin du délai, ce qui peut suffire à obtenir une extension pour compléter le produit (même si le client ne paie plus!).

Il existe des cas où une date limite est une date limite, mais imaginez que vous écrivez un jeu et que celui-ci doit absolument être publié à temps pour les vacances de Noël. Se tromper a fait faillite à de nombreuses entreprises!

Scrum n'est probablement pas la meilleure méthode à utiliser pour les méthodes agiles qui doivent compléter une certaine quantité de fonctionnalités avant une certaine date (car j'ai toujours constaté que scrum rend dev go plus lent et ne permet pas assez d'agilité pour modifier le processus lorsque nécessaire.

Quelle que soit la méthodologie, vous avez besoin de créer un arriéré de fonctionnalités requises pour donner une visibilité des progrès. Les progrès sur chaque sprint ne sont pas assez bons, vous ne saurez pas si vous atteignez la cible ultime. Il serait donc préférable d'utiliser une méthodologie de type kanban: définissez toutes les fonctionnalités à gauche et utilisez-les dans le système pour afficher les progrès accomplis.

Cela concentre l'esprit des gens sur ce qui doit encore être fait d'une manière que Scrum ne gère pas, et permet à des personnes autres que l'équipe de développement de voir ce qui reste et si vous êtes susceptible d'atteindre la cible (et ainsi de gérer les attentes du client plus tôt). , ou organisez ces bonus en heures supplémentaires avant qu’ils ne soient nécessaires).

Scrum est un système à la fois indélébile, définissant et perfectionnant en permanence quelque chose. Son tout simplement pas adapté à ce genre de développement. D'autres peuvent gérer ce type tout en conservant le concept de développement itératif, Kanban en est un, Crystal en est un autre. Mais ce qui est essentiel à comprendre, c’est que si vous suivez Scrum avec religion, vous n’êtes pas agile. Tout véritable système agile doit pouvoir s'adapter à ces problèmes particuliers, c’est pourquoi il s’appelait agile en premier lieu. tenez compte de cela dans votre façon de travailler.

Le paradigme de développement n'est pas synchronisé avec le paradigme du contrat. Idéalement, la manière dont les contrats sont écrits changerait, mais cela ne se produira probablement pas. Cependant, même si vous laissiez tomber Scrum, vous auriez toujours des surprises et des échéances non respectées (seulement vous le seriez probablement beaucoup plus tard, car vous aviez conçu tout cela à l'avance et tout était faux !!).

Avec ou sans modification de la rédaction des contrats, vous livrez ce que vous avez travaillé . Ensuite, remplissez le contrat en consommant un cycle de temps de développement afin de terminer les fonctionnalités que vous n'avez pas réalisées.

Est-ce bien que vous ayez omis de tenir tout ce que vous avez promis le jour de votre promesse? Non, mais votre client sera beaucoup plus heureux si vous pouvez livrer quelque chose qui fonctionne à temps, puis le reste rapidement après que si vous êtes simplement en retard et que vous n'avez rien du tout à leur donner.

De nombreux ouvrages et articles de Scrum indiquent qu'un sprint échoué (lorsque l'équipe ne parvient pas à compléter certaines fonctionnalités du backlog de sprint) n'est pas si grave, il arrive de temps en temps et peut s'avérer utile si l'équipe apprend de ses erreurs. et améliore quelque chose dans les sprints suivants. Et l'équipe ne doit pas être punie pour ne pas avoir achevé le travail auquel elle s'est engagée.

Vous «punissez» ce type de comportement en limitant la quantité de travail que ceux qui n'ont pas terminé peuvent assumer le prochain sprint. Les chances de travailler sur des trucs sympas disparaissent. La récompense pour faire du bon travail est plus de travail.

Cela semble très bien du point de vue du développeur, cependant, supposons que nous avons une société de logiciels "Scrum-Addicts LLC" qui développe quelque chose pour les clients sérieux ("Money-Bags Corporation"):

Les responsables de Scrum-Addicts suggèrent de créer un logiciel pour Money-Bags. Ils conviennent d'une liste de fonctionnalités. Money-Bags demande à fournir une date d'expédition. Les responsables de Scrum-Addicts consultent leur équipe Scrum. Selon l'équipe, cela prendra 3 semaines. -longues sprints pour compléter toutes les fonctionnalités Le gestionnaire Scrum-Addicts ajoute une semaine par sécurité, s'engage à expédier le logiciel dans un mois et signe un contrat avec Money-Bags. Après 4 sprints (délai d'expédition), l'équipe Scrum ne peut livrer que 80% de fonctionnalités (en raison de l'inexpérience avec le nouveau système, de la nécessité de corriger des bogues critiques dans les fonctionnalités précédentes dans un environnement de production, etc.) Comme Scrum le suggère, à ce stade, le produit est potentiellement livrable, mais Money-Bags a besoin de 100% de fonctionnalités, comme mentionné dans le contrat. Alors ils rompent le contrat et ne paient rien.

Scrum-Addicts est au bord de la faillite car Money-Bags ne leur a pas donné d'argent et les investisseurs ont été déçus des résultats et ne veulent plus aider la société.

Si lundi je te parie 100 $ qu'il va pleuvoir jeudi et qu'il ne pleuvra pas avant vendredi, tu aurais raison de prendre mon argent. Si, au lieu d’une chance de jouer, vous voulez des prévisions météorologiques, nous avons besoin d’un contrat nous permettant de vous donner une prévision à jour mardi.

De toute évidence, aucun éditeur de logiciel ne veut être à la place de Scrum-Addicts. Ce que je ne comprends pas à propos d’Agile et de Scrum, c’est la façon dont ils suggèrent aux équipes de gérer la planification et les délais afin d’éviter la situation décrite ci-dessus.

Pensez à POURQUOI MB veut prendre sa balle et rentrer à la maison. MB n'a pas exigé que le travail soit effectué dans un mois au début. SA a promis 100% des fonctionnalités critiques en un mois et n'a pas tenu ses promesses. SA a défini l’échéance et non le MB. SA a même ajouté arbitrairement une semaine à la date limite. Alors, pourquoi est-ce une date limite?

Parfois, lorsqu'ils sont en concurrence pour le travail, les éditeurs de logiciels cèdent à la tentation de se montrer et de promettre la lune. Les professionnels établissent avec soin si une lune est même nécessaire. Quel est le besoin le plus critique de MoneyBags? 100% de fonctionnalités ou un produit fonctionnel dans un mois? Savent-ils même ce qui est vraiment critique? Y at-il un événement à venir fixant une date limite?

Si je négociais ce contrat avec Scrum-Addicts, je voudrais en savoir plus sur les besoins de Money-Bags et structurer le contrat afin d’accorder autant de flexibilité que possible avec Money-Bags. Je leur apprendrais comment fonctionne le processus agile pour qu'ils sachent à quoi s'attendre de nous.

Ainsi, au lieu de s’attendre à ce que tout fonctionne à la perfection en un mois, ils s’attendraient à ce que le premier produit livrable soit évalué en 1 à 2 semaines.

Donc, pour résumer, j'ai 2 questions:

Qui est à blâmer? Les gestionnaires, parce que c'est leur travail de faire la planification
L'équipe, parce qu'ils sont engagés à faire plus de travail qu'ils pourraient
quelqu'un d' autre

N'importe qui aurait pu arrêter cette mascarade avant que nous ayons un mois plus tard.

Je pourrais aller aussi loin que blâmer Money-Bags Corp pour avoir embauché une équipe qui, de manière frauduleuse, représentait de manière agile un processus en cascade comme agile. Le contrat lui-même indique clairement que ce n'est pas agile. Planifier d'être fait dans un mois ne le rend pas agile.

Si vous insistez pour que ce soit agile, c'est agile avec un seul sprint d'un mois. Ce qui, oui, je ne le recommanderais pas car c'est, encore une fois, la même chose que cascade.

Qu'y a-t-il à faire?

Que diriez-vous de l'agilité? Livrer quelque chose à chaque sprint? Obtenir des commentaires avant la date limite? Des sprints d'une semaine? Pourquoi ne pas renégocier le contrat draconien au moment même où vous soupçonnez que le délai est en danger plutôt que de vous cacher et de prier? À tout le moins, vous pouvez arrêter de perdre du temps sur un projet condamné et trouver un client plus raisonnable.

Les gérants doivent déplacer l'échéance deux fois (ou trois fois) plus tard que l'estimation de l'équipe d'origine.

Les multiplicateurs de date limite sont à peu près aussi utiles que de régler votre montre 15 minutes plus tôt pour ne jamais être en retard. Vous pouvez seulement vous tromper si longtemps avant de réaliser ce que vous êtes en train de faire.

Les premières estimations sont fausses. Essayez de capturer comment mal. 5 semaines, donner ou prendre quelques semaines est une expression simple qui vous permet d'exprimer à quel point la date d'achèvement est incertaine. Plutôt que d'essayer de deviner avec précision, vous devinez à quel point votre hypothèse est folle. Faites du vrai travail et obtenez de vraies données. Ensuite, vous pouvez commencer à faire des estimations avec une plage plus étroite. Une à deux semaines, c'est amplement le temps de le faire.

Les membres de l'équipe doivent être encouragés à faire tout le travail auquel ils se sont engagés, peu importe les circonstances (en infligeant des pénalités pour les sprints manqués).

Les membres de l'équipe doivent être encouragés. Échec, commis ou autre. Plutôt que de construire des conséquences artificielles telles que des punitions ou même des bonus (carottes et bâtons), des études ont montré que les personnes qui font du travail créatif, tel que la programmation, réagissent mieux si trois choses sont fournies: Autonomie, Maîtrise et But.

Daniel Pink en a parlé à TED . La discussion porte sur la motivation, pas l'agilité, mais j'ai facilement vu comment mapper ces points sur l'agile:

Autonomie - Je veux diriger ma propre vie - Laissez-moi choisir un travail dans l'arriéré.
Maîtrise - Je veux améliorer quelque chose qui compte - Les commentaires des clients.
Objectif - Je veux faire partie de quelque chose de plus grand que moi - Une équipe collaborative.

L'équipe doit abandonner Scrum car cela ne correspond pas à la politique de l'entreprise en matière de délai. Scrum peut respecter un délai plus précis que la cascade. Compte tenu d'un délai, Scrum peut le respecter. Il peut le rencontrer avec seulement 1 fonction sur 47 en fonction du temps, des fonctionnalités et des compétences, mais il peut le faire.

Un projet agile peut être conçu de manière tellement efficace que chaque soir, lorsque l'équipe rentre chez elle, elle est prête à être expédiée. Cela semble idiot, à moins que vous ne pensiez à l'expédition comme à un test du client. Le plus tôt possible, le plus tôt vous pourrez faire des ajustements. Cela touche toutes les échéances possibles. Juste pas toutes les fonctionnalités. Mais cela vous oriente vers les fonctionnalités qui comptent.

Nous devrions tous abandonner le développement de logiciels et rejoindre un monastère

Oui, comme m'enfermer dans une pièce à l'écart de la vraie vie, ça va me faire écrire moins de code.

J'ai édité cette réponse à la taille. Si vous êtes curieux, lisez l'historique d'édition.

Tout le monde doit être agile. Quoi que vous décidiez, cela ressemblera à qui fait quoi, comment, quand, où et pourquoi par toutes les parties. Clients, responsables et développeurs agiles.

Vous ne pouvez pas donner une date d'expédition trop éloignée dans le futur. Vous donnez une estimation.

Quelqu'un avait besoin de gérer les attentes du client. La raison pour laquelle vous ne craignez pas trop de perdre quelques sprints, c’est parce que vous vous ajustez pour empêcher tout le projet de prendre du retard. Si, après un sprint ou deux, vous concluez que vous ne finissez pas de respecter la "date d'expédition", vous en informez le client.

Maintenant que veux-tu faire? Supprimez les fonctionnalités dont vous n'avez pas besoin ou déplacez la date. Si vous pouviez livrer à temps, vous le feriez. N'hésitez pas à apporter de mauvaises nouvelles.

Qui sait, sur certains projets, vous pouvez expédier plus tôt.

Vous ne pouvez pas être agile si le client ne veut pas.

Objectif

Je crois que les deux "mesures" suivantes devraient constituer la base de toute décision opérationnelle:

• le travail est-il rentable (pour le client)
• travaillons-nous le plus efficacement possible

Ce sont assez universels. Bien sûr, cela devient très compliqué très rapidement, par exemple, pour que le travail soit rentable, il faut que le produit fonctionne correctement, que l'utilisateur puisse utiliser le produit, qu'il soit commercialisé correctement, etc. - pour bon nombre de ces " Scrum-Addicts". LLC "ne porte pas la responsabilité.

Problème

Le contrat ne se concentre pas sur les objectifs décrits ci-dessus. Il existe une clause "tout ou rien" - tout faire et être payé, ou ne rien faire et ne pas être payé. Cependant, cela ne concerne pas directement la création de valeur. Un autre inconvénient est le suivant: nous devons maintenant passer du temps et de l’argent pour assurer et vérifier que le contrat est respecté. Pourquoi voudrions-nous dépenser cet argent? Comment faire en sorte qu'un contrat soit rempli aide-t-il lorsque les exigences ont changé entre-temps et que nous avons découvert que le logiciel commandé ne crée aucune valeur? Il y a juste plus d'argent qui coule à l'eau! Maintenant, bien sûr, il y a une raison à ce comportement:

• Culturellement, nous avons l'habitude de magasiner pour des choses comme ça. Nous attendons des acheteurs de logiciels comme nous le ferions pour une voiture: choisissez une configuration, obtenez un prix et une échéance, et soyez très mécontent si ces deux problèmes ne sont pas respectés.
• nous voulons décharger le risque et la responsabilité
• nous voulons de la stabilité, cela aide à la planification et nous fait sentir mieux (ainsi que notre client, qui est un aspect important!)

En fin de compte, nous devrons choisir un compromis qui nous permettra de satisfaire au mieux nos objectifs.

Voici comment cela devrait fonctionner

• avoir un contrat de services et de travail au lieu d' un produit
  • doit pouvoir être résilié avec un préavis relativement court
• travailler en étroite collaboration pour assurer une efficacité optimale
• impliquer toutes les parties nécessaires, à la fois de " Scrum-Addits LLC " et de " Money-Bags Corporation " - un "point de contact unique" crénelant toutes les informations ne fonctionnera pas ici

Eh bien, en gros, je viens de dire "soyez agile". Maintenant, voici pourquoi:

• processus et contrat sont optimisés pour dépenser autant d' argent sur le but que possible
• vous devrez faire confiance à l'entrepreneur pour faire son travail et ne pas avoir à investir beaucoup d'argent pour vérifier qu'il est à la hauteur.
• la possibilité de poursuivre votre entrepreneur en justice si vos attentes / votre contrat n’est pas respecté n’aide en général pas, car cela coûtera plus cher que de simplement le laisser tomber. Certaines des principales préoccupations ici sont la mise sur le marché. Vous allez probablement perdre beaucoup plus d’argent / d’affaires en allant au tribunal que vous ne l’obtiendrez.
  • à la fin de la journée, vous devrez assumer vous-même certains risques.