mai 26, 2011 4

Scrum et agilité en startup : micro-scrum ?

By in Agile, gestion de projets, la vraie vie, Scrum

La startup dans laquelle je travaille désormais depuis presque 2 mois a des problemes. Ce ne sont pas de graves problèmes, mais ils sont bien présents, et ont un impact certains sur la visibilité, la communication, et la gestion globale des projets principaux comme annexes.

Aussi, quelques semaines après mon arrivée, j’ai envisagé d’appliquer certaines pratiques agiles dans un contexte startup. Non concluant, ayant oublié l’essentiel: je me suis en effet concentré sur la communication au sein de l’équipe, en cherchant à être le moins intrusif possible dans les process en cours, sans pour autant tout mettre en œuvre et proposer les mesures nécessaires à une vraie communication. Résultat : des idées, mais non abouties. Aussi, lorsque notre boss est rentré de weekend avec l’envie soudaine de faire du scrum, du vrai, du dur, 2 idées contradictoires m’ont assailli :

  • scrum, en mode “méthode hyper appliquée”, c’est n’est pas lourd, mais compliqué a mettre en place (cette complication étant avant tout relative aux mentalités/habitudes qui ont la vie dure, aussi petite soit la structure où on l’applique)
  • scrum, c’est tellement classe sur le papier que, bien appliquée, cette méthode pourrait prévenir tous les problèmes auxquels nous faisons actuellement face : manque de clarté, interférences lors des processus de développements, regressions sur l’application, délais non tenus …

Alors je m’interroge, n’étant pas certifié scrum: est-ce une hérésie que de penser adapter scrum à son contexte ? J’ai l’intime conviction que, si l’on colle au méthodes et dogmes de base, on doit pouvoir non pas assouplir les règles, mais assouplir/modifier la maniere de les appliquer.

Qu’en pensez-vous ?

4 Responses to “Scrum et agilité en startup : micro-scrum ?”

  1. Scrum n’est pas *la* réponse à tous les maux, elle ne fait que t’offrir un cadre pour le travail.

    Il faut identifier clairement les problèmes actuels, dont tu parles :

    - Régressions de l’application
    - Respect des délais
    - Manque de communication

    Et trouver une solution à chacun :

    - Régressions de l’application = prévoir l’écriture de tests fonctionnels pour renforcer la stabilité + intégration continue pour s’assurer *automatiquement* que le projet est OK
    - Respect des délais = Faire des lots suffisamment petits pour être mesurables en heures (5 heures, 10 heures, 15 maximum) + Tracking précis du temps de chacun sur chaque tâche
    - Manque de communication = Mettre en place un process simple : fonctionnement par tâche, la tâche n’est pas “commencée” tant que le développeur n’a pas certifié avoir toutes les infos + ne pas rester bloqué sur une inconnu/incertitude : dans ce cas, suspendre la tâche, demander les infos.

    Je pense qu’il est possible de faire une transition douce vers Scrum. Tu peux le faire par étape :

    0. Definition of Done : dire qu’une tâche est “terminée” veut dire : réponse correcte à la demande + documentation + tests + ce qui est propre à ton projet –> A DÉFINIR AVEC TOUTE L’ÉQUIPE
    1. Toute demande doit être splittée en tâches traitables (15h maximum, privilégier les 2h/3h) + vérification des requis avant de les commencer : avoir compris le besoin + avoir tous les élements pour y répondre.
    2. Intégration continue
    3. Désigner un scrum master, qui sera responsable de la mise en oeuvre global d’un process

    Des sociétés

  2. Pwa commentaire parti trop vite :

    Des société existent pour accompagner la mise en place de tels méthodos. Dis à ton boss que ça pourrait être opportun de faire un consulting. La seule que j’connaisse : http://www.efidev.com/ (les mecs sur la photo sont les vrais gars ;) ).

    Voilà bon courage à vous !

  3. pixelboy dit :

    Yo,
    l’article est peut etre mal formulé, mais il est évident que je ne considère pas la méthode comme un remède, mais comme un cadre de travail sructurant, avec tous les avantages qu’implique cette structure. Je réfléchis justement à la meilleure manière d’appliquer scrum en douceur. On commence par exemple à se familiariser avec la notion de user-story, on parle peu a peu d’itérations… MAIS ! pour plonger la tête la premiere dans le bain, la période n’est pas la bonne.
    De plus, le fruit de mes reflexions concerne avant tout la justesse/la bêtise d’installer scrum dans un environnement qui ne lui conviendrait pas (la méthode nécessite certaines ressources dont nous ne disposons pas forcément) sans justement l’y adapter.
    Je réfléchis au moyen de trouver un juste milieu entre respect de la méthode et adaptation de celle-ci. Sans méthode, pas d’efficacité, mais sans souplesse, trop de contraintes, et donc pas de méthode non plus…

  4. C’est quoi la méthode ?
    J’ai cru en entendre parler ça et là, et de mon expérience sur un projet sur lequel je travaille en ce moment, la méthode n’est pas toujours applicable.

    Cela va dépendre de multilples contraintes :
    - tâches courantes/quotidiennes pour assurer un maintient d’une application en production
    - contraintes business
    - la volonté de l’équipe à se soumettre à la méthode

    Mais je pense que l’on peut quand même structurer sa manière de travailler. Ce que propose le monsieur qui prenait ses pieds en photos est une bonne approche je pense.

    Mais dans l’utilisation de toute méthode il y aura du temps de gestion consacrer au bon déroulement de la méthode.
    Je pense aussi que l’utilisation de certains outils peuvent aider à structurer : redmine, pivotaltracker, thescrum (là on es clairement dans la méthode).

    Sur ce, aurevouaîre !

Leave a Reply