Carnet de notes

Catégorie : Méthodes agiles

  • Arrê­tons avec les frame­works agiles

    Jetez moi SCRUM, Shape-up et les autres, et encore plus leurs versions dites « at-scale » type SAFe. Je ne comprends même pas comment on en est arrivé là alors que le mani­feste agile met en avant «  Les indi­vi­dus et leurs inter­ac­tions, de préfé­rence aux proces­sus et aux outils ». Prétendre cadrer les indi­vi­dus et les inter­ac­tions via…

  • Les esti­ma­tions de petites tâches ne sont pas plus précises

    Un des premiers mensonges qu’on vous livre trop souvent avec SCRUM c’est qu’on peut esti­mer des petites tâches avec bien plus de préci­sion que des grandes, et qu’en consé­quence on peut être assez fiable dans l’es­ti­ma­tion des une à trois semaines de chaque itéra­tion. Foutaises ! Combien de temps faut-il pour mettre les blou­sons avant d’al­ler…

  • Story points

    Points de complexité, points d’ef­fort, tailles de tshirt… J’ai vu des équipes travailler avec des comp­tages allant d’une mesure en heures de travail à des mesures au simple nombre de tickets. Je n’ai pas trouvé de réelle corré­la­tion entre la réus­site des équipes et leur façon d’es­ti­mer, ou même avec l’exis­tence ou non d’es­ti­ma­tions. Si…

  • Conti­nuous Deli­very: The Dirty Details

    Conti­nuous Deli­very: The Dirty Details from Mike Brit­tain Il n’y a rien d’ex­cep­tion­nel­le­ment nouveau mais ça permet quand même de prou­ver certaines pratiques : Préfé­rer des déploie­ments en perma­nence plusieurs fois par jour plutôt que de faire un événe­ment une fois de temps en temps à date program­mée avec vrai proces­sus autour.

  • Product Mana­gers, Product Owners, and Scalable Models for Agile Product Teams (Cisco)

    Le titre dit déjà tout. Peut être rien de révo­lu­tion­naire, mais quelques rappels et défi­ni­tions bien inté­res­santes. Je refor­mule mais « les commer­ciaux ont pour rôle de faire tout ce qui est raison­nable ou dérai­son­nable pour boucler le gros deal à venir, dont les un ou deux trucs que que le produit n’a pas et qui…

  • How we do large scale retros­pec­tives

    In late 2014 we had an oppor­tu­nity to run a program level retro for an inno­va­tion initia­tive that span­ned across 80–90 people in NYC and Stock­holm.  Instead of a large session, we opted to try some­thing bit different – and we found it to work better for these types of initia­tives. — Labs at Spotify Et…

  • Micro­soft’s 16 Keys To Being Agile At Scale

    Every six months there are scena­rio reviews. The group reviews progress and examine where they want to go next. That gene­rally means a recas­ting of the scena­rios. There are three ques­tions: what have we lear­ned over the last six months based on what we built? What do our custo­mers tell us? And what’s chan­ged in…

  • Retro­mat – inspi­ra­tion & plans for (agile) retros­pec­tive

    En panne sur les rétros­pec­tives ? Envie de redon­ner un peu de souffle et d’en­train ? Florie m’a fait passer un lien vers Retro­mat, je vous recom­mande de jouer avec. Plein d’idées pour réflé­chir. Plan­ning your next retros­pec­tive? Get star­ted with a random plan, tweak it, print it and share the URL. Or just browse around for…

  • One Product Team

    One Product Team: We are not a sepa­rate group of desi­gners, gang of deve­lo­pers, bunch of testers, with a king product owner, who only meet each other when it is needed. We sit toge­ther as a team. We talk and play every­day. And we all love what we are buil­ding. — User expe­rience and design in…

  • Prio­ri­sa­tion du back­log

    Ce billet vient d’un désac­cord sur twit­ter sur les éléments qui permettent de prio­ri­ser un back­log dans un déve­lop­pe­ment agile. On me propose de trier par valeur fonc­tion­nelle (je vais parler de valeur ajou­tée au produit, pour éviter de mélan­ger avec la complexité fonc­tion­nelle) mais cela ne me convient pas. Toutes les histoires n’ont pas…