La culture d'entreprise et la performance des équipes
Vos équipes ne sont pas performantes et vos applications sont pleines de bugs ? Regarder d'abord votre culture !
Articles sur organisation
Imposer ne signifie pas être un bon leader !
En imposant, on se retrouve à faire des actions qui ne sont pas forcément comprises et faites correctement.
Une équipe ne devrait pas avoir à justifier sa manière de travailler
On voit souvent dans les entreprises, des responsables qui ont la main mise sur l’organisation des équipes et qui souhaitent la garder de peur de ne pas atteindre les objectifs fixés.
Peut-on dire que l’on est une équipe en étant chacun dans son coin ?
En principe dans l’IT, chaque membre d’une équipe avance de son côté et se retrouve uniquement lors de réunions. Cela nous permet de faire le point, de potentiellement se débloquer, et l’on reprend comme si de rien n'était nos tâches en cours, seul...
Vous cherchez comment faire monter en compétence votre équipe ?
Faites du mob ! Le mob programming (ou Software Teaming) est une approche rassemblant une équipe pour travailler sur la même tâche, au même moment, dans un même espace et sur le même ordinateur.
Un QA ne devrait pas être séparé de l’équipe de développement
L’intérêt d’un QA n’est pas juste de faire ce que les devs ne font pas, mais de leur donner la possibilité de faire mieux !
Pourquoi tant d’entreprises font du cycle en V avec Scrum ?
On pense faire de l’agilité, mais on garde nos vielles habitudes qui ne sont pas agiles ! Que cela soit la durée d’un sprint ou d’une US, un waterfall itératif reste un waterfall.
Un développeur n’est pas un simple exécutant !
Ils ne sont pas là pour suivre des directives et faire ce qu’on leur demande.
« On est organisé en feature team mais on n’a pas accès à la prod »
C’est un peu comme vouloir utiliser une moto de course dans Paris. Elle sera forcément bridée et ne pourra pas aller à son plein potentiel.
Utiliser le Daily Scrum pour suivre les devs fait perdre du temps !
Plutôt que de s’attarder sur l’avancement de manière individuelle, pourquoi ne pas juste regarder l’avancement des tâches ?
Vous ressentez de la frustration à cause de vos Pull Requests ?
Voici 10 cas personnels et des solutions que l’on peut envisager pour y répondre👇
Le Daily Scrum n’est pas fait pour suivre les développeurs
Le daily est fait pour les développeurs par les développeurs !
« C’est toi le lead, c’est à toi de réfléchir »
J’ai déjà entendu cette phrase il y a quelques années et elle m’avait particulièrement choquée. 😱
« J’ai pas le temps pour écrire des tests »
L’écriture de tests ne fait pas perdre du temps, bien au contraindre !