100% Agile, 100% Fragile... what means 100% Agile?

Did you never had a customer/manager saying… guy, we don’t want to be 100% agile?

I heard quite often this kind of arguments and I was asking myself what did I? what’s wrong? What kind of mistake did I provide through my transition steps?

Then, I start to look back to basics. 

The Agile Manifesto? not explicite enough.

The Declaration of Interdepence? too business oriented.

The underlaying principles of the Agile Manifesto? Yes, that’s the point.

I re-read the points and I start grouping them in categories:

• continuous improvement
• self organization
• changing requirements
• simplicity
• sustainable pace
• iterations
• working items
• technical excellence
• customer satisfaction
• business and development working together
• motivated individuals
• clear communication

Now, based on this, what means 100% agile?

I question myself:

• if you are doing only continuous improvement are you agile?
• or if your teams are only self organized are you agile?
• or if you are accepted changing requirements only are you agile?
• or if you have working items only are you agile?
• or if you have technical excellence, are you agile?
• or if you have only customer satisfaction?
• or if business is working closely with development only are you agile?
• or if you only have motivated individual?
• or if you only have clear communication, are you agile?
• or if you only iterate, are you agile?

Bizarre, isn’t?

It’s an « AND » not an « OR ».

Now if you replace « OR » by « AND », this makes a bit more sense. No?

Assumption 2: it’s an « AND »

• what means 100% continuous improvement?
• 100% means full achievement. Right?
• continuous improvement is, in my brain, an infinite loop
• how could I reach 100% of infinity!?!?!
• 100% self organized teams?
• 100% means that all teams are self organized
• sounds simple
• isn't at all
• 100% accepted Change requests?
• 100% accepted Change requests (CR) is also simple.
• it means that:
• business can make the difference between CR and scope
• there is acceptance and triage
• Change has a governance
• Consulting company accepts change for free (no charge, no new SOW)
• sounds simple
• isn't at all 
• 100% working items?
• 100% working items sounds simple
• for simple products.... very simple products
• low complexity
• it's what I call "Lego bricks and plumbing"
• sounds simple
• isn't at all
• either when you didn't defined somebody in charge with the product aka Product Owner
• 100% technical excellence?
• 100% technical excellence
• like before, everything should be very very simple
• 1 technology (ask SAP guys if it's simple)
• sounds simple
• isn't at all
• 100% customer satisfaction?
• sounds simple
• when you have one customer and it's your loving grand'ma
• not a proxy or a business analyst, a real one with flesh and blood
• according to the level of UX adoption, it sounds that it isn't that simple
• isn't?
• 100% business and development working closely together?
• that's easy
• working closely together? how close? is 5.000km close? is WebEx or Skype close enough?
• I don't know?
• does closely together mean that they have to partner on a daily basis?
• every day?
• sounds simple
• isn't at all
• 100% motivated individuals?
• that's an easy one!
• I make a retro with legos and serious game, we have a lot of fun and it's done!
• really?
• motivated how?
• motivated to follow what daddy says? or the commander-in-chief?
• motivated if one guy wants the latest tool and another pizzas if a third one is vegan and HR prevents for harassment?
• kidding
• sounds simple
• isn't at all
  
• 100% iteration?
• we can iterate one day of another?
• or one week, then 2 weeks, then 3, like a Fibonacci?
• if I iterate once a year, is it enough?
• sounds simple
• isn't at all
• 100% clear communication?
• that's an easy one but I have to get management buy in first ;b)

UX et Agile : Duo gagnant pour livrer des produits efficaces (Revue de Presse)

Une de mes connaissances vient de me transmettre cet article est me demande de le commenter:

http://letrainde13h37.fr/29/ux-et-agile-duo-gagnant-pour-livrer-des-produits-efficaces/

Cet approche est intéressante, mais elle me donne le sentiment que Scrum n'est toujours pas bien compris par ces auteurs.

Ci-dessous mes commentaires en vrac:

· Le Fond

• Les projets (IT en particulier) ont évolués dans le sens où le produit développé doit répondre aux attentes d'un utilisateur et non aux attentes de la technologie. L'Agilité en particulier expose le postulat qu’un bon produit est celui qui est utilisé car répondant aux attentes du marché (les utilisateurs). A l'opposé, les démarches prônées par le marketing de Kottler, le produit ne crée plus les attentes.

• dans les projets Scrum évolués, le produit devient une histoire que l'on raconte à un groupe d'utilisateur. Dans un premier temps nous répondons directement à leurs attentes, mais le développement du produit induit un nouveau facteur la participation active du client et des utilisateurs. Scrum dispose dans son ADN ce type de démarche. La maturité aidant, les Product Owner (Resp. du produit) deviennent des acteurs de l'équipe projet (pas le représentant du client) focalisé sur "l'histoire-produit" à leur raconter de sorte qu'une relation étroite et permanente entre Product Owner et Utilisateurs s'installe favorisant la livraison du bon produit au bon moment et, comme le dit Roman Pichler, un produit que les utilisateurs aiment.

• les apports de l'agilité (rectification): l'agilité apporte un process permettant de créer un environnement favorisant la collaboration étroite entre le développement et les utilisateurs en libérant les blocages de part et d'autre: les itérations livrent une "histoire-produit" pour avoir à chaque fois le retour d'information des utilisateurs. La notion de valeur est un point à valider dès le début de la relation: est-ce que la valeur est pour le client ou pour les utilisateurs? L'approche itérative crée cet environnement de communication où un compromis limité dans le temps permet d'avancer pas à pas vers la solution. En fait, l'Agilité (Scrum en particulier) gère l'équilibre entre "Doing" et "Talking".

• Réduire l’écart entre “Cycle d’évolution d’un produit” et “Processus d’une organisation” est un faux ami. Le cycle de vie du produit reste au cœur de la discussion cependant celui-ci est calé aux attentes réelles du marché (utilisateur). Le Processus d'organisation est un effet collatéral important de l'approche centrée utilisateur ou centrée produit. Les organisations mutent en systèmes où l'ensemble des participants sont au front (plus de back office!): voir modèle Beyond Budgeting (Agile Governance & Finance).

• N’oubliez pas qu’Agilité signifie livrer au plus vite de la valeur. Ceci est faux. L'Agilité c'est créer une relation de confiance entre l'organisation, le client, les utilisateurs et l'équipe de développement. La livraison de la valeur n'est qu'un vecteur pour arriver à cette fin: pendant les itérations la relation avec les utilisateurs reste permanente sans qu'il n'y ait livraison de valeur. Cette livraison ne parvient qu'à la fin de l'itération. Ne pas confondre vitesse avec précipitation.

• Intégration de l’UX dans le Backlog du produit

Cela fait plus de 7 ans déjà que Scrum intègre les préceptes de l'UX dans la mission du Product Owner. En France où la culture projet est à ses balbutiements, nous découvrons que les vertus proposées. Le Product Owner est un peu le parent pauvre de Scrum car cette méthode, principalement portée par les développeurs,  expliquait il y a vingt ans que le Product Owner est un ersatz de Business Analyste. En 1988, cette erreur a été relevée et corrigée et les UX Designers ont été intégrés dans les équipes de développement. Depuis 2001, nous considérons que le Product Owner est un UX Designer avec des compétences en gestion de produit et il travaille au sein de l'équipe Scrum au même titre que le Scrum Master. Cette démarche est perçue avec difficulté par les SSI car cela change leur relation avec le client. Avec Scrum, maximiser les résultats signifie également de fournir une équipe complète (PO compris) et s'engager sur un résultat (obligation de résultat) a contrario des contrats en régie donnant le leadership de l'agilité au client (qui a rarement été formé à cela!).

En conclusion, cet article présente l'UX Designer comme un doublon au rôle du Product Owner qui couvre déjà tout le spectre décrit. La réponse, de mon point de vue, serait de dire que le Product Owner est un UX Designer fait plus de sens.

L'Agilité se veut pragmatique et évite les surcharges. Fusionner les deux fonctions telles que la nature de mes formations PO depuis 5 ans déjà.

· La Forme

• l'approche est un peu "junior" et les références françaises Claude et Jean-Claude ne peuvent pas réellement répondre à cette question:
• Claude analyse intelligemment Scrum du point de vue développeur IT
• Jean-Claude du point de vue UX
• il manque une dimension réduisant la surcharge apportée par une fonction supplémentaire ayant été clairement exprimée par Roman Pichler, Jeff Sutherland, Ken Schwaber, Mike Cohn, Johanna Rothman, Jochen Krebs,