Pretotyping - rien de nouveau sous le soleil?

Pretotyping est la contraction du verbe to pretend (prétendre) et du mot prototype. Le pretotyping a pour but de valider une idée de produit, voire de trouver de premiers clients, alors qu'il n'y a ni produit ni vrai prototype développé.

Saviez-vous qu'un des exemples les plus anciens remonte au XVIIIème sciècle! Il s'agit du Turc mécanique. Je vous invite à aller voir sur wikipedia son histoire assez incroyable.

Si vous vous voulez découvrir un peu mieux ce qu'est le pretotyping, vous avez deux possibilités:

• Le site de référence en anglais (qui depuis sa création s'est beaucoup étoffé)
• Une traduction du site d'origine en français qui explique essentiellement de quoi il retourne.

  Bonne lecture!

Pourquoi la taille des équipes est-elle limitée en Scrum ?

Il est préconisé qu'une équipe de développement comporte de 3 à 9 personnes, Scrum Master non compris. En dessous de 3, se parler directement est ce qui fait le plus sens (d'ailleurs on appelle ça un binôme) et si vous êtes tout seul évitez de vous parler à voix haute trop souvent, pour collaborer avec vous même, ça pourrait paraître un peu bizarre ! Au dessus de 9 on constate que cela devient difficile à gérer, car on perd en efficacité et la coordination devient très complexe.

Une raison organisationnelle

Prenons par exemple la mêlée quotidienne (Daily Scrum) qui sert notamment à faire le point sur l'avancement et à se coordonner. Celle-ci doit tenir dans un temps de 15 minutes maximum. Avec une équipe de 5/6 personnes l'exercice n'est déjà pas si évident. En effet, pour tenir dans ce laps de temps, il faut que chacun ait une idée claire de ce qu'il va dire, qu'il arrive à le dire de façon concise et claire, et enfin qu'il se cantonne aux 3 questions : Qu'ai je fais depuis la dernière réunion ? / Qu'est ce que je vais faire aujourd'hui / Quels sont les obstacles qui gênent ma progression ? (et donc implicitement, Comment peut-on m'aider ?) Tout cela nécessite une préparation personnelle. 

Si vous dépassez les 15 minutes, vous risquez de faire perdre du temps à plusieurs membres de l'équipe voire à tous. On peut limiter le temps de parole, mais que ce soit plutôt pour que chacun s'exprime en un temps imparti. La mêlée quotidienne est donc un exercice exigeant.

Prenons une réunion plus longue comme le Sprint Planning. C'est lors de cette réunion que le Product Owner expose les scénarios (User Stories) qu'il envisage pour une livraison à la fin du sprint suivant (l'itération suivante). De façon très résumée, l'équipe échange avec lui pour comprendre les scénarios, évalue la complexité de ceux-ci et s'engage sur ceux qu'elle réalisera. Hors mécaniquement, le temps nécessaire pour faire ce travail s'accroît avec le nombre de personnes présentes, la variété et le nombre de scénarios. La durée d'une telle réunion étant limitée pour des raisons d'efficacité, on ne peut avoir un nombre de participants trop grand. 

Une raison physique et humaine

Des études ont montrées que si une équipe de développement logiciel est toute réunie au même endroit (sans cloison) elle sera jusqu'à deux fois plus productive que si elle est disséminée (Teasley, Covi,Krishnan, & Olson, 2000). On considère que pour un fonctionnement optimal, tout membre de l'équipe doit être à 6 mètres maximum de tout autre membre, et j'ajouterai même, il est mieux que l'équipe soit regroupée en un îlot. 

J'ai géré récemment un projet avec deux personnes situées à une vingtaine de mètres du reste de l'équipe et je peux vous dire que c'était assez pénible à cause du temps perdu à faire les allers-retours, et à cause des problèmes que cela ajoutait en termes de communication et de collaboration du fait de leur isolement. La proximité physique favorise le dialogue en face à face, les échanges et aide à sortir de l'isolement.

Entendre ce qui se dit, voir les visages, les attitudes, facilite la convivialité, la détection des problèmes humains, techniques et permet d'avoir une meilleure perception de l'équipe et du déroulement du projet. C'est donc une aide pour le Scrum Master dans son rôle de "leader au service de l'équipe". L'organisation physique doit ainsi favoriser tout cela en permettant :

• de voir les autres membres de l'équipe sans se lever de son siège,
• d'avoir la possibilité d'aller les voir facilement et donc de communiquer en face à face,
• d'entendre ce qui se dit à proximité.

Et donc forcément, cela fonctionne bien avec une équipe à taille contenue.

Conclusion

Dans une approche agile comme Scrum on recherche avant tout l'efficacité et c'est pour cela que l'on fixe des contraintes et des limites. Celles-ci n'ont pas été décrétées du jour au lendemain, mais sont le fruit de l'expérience acquise par la pratique. Au delà de la taille de l'équipe d'autres éléments sont à mettre en place comme la disposition dans les locaux. Si votre projet nécessite un nombre plus important de personnes que celui préconisé, c'est une organisation adaptée qu'il faudra mettre en place avec davantage d'équipes et une coordination adaptée. Il existe pour cela diverses approches comme SAFe pour Scaled Agile Framework, Nexus qui a été conçu par un des fondateurs de Scrum, mais c'est un autre sujet.

L'année de la simplification ?

Albert Einstein disait « N’importe quel imbécile peut faire quelque chose de sacrément complexe. Mais il faut un génie pour faire quelque chose de simple ». Tout de même, il n'est pas nécessaire d'être bête pour faire des choses complexes: c'est à la portée de tout un chacun! Par contre faire simple est souvent bien moins évident.

Entre le code du travail qui atteint les 3400 pages, le journal officiel qui atteint les 23000 pages par an (!), l’excès de normes et le choc de simplification qui parait finalement un peu mou, les français semblent s'être fait les champions de la complexité et semblent aussi peiner à en sortir. Tout cela nous ferait presque douter du génie français ou au moins de son utilisation à bon escient!

La recherche de la simplicité nécessite une capacité de synthèse, des choix en fonction de ce qui est important, une réelle vision, de l'analyse de la valeur pour garder ce qui en apporte, mais aussi une prise en compte des impacts de la transformation que l'on va engager. Simplifier c'est aussi parfois rendre son vocabulaire métier plus cohérent, lever les ambiguïtés, donner accès à l'information de façon plus transparente, (se) rendre plus accessible, mettre fin à de mauvaises habitudes...

Si apprendre à faire simple demande de la réflexion, du temps, de la persévérance, de l'expérimentation, de la méthode et un certain courage, on mesure bien que c'est pour un réel gain qui peut être sur le plan humain, organisationnel, projet, financier, ... 

Enfin si vous n'avez pas de génie sous la main, vous avez au moins l'intelligence cumulée de vos collaborateurs et conseils, qui je vous le souhaite, pourra vous aider grandement dans vos démarches. 

Aussi je vous souhaite une belle année 2016 synonyme de simplification et de simplicité.