Expérience : Sortir de l’agile (sans le vouloir)

Au cours de mes missions, j’ai eu l’occasion de participer à une expérience assez peu commune :

Sortir de l’agile (sans le vouloir)

Le projet se déroulait dans un contexte Scrum depuis plus d’un an. L’équipe était responsabilisée et auto-organisée. Des dysfonctionnements dans l’application du framework existaient mais les valeurs et les principes étaient bien intégrés. La performance de l’équipe était élevée et le produit de qualité.

Une réorganisation dans le service a eu les conséquences suivantes :

  • Fusion avec une équipe fonctionnant en méthode l’arrache
  • Nouveau produit à prendre en charge

L’équipe (L’arrache) ne souhaitant pas fonctionner en Scrum, le management a fait quelques aménagements pour uniformiser le fonctionnement :

  • Dispatche de l’équipe dans 2 équipes puis dans des sous-ensembles
  • Disparition du Scrum Master remplacé par un responsable d’équipe
  • Disparition du vocabulaire Scrum, de certain évènement (Scrum planning), des roles
  • Mise à la marge des product owners
  • Pas d’intervention de Coach agile

Après 2 sprints/cycles de transition, nous avons pu faire une rétrospective. La rétrospective se déroule avec l’ensemble des membres de l’équipe. L’objectif est de permettre un libre échange sur ce qu’il s’est passé durant le sprint pour réfléchir à des améliorations pour le sprint suivant. Cet évènement a été conservé même si le management ne voyait pas son utilité.

Les membres de l’équipe ont apporté du feedback sur le déroulement du sprint. Parmi les feedbacks, l’impuissance, la frustration, la démotivation, la perte de qualité du produit et l’incompréhension ont été soulignés. L’évènement qui m’a le plus marqué durant cette rétrospective est que le responsable de l’équipe s’est retrouvé responsable de tous les problèmes rencontrés.

Rejetant sa responsabilité car appliquant les décisions de son management, sa réaction a été de faire un peu plus de command and control dans le sprint suivant.

… C’est ainsi que le projet est rentré dans un cercle vicieux menant à sortir de l’agile.

Et vous, avez vous rencontré ce type d’expérience ?

Mémo : Ajouter une dimension existante dans un projet SSAS

Bonjour,

Je relais un mémo technique sur une problématique fonctionnelle plutôt courante. Il s’agit de permettre à des utilisateurs d’analyser un changement d’état (en gros, le passage d’état initial à un état final via une opération).

Imaginons un cas simple dans le domaine de l’automobile. Le service commercial connait l’ancienne voiture et la nouvelle voiture achetée. Avant l’achat, le client possédait un Coupé et il a acheté un Monospace.

Cette information peut permettre de mieux cibler les futurs clients et de fournir au vendeur des arguments de vente sous forme de statistiques. On peut réaliser une analyse simple du type x% des prospects possédant un Coupé achète un Monospace.

Pour permettre cette analyse dans un cube, nous avons besoin d’un produit d’arrivée (Monospace) et d’un produit de départ (Coupé).

D’un point de vue technique, nous avons 1 dimension produit qui contient le coupé, le monospace et certainement la segmentation complète des véhicules du marché. Dans le cube, nous avons besoin de 2 dimensions connectées sur cette table/vue contenant les véhicules.

Le lien ci-dessous vous donne le mode d’emploi pour ajouter une dimension existante dans un projet SSAS.

http://www.dimodelo.com/blog/2011/how-to-add-an-existing-dimension-to-a-ssas-project/