Scrum est un Framework permettant de concrétiser la gestion Agile d’un projet. Depuis plusieurs années, il s’est fortement répondu et est devenu un indispensable pour certains types de projets.
Pour rappel, Scrum est utile pour des projets complexes. Il n’est pas une méthode mais bien une boite à outils pour une organisation.
Low-Code de son coté, est une solution qui permet de délivrer des projets informatiques dans des délais très courts. Livrer des projets rapidement peut être une bonne chose mais peut également amener vers un travail moins précis que s’il avait été réalisé en plus de temps.
Aujourd’hui nous pouvons mettre plusieurs éléments sous la loupe avec Scrum et Low-Code, nous les avons listé ci-dessous :
Sous la loupe
1) Scrum est plutôt destiné à des projets complexes, Low-Code rend la plupart des projets très simples.
Comme nous l’avons évoqué plus haut, Scrum est un Framework Agile qui va décomposer le travail complexe est une succession de travaux plus simples, effectués en plusieurs étapes jusqu’à livraison du résultat escompté.
Avec le Low-code, le volet développement de cette décomposition est très sommaire par ce que le travail des développeurs consiste surtout à faire interagir des modules déjà existants, ce qui permet de transformer des projets techniques complexes en projets simples.
2) Scrum préconise un product backlog par produit.
Grâce à Low-Code, une Scrum team peut travailler sur plusieurs product backlogs. En effet, habituellement, une Scrum team travaille sur un seul P.B à la fois.
Avec le Low-Code, une Scrum team est dans la possibilité de travailler sur plusieurs product backlogs en même temps.
3) La Timebox préconisé par Scrum d’un sprint de référence est d’un mois mais avec Low-Code, celle-ci peut être réduite jusqu’à une semaine.
Scrum met en place des réunions régulières destinées à garantir la bonne compréhension des besoins des clients au travers des périodes de validation les impliquant activement. D’autres réunions se focaliseront l’amélioration du cadre de travail des développeurs.
Ces réunions déterminent le début et la fin d’une période de travail appelée Sprint.
Selon la littérature, la durée d’un sprint doit être la plus courte possible pour permettre des réunions régulières et suffisamment longues que pour livrer des incréments amenant de la valeur ajoutée.
Avec le Low-Code, la vélocité de l’équipe (la vitesse avec laquelle il délivre ses incréments) est très fortement augmentée. Si on n’adapte pas la timebox (la durée) du sprint, nous risquons de perdre en efficacité.
4) Une Scrum team peut commencer à travailler à partir d’un scope suffisamment clair
On affinera alors les besoins en cours de développement. Les besoins vont changer pendant toute la durée de la création. On peut très bien changer de voies, revoir certains besoins, soumettre d’autres pistes et ainsi être amené à changer radicalement le scope principal. En partant d’un scope clairement défini, on peut commencer à travailler sur le projet, changer et affiner les éléments en cours de route.
Avec Low-Code on doit être beaucoup plus précis dans l’expression des besoins avant de commencer à développer. Low-Code qui est une outils RAD (Rapid Application Develment) doit partir d’un scope non seulement bien défini mais aussi précis dans les besoins sinon on risque de bloquer l’équipe de développement, faute d’input suffisant. On doit travailler plus en détail sur l’expression des besoins.
Scrum nous donne quelques outils, à condition de tolérer plusieurs coups de canifs dans le contrat.
On en a listé trois :
1) Plusieurs Product Owner pour des projets simples (à réaliser) en parallèle
Si l’équipe de développement travaille sur plusieurs product backlog, il faut un nombre de Product Owner au prorata pour garantir pour chacun d’entre eux une livraison time-to-market (adéquate avec les attentes du moment)
2) Apparition de deux rôles périphériques : Head-Of Product Owner et Tech Lead
Coté métier, le Head-Of Product Owner aura la vue métier transversale permettant de fixer des priorités entre les différents Product Backlogs en concurrence. Il sera celui qui coordonne et optimalise et priorise le travail des Product Owner.
Côté technique, le Tech Lead est le référent technique des Product Owner d’un côté et des développeurs de l’autre. Il fera une première passe sur les solutions technico-fonctionnelle afin de garantir la conformité des choix avant de confirmer la prise en charge du travail de développement.
3) Scrum Master très expérimenté, très flexible et très réactif
En fait, Une Scrum Team “low-code” va expérimenter les mêmes problématiques qu’une équipe de développement “classique” Mais elle va les expérimenter beaucoup plus vite.
Afin de ne pas noyer la Scrum Team dans des concepts au détriment de leur cœur de métier, c’est à dire la livraison d’incrément (c’est-à-dire des parties du produit), le Scrum Master doit être suffisamment expérimenté pour proposer des solutions robustes rapidement et pour faire vivre l’approche clé de l’empirisme et de la co-création…
Conclusion
Scrum est-il un Framework qui convient pour gérer un projet Low-Code ?
La réponse est oui si les coups de canif dont nous avons parlé ne vous font pas peur.