scopyleft

Transformation en cours

Depuis quelques mois, Scopyleft se donne les moyens de changer et d’explorer de nouvelles pistes. Nous avions pour cela besoin de nous faire accompagner. Voici quelques notes lors de notre session de synthèse avec Olivier après des entretiens individuels.

Photo

Scopyleft est un OVNI qui peut difficilement être comparé ou suivre un chemin déjà arpenté par d’autres. Cette unicité nécessite de trouver nos propres chemins d’évolution.

Nous avons conscience que nos finances actuelles nous ouvrent beaucoup d’opportunités grâce au véhicule que nous avons conçu et alimenté, mais vers où allons-nous ensemble ?

Il y a une résonance forte dans les valeurs que nous partageons aujourd’hui. La deuxième vague de recrutements n’a pas modifié en profondeur la culture que nous générons.

De manière générale, notre frustration est commune. Peut-être que la Communication Non Violente (CNV) est un frein pour notre organisation et donne lieu à des non-dits et à une perte de dynamique.

Nous sommes dans un paradoxe d’équipe vs. groupe. Investir du temps ensemble pour faire équipe ne devient rentable que s’il y a effet levier en terme d’efficacité. Nos projets individuels locaux envisagés sont peut-être un plan B qui ne nous satisfait pas pleinement.

Grille de lecture

Dans l’archétype homme / femme (performance / relations), nous sommes en déséquilibre vers le relationnel avec l’équipe actuelle. Un système équilibré sur ces critères va être davantage efficace si on envisage du changement, notamment la nécessite de pouvoir quantifier des choses.

Scopygot (dont l’emblème est l’escargot) est une réussite dans l’idée de changer lentement mais ce n’est pas vraiment ce que l’on souhaite ! Notre système actuel est trop stable grâce à la CNV + décision par consensus. L’instabilité va être nécessaire pour aller de l’avant.

Le référentiel de Richard Barrett peut nous aider à comprendre notre dynamique actuelle à travers ses 7 niveaux de conscience.

Options / portes d’entrées

• Travailler nos différences et mettre en évidence nos talents respectifs. Accepter que nous avons des besoins différents. Des outils comme The Leadership Profile ou le Process Communication Model pourraient nous aider.
• Clarifier les règles et processus de décision. Le consensus est difficile à 7 et le consentement pourrait être davantage approprié. Les règles pourraient sembler antithétiques à la confiance mais attention au contrôle social sous-jacent qui est délétère.
• Définir le domaine d’expertise du collectif, le métier de Scopyleft n’est pas clair. Comment être en capacité de reproduire les situations où l’on est bon·nes ? Nous sommes un collectif à cohésion interne hétérogène.
• Utiliser les rôles délégués nous permettrait d’étendre notre intelligence collective. Celle-ci à besoin d’objectifs, de liens et d’énergie.
• Formaliser une vision / ambition sans que celle-ci ne soit trop à l’eau de rose, il faut être précis. Si le valeurs n’entraînent pas de changement dans les pratiques et les modes de décisions c’est de la propagande !

Comme le proposait Emma, il ne s’agit pas tant de sortir de notre zone de confort que de l’étendre.

Petit panorama des pratiques de rémunération en horizontalité

L’histoire des salaires à Scopyleft, c’est d’abord un salaire contraint parce que y’avait pas d’argent pour se rémunérer correctement, puis un salaire égalitaire, avant d’arriver à un salaire au besoin. Les quelques règles qui fixent ce salaire sont :

• ne pas mettre en péril l’équilibre financier de la boite.
• le salaire est décorrélé du travail facturé, de l’ancienneté ou des compétences.

À lire pour aller plus loin : blog de David

Avec Violaine, quand nous sommes arrivées à Scopyleft il y a environ deux ans, nous nous sommes confrontées à l’expérience de devoir fixer nous-mêmes notre salaire. Ça peut paraître sympa au premier abord de devoir fixer son propre salaire, mais dans les faits, ce n’est pas si simple ! Car comment faire pour différencier besoins et envies ? Étant toutes les deux dans la même situation, nous avons pris le temps de discuter et de réfléchir à nos dépenses mensuelles pour évaluer un montant. Devant le manque de règles et de guides pour fixer ce fameux salaire, nous nous sommes alignées sur le plus bas salaire et le syndrôme des impostrices n’y est sans doute pas pour rien dans le fait de ne pas oser demander une somme assez conséquente.

Depuis, suite à l’envie de réduire les écarts de salaires au sein de la Scop et aux montants faramineux exigés pour demander un prêt immobilier, nous avons augmenté nos salaires de 500 €.
Cela dit, cette histoire des besoins a continué à nous turlupiner et nous sommes allées voir les copaines des structures qui nous entourent et qui bossent dans la tech pour voir comment ielles faisaient.

Rémunération sur son travail

Chez les premières copaines, c’est plutôt le type Coopérative d’Activités et d’Emploi, c’est-à-dire que c’est une structure commune, mais chacun.e se fixe son salaire en fonction de ce qu’ielle facture en laissant 10% pour les frais et le pot commun de la boite. Les salaires varient en fonction du temps de travail que les personnes ont envie d’effectuer. Chacun·e est ainsi très autonome sur son temps de travail et cela permet de franchement réduire le temps de travail si ils ou elles en ont envie. Ielles ont conscience que c’est pas très « politique » comme manière de fixer les salaires, mais ils et elles ont eu des discussions sur le salaire au besoin qui a soulevé plus de questions que cela en a résolu.

À la tête du client

Chez une autre structure, pour l’instant c’est : tu arrives dans la boite avec une demande de salaire et tu peux t’augmenter plus tard, mais sans règles précises. Le salaire est un peu décorrélé du travail facturé et du temps de travail, mais pas trop non plus. A priori, tout le monde n’est pas très à l’aise avec la fixation des salaires et la question est en chantier.

Tout le monde à la même enseigne (ou presque)

Pendant ce temps là, on trouve chez d’autres un « salaire unique » plutôt élevé, quelque soit le travail facturé et le temps de travail ; avec une personne qui a un salaire un peu plus élevé pour x ou y raisons.
Plusieurs discussions sur le salaire au besoin ont eu lieu il y a longtemps, mais les discussions ont fait mal aux personnes puisqu’elles vont sur des terrains intimes. C’est surtout le terme besoin qui pose problème, car il n’est pas défini entre les personnes et qu’il fait émerger des questions entre désirer quelque chose et ne même pas oser imaginer un désir.

Grille des besoins et holacratie

Sur notre route, on a aussi croisé des copaines férues d’holacratie qui ont mis collectivement en place une grille bien précise pour déterminer qui gagne quoi. Un salaire de base est complété en fonction de différentes variables individuelles. Parmi ces dernières, on trouve : le nombre d’enfants, le loyer ou le prêt immobilier de la résidence principale, la situation géographique, le temps de travail et la possession ou non d’un patrimoine. Cette grille est ainsi une tentative d’objectiver les besoins et d’équilibrer les écarts.

Grille des compétences

Et enfin, d’autres personnes ont réfléchi à une grille basée sur les compétences autour de cinq axes notés sur sept niveaux. Il y a un salaire de base et les niveaux de compétences le bonifient. Il y a également un bonus pour les enfants à charge et pour la personne responsable de la gérance. Chaque personne s’auto-évalue, puis une commission regarde si c’est cohérent et les salaires sont ajustés comme ça. Il n’existe pas de corrélation entre ce que facture la personne et son salaire. Mise en place depuis peu, cette grille ne convient pas nécessairement à tout le monde et demeure un sujet de fond voué à évoluer.

Nos questionnements

Ce qui a été chouette pour nous, c’est de voir que chez les copaines en SCOP ou en structure horizontale, on peut décider de notre système de rémunération et que là on voit bien qu’il y a 6 systèmes différents qui sont amenés à bouger ou évoluer. Personne n’est sûre que c’est le bon fonctionnement. Même s’il a été discuté au sein des structures, le concept du salaire au besoin n’a pas été adopté pour diverses raisons, la principale étant la difficulté d’objectivation du besoin.

Chez Scopyleft par exemple, on n’objective pas les besoins et c’est chacun·e qui se fixe sa rémunération, à priori sans devoir se justifier. Mais, en fait, certaines personnes se sont justifiées souvent pour des questions liées au logement. C’est sans doute plus légitime de parler d’une augmentation de loyer ou d’achat immobilier, que de dire qu’on veut s’acheter une plus grosse bagnole par exemple !

Et c’est là que le bât blesse : est-ce qu’on a des « vrais » besoins et des besoins plus triviaux ? Comment on fait pour objectiver des besoins ? Chez Scopyleft, c’est quelque chose qu’on ne souhaite ou qu’on n’ose pas faire, peut-être parce que ça rentre dans l’intime et un sentiment de contrôle social de juger les besoins des un·es et des autres.

De plus, le salaire au besoin ne semble pas « équitable » parce que chacun·e se fixe sa rémunération et qu’il y a des écarts (mineurs dans notre cas). Par contre, on peut se demander si les écarts de salaire peuvent être dûs à des biais genrés comme par exemple moins oser demander plus quand on est une femme.

On peut se demander si le fait de parler des besoins ne génère pas des culpabilités inutiles et que peut-être le problème c’est que le salaire est mal nommé et qu’on devrait peut-être l’appeler salaire à l’envie. Mais cela ne résoud toujours pas certaines questions, voire ça complexifie encore le truc.

Alors, salaire au besoin, on continue ou on évolue ?

scopyleft, l’aventure humaine

L’épopée scopyleft continue son chemin, un peu comme un projet Web. Nous sommes partis d’une idée, nous la réalisons, et sur la route nous rencontrons des choses très éloignées de nos prédictions. Nous testons des attentes, des envies en essayant d’apprécier pleinement les réussites, sans souffrir des échecs.

Un parcours d’aventure et d’échange débuté à 4, essayé à 5 et continué à 3. Le départ de NiKo pour Mozilla en début d’année et celui d’Élodie plus récemment nous donne de nouveaux angles de vision. Élodie aura testé les interviews sur une partie de l’(ex-)équipe pour essayer de synthétiser une perspective du passé. Elle a baptisé ce document "L’Histoire de scopyleft". Il n’est ni finalisé ni synthétisé, mais nous préférons ne pas altérer ses collectes.

Aujourd’hui nous continuons cette épopée en protégeant notre Graal : "Travailler ensemble sur des projets utiles et intéressants en préservant le bien-être de chacun". Les envies et besoins de chacun étant différents, cela nous mène sur des routes où nous nous croisons parfois.

Mais quelle est la réalité actuelle ?

À Clapiers, Stéphane cultive un potager numérique avec des innovateurs volontaires. Il tente de construire un espace collaboratif ouvert, un "tiers-lieu", en proposant des ateliers, et l’accompagnement de projets innovants.

Vincent s’axe sur l’experience en remote et tente de rencontrer des humains en toutes contrées. Il travaille sur des projets clients quand ils se présentent et ponctue de son côté sur du volontariat.

David se concentre en petite équipe externe sur la technique à partir d’Arles. Il travaille notamment en pair sur des projets Mozilla avec des confrères distants.

C’est le tableau d’une petite équipe dispersée, qui s’épanouit dans la diversité. La communication est souvent minimale, incertaine et maladroite, parfois plus rapprochée et partagée, et toujours intensément humaine. Ce n’est ni un objectif, ni un modèle à suivre ou à éviter, c’est un simple constat.

Les projets utiles et intéressants sont humbles. Nous souhaitons activement contribuer à des projets citoyens, et sommes motivés pour les aider à émerger. Nous travaillons avec des clients/partenaires sur leur projet, et aspirons à les voir aboutir. On les aide à minimiser leurs besoins, leur budget, et à maximiser leur motivation et leur indépendance.

Scopyleft aujourd’hui, c’est un peu tout ça, et c’est surtout beaucoup de choses imprévues et imperceptibles.

Arbrifeste

L’arbre de la haute performance se développe en s’alimentant sur ces valeurs. Si elles sont fortes l’arbre grandit et la ramure se développe pour aller chercher la lumière, l’arbre se renforce, ses racines grandissent en retour et tout l’arbre en profite

Jean-François sur le blog de Lyssa Adkins.

Nous souhaitions reprendre le manifeste co-écrit à la création de scopyleft pour exprimer nos valeurs, nos motivations et trouver des moyens pour les mettre en pratique dans notre aventure humaine. Les objectifs des discussions sur ce manifeste étaient :

• imaginer ensemble, rêver, partager, co-créer
• s'aligner sur les valeurs et les principes
• définir la vision des membres de scopyleft

Échanger sur les valeurs dans un collectif est un exercice périlleux, qui nécessite un cadre d'expression souple et structurant. David a proposé l'animation d'un atelier d'intelligence collective : l'atelier Manifeste#1 sur le modèle de Lyssa Adkins l’arbre de haute performance que nous avons renommé « Arbrifeste ».

D'abord, chacun a dessiné individuellement son arbre qu'il souhaitait pour scopyleft. Puis, nous avons interrogé nos propres représentations sur les valeurs et les principes affichés. Ces notions réfléchies et choisies ensemble ont été mises en commun dans l'arbrifeste.

Les racines représentent les valeurs : partage, respect, courage, bien-être, honnêteté.

Les branches sont les qualités : scop, bonne humeur, réseau, transmission, égalité, quête de sens, rencontre, expérimentation, confiance, coopération, citoyenneté, compétence, générosité, curiosité, bienveillance, solidarité.

Les pommes symbolisent les fruits de nos réalisations (les actions) en accord avec nos valeurs et nos principes : outils citoyens, web app, collaboration, binômie, événements, tarifs adaptés...

Le jardinier qui arrose l'arbre incarne l'espoir...

A la fin de l'atelier Manifeste#1, les pommes semblaient trop abstraites et non mesurables. Comment pourrait-on sortir du pourquoi (manifeste initial) pour aller vers le comment ? David et Élodie ont organisé un atelier Manifeste#2, pour enrichir les pommes (plus de pommes et mieux qualifiées) sous forme d'indicateurs mesurables à 6 mois, et à 1 an afin de pouvoir vérifier et ajuster.

Élodie et David ont imaginé de nouvelles pommes mesurables : espace de travail partagé, expérimentation citoyenne (ateliers de co-construction), éducation citoyenne (vulgariser nos outils pour impliquer des non-geeks). De nouvelles pommes ont été ajoutées par l'équipe au complet : formations (classique + ateliers), moins d'administratif, travail à distance, transparence. Les pommes proposées par David et Élodie ont été discutées et validées.

Ces pommes se sont transformées en actions mesurables avec des objectifs. Voici les pommes sélectionnées et leurs moyens de mesure choisis par l'équipe :

Outils citoyens (Typhon futé, implication ESS, Scolia)

• 6 mois : organisation d'un atelier de co-construction
• 1 an : publication d'un MVP citoyen avec 5 utilisateurs

Edition webapp

• 6 mois : avoir mis en ligne au moins un MVP utilisé par l'équipe
• 1 an : publier une "trame de MVP" open-source ? (code source partageable à la communauté)

Collaboration (interne et externe)

• 6 mois : avoir au moins un rituel d'un présentiel à 4 par mois en interne, échange de pratiques avec les pairs du web et du lean au moins une fois par mois (jam clapiers et partage de savoirs avec des co-workers)
• 1 an : projet commun avec des co-workers, binômie fluide en interne (1 fois tous les 15 jours minimum, hors présentiels à 4)

Événements (plus de 20 personnes)

• 6 mois : avoir participé à un événement, avoir organisé un événement (coach retreat, devopensud, etc)
• 1 an : avoir partagé son retour d'expérience sur le blog suite aux événements, avoir pris le temps d'analyser ce que ça nous a apporté

Tarifs adaptés (troc, échanges, coproduction en lean ex: maison édition blog)

• 6 mois : avoir un client qui bénéficie de tarifs adaptés
• 1 an : avoir 50% de nos clients qui bénéficient de tarifs adaptés

Espace de travail partagé

• 6 mois : avoir un espace confortable/silencieux dédié aux activités de concentration et un espace de collaboration/convivialité dédié aux activités d'échanges
• 1 an : ?

Expérimentation citoyenne (ateliers de co-construction)

• 6 mois : partager l'implication dans la co-construction avec 3 citoyens "engagés"
• 1 an : publier un modèle de co-construction de projet diffusable et reproductible

Éducation citoyenne

• 6 mois : avoir impliqué 5 citoyens non-geeks (sur la valeur métier) dans les expérimentations ou événements
• 1 an : définir un glossaire rendant accessible les interventions scopyleft aux non-geeks

Formation (traditionnelle + ateliers)

• 6 mois : 5 jours de formation par mois
• 1 an : 10 jours de formation par mois

Moins d'administratif

• 6 mois : mesurer le temps d'admin + imprévus urgents
• 1 an : réduire de 20% le temps d'admin et 50% les imprévus urgents (déléguer ou automatiser++)

Remote

• 6 mois : pouvoir passer 1 semaine par mois à l'étranger
• 1 an : pouvoir passer 1 semaine dans le coin par mois

Transparence

• 6 mois : avoir mis à jour la page d'accueil du site internet et avoir communiqué sur notre relation avec Alter'Incub
• 1 an : avoir mis à jour le site internet + continuer à publier la compta documentée

L'arbrifeste a désormais des racines (des valeurs socles) qui ne bougent pas, des branches (des qualités) qui peuvent pousser, se ramifier, des pommes (actions mesurables vérifiables et ajustables à 6 mois et 1 an) qui peuvent tomber lorsqu'elles sont mûres… ou pourries !

Le manifeste initial apporte un coté plaqué et figé, il ne montre pas le coté vivant de l'arbrifeste avec des objectifs d'actions à 6 mois et 1 an. En même temps, le manifeste sur notre site en page d'accueil participe à notre différentiation. Se pose alors la question de la réécriture du manifeste scopyleft, comment traduire l'arbrifeste en manifeste et est-ce que cela serait vraiment utile ? La question reste ouverte.

Un hackaton pour (re)penser impôts.gouv.fr

Ce dernier mercredi de juin a eu lieu le hackaton de impots.gouv.fr. Un événement plutôt surprenant auquel, en tant que contribuable, citoyen et développeur, il était de bon sens de participer. Et c'est sans regret. L'événement se passait dans l'atypique salle de TheFamily, proche de la Bastille. Une cinquantaine de personnes, principalement des profils développeurs, marketing, UX-design, mais aussi des internes en masse de la Direction Générale des Finances Publiques.

DGFiP et confessions

Parmi la DGFiP des développeurs, des webmasters, des gestionnaires ainsi que des directeurs. La structure interne nous est annoncée comme une trop forte hiérarchie qui en fait leur talon d'Achille, et un vaste méli-mélo. Ils témoignent des lourdeurs en interne, de la lenteur des décisions de par la structure pyramidale, de la rigidité de trop de décideurs, leur honte auprès de leur proches dans la complexité d'être contribuable, du manque de culture sur des méthodes adaptatives (ils en sont toujours à l'époque cahier "décharge"). Ils confessent avoir mis 12 ans pour avoir la plateforme existante, déjà obsolète dès la commande, jeter l'argent par la fenêtre du jour de la signature avec les grandes SSII de ce pays (leurs noms sont ouvertement cités à la conf) en sachant que dès la signature, "ils n'en auront pas pour leur argent, et pourtant il y en a de l'argent de posé". Si l'on peut témoigner de tout ceci, c'est aussi parce qu'on pouvait sentir une franche intention de changement chez la plupart de la DGFiP, un appel à l'aide et à l'inspiration, une volonté de sortir de ces sillons. Un besoin d'air frais et de nouveau. Ils veulent ce changement, et pas dans 12 ans. Ils se sont même tournés à la dérision à la vue d'un dinosaure pour le photographier en s'amusant d'en faire leur mascotte. Les messages étaient forts, sans concession, sans demi-mots.

la journée

Alors, ont-ils eu ce qu'ils voulaient ? Il me semble pouvoir dire oui. Ils paraissaient satisfaits à la hauteur de l'investissement des 10 équipes constituées à ce hackaton lors de cette journée. Tout le monde a joué le jeu jusqu'au bout. Les travaux délivrés étaient de bonne qualité et les présentations pêchues. On aurait pu se croire à un startupweekend auquel on aurait remplacé la couche bullshitesque du prévisionnel par de l'intention et de la souplesse, l'assoiffement financier par la participation co-citoyenne, et les jugements du jury incompétent par une écoute impliquée.

Open API

Le projet sur lequel j'ai choisi de consacrer ma journée était l'implémentation d'une open API qui exposerait les données de impots.gouv.fr en HTTP. L'idée est donc de permettre d'accéder en lecture à un ensemble de données d'un contribuable, de sa déclaration, calendrier, ou aux données générales du Trésor Public, mais également de participer à ces données. L'intérêt pourrait être d'envisager des plateformes indépendantes et spécialisées dans une tâche pointue. Par exemple si j'ai fait de nombreux dons à certaines associations, une app me permettrait de les renseigner. Ma déclaration pré-remplirait les cases adéquates en récupérant directement ces données du service compatible. Un autre exemple serait une interface de remplissage optimisée revenus BNC, via une application dédiée, et renseignerait directement la déclaration d'impôts.

Les intérêts sont nombreux :

• expertiser la DGFiP sur la détention, la sécurisation, l'exploitation et le contrôle des données ;
• les décharger d'une partie des interfaces ;
• permettre à des entreprises, startups, scop, développeurs, de fabriquer leurs propres apps ;
• offrir un vrai choix d'interfaces au contribuable.

En déchargeant la DGFiP des applications, on leur permet donc de s'axer sur l'essentiel, la donnée. Leur lenteur procédurière ne leur permettant pas de faire face au monde mouvant du web, ils pourraient alors décharger les interfaces, l'ergonomie, le design et la convivialité à des externes. On pourrait tout de même imaginer conserver des applis internes aux impôts (probablement l'existante actuelle) qui auraient pour sens de couvrir des besoins non implémentés en externe, ou pour une consultation éventuelle "officielle" de ce qui en est généré.

Et la suite ?

On verra prochainement si ce hackaton est à rajouter à http://hackathonbullshit.tumblr.com/ ou si la volonté de travailler avec des entreprises à taille humaine sur des mini-plateformes est réelle. La vision que j'en ai est que les idées de ce hackaton sont une source d'inspiration pour faire changer les choses. On ne parle pas d'argent, et peut importe qui s'occupe de la réalisation. La vraie question est : verra-t-on enfin le jour de api.impots.gouv.fr ? La peine du quotidien des fonctionnaires de la DGFiP a-t-elle déjà repris le dessus ? La lourdeur hiérarchique va t'elle continuer à freiner les innovations ? La DGFiP va t'elle enfin permettre au contribuable de contribuer ?

Liens

Des ressources disponibles :

• le speech de présentation : http://forum.journaldupirate.com/viewtopic.php?f=40&t=8864&p=70876#p70850
• les ressources fournies : http://www2.impots.gouv.fr/telechargement/ux-camp/dgfip.html#elem
• de l'inspiration britannique : https://github.com/alphagov
• un portail où pourrait figurer la France : https://government.github.com/
• les slides et leur annexe (prochainement).
• et peut-être un jour api.impots.gouv.fr (si ce n'est plus une 404, on débouche le jus de pomme).

Blank Disrupt or how to make things different

Take a minute to think of "What is a chair?". Most people have concepts like "a place to sit", "a furniture around a table", "an artwork", … What if you think of it as "an item to lift your bottom off the floor"? Don't you feel like you could open up to a whole new way to think and design? That's actually what does happen.

End of March the Blank Disrupt conference took place in Catania (Sicilia). Each topic was somehow about disruptive innovation. The idea was to bring new ways to think of how to deal with your daily life and work in a totally different way. An innovative disrupted way.

All about people

It was all about ideas, projects and on top of all, people.

Jacopo Romei was talking about flat collaborative enterprises and "Liquid organisations". He's a member of the value driven innovation Cocoon Project. He also make us discover his acapella band http://www.anonimarmonisti.com. We will see him again at his "From TDD to kanban" session next thursday.

Ralph Weickel mentioned all those best tips to open up actively to disruptive changes like drawing while you talk, read biography of people you'd never read, run "what if…" sessions.

Salvatore Di Dio - from Push - presented Traffic O2 to improve urban sustainability.

Claudia and Vincenzo Di Maria were introducing "Design for the real world". They told us about the Impact Hub network, ideas like welcoming Digital Nomads and the inspired the intro above.

We were invited to read more about Victor Papanek, listen to Kings of Convenience, discover the Change Makers Project. We left with a bunch of ideas and human exchanges.

We were so excited to meet that community that we set a homepage in Italian.

Nouvelle recrue

Entre le 1er avril et début septembre, trois des développeurs de scopyleft ont vu leurs disponibilités s'effacer. David, Nico et Vincent sont passés à 99% sur des prestations, le voyant de la trésorerie affiche un joli vert, et un nouveau silo s'est dessiné.

Au démarrage nous tenions beaucoup à partager les tâches, même les moins passionnantes. Nous avions été labellisés intégristes de la collaboration en refusant l'invitation du délégué SCOP à devenir plus raisonnables sur la co-gérance que nous envisagions à 4. Pour Denis, il y avait certainement un seul gérant naturel au sein de scopyleft, nous devions identifier la bête, la nommer et lui refiler la gamelle de gérance.

Si la disponibilité de chacun passait à 75 ou 80%, nous pourrions envisager de s'octroyer des moments de partage. Mais comment construire une culture et gouvernance collaborative avec une équipe focalisée à 99% ? Adieu scopylabs et autres scopyfuns, comment maintenir une dynamique d'équipe ?

Stéphane le facilitateur de scopyleft impulse l'idée de recruter un nouveau membre afin de lui filer la patte sur la gérance, le stratif, et le commercial et aussi sur d'autres missions si la nouvelle recrue souhaite se former à l'agilité. L'idée est d'embaucher quelqu'un pour jardiner — à deux dans un premier temps — et ouvrir un nouveau potager.

Les questions se succèdent au sein de l'équipe, comment peut-on recruter dans une SCOP à gouvernance collaborative ? Comment s'improviser recruteur, dans ce type de gouvernance, la posture d'autorité étant aux antipodes de nos valeurs ? Doit-on plaquer une jolie fiche de poste et imposer des missions sans laisser la place à l'initiative et à la co-création ? Faut-il embaucher une fille pour apaiser nos âmes de chasseurs ? ou doit-on rester sur la même lignée d'une équipe de chasseurs-cueilleurs ? (dixit Pablo).

Nous résolvons cette question en nous appuyant sur une recherche de complémentarité. La personne doit-elle forcément être geek ? Si l'on s'en tient à notre commandement d'enrichissement et de complémentarité, nous serions prêts à accepter une "no-geek". Se pose la question de la motivation, il faut trouver une personne qui soit salariée avec l'envie d'intégrer la SCOP en qualité d'associée. En effet, nos statuts imposent aux salariés qui rejoignent scopyleft de devenir sociétaires au bout d'un an, nous décidons d'accueillir une salariée sur une phase de test.

Fin août 2013, il nous faut plus d'un mois pour nous mettre d'accord, sur le pourquoi, le comment, le qui de l'embauche. Élodie, que nous avions rencontrée dans nos réseaux de l'économie sociale et solidaire (Alter'Incub) nous a rejoint début octobre pour partager sa passion du social et imaginer avec nous de nouveaux projets d'utilité citoyenne. Nous l'acculturons en ce moment aux délires du web, aux différents langages et fonctionnalités et aux prospectives de l'imprimante 3D. Sa fiche de poste se construit au fil des échanges et des possibles !

Scopyleft grandit, et se transforme chaque jour. Vers un nouveau chemin d'alignement à 5, avec cette envie de partage, et de collaboration, à jardiner !

Advanced Django user model inheritance

Recently I had to manage a few user types each having its own specificities with Django 1.5. Not a big deal in theory.

It actually turned quite different and clues were scattered around the web.

Here is what I expected to get at the end:

• users can authenticate by email. No username at all.
• we should have individuals and professionals. We should also preserve system users such as admin accounts.
• the email must be unique. Though an individual can also have a professional account with the same email address.
• We should be able to retrieve an account with its specificities without knowing what kind of account it refers to. That means calling it by pk for instance.

Email authentication

A lot of ressources available on the web.

from django.db import models
from django.contrib.auth.models import AbstractBaseUser

class BaseUser(AbstractBaseUser):
    email = models.EmailField(unique=True)

    USERNAME_FIELD = 'email'
    REQUIRED_FIELD = USERNAME_FIELD

Extending BaseUser

Let's make BaseUser abstract and write specific Users that extend it.

class GenericUser(BaseUser):
    pass

class Professional(BaseUser):
    company = models.CharField(max_length=50)
    reference = models.CharField(max_length=10)

class Individual(BaseUser):
    name = models.CharField(max_length=100)

A GenericUser is a system user such as an administrator. settings.AUTH_USER_MODEL would refer to it.

create_user and create_superuser

As we're not using the default Django model, we lost these functionalities. We can reproduce them easily.

from django.contrib.auth.models import (AbstractBaseUser, BaseUserManager as DjBaseUserManager)

class BaseUserManager(DjBaseUserManager):
    def create_user(self, email=None, password=None, **extra_fields):
        now = timezone.now()
        email = BaseUserManager.normalize_email(email)
        u = GenericUser(email=email, is_superuser=False, last_login=now, **extra_fields)
        u.set_password(password)
        u.save(using=self._db)
        return u

    def create_superuser(self, email, password, **extra_fields):
        u = self.create_user(email, password, **extra_fields)
        u.is_superuser = True
        u.save(using=self._db)
        return u

class BaseUser(AbstractBaseUser):
    is_superuser = False
    objects = BaseUserManager()
    …

We also make BaseUser.is_superuser as a hardcoded field which is False by default.

Call a User and get its matching subtype

So far we can't call SomeUser.objects.get(pk=1) and get the matching user with its properties. Django model utils with InheritanceManager comes to the rescue.

As our BaseUser is abstract we cannot call BaseUser.objects.get(pk=1). We need to write an intermediate concrete table that we can call objects on.

We also make BaseUserManager inherit from InheritanceManager.

class BaseUserManager(DjBaseUserManager, InheritanceManager):
    …

class CallableUser(AbstractBaseUser):
    objects = BaseUserManager()

Ressources

• The final models file with revisions (and their associated tests) is here: https://gist.github.com/vinyll/6103202
• Django doc about model inheritance: https://docs.djangoproject.com/en/dev/topics/db/models/#multi-table-inheritance
• django-model-utils: https://github.com/carljm/django-model-utils

Scrum ou pas ?

Aujourd'hui, j'avance dans le doute, ça mélange les anciennes certitudes dans un joli précipité.

En essayant de se rapprocher de Scrum, nous avons fait des choix et adopté des contraintes qui endommagent notre quête ; mais qui semblent inhérents à l'orientation prise par le développement Web.

Équipe multidisciplinaire ?

L'équipe est rarement multi-disciplinaire. Nous travaillons volontiers avec des intégristes de l'intégration, et respectons les préférences en laissant par exemple David déguster JS à son rythme. C'est handicapant pour attaquer les Users Stories conjointement, mais ça nous semble coller à la nouvelle façon de construire le Web.

100% dans le sprint ?

Dans nos balades, les développeurs sont rarement à plus de 80% et très souvent en dessous. Ils souhaitent souvent garder du temps pour d'autres activités. Ça donne une drôle de tête aux burndowns, mais on adore le confort que ça apporte.

Communication en face à face ?

On reconnait que ça endommage vraiment l'émergence de pépites collaboratives, mais on admet que ce n'est pas très facile de se retrouver dans la même salle. Et, finalement, on pense que ça ne va pas s'arranger.

Servant leader ?

Aujourd'hui, Stéphane le facilitateur considère que son rôle n'est pas de supprimer les obstacles à l'instar d'un brosseur au curling. Il (Alain Delon) préfère exposer clairement les problèmes en aidant l'équipe à faire émerger les solutions.

Une PO expérimentée ?

Le Product-Owner est souvent débutant. Pas facile dans ces conditions d'espérer construire un backlog efficace. En six mois d'activité, toutes les PO ont été formées par nos soins et accompagnées par un simplificateur.

Équipe auto-organisée ?

On commence souvent avec une équipe toute neuve sur un projet tout neuf qui ne va durer que quelques mois. L'amélioration continue est difficile à envisager. À chaque démarrage, nous sommes obligés d'apprendre à coopérer.

Dans ces conditions, pourquoi l'équipe continue-t-elle à s'entêter pour conserver le cap sur Scrum ? Pourquoi ne pas se rendre à l'évidence et débrayer simplement sur Scrumban ou Kanban ?

Les préconisations de Scrum fournissent un cadre de travail facile à comprendre et difficile à appliquer. Une petite liste de propositions recommandables et très apprenantes, un pédiluve qui nous encourage à faire des bombes sans trop salir la grande piscine de l'Agilité.

6 mois

Petit retour sur ces 6 premiers mois d'existence.

Du point de vue financier, un début très difficile avec les 2 premiers mois quasiment sans activité. Heureusement, celle-ci a ensuite décollé et cela nous permet d'envisager (enfin !) des salaires au-dessus du SMIC. Un point comptable doit être fait d'ici la fin du mois et notre comptabilité réelle sera alors publiée.

Du point de vue humain, le stress financier a forcément cristallisé certaines tensions qui ont réussies à être désamorcées par les rétrospectives et les discussions. Cela nous a permis de mieux nous connaître et de nous aligner.

Du point de vue positionnement, certains projets ont fait débat et on s'est finalement accordé sur une période de transition entre nos précédentes activités et le cap de la SCOP. Il est très difficile de se prononcer sur les problématiques éthiques d'un client sans avoir suffisamment d'éléments à confronter.

D'un point de vue fun, on essaye de se réserver une demi-journée par semaine dédiée aux activités ludiques (slackline, grimpe, etc) et une autre à la transmission technique (web components, métaclasses, etc). C'est vraiment bénéfique et ça a un impact direct sur l'ambiance et la productivité.

D'un point de vue méthodologie, on a testé beaucoup de choses, actuellement on fonctionne en interne avec une planification à la semaine sur une sorte de kanban. Le télétravail et la dualité physique/numérique du tableau pose encore quelques problèmes de synchronisation mais l'on essaye d'y palier au travers de micro-réunions quotidiennes. Nous utilisons scrum avec nos clients.

D'un point de vue innovation, nous sommes actuellement en pré-incubation pour un projet d'innovation sociale au service de l'économie sociale et solidaire (en opposition à l'économie cynique et suicidaire pour reprendre la terminologie d'Outils-Réseaux). Cela va nous permettre d'animer des ateliers de co-construction citoyenne afin de réaliser un produit utile à tous.

D'un point de vue partage, même si l'on a participé à pas mal de conférences, c'est encore insuffisant mais on manque de recul pour savoir ce qui est le plus pertinent pour vous donc n'hésitez pas à nous contacter si vous avez des interrogations !

Mix-IT 2013

Nous étions en force à Lyon pour rencontrer des personnes combinant une approche agile et technique aux profils très variés. Cette mixité se retrouve dans le programme sur 2 jours et dans les échanges que nous avons pu avoir, il était même possible de slalomer entre les interventions Java grâce aux 3 salles de conférences + 2 d'ateliers en parallèle.

Ces 2 jours nous auront permis :

• d'avoir des retours d'expériences suite aux pratiques agiles dans le monde réel ;
• de réfléchir à l'influence des objectifs que l'on soumet à une équipe ;
• d'avoir un aperçu du web de demain avec les Web Components, AngularJS ou Dart ;
• de discuter d'API HTTP et Hypermedia ;
• d'être confrontés aux problèmes de flux tendus déficients dans le domaine de la restauration ;
• de se faire une virée nocturne en vélo sur les quais lyonnais ;
• d'essayer ElasticSearch sans pouvoir aller jusqu'au facettes malheureusement ;
• d'avoir une démonstration de l'approche produit en version anglo-saxonne chez GitHub ;
• de découvrir le robot NAO et les possibilités offertes en terme de programmation à partir du langage Python !

Beaucoup d'échanges et de rencontres pendant et entre ces sessions, le tout en restant à taille relativement humaine, tout ce que l'on aime.

Du code acentré

Nous nous sommes retirés pendant 3 jours dans les Pyrénées en novembre dernier pour travailler ensemble sur un projet en mode mandala (les sources furent détruites à la fin). Ce fut l'occasion de tenter une approche non centralisée de notre travail. L’utilisation qui est faite aujourd’hui des Distributed Concurrent Versions System (DCVS) se focalise presque exclusivement sur une approche centralisée (bien souvent sur GitHub ou Bitbucket).

Or, il est tout à fait possible d’avoir des échanges de code locaux de pair à pair sans qu’il n’y ait de centre, chaque machine pouvant avoir une version différente du projet à différents stades de développement et incluant des fonctionnalités différentes. Cela peut poser problème dans un contexte de release, mais ce n’était pas notre objectif principal (et ça reste possible à partir du moment où une machine récupère l’intégralité des fonctionnalités développées sur les autres).

Pour mettre en œuvre par la pratique ces concepts, nous avons choisi Git — mais nous aurions pu tout aussi bien utiliser Mercurial, qui offre le même type de fonctionnalités.

Notre premier essai a été de tenter de passer par les dossiers partagés d’OS X mais Git ne permet malheureusement pas d’utiliser le protocole afp://, je me suis alors souvenu d’avoir déjà eu à servir mon dépôt Mercurial localement avec la commande serve et je me suis mis en quête de trouver la même commande en Git qui est la suivante :

$ git daemon --reuseaddr --base-path=. --export-all

qu’il est possible de mettre en alias dans son fichier de configuration global ~/.gitconfig :

[alias]
    serve = !git daemon --reuseaddr --base-path=. --export-all ./.git

Notez qu’il est possible d’ajouter l’option --verbose pour voir qui récupère quoi sur sa machine.

Une fois le dépôt servi par une machine source, il est possible de s’y connecter directement via son adresse IP, mais nous avons préféré utiliser la résolution du nom de la machine, ce qui s’avère plus pérenne si vous êtes en DHCP (il faut être sur le même réseau pour la résolution DNS, attention aux noms d’hôtes aussi ! La commande ping est votre amie pour tester ça) :

$ git clone git://nom_machine_source/

Ne surtout pas oublier le / final sinon la récupération ne pourra pas être effectuée. À partir de là, il est possible d’effectuer l’intégralité des commandes Git. Il peut être utile d’ajouter les machines concernées en remote pour éviter d’avoir à re-taper l’URL à chaque fois :

$ git remote add nom_source git://nom_machine_source/

Une fois cela mis en place, le workflow de travail est un peu différent puisqu’il n’y a jamais de push, chaque développeur récupérant ce dont il a besoin chez les autres pour avancer sans rien leur imposer.

L’expérience s’est avérée relativement concluante une fois les différentes commandes ci-dessus acquises, et permettra de mettre en pratique un tel workflow lors d’un futur /dev/fort où la connexion est par définition limitée.

Qu’il est bon d’enfin utiliser un DCVS à bon escient !

Innovation sociale

L'innovation sociale consiste à « répondre à des besoins sociaux et environnementaux mal ou peu satisfaits par des solutions entrepreneuriales ».

Les entreprises sociales sont des entreprises à finalité sociale, sociétale ou environnementale et à lucrativité limitée. Elles cherchent à associer leurs parties prenantes à leur gouvernance.

Nous avons été retenus en début d'année par ALteR'Incub pour une période de pré-incubation de 6 mois relative à l'activité sociale et solidaire que nous souhaitons développer au sein de scopyleft. Celle-ci sera suivie dans le meilleur des cas d'une période d'incubation d'un an au cours de laquelle le projet sera concrétisé.

Cet accompagnement nous permet de nous poser beaucoup de questions relatives au modèle économique de cette activité et aux différents partenariats et interlocuteurs que l'on peut avoir sur ce type de projet. Il nous permet également de rencontrer des « co-incubés » aux projets très intéressants qui enrichissent notre propre vision du produit proposé par leurs regards néophytes et citoyens.

Ce projet est une expérience nouvelle qui nous permet de mettre en pratique des outils de concertation propres aux méthodes Agiles sur une population non technique en impliquant tous les acteurs pouvant intervenir dans la mise en place de la plateforme et son utilisation. Il nous permet de mieux définir nos activités et de les rendre compréhensibles par tout un chacun.

L'objet même de la plateforme sera détaillé dans un prochain billet.

Applications mobile : Web vs. Natif

Nous avons récemment eu à enrichir une application Web d’intranet afin d’aménager un accès pour des utilisateurs de mobiles (parc de périphériques connu et contrôlé). Trois approches étaient possibles :

• l’utilisation d’un responsive design sur la version Web pour réutiliser l’existant mais cela posait des problèmes de performances (chargement inutile de l’intégralité du HTML et des ressources de la page, mise en cache complexe) ;
• l’utilisation de code natif — ou d’un intermédiaire comme Titanium pour bénéficier de la réactivité et des APIs — mais cela nous liait trop fortement aux plateformes propriétaires ;
• l’utilisation d’une version Web dédiée aux périphériques à petits écrans, c’est celle pour laquelle nous avons opté en misant sur la pérennité et l’évolutivité d’une telle approche.

Rapidement, nous avons été confrontés à plusieurs problèmes que nous souhaitions partager avec vous :

La réactivité

C’était la grande inconnue et nous avons rapidement opté pour une architecture permettant de servir les données en JSON via une API HTTP pour alimenter une application JavaScript en Backbone.js avec la possibilité de mettre en cache les données côté client (utile lorsque la connexion est aléatoire !).

La latence perceptible au tap sur un périphérique iOS pour afficher une page Web s’explique par une préconisation Apple à à patienter 300ms avant de prendre en compte l’action de l’utilisateur ; cela nous semblait trop important compte-tenu de la cible. Des solutions techniques comme celle proposée par la bilbliothèque FastClick permettent heureusement de s’affranchir d’une telle contrainte.

Côté performance et réactivité des interfaces, si nous (et notre client) sommes satisfaits des résultats obtenus vis à vis des usages cibles sur leur parc de machines (iPhone 5, iPad et machine Android récentes), il semble pour autant que cela ne soit malheureusement pas le cas pour tout le monde ; tout dépendra donc du type d’usages auxquels vous destinez votre application.

Le choix du framework Web mobile

Parmi l’offre pléthorique d’outils Open Source à disposition sur ce créneau en plein essor, nous avons évalué trois frameworks de développement Web mobile : iUI, jQT et jquery-mobile.

iUI

iUI est le moins complet et ne semble plus vraiment maintenu, il est néanmoins léger et très efficace pour un site basique. C’est par ailleurs le plus performant sur les animations de transition.

jQT

jQT est un projet relativement actif, mais qui manque cruellement de documentation et nous a posé de nombreux problèmes quand à la gestion des évènements spécifiques à une utilisation mobile. De plus, il est très difficile d’étendre ou de hooker l’API proposée, ce qui s’est avéré rhédibitoire eu égard aux besoins du projet.

jquery-mobile

jquery-mobile nous a finalement donné entière satisfaction, avec la possibilité de réaliser un thème rapidement, disposant d’une bonne extensibilité, la possibilité de débrayer tout ou partie des fonctionnalités de navigation intégrées (contrairement à jQT) et l’intégration native des fonctionnalités de FastClick.

Le catalogue de widgets est relativement complet, leur mise en place et leur configuration est rendue très aisée par l’utilisation des data attributes (même si l’on peut toutefois questionner la pertinence de les utiliser pour gérer la présentation par exemple…)

Appification et contextes

Sur iOS, il est possible de placer un site — ou plutôt une URL — en tant que raccourci d’application sur l’écran d’accueil ; celui-ci peut alors disposer d’une icône dédiée et d’un écran d’attente de chargement au lancement, tout en masquant l’interface utilisateur de Safari.

Si cette solution nous semblait satisfaisante dans un premier temps, elle s’est vite révélée problématique lors des changements de contextes :

• l’ouverture d’un lien externe au sein de l’application ouvre inévitablement un nouvel onglet dans Safari ;
• la sortie vers un lecteur PDF ne permettant pas de retrouver l’application dans l’état où elle avait été quittée (ce qui est plutôt gênant pour un moteur de recherche)

Sous Android, la situation est à peine meilleure avec Chrome, puisqu’un clic sur un lien vers un document PDF entraîne son téléchargement en tâche de fond… Ne reste qu’une obscure notification une fois l’opération effectuée, nécessitant une action utilisateur pour le visionner.

Dans les deux cas, l’utilisateur lambda risque vraisemblablement d’être a minima perdu ou plus vraisembalement agacé par ces modes de fonctionnement.

Au final, si certaines limites nous semblent justifiées, d’autres laissent à penser que les plateformes ont tout à gagner (environ 30% en fait) à encourager le développement d’applications natives en conservant de manière stratégique ces freins au développement d’applications Web.

Acte de naissance

« Ce n’est pas un signe de bonne santé que d’être bien adapté à une société profondément malade » — Krishnamurti

Le projet de monter une coopérative de développement Web avait germé il y a bien longtemps dans nos cerveaux épris d’équité et de démocratie solidaire ; nous sommes heureux de donner concrètement vie à cette idée en créant un outil de travail pleinement conforme à nos valeurs. Oui, nous venons de créer la boîte dont nous avons toujours rêvé.

Scopyleft est empreinte de nos convictions parmi les plus insensées ; celles de partager, d’échanger, de redistribuer, de s’ouvrir le plus complètement possible, de se donner les moyens de s’épanouir et d’être heureux dans l’exercice de notre activité professionnelle. Puisqu’on vous dit qu’on est fous.

Vaste programme

Évidemment, tout n’a pas été forcément facile durant cette phase de création. Et contre toute attente, les démarches administratives n’ont pas été les obstacles les plus difficiles à surmonter, malgré leur pénibilité. Le plus stimulant — bien qu’éprouvant — a été de confronter, valider et accorder nos principes et valeurs respectifs.

Ce travail de plusieurs mois, bien plus fastidieux qu’il peut n’y paraître de prime abord,  nous a permis d’engager de nombreuses discussions, de soulever tout autant d’interrogations et de prendre le temps d’y répondre, ensemble. Ces efforts ont débouché sur l’établissement d’un manifeste, dont la version la plus épurée accueille aujourd’hui les visiteurs sur le site. Une version plus détaillée de ce manifeste a été également ajoutée en préambule des statuts de la société.

Transparence

Si vous avez cliqué sur le lien précédent, vous vous êtes probablement rendu compte que nous avons mis à disposition les statuts de Scopyleft publiquement sur Github, ainsi que tout un ensemble de ressources liées à la constitution, mais aussi à nos encours quotidiens (excepté les échanges confidentiels avec nos clients bien entendu),  nos rétrospectives ou encore notre comptabilité !

Nous projetons de rédiger à terme des notices explicatives pour chacun des types de document que nous libérons et de régulièrement publier ici-même le fruit de nos expérimentations à ce sujet.

Bien évidemment, vous êtes encouragés à contribuer et vous approprier ces documents, leur amélioration collective étant l’un des principaux objectifs de cette libération.

Aspirations

Nous souhaitons avant tout mettre nos compétences individuelles et collectives au service de projets Web et mobiles utiles au plus grand nombre.

Nous avons à notre disposition une très bonne connaissance du Web en général et de technologies comme Python, Django et Javascript en particulier.

Nous abordons chaque nouveau projet avec un regard neuf et débutant. Nous prenons beaucoup de plaisir à échanger, à partager notre culture et nos valeurs en accompagnant partenaires et organisations dans leur transformation Agile ou vers le Lean thinking.

Nous n’attendons maintenant plus qu’une chose : concevoir et fabriquer de belles choses, avec vous.