What's up agile : Quand le démarrage d’un projet en agile n'est pas "assez rapide"
Découvrez tous les tweets les plus marquants de la twittosphère #agile #kanban #scrum. Dans ce nouveau what's up agile, les twittos vous racontent les démarrage de projets agiles.
Vous démarrez un projet en agile pleins d’entrain et êtes impatients de voir les premières réalisations. Oui mais ... passé l’engouement des premiers jours, vous avez la sensation que les choses n’avancent pas aussi vite que ce que vous espériez. Que se passe-t-il réellement ? Est-ce normal ? Questionnez-vous d’abord sur vos attentes. Est-ce que la rapidité est un critère de qualité pour vous ? Envisagiez-vous d’aller vite dès le début du projet ?
Agile n’est pas le synonyme de rapidité. Cela signifie adaptable/réactif. Si ce n’est pas votre objectif, vous pourriez être déçus. #Agile is not a synonym for fast. It means adaptive/responsive. If that is not your goal, you may be disappointed.
— Karim Harbott (@KarimHarbott) 17 juillet 2017
Et bien souvent les démarrages de projets ressemblent plutôt à ça :
They call it "iteration 0" for a reason... #agile pic.twitter.com/TbObVYQSVq
— I Can Haz Agile? (@agile_memes) 2 février 2018
La première revue de sprint du projet. Ce n’est pas pour rien qu’ils appellent ça "l’itération 0" …
Oui au départ les équipes ont parfois peu ou pas d’éléments fonctionnels à présenter … mais c’est normal !
Si vous élaborez un produit qui doit tenir dans le temps, vous aurez besoin d’une phase de démarrage plus longue pour construire des bases solides et durables. Si vous allez vite dès le début, cela signifie potentiellement que votre produit sera rapidement obsolète ou de mauvaise qualité.
En voici un exemple avec du refactoring :
make a case for regular refactoring / debt workdown. At least try to get some $s behind the idea #agile #funding pic.twitter.com/df7eC71LVF
— John Cutler (@johncutlefish) 9 février 2018
Faites un refactoring régulier pour faire baisser la dette. Au minimum essayez de gagner de l’argent grâce à cette idée.
Sans refactoring, le projet peut démarrer plus vite mais le coût sur le long terme est plus élevé que si le refactoring avait été initié dès le début.
Le démarrage du projet sert aussi aux équipes à s’approprier le sujet.
La vélocité moderne pour les équipes agiles devrait plutôt être de mesurer sa vélocité à apprendre. The velocity modern #agile teams should actually measure is velocity of learning.
— Jeff Gothelf (@jboogie) 7 février 2018
Voici un bon principe pour trouver le juste équilibre entre apprentissage et réalisation :
Ne fabrique pas plus vite que ce que tu peux apprendre. Good, simple principle: Don't build faster than you can learn.#Agile #UX #DevOps
— Charles Lambdin (@CGLambdin) 5 février 2018
L’important n’est donc pas d’essayer d’aller plus vite (au risque de perdre la qualité recherchée), mais de ne pas se perdre dans des détails qui risquent d’évoluer au fil du temps.
Quand nous sommes concentrés sur un problème, il est important de ne pas perdre le contexte. When concentrating on a problem it's important not to lose context... #troubleshooting #agile #devops #devopscats pic.twitter.com/NoDWZxqwJf
— DevOpsCats (@DevOpsCats) 5 octobre 2017
Il vaut donc mieux avancer en expérimentant.
Dans la plupart des cas, l’action produit bien plus de résultats que la planification. In almost every case, action will produce many times more results than planning. #scrum #agile #team… ^ @mccarthyshow pic.twitter.com/KiZ6TYI2Fw
— AgileFortune (@AgileFortune) 22 février 2017
Alors, ne foncez pas tête la première pour produire à tout prix, mais ne passez pas non plus trop de temps à contempler et à vous perdre dans les méandres de l’information récoltée. Le succès viendra de votre capacité à apprendre tout au long du projet. Et l’apprentissage s’acquiert également par l’action …
While ( ! ( succeed = try() ) ); Don't stop trying#devon #agile #scrum #motivational #leadership pic.twitter.com/Y6rkCyW2ah
— DevOn India (@DevOn_India) 7 février 2018
Pendant que (!(succès = essaye())); N’arrête pas d’essayer!