Avoir des dates de livraison fixes pour les éléments est-il une méthode de travail «Agile»?

On continue à nous dire que la haute direction va travailler de manière agile sur un nouveau projet. Ils ont mis en place des stand-ups, des planifications de sprint, des rétrospectives, etc. etc. Cependant, ils ont mis au point un plan détaillant tous les travaux qu’ils souhaitent que nous livrions avec des dates par rapport à chaque élément et des dates de démonstration avec à nouveau ce qui sera présenté dans chaque un. Ce plan va au deuxième trimestre 2017.

Pour moi, cela ressemble à une cascade dans le pire sens du terme, un plan sans contribution de l'équipe technique a été élaboré. Certains récits sur le plan sont très peu clairs et aucun n'a été estimé par l'équipe de développement.

Cependant, je sais que leur argument sera le suivant: "Les principaux acteurs doivent avoir des dates et un plan, nous ne pouvons pas nous en tenir à un arriéré". Cela me semble que les principaux acteurs n’ont pas adhéré à Agile et nous sommes donc condamnés à ne pas l’appliquer à un niveau inférieur.

Est-ce un jugement juste ou est-ce que je réagis de manière excessive à ce plan!?

Il y a une différence entre respecter les délais et satisfaire à toutes les exigences. C'est comme le vieil adage "rapide, bon ou pas cher, choisissez deux".

Donc, ici, vous avez des dates fixes pour la livraison - c'est bien, cela signifie que vous êtes limité dans le temps en ce que ce que vous livrez à la fin de votre dernier sprint sera le produit final. Vous vous souvenez que vous devez toujours publier un logiciel opérationnel à la fin de chaque sprint, n'est-ce pas?

Ce qui peut arriver, c’est que le logiciel final manquera de certaines fonctionnalités. Eh bien, cela se produit avec toutes les méthodologies de développement, y compris la cascade. Tout ce qui va arriver, c'est que vous serez chargé de produire un correctif par la suite, ou une version 2. Cela suppose que votre livraison finale est suffisante, bien sûr!

Les dates fixes ne sont donc pas une méthode de travail non agile. Agile ne signifie pas qu’un budget illimité vous permet de jouer avec vos nouveaux outils de planification. Cela signifie que vous devrez vous concentrer sur la livraison, ce n'est jamais une mauvaise chose.

Non. C’est exactement le genre de choses que les entreprises autres que de logiciels ont tendance à faire. Il y a des plans, des échéances et des budgets. Et cela échouera inévitablement, car les humains ont du mal à prédire l'avenir.

Passons en revue les différents points ici:

On continue à nous dire que la haute direction va travailler de manière agile sur un nouveau projet.

Si vous étiez agile, alors vous auriez des équipes auto-organisées, sans se faire dire comment travailler par la direction.

Cependant, ils ont maintenant mis au point un plan détaillant tous les travaux qu’ils souhaitent que nous livrions, avec des dates par rapport à chaque élément et une nouvelle présentation des dates avec ce qui sera présenté en démonstration pour chacun.

Nan. C'est à peu près l'antithèse du développement itératif. Quelque chose va se passer (quelqu'un tombe malade, quelqu'un part, une exigence a été oubliée, vos serveurs meurent, peu importe) et vous ratez l'un de ces objectifs. Maintenant, la direction doit soit recalculer le plan complet , soit craquer le développement.

aucun n'a été estimé par l'équipe de développement.

Alors , comment savoir la gestion que ce plan est viable du tout ? Dans Agile, le travail est une négociation. Les entreprises disent: nous aimerions ceci. L'ingénierie dit: d'accord, en supposant XYZ, cela prendra 3 semaines. Il n'y a pas de collaboration client dans ce que vous décrivez. Pas d'individus et d'interactions.

Cela me semble que les principaux acteurs n’ont pas adhéré à Agile et nous sommes donc condamnés à ne pas l’appliquer à un niveau inférieur.

Vous n'êtes pas nécessairement condamné, mais sinon, ce n'est qu'une coïncidence. Lorsque tout le travail apparaît parce que la direction ne peut voir l'avenir, vous manquerez vos dates (ou produirez du code de mauvaise qualité, ou nécessiterez plus de ressources que prévu). Ce sera alors votre faute. La direction va probablement faire pression sur vous pour que vous travailliez plus longtemps pour trouver la date, ou peut-être jeter les gens sur le problème.

Dans le meilleur des cas , la gestion est en fait agile et suffisamment intelligente pour en réduire la portée. Ce qui signifie qu'ils viennent de passer tout leur temps à élaborer un plan détaillé qui ne vaut rien.

Si l'on s'attend à ce que des ensembles spécifiques de fonctionnalités soient livrés à des dates spécifiques, alors non, ce n'est pas de la gestion de projet agile. La gestion de projet agile est de nature empirique. Les projections ne sont pas fondées sur les souhaits des dirigeants mais sur l'analyse des performances antérieures.

Votre description correspond à ce que je considère agile comme un cargo. L'accent est mis sur les processus et les cérémonies spécifiques et non sur les concepts de base de la gestion de projet fondée sur des preuves. Vous aurez peut-être de la chance de faire comprendre aux gens d'affaires si vous associez cela à Lean ou à TPS . Le vrai problème que vous devez résoudre ici est de faire en sorte que la direction ne craigne pas l'inconnu. La bonne réponse aux dirigeants est "nous ne pouvons pas vous dire maintenant quand les choses vont être faites, mais une fois que nous commençons à créer de la valeur, nous pouvons établir des projections basées sur notre expérience." Les développeurs ont tendance à dire des choses comme "c'est fait quand c'est fait" et "je ne sais pas quand ce sera fait". Les gestionnaires ne diront pas des choses comme celles-là aux cadres, cela les fait sonner comme des inconnus.

Très probablement, le plan échouera et devra être révisé. Le plus gros risque pour l’équipe est qu’il y ait une forte pression pour respecter les délais et que la qualité en souffre. À un moment donné, vous ne serez pas sur la cible (très probablement, ce sera la première échéance) et il y aura une pression pour atteindre cette date. Des heures supplémentaires seront attendues et il y aura une pression pour couper les angles (test d'unité, évaluations de code, etc.) C'est une pente glissante et une fois que vous commencez dans cette voie, c'est un peu une spirale descendante et les choses vont mal tourner. La productivité va se dégrader au fur et à mesure de l'avancement du projet.

Si vous pouvez amener l’équipe de développement à présenter un front unifié, vous devez vraiment reculer et maintenir le cap sur la qualité. Mon expérience est que les gestionnaires de projet ont tendance à penser que la sortie logicielle est linéaire. C'est-à-dire que chaque période X produira Y «centrage complet». Autrement dit, si vous n'êtes pas "terminé à 50%" à la moitié du temps imparti, les klaxons commencent à retentir. En réalité, si vous le faites bien, le premier long métrage prend généralement beaucoup plus de temps que le cinquantième long métrage (de taille similaire). Si vous pouvez traverser cette période de crise de danger initiale ("que se passe-t-il?", "Je ne rien ne se fait! ") vous serez probablement OK.

Bienvenue dans les vraies affaires.

Il existe un style d'entreprise plus ancien, que j'ai tendance à appeler de manière dérisoire «développement traditionnel», puis un nouveau style, «développement agile». Si j'essaie de traiter ceux-ci comme des idéaux opposés, nous constatons une division claire au centre: les plans et les exigences sont définis dans la colonne traditionnelle, la découverte et l'évolution dans la colonne agile. C'est soigné, bien rangé et faux.

En réalité, les affaires sont une recherche du juste milieu entre les deux. Il est facile de montrer que l’un ou l’autre des extrêmes tombe à plat. Nous qui aimons Agile, nous démontrons avec enthousiasme tous les problèmes de l'idéal pur du développement traditionnel, et nombreux sont ceux qui peuvent montrer les nombreuses façons dont l'Agile pur s'effondre. Les entreprises agiles qui réussissent sont celles qui trouvent leur équilibre particulier entre les deux. Les entreprises traditionnelles qui réussissent sont celles qui trouvent leur équilibre particulier entre les deux. Vous ne pouvez pas avoir l'un sans l'autre.

Même notre processus béni SCRUM montre un équilibre entre les deux. Bien que l'on cherche clairement à maximiser l'agilité, quelques compromis clés sont faits. Par exemple, le responsable de produit a la tâche primordiale de défendre tous les clients. SCRUM ne spécifie pas intentionnellement comment cette interaction fonctionne. Il a intentionnellement laissé tomber le fait que tout le monde doit être payé à la fin de la journée. C'est le travail du propriétaire du produit de créer l'illusion que cela n'a pas d'importance.

(Il est intéressant de noter que l'agile pur fonctionne très bien, tant que vous n'êtes pas payé avant de produire un produit et que vous n'avez pas accès à des informations confidentielles tant que vous n'êtes pas acquis. Je pense que les seuls ingénieurs en logiciel qui sont à l'aise avec ce commerce sont les entrepreneurs)

La direction a donc dicté les fonctionnalités qui y figureront et à quel moment elles doivent l'être. C'est très bien. Une phrase que j'ai entendue est "le client choisit le quoi et le quand, le producteur choisit le qui et le comment". Vous avez été inscrit pour le "quoi" et le "quand". Ils n'ont rien dit à propos de qui ou de comment, sauf pour vous offrir une chance d'utiliser "Agile" comme votre comment. Il ne reste plus qu’à aider la direction à comprendre le nombre de personnes qu’elle devra embaucher pour répondre à ses besoins.

Dans un monde parfait, votre entreprise est agile de l'extérieur. Il interagit avec ses clients de manière agile, laissant les développeurs se développer facilement pour eux. Cependant, très souvent, l’entreprise doit interagir avec l’extérieur tout en se développant avec agilité. Entre les deux, il existe toujours un ensemble complexe de compromis, propres à chaque entreprise.

Personnellement, je considère cette situation comme un test pour quiconque pense comprendre le développement agile. Dans le futur, vous devrez développer un produit pour une date limite, et cette paire produit / date limite sera relativement fixe. Si un produit fixe / une échéance brise votre processus, pouvez-vous vraiment dire que vous étiez Agile en premier lieu?

Mon conseil: ne considérez pas cela comme une cascade. Vous contrôlez toujours le "comment". Vous pouvez toujours faire tout le sprinting rapide et le prototypage flexible pour lesquels Agile est si célèbre. Vous devez simplement être conscient que le caoutchouc rencontre la route, et vous devez livrer. C'est le monde réel, pas le monde idéal. Aurait-il été préférable pour eux de vous demander en premier lieu? Sûr. Ce n'est peut-être pas votre appel. Il y a peut-être mille raisons liées aux affaires de le faire que vous ne comprenez tout simplement pas. N'hésitez pas à les appuyer, mais comprenez qu'ils peuvent avoir une très bonne raison pour ce qu'ils ont fait.

Agile ne vous empêche pas de planifier des jalons (par exemple, nous publierons V 1.0 dans 3 mois), mais le contenu de chaque jalon ne peut pas être corrigé.

Je pense que votre réaction dépend de la nature du projet. Si le projet consiste à envoyer un homme sur la lune d'ici le deuxième trimestre de 2017, tout le monde conviendra qu'il est voué à l'échec. Si vous pensez pouvoir livrer un MVP d'ici la fin du deuxième trimestre 2017, vous devriez travailler dessus sprint par sprint.

Si la direction pense que votre équipe fait de son mieux et que vous pouvez montrer des progrès à chaque sprint, vous devriez être en mesure de négocier davantage de temps.

CHAQUE projet pertinent pour l’entreprise a des contraintes:

• Temps
• Ressources
• Un ensemble de fonctionnalités minimum attendu

Ce n'est rien d'autre. Développer agile ne signifie pas "les gens nous paient pour nous permettre de développer ce que nous voulons chaque fois que cela est prêt" - vous aurez toujours un délai. Il y aura toujours des dates avec certaines exigences minimales et si elles ne sont pas respectées, le projet sera annulé et qualifié de "raté". Elles peuvent parfois être implicites - le responsable sait donc si "Si je ne dispose pas d'une interface utilisateur fonctionnelle avec ces fonctionnalités au bout de 4 semaines, ce projet est voué à l'échec", ou il peut y avoir des actionnaires qui se fixent un objectif.

Il y a beaucoup de projets résultant de la législation. - Si le gouvernement décide de mettre en œuvre la fonctionnalité X jusqu'en 2017 pour respecter une nouvelle loi, vous aurez un délai non négociable et un ensemble de fonctionnalités qui doivent être prêtes. La seule variable est la quantité de ressources que la direction peut allouer à la tâche. - Et dans ces projets, où la date limite est une décision externe, ils devront surveiller vos progrès, entendre votre pronostic et renforcer les équipes ou externaliser une partie du travail pour atteindre leurs objectifs.

Tout cela ne s'oppose pas au développement agile. Vous aurez toujours vos sprints, développerez vos fonctionnalités dans votre propre laps de temps. Vous obtiendrez toujours les priorités de vos fonctionnalités d’un client - et vous travaillerez pour fournir autant de ces fonctionnalités que vous pourrez jusqu’à la date limite.

Si le délai est effectivement respecté avec les ressources disponibles, c'est un problème de gestion. Vous pouvez donner votre pronostic et vos mises à jour hebdomadaires / quotidiennes et décider s'ils ont besoin de plus de ressources. Sinon, vous continuerez à travailler dans les sprints et livrerez des runnables, comme n'importe quel projet.

Comme quelqu'un l'a déjà fait remarquer avant le manifeste:

Individus et interactions sur processus

Je vous suggérerais de jeter un coup d'œil sur le plan proposé et de suggérer des modifications. Rappelez-vous que le manifeste dit que l’arriéré n’est jamais définitif, il évolue constamment.

Vous pouvez donc apporter vos suggestions à l'équipe. Si vous avez un raisonnement valable et que l’équipe y consent, tout propriétaire de produit digne de ce nom considérera le problème et accumulera le retard nécessaire pour refléter l’opinion de toute l’équipe.

C'est le point où cela pourrait aller de deux manières.

1. Le propriétaire du produit et les entreprises sont d'accord avec votre raisonnement et peuvent augmenter les ressources pour respecter l'échéance si cela leur est une option OU ils peuvent choisir de supprimer certaines fonctionnalités pour respecter l'échéance.

2. Ils peuvent toujours vouloir s'en tenir à leur propre version contre l'opinion collective de l'équipe.

Si le résultat est n ° 2, alors ce n'est pas agile.

Si vous vous retrouvez avec le numéro 1, alors je dirais que l'équipe est sur la bonne voie, car Agile ne concerne pas uniquement les développeurs.

Imaginez que vous demandiez à quelqu'un de peindre un mur, une maison puis une rue entière pour vous, combien de temps lui donneriez-vous?

Quelle que soit votre réponse, vous aurez tort. C'est ça.

Ils n'auraient aucun doute sur les dates sans demander aux personnes qui doivent faire le travail ce qu'elles pensent.

À propos, si vous (en équipe) acceptez ces dates, vous vous trompez.

Vous devriez demander un peu de temps pour travailler sur cette planification avec les parties prenantes, de sorte que vous puissiez définir des priorités en fonction de la facilité et de la rapidité d'exécution.

Par exemple, le travail final prendra peut-être deux fois plus longtemps que prévu, mais ils pourraient utiliser une version bêta beaucoup plus tôt que prévu.

Globalement, vous ne pouvez pas laisser les gens penser que vous serez capable de faire X en même temps si vous ne pouvez ou ne pouvez pas aller plus vite. C'est votre responsabilité de préciser clairement ce dont vous avez besoin en termes de détails et de temps.

Ce n'est pas aglie planification non.

Mais si vous prétendez que vous ne connaissez pas le plan et que vous travaillez juste sprint par sprint. Ce pourrait être un travail de travail.

Il y aura toujours des dates et des budgets. Il y a toujours un risque qu'ils soient manqués ou dépassés et lorsque cela se produira, vous devrez toujours vous rabattre sur un plan B.

Si vous avez travaillé de manière agile, alors plan B est, espérons-le, la démo du dernier sprint