Chaîne de valeur pour l’entreprise et le Produit

Actuellement, l’agilité sur la création ou la gestion de Produits se concentre sur la valeur pour nos utilisateurs.

La valeur ?

La valeur se représente le plus généralement en :

  • Valeur monétaire :
    Quels sont les gains potentiels de cette fonctionnalité, si nous la réalisons ?
  • Valeur de gain de temps
    Comment pourrions-nous réduire le temps entre le paiement et la livraison ?
  • Valeur émotionnelle :
    Comment créer une relation durable avec nos clients ?
    Qu’est-ce qui permet à notre client d’être satisfait de notre application ?
  • Valeur de réputation :
    Comment faire pour communiquer sur nos succès ?

Les agilistes vont vous pousser à valider vos hypothèses :
Comment pouvons nous démontrer que nos utilisateurs utiliseront cette fonctionnalité ?

Ici, je présente un processus d’accompagnement traditionnel pour les coachs agile qui cible un Produit pas trop complexe avec une à deux équipes.

Alors comment gérer le passage à l’échelle ? Spotify, Safe, Nexus …

Spotify est souvent mis en avant comme l’exemple à suivre, mais de quoi parle ton ?
On parle du premier modèle qui a fait son succès avec les tribus, les chapitres et les guildes :

Screenshot-2017-11-16-spotify-engineering-culture-part1-jpeg-Image-JPEG-5000-×-2700-pixels1-1024x581

Cependant la réalité est différente :

  1. Spotify est un service suédois de streaming musical sous la forme d’un logiciel propriétaire et d’un site web. Donc votre organisation ou votre produit n’est pas Spotify.
  2. Spotify n’est plus sur ce modèle… (la version présenté en conférences à depuis bien évolué, Spotify ayant expérimenté et appris beaucoup de nouvelles choses).
  3. Spotify à l’Agile c’est comme Toyota au Lean : c’est avant tout une culture d’entreprise et le développement de leurs modèles de travail pour eux et utilisable chez eux.
  4. Spotify a aussi aplatis la pyramide managériales MAIS ensuite la re-créé en rapport à leurs besoins.

Tout ceci n’est pas nouveaux pour les connaisseurs, Je vous invite à lire cette article : Ne copiez pas le modèle Spotify .

Alors comment passer à l’échelle ?

J’aimerais vous faire réfléchir à un autre axe si vous souhaitez construire votre modèle comme Spotify, alors vous devez penser à votre entreprise comme un organisme vivant de grande taille avec des équipes qui se croisent, s’entrechoquent ou s’ignorent.  La transformation est donc organique et elle se structurera autour de la chaîne de valeur intrinsèque dans votre organisation.

Comment travailler ses Chaînes de valeurs ?

Il faut apprendre à écouter son organisation, redécouvrir les cellules qui l’a font vivre.
Ensuite vous devez faire confiance à ses organes, les consultants sont bons pour aider mais se sont vos collaborateurs qui font la richesse de votre organisation et son avenir.

À la tribu, nous avons co-créé un atelier de prise de conscience et d’acculturation pour vous aider dans vos organisations à démarrer une démarche « chaînes de valeurs » : http://www.agiletribu.com/contenu.html?uid=atelier-poupee-lego

ChaineDeValeurDansLEntreprise

Notre proposition est de réaliser cet atelier dans votre organisation et ensuite de vous accompagner dans une démarche de co-création et co-apprenance pour permettre de mettre en place :

  • vos chaînes de valeurs
  • une organisation organique et mobile avec des équipes BizSecDevOps : équipe représentante l’ensemble des acteurs d’une chaîne de valeurs
  • un recrutement par les pères et de la formation pour vos équipes par les membres de votre organisation
  • la gestion du bien être du collaborateur au sein de sa chaîne
  • une vision Permagile de votre organisation.

L’Agile Tribu est là pour vous aider à transformer votre organisation vers une organisation apprenante, responsable, proche de ses valeurs et de sa vision.

Contactez-nous : contact@agiletribu.com

La tribu fait deux Cubes le Jeudi 26/01

Oyé Oyé

Agile Tribu fait son 2ème et 3ème Cubes : Prioriser, estimer et planifier et Expliquer l’agilité dans mon entreprise

le Jeudi 26 janvier 2017

logo_1cubego_officiel

Cube Après-midi : Expliquer l’agilité dans mon entreprise

Depuis plusieurs jours, semaines ou mois, vous entendez des personnes de votre entreprise dire qu’il faut passer à l’Agilité.

Vous entendez des : « Agile c’est quand tu collabores pour réaliser des user stories grâce au Scrum Master », « Tu es agile, tu mets des post-it au mur, et tu fais des points courts quotidiens » ou encore « Agile c’est un truc de dev, c’est pour qu’ils arrêtent la spec’ ! »…

Deux possibilités : vous ne savez pas exactement ce que c’est et vous aimeriez bien qu’on vous éclaire sur ce qu’est réellement l’agilité ou bien vous connaissez le sujet par cœur mais ne savez pas comment bien l’expliquer aux acteurs de votre projet.

Comment expliquer la démarche à mon équipe de développement sans qu’elle ne prenne peur ? A mon manager pour qu’il se sente impliqué ? A mon métier pour qu’il se sente rassuré ? A mon client pour qu’il se sente valorisé ?

Cube matin : Prioriser, estimer et planifier

De responsable métier avec son cahier des charges à Product Owner avec son backlog produit, prioriser est probablement un des sujets les plus délicats.


Estimer la valeur, le contentement client ou l’effort, tous ces critères sont indispensables pour faire une bonne priorisation et satisfaire tout le monde.


Vous testerez plusieurs techniques de priorisation, d’estimation et de planification. A pratiquer seul ou en équipe, de basique à complexe, il y aura des pratiques pour tous les goûts.

Venez prioriser, c’est une priorité !

Vos hôtes : Nathaniel Richand, Jean-Claude Grosjean et Yannick Ameur.

Rendez-vous chez nous au 4 ter passage de la main d’or 75011 Paris de 8:45 à 12:30
Métro Ledru-Rollin

Tarif : 216 € TTC / cube
Inscriptions à la Billetterie :

Product Owner : études récurrentes, Studies Loop

Comme d’autres Product Owner, dans le monde de l’Agile, j’ai besoin de clarifier certain mode de fonctionnement.

En ce moment, je suis confronté à définir un Produit qui encapsulera et simplifiera d’autres produits. Chaque produit à intégrer se transforme donc en épic.

Donc voici le mode de fonctionnement que j’ai décidé de tester :
Je considère que chaque épic à intégrer représente une release dans ma roadmap, donc un lot fonctionnel à mettre en production en fin de release.

La Release sera composée de tout ce qui est nécessaire pour livrer l’épic : son découpage en stories fonctionnelles, mais aussi les stories techniques ou autres stories transverses nécessaires à la livraison.

Processus de l’étude de la Release commence par un Sprint 0 :

etudeproduitenboucle

Step 1 : Workshop de Définition

  • Timing : Selon l’épic, le workshop prendra entre 3h et 2j
  • Participants : les responsables et acteurs de l’épic
  • Animateur : un facilitateur externe au projet
  • Target / output / livrables :
    • Première vision de la vie actuelle de l’épic
    • Première vision de la cible intégrée et simplifiée
    • Les utilisateurs concernés par la cible : la liste avec nom prénom pour le 2.1
    • Les gains attendus pour établir la business value

Step 2.1 : Découverte des utilisateurs

  • Timing :
    • 30min à 1h par type de end-user,
    • observation de 3 à 4 actions différentes
  • Passer du temps avec les end-users :
    • Laissez-vous guider par leurs explications sur les cas d’utilisations, les besoins
  • Observez leurs manières de travailler et … trouvez le moyen de simplifier leurs actions, interactions, délais d’attentes…
  • Type de rencontre : One To One ou sur les genoux du end-user
  • Target / output / livrables :
    • Affinage de l’épic en end-user Stories dans votre Release Backlog ou Epic Backlog

Step 2.2 : Design cible

  • Timing :
    • en parallèle du Step Customer Discovery
    • cette étape continue dans les sprints de la release, car l’ergonomie, le look&feel, l’UX devront être challengés par vos équipes de réalisation, votre UX designer et par vous.
  • Réalisez vos Mockups des écrans à réaliser
  • Avec un UX (ou pas) alimentez le schéma des écrans avec les chemins d’utilisations de votre application.

Step 3 : Release Roadmap Mapping

  • Timing : 2 heures
  • Target / output / livrables
    • User Stories avec :
      • une priorité
      • une business value
      • une estimation avec vos équipes
    • Une estimation du nombre de sprint

Fin du sprint 0 :

  • Début du sprint 1 de la release
  • Début du sprint 0 de la prochaine Epic pour vous

Voila, merci pour vos commentaires, vous répétez cela en l’améliorant à chaque fois jusqu’à épuisement du Product Backlog ou de vous ;o)

Yannick AMEUR