---

Surmonter le manque d’engagement, de gestion du changement et de travail d’équipe ! Cela pourrait vous surprendre !

La principale faiblesse des cadres d’amélioration antérieurs à Scrum était la suivante : Ils privilégiaient les exigences organisationnelles servant les intérêts de la direction.

notamment surveillance, conformité et prévisibilité. Bien servir les clients et améliorer le moral des employés n’étaient pas des priorités.

Les responsables logiciels et autres parties prenantes internes et externes cherchaient donc une date fixe de livraison et un suivi simple des phases d’ingénierie.

Ils pénalisaient les écarts au plan et espéraient résoudre les problèmes émergents avant la date prévue.

Des silos indépendants réalisaient des phases séparées. Le développement était totalement indépendant du test logiciel. La plupart des personnes censées partager la même mission ne connaissaient même pas le nom de leurs collègues.

Pourquoi cette mentalité de silo plutôt que des missions métier et la maturité professionnelle des employés ?

La raison est simplement la gestion matricielle . Ce modèle d’organisation et de gestion des employés existe depuis les années 1970. Son idée distinctive paraît intelligente au premier abord.

La direction regroupe les employés aux compétences fonctionnelles et techniques similaires dans les mêmes silos, ou au mieux des silos voisins.

La livraison en cascade dans une organisation matricielle

Les « centres de compétences » étaient courants ; chacun formait un silo indépendant et autonome.

Un silo de développeurs C++, un autre d’administrateurs de bases de données, un silo qualité complètement séparé à l’étranger, et ainsi de suite. Allez comprendre !

Sans Scrum ni Scrum Masters, les chefs de projet devaient emprunter temporairement des employés aux silos pour livrer leurs projets.

Ces personnes restaient même physiquement dans leurs centres de compétences, loin des équipes projet.

À la fin, les équipes temporaires étaient dissoutes et chacun passait à d’autres projets.

La valeur métier des projets n’était donc jamais la priorité suprême de ces silos indépendants.

Ils voyaient leur travail comme des cases à cocher pour un projet, puis un autre.

Ni la direction ni le modèle matriciel ne leur enseignaient l’engagement professionnel envers ventes, revenus et bénéfices de l’entreprise.

Un article de McKinsey & Company dans McKinsey Quarterly a aussi clairement illustré cette illusion d’optimisation des coûts au-delà de l’organisation matricielle .

Gartner estimait que les organisations mondiales dépensaient chaque année 600 milliards USD pour remettre leurs systèmes informatiques en état après des travaux de maintenance imprévus et des défauts.

Imaginons maintenant comment les projets géraient changements et obstaclesdans une configuration en cascade, matricielle et sans Scrum.

Oui, vous avez raison.

Direction et employés traitaient changements, obstacles et erreurs comme des exceptions malvenues qui n’auraient jamais dû arriver.

Un changement devenait synonyme de retard, provoquant souvent un effet domino. Les équipes cherchaient quelqu’un à blâmer pour les défauts et obstacles.

Sans mécanisme pour traiter, corriger et comprendre leurs erreurs, les silos répétaient les mêmes fautes.

De plus, ils continuaient d’accumuler la dette technique tout en tentant passivement de gérer leurs problèmes.