Présentation du développement Agile après le lancement traditionnel d'un projet

Il y a environ un an et demi, je suis entré dans un lieu de travail qui prétendait faire du développement Agile. Ce que j'ai appris, c'est que cet endroit a adopté plusieurs pratiques agiles (telles que les standups quotidiens, les plannings de sprint et les critiques de sprint) mais aucun des principes (juste à temps / juste assez bonne mentalité, exposant l'échec tôt, communication riche).

J'ai maintenant la tâche de rendre l'équipe plus agile et j'ai la certitude que j'ai l'adhésion complète des développeurs et de l'équipe commerciale. En tant que programme pilote, ils m'ont donné un projet qui vient de terminer 15 mois de collecte des exigences, a un document d'analyse et de conception de 110 pages (à considérer comme "écrit dans la pierre"), et où je n'ai pas accès à la fin utilisateurs (uniquement au comité composé des gestionnaires des utilisateurs qui n'utiliseront pas réellement le produit).

J'ai commencé petit, en leur donnant une liste des livrables attendus pour les 5 premiers sprints (laissant les futurs sprints indéfinis), une liste d'objectifs pour le premier sprint, et j'ai disséqué le document A&D pour obtenir suffisamment de user stories pour atteindre les objectifs du premier sprint .

Depuis lors, ils ont demandé pourquoi nous n'avons pas toutes les exigences pour tous les sprints, pourquoi je n'ai pas commencé à travailler sur des trucs pour le troisième sprint (qu'ils considèrent plus importants mais basés sur les livrables du premier). 2 sprints) et nous demandons encore plus de documentation que toute mon équipe informatique considère comme un travail occupé ou sans rapport avec nous (comme écrire le manuel d'utilisation à l'avance, documenter tous les champs de données de tous les sprints à l'avant, et plus encore). travail "en amont").

Cela a été assez difficile pour moi en tant que nouveau chef de projet, mais j'ai effectivement mis en œuvre des améliorations telles que Scrumban pour la gestion des histoires, la programmation des paires et le fait que l'entreprise nous donne des tests d'acceptation des clients dès le départ (dans le cadre de la documentation des exigences). .

Mes questions sont donc:

1. Que puis-je faire pour introduire plus efficacement le changement dans une entreprise résistante?
2. Y a-t-il d'autres pratiques que je peux introduire du côté informatique pour aider à montrer à l'entreprise les avantages de l'agilité?
3. Le fardeau de la documentation nous étrangle - l'entreprise y voit toujours une stratégie de gestion des risques plutôt qu'un risque. Que pouvons-nous faire pour atténuer leurs préoccupations et leurs demandes en matière de documentation (en particulier la quantité de documentation et leur besoin immédiat de toute la documentation)?
4. Nous sommes dans un bâtiment séparé de notre entreprise, à environ 3 pâtés de maisons et ils refusent que leurs employés participent au projet, car cette personne "ne pourra pas travailler sur leurs autres projets pendant qu'elle est chez nous. bâtiment." Ils s'attendent à ce que nous nous rendions toujours là-bas et que nous groupions nos questions afin que nous puissions toutes les poser en même temps et ne pas perdre le temps de cette personne avec des «interruptions constantes». Que pouvons-nous faire pour obtenir une communication plus riche de leur part?

Tout conseil supplémentaire serait également apprécié.

Merci!

On m'a assuré que j'avais l'adhésion complète des développeurs et de l'équipe commerciale [...] Je n'ai pas accès aux utilisateurs finaux [...]

Une chose à préciser est la différence entre être assuré verbalement que vous "avez l'adhésion", d'une part, et d'autre part l'engagement réel de la personne qui parraine votre travail.

Mon meilleur conseil est de mettre de côté le label "Agile". Interdisez le mot de la conversation dans la mesure du possible. Au lieu de cela, concentrez-vous sur les choses suivantes:

• Quels résultats vous sont demandés (vous en particulier, pas l'équipe)
• Quels sont les critères de réussite de votre mission (encore une fois, le vôtre plutôt que celui de l'équipe)
• Quels moyens vous avez à votre disposition (y compris les personnes, l'accès aux personnes, le temps, les informations, le budget de formation, etc.)

"Rendre l'équipe plus agile" n'est pas un objectif réalisable. Ce n'est pas assez précis, ce n'est pas mesurable, il n'a pas de condition finale. Ce dont vous avez besoin est quelque chose de spécifique: une cible exprimée en termes de X% de défauts en moins, ou Y% de vos dates de livraison de fonctionnalités réellement honorées, par date Z.

Pour atteindre ces objectifs, vous devrez peut-être introduire des changements. Maintenant, quelques règles générales s'appliquent. Chaque amélioration est un changement, mais pas chaque changement est une amélioration. On dit souvent que les gens résistent au changement, mais en réalité les gens résistent au changement et ne savent pas si le changement sera une amélioration.

Concentrez-vous sur des pratiques qui, selon vous, seront des victoires faciles, des fruits bas. Concentrez-vous sur les pratiques qui établissent un cadre non seulement pour mettre en œuvre le changement, mais pour évaluer les effets du changement, et rassurer les gens sur le fait qu'ils entraînent une amélioration plutôt qu'une régression. Les «radiateurs d'information» sont bons, tout comme les rétrospectives.

Certains de ces changements peuvent être à la fois nécessaires et perçus comme menaçants, comme l'accès accru aux personnes qui détiennent des informations clés. Ne faites pas de compromis sur ces points: «adhérer» signifie un processus de négociation où vous avez réellement une chance de livrer ce que l'on vous demande, sans être conduit comme un agneau vers un massacre politique.

Essayez de mettre les choses en place de sorte qu'il soit difficile de vous imputer le blâme si les choses ne vont pas bien (et beaucoup se tromperont probablement). Soyez conscient que cela peut arriver et soyez prêt si cela se produit: connaissez votre stratégie de sortie.

Afin d'introduire une nouvelle chose en douceur, vous devez vous assurer que les gens ne la verront pas comme une menace et permanente .

Beaucoup d'entre nous sont naturellement câblés pour éviter toute sorte de nouvelles choses. C'est biologique. Les gens qui recherchent généralement la nouveauté ne vous causeront jamais de problème. Vous devez vous assurer que les personnes plus anxieuses ne verront pas votre suggestion comme une menace pour leur confort actuel.

Le moyen idéal pour une équipe d'adopter une pratique ou une idée est de s'assurer que l'idée vient d'elle, et non de personnes externes telles que la direction, ou pire, de consultants aléatoires. Pour y arriver, créez des réunions de brainstorming avec toute l'équipe avec un seul sujet. Le sujet devrait être le problème. Lors de la réunion, vous devrez apporter soigneusement les idées et venir avec des arguments et des faits.

Nous n'aimons pas prendre de décision sur des choses permanentes. Nous sommes déjà inquiets de l'effet d'un changement potentiel. Ce comportement est bien connu des animaleries. L'achat d'un chien est une décision très importante et changera probablement radicalement votre vie. Lorsque vous êtes au magasin, le vendeur vous proposera souvent de le ramener chez vous et de le retourner si vous changez d'avis. Comme vous pouvez vous y attendre, il y a très peu de retours. La proposition n'a qu'un objectif: réduire l'anxiété qui empêche les gens de prendre des décisions. Suggérez à votre équipe de s'entraîner à essayer pendant un certain temps après ce que vous allez évaluer son effet.

Concernant votre deuxième question, je vous suggère fortement d'apporter une chose à la fois.

Votre problème de documentation mérite son propre article ici sur P.SE et je ne vois aucun problème avec le fait que vous êtes dans deux bâtiments différents si les deux sont prêts à se réunir régulièrement. Il y a des situations dans lesquelles l'une des parties ne veut pas du tout se rencontrer;)

Agile n'est pas pour tout le monde, il semble que votre entreprise aime juste dire agile parce que c'est le mot à la mode le plus chaud. Tout d'abord, cela aurait probablement été une bonne idée de pousser pour un tout nouveau projet ou des projets de maintenance plus petits pour commencer à rendre leur processus plus semblable à de vraies méthodologies agiles. Essayer de repenser une méthodologie à l'aide d'un projet déjà en cours, c'est comme essayer de changer un pneu au milieu d'une autoroute à 8 voies. Vous avez besoin d'un moyen de montrer que votre entreprise peut fonctionner de manière agile, mais vous avez besoin d'un environnement où elle a une chance de fonctionner, mais sur la base de ce que vous avez dit, il est peu probable que l'agilité fonctionne bien avec sa culture établie.

Selon ce qu'ils veulent pour la documentation, vous pourrez peut-être leur montrer que cela est généré automatiquement à partir d'un outil que vous utilisez, ou est redondant et que le document B a le document d'information A a été demandé de montrer. Vous devez également ajuster vos plans de documentation, leur faire savoir pourquoi vos estimations changent et leur demander de réduire la quantité de documentation demandée ou de consacrer des ressources comme un analyste commercial pour créer la documentation.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

C'est ton problème. Ils ne comprennent pas. Quelqu'un ne peut pas vous demander d'être plus agile et de ne pas vouloir faire le tour. Ils ont de mauvaises attentes. Les choses sont cassées, à l'avant, avant même de commencer. Corrigez les attentes ou vous échouerez. C'est comme si je vous demandais de conduire 150 MPH et je vous donne une Chevette pour le faire.

Construisez le temps / les ressources / le coût de la documentation qu'ils veulent et laissez-les voir jusqu'où cela pousse le calendrier.

Cela peut aider à leur montrer combien de travail ils mettent sur l'équipe de projet, et comment cela pourrait être réduit s'ils ne le faisaient pas.