Comment j'ai ajouté de la structure à une équipe de développement de start-up - Et ce que j'ai appris du processus

Article original : How I Added Some Structure to a Start-up's Development Team - And What I Learned from the Process

Par Hughie Coles

Jusqu'à récemment, j'avais passé les 4 dernières années de ma carrière dans des start-ups FinTech. J'avais toujours travaillé pour des petites entreprises, et rejoindre une start-up était l'étape logique suivante pour chercher des rôles où je pourrais faire la plus grande différence.

Mais un problème courant avec les start-ups en phase initiale est qu'il s'agit un peu d'un chacun pour soi en termes de gestion.

Ces entreprises sont souvent dirigées par des personnes qui n'ont pas une tonne d'expérience dans la gestion d'entreprises. Et la gestion tend à être assurée par les fondateurs et ceux qui sont entrés tôt, pas nécessairement ceux qui excellent dans les rôles de leadership. (Pas de critique – une bonne personne + talentueuse ne signifie pas nécessairement qu'elle est un bon patron ou leader).

Pendant mon temps dans une telle start-up, j'ai été promu de développeur senior à développeur principal.

Le catalyseur de ce changement était que l'équipe de développement manquait de leadership. Le CTO avait trop de responsabilités, et le travail de maintenir l'équipe de dev engagée et productive tombait dans les craques.

En plus de cela, nous n'avions pas de chef de projet, et nos chefs de produit étaient trop inexpérimentés pour introduire une quelconque structure.

C'est l'histoire des victoires et des défaites, et comment ajouter un processus à une entreprise qui n'en a pas.

Événements menant au changement

D'abord, un peu de contexte. Mon travail précédent avait été celui de développeur dans une agence digitale. Cette agence était un pur shop scrum qui avait formé tous ses employés de manière assez approfondie à scrum, et à l'agile en général.

Je venais donc d'un environnement avec beaucoup de processus. C'est partiellement pourquoi j'ai quitté pour poursuivre dans une start-up.

Environ un an après, j'ai commencé à remarquer quelques problèmes. Tout d'abord, le turnover des développeurs augmentait. Les développeurs ne se sentaient pas engagés. On leur confiait des projets à moitié cuits sans contexte sur la manière dont cela aiderait la croissance de l'entreprise, sans input dans la conception ou la planification, et avec loin de suffisamment de détails.

Puis est venu un projet qui a cristallisé notre problème. Le produit sur lequel je travaillais avait le concept de factures (comptes à payer) et de factures (comptes à recevoir). Nous travaillions sur une nouvelle fonctionnalité qui permettrait aux utilisateurs de télécharger une image d'une facture et de la faire saisir manuellement par un service.

Le problème était que le chef de produit continuait à dire "factures" au lieu de "factures". Il n'y avait pas d'histoire utilisateur, pas de ticket, tout cela était dans l'esprit du chef de produit. Les exigences étaient communiquées verbalement ou dans des messages Slack. Le développeur travaillant sur le projet n'avait jamais entendu que "factures".

Ce n'est que lorsque le CTO a entendu une conversation quelques jours avant la sortie que nous nous sommes rendu compte que nous avions ciblé le mauvais aspect du système.

Heureusement, les factures et les factures étaient, pour la plupart, symétriques dans notre système, donc ce n'était pas beaucoup de travail pour faire le changement. Il est simplement devenu très clair que nous avions un problème.

Étant donné mon expérience et le fait que j'étais l'un des développeurs les plus seniors et anciens de l'entreprise, il était logique que je prenne les rênes.

Puisque je dirigeais l'initiative, j'ai choisi de mettre en place un processus de type scrum. Dans le reste de cet article, je vais décrire ce que nous avons fait, comment nous l'avons fait, et pourquoi cela a été fait, ainsi que mes apprentissages.

Obtenir l'adhésion

Je vais commencer par dire que je n'aime pas imposer des commandements d'en haut. Je pense qu'une relation leader-équipe est collaborative. Je peux occasionnellement jouer le rôle de leader parce que c'est ma nature, mais il est important que les idées soient discutées et que les gens sentent que leurs opinions sont entendues et valorisées.

La première étape a été de réunir les développeurs pour une discussion. Lors de cette discussion initiale, j'ai exposé ce que je pensais être nos problèmes. Cela comprenait le manque de clarté sur les exigences, les délais glissants et notre absence totale de stratégie de test. La discussion a validé mes pensées, car l'équipe ressentait la même chose.

Le reste de la réunion a consisté à exposer scrum, les éléments que je pensais pouvoir nous bénéficier et à quoi cela ressemblerait. J'ai également discuté de certaines choses que j'avais apprises sur les plans de test et le QA systématique que j'avais appris lors de mes jours d'agence. Nous avons ensuite fait le tour de la table, donnant des avis, posant des questions et ajustant.

J'ai concédé que les tests manuels n'étaient pas amusants ou idéaux pour l'équipe de dev, mais jusqu'à ce que nous puissions justifier un ingénieur QA à temps plein, nous devions faire de notre mieux avec ce que nous avions.

Apprentissages :

• Si vous avez une bonne idée, tout ce dont vous avez besoin est une chance de prouver sa valeur.
• Enrôlez votre équipe pour aider à construire cela ensemble, faites en sorte que tout le monde fasse partie de la solution et ils la posséderont avec vous.

Notre version de Scrum

Après avoir décrit à quoi ressemblerait un processus scrum "complet", j'ai exposé à l'équipe le but de chaque aspect et rituel. Je voulais souligner où nous pourrions obtenir les plus grands gains. Personne ne voulait 10 heures de réunions par sprint.

En parlant de sprints, nous avons décidé de commencer avec une boîte de temps de 2 semaines avec l'idée de la passer à 3 semaines si nous voulions moins de frais généraux et pouvions nous permettre des sorties moins fréquentes.

Le processus que j'ai mis en place était le suivant.

Nous avions un sprint commencé avec une réunion de toilettage/planification de 2 heures un lundi matin. Lors de cette réunion de planification, nous (l'équipe de dev et le chef de produit) avons fait un passage sur le backlog. Ce passage consistait à clarifier l'histoire pour lever les malentendus ; estimer en utilisant des points d'histoire ; et prioriser en fonction de la feuille de route de l'entreprise. L'équipe a ensuite sélectionné la quantité de travail que nous pensions pouvoir faire, en fonction de la priorité, et l'a apportée dans le sprint actuel.

Ce travail était une collection d'histoires utilisateur. Le chef de produit partait, et l'équipe de dev décomposait ces histoires en tâches, avait une idée générale de qui travaillerait sur quoi, et ensuite nous nous mettions au travail. Cela a donné au chef de produit une transparence sur ce que nous pouvions livrer, ce qui faisait cruellement défaut. Cela a également donné à l'équipe leur charge de travail complète pour 2 semaines, ce qui nous a permis de planifier et de rythmer en conséquence.

Les jours suivants étaient des jours de dev. Cela comprenait des revues de code par les pairs sur les branches de fonctionnalités avant qu'elles ne soient fusionnées. La fin du travail des devs était le mercredi de la 2ème semaine à midi. Nous préparions ensuite la build QA, la feuille de calcul QA (plus d'informations à ce sujet dans un instant), et commencions les tests manuels.

L'idée était de terminer le premier passage QA d'ici la fin du mercredi, et de passer le jeudi et le vendredi dans une boucle de correction de bugs/test jusqu'à ce que nous soyons satisfaits de la build.

À ce stade, la build était remise au CTO pour une revue de code finale, et elle était déployée le mardi suivant. Les problèmes trouvés lors de la revue de code étaient corrigés et testés le lundi si nécessaire.

Le vendredi après-midi, nous avions une rétrospective/postmortem sans blame. Ici, nous avons tout mis à nu. Il est important de reconnaître ce qui s'est mal passé, et de s'attaquer à la ou aux causes afin que nous puissions l'éviter à l'avenir.

Tous les développeurs (y compris moi-même) ont beaucoup appris grâce à ce processus. Je pense que nous sommes tous mieux lotis après l'avoir traversé. J'ai même entendu le PDG suggérer de faire des postmortems sans blame quelques semaines après que nous avons commencé à les faire dans l'équipe de dev. C'était agréable de voir que nos idées étaient adoptées.

C'était l'une des grandes victoires. Nous avons appris pourquoi une fonctionnalité était nécessaire, quelle était l'intention derrière elle, et tous les détails et attentes.

Apprentissages :

• Divisez et combinez les réunions en fonction des besoins de votre équipe. Ne faites pas les choses "juste parce que"
• Partagez vos progrès en dehors de votre département. Parfois, vos idées peuvent apporter des bénéfices en dehors de votre équipe.

Un Framework de Test en Qui Vous Pouvez Croire

Cette entreprise n'avait jamais eu de processus de test formel. Cela signifiait pas de plan de test, pas de test par les pairs, juste un développeur vérifiant que cela fonctionnait, et cela allait en production.

D'après mon expérience, les développeurs sont aussi bons en test qu'en estimation, donc nous devions changer cela. Nous avions une bonne suite de tests automatisés (unitaires et d'intégration), mais pas de tests de bout en bout. Je préfère aussi avoir quelques tests exploratoires. Dans le passé, je les ai vus découvrir des comportements étranges que les tests automatisés peuvent manquer.

Nous avons mis en place un document Google avec tous les tickets (y compris les liens vers les histoires utilisateur) dans la première colonne, et tous les noms des développeurs (et le PM) dans la première ligne. L'idée était que chaque ticket devait avoir 2 X, tous deux de personnes qui n'avaient pas travaillé sur la fonctionnalité. Cette stratégie de diviser pour mieux régner nous a permis de tester très minutieusement en un temps relativement court.

Apprentissages :

• Misez fortement sur les tests automatisés. Ils sont fiables et trouvent de nombreuses classes de bugs sans temps manuel.
• Testez avec un plan. Vous allez perdre beaucoup de temps à errer. Une approche systématique peut rendre les tests manuels plus efficaces.

Succès

Quel a été le résultat ? Je n'ai pas de chiffres exacts, mais le taux de défauts a chuté. Il n'y avait plus de correctifs chauds précipités en production. Le travail promis était livré. Les fonctionnalités étaient publiées à temps.

Nous avancions plus vite que jamais, et les développeurs étaient plus heureux. Nous travaillions en équipe au lieu de travailler en silos, nous connaissions tous les fonctionnalités des autres intimement parce que nous avions tous passé en revue les histoires utilisateur et estimé ensemble. Il n'y avait plus ce "oh, je ne peux pas toucher la fonctionnalité X, je n'ai pas travaillé dessus" en silos.

Un développeur qui prévoyait de partir a arrêté de chercher. C'était génial.

Apprentissages :

• Continuez à ajuster votre processus en fonction des résultats. C'est un processus continu.
• Parfois, les gens ne veulent pas quitter une entreprise, ils veulent quitter une situation.

Une Fin Abrupte

Mais rien de bon ne dure :) D'accord, c'est un peu dramatique. Alors que l'équipe de dev se soudait, augmentait notre vélocité et construisait plus de camaraderie, la direction allait dans une direction différente.

Le PDG avait fait beaucoup de lectures et décidé que les OKR étaient ce qui allait faire passer l'entreprise au niveau supérieur. Malheureusement, il a été décidé que les OKR iraient jusqu'au niveau individuel, ce qui signifiait que l'équipe ne regrouperait plus le travail, ne le décomposerait plus et ne l'aborderait plus ensemble. Au lieu de cela, chaque développeur travaillerait (ou en pratique, se verrait attribuer) un ensemble de KRs, et lui seul serait responsable de leur livraison.

Nous étions de retour aux silos. L'équipe de développement a résisté, nous avons essayé de compromettre, de stopper les OKR au niveau de l'équipe, mais c'était inutile. Le rêve était mort. Oui, encore avec le drame, mais c'était un peu triste.

Ce changement a coïncidé avec un léger changement dans la structure de pouvoir, mon titre de développeur principal est devenu peu plus qu'une platitude, le "leadership" a dit des choses très désagréables à l'équipe de développement (quelque chose comme "embarquez ou partez"), ce qui a conduit à la moitié de l'équipe de dev, y compris moi-même, à partir dans le mois.

Apprentissages :

• Les bonnes idées ne l'emportent pas toujours. Même dans une situation comme celle-ci, vous pouvez apprendre beaucoup.
• Reconnaissez quand vous ne pouvez plus faire la différence.

Des Erreurs Ont Été Commises

Étant donné la manière dont le dernier paragraphe s'est terminé, vous pourriez penser que j'allais énumérer les erreurs commises par l'entreprise. Mais je ne vais pas faire cela.

Cela fait environ un an que je suis parti, et depuis, j'ai appris une ou deux choses. Il y avait des lacunes sérieuses dans le processus que nous avions créé. C'étaient des choses que je ne comprenais pas vraiment ou que je ne connaissais pas à l'époque. C'était dû à mes lacunes, mais nous nous améliorons tous chaque jour.

Avec le recul, voici quelques choses majeures que j'avais manquées :

Nous ne mesurions pas.

Comment savez-vous que vous avez bien fait si vous n'avez pas pris de mesures avant et après ? Nous n'avions pas de télémétrie, très peu d'alertes, et franchement, si une fonctionnalité avait un impact négatif, nous ne le savions pas.

Trop de tests manuels, pas assez d'automatisation.

Ce qui nous manquait vraiment, c'était une belle suite de tests E2E automatisés. Nous avons commencé à travailler sur ceux-ci vers la fin, mais nous ne les avons pas assez priorisés. Beaucoup des erreurs que nous avons trouvées lors des tests manuels auraient pu être attrapées lors de certains tests d'acceptation utilisant cucumber, ou certains tests E2E selenium.

Sorties en grand bang.

Je sais qu'une partie commune de scrum pour de nombreuses entreprises est l'idée que tout le travail du sprint est démontré et publié ensemble.

Le problème avec cela est double. Premièrement, dans une start-up, vous devez bouger plus vite. Vous devez devancer les autres et obtenir de la valeur pour les clients et des retours des clients aussi rapidement que possible. Et plus la boucle de retour est serrée, mieux c'est.

Par conséquent, plusieurs sorties par sprint auraient été meilleures. C'est plus difficile à coordonner les tests et le QA, mais c'est toujours mieux de sortir rapidement et souvent.

Deuxièmement, plus la sortie est grande, plus le risque est élevé. Sortir de plus petits morceaux signifie que moins de changements sont publiés en une fois. Si un problème survient, il est plus facile à identifier et à corriger, et un retour en arrière n'affectera pas d'autres fonctionnalités correctement fonctionnelles.

J'ai donc appris que sortir en verticales aussi petites que possible est la manière la plus sûre et la moins couplée de sortir du logiciel.

Conclusion

Malgré tous les faux pas et la fin malheureuse, je pense que l'expérience a été un succès. J'ai appris ce que cela signifiait de guider une équipe de développeurs à travers un processus, de prendre des retours et de les appliquer, et d'essayer et de rejeter des idées qui, même si elles "devraient être là", ne convenaient tout simplement pas à notre équipe.

Il est important d'adapter votre processus à votre équipe et à votre organisation. Vous devez ajouter suffisamment de processus pour guider, mais pas assez pour entraver. Cela m'a appris comment mettre en œuvre un processus, faire avancer des idées, aider les autres à être entendus et comment diriger depuis l'intérieur d'une équipe.

Bien que cela se soit mal terminé, ce fut un grand pas en avant dans ma carrière, et cela a vraiment consolidé ma capacité et mon désir de diriger.

Vous pouvez trouver plus de mes articles sur mon blog medium.