Les 24 Work Hacks de sipgate

24 Work Hacks by sipgate

Sipgate, un opérateur européen de téléphonie mobile basé à Düsserldorf en Allemagne de distingue par ses pratiques agiles et pionnières déployées depuis 10 ans dans l’ensemble de la société. Tim Mois, président, et Corinna Baldauf, Content Creator chez Sipgate, ont co-écrit un livre présentant comment fonctionne leur entreprise à travers les “24 Work Hacks qu’ils auraient voulu découvrir plus tôt”. Ce livre étant sorti uniquement en anglais et en allemand, voici un résumé français de ces fameux 24 work hacks : organisation, agilité, recrutement, feedback, tout y passe !

Pour les anglophones on vous conseille quand même de lire ce super bouquin plein de photos de l’entreprise et de ses hacks, pensé avant tout pour inspirer les amoureux du Lean et des méthodes agiles : 24 Work Hacks (anglais).

Open Friday

Deux vendredis par mois, tous les collaborateurs se retrouvent pour un Open Space, lors duquel chacun propose des thèmes qu’il veut traiter dans une salle à part et revient 45 minutes plus tard en plénière présenter les résultats et un bilan. But : partager et diffuser de la connaissance, essayer de nouvelles pratiques, demander de l’aide, proposer de changer des pratiques désuètes ou stupides, et prendre des décisions les concernant. Les échanges sont donc grandement favorisés et en cas de tensions ou problèmes, nous ne sommes qu’à 2 semaines de sa résolution.

Tout afficher et coller

Toutes les salles de réunion et de travail disposent de whiteboard, de marqueurs et de Post-it à profusion, donc pas d’écran derrière lequel se cacher. Tout est donc visualisé sur les tableaux, sur les taskboards, ce qui encourage et permet à tout le monde de montrer ce qui est en cours, ce qui nous préoccupe. Chacun dispose de 2m2 et aucun logiciel de gestion de projet n’est utilisé. But : visualiser tout ce qui est en cours, ou fait, facilite énormément les échanges et permet à chacun de comprendre en profondeur ce que chacun fait. Cela devient beaucoup plus facile d’échanger et de parler de la même chose.

Lean, Agile et Scrum

Nous appliquons en permanence des méthodes agiles, d’auto-gouvernance, de Kaizen… Les nouveaux venus apprennent de leur pairs lors de Workshops appelés “Santa-Maria”, lors desquels ils vont vivre les principales d’agilité, de Lean et de Scrum. C’est un mélange de théorie, de pratique, de legolympia, de “Famille Toyoda” et de Scrum Framework. Cela permet de belles découvertes et de transfert de connaissances sans transparent et sans monologue. But : chaque question est répondue, chacun partage ses expériences : “comment faire avec les tickets ?”, “Est-ce que cela ne perturbe pas le Sprint ?”, “Est-ce que tout le monde décide ?”, “Est-ce que les équipes non-produits utilisent les méthodes agiles ?”. Nous invitons également des entreprises extérieures, ce qui garantit un échange et de nouvelles perspectives pour tous.

Stand-ups

Les réunions quotidiennes debout “Stand-ups” fonctionnent tellement bien dans toutes les équipes et sont appliquées aux équipes responsables de la comptabilité, de la finance, du juridique, des ressources humaines. Depuis que Scrum a été introduit les équipes se regroupent chaque matin devant leur tableau avec leur tâches et activités, sans avoir besoin de faire un rapport. Cela permet de planifier : Qu’est ce qu’il y a à faire ? Pouvons-nous atteindre ce que nous avons prévu ? Qui fait quoi ? Les stand-ups sont ouverts à tous, tout le monde peut venir et écouter. Les stand- ups ne sont pas interrompus, ont lieu tous les jours à la même heure (choisie par l’équipe). But : les journées commencent de manière structurée, et cela dure seulement 15 minutes.

Equipe pluridisciplinaire

Nous souhaitons sortir de nouveaux produits, et voulons éviter de transférer des tâches de personnes à personnes. Donc nos équipes sont pluridisciplinaires. Chaque équipe est responsable d’un produit. Ils s’identifient à leur bébé et construisent ensemble la connaissance produit. Il y a quelques produits sur lesquels plusieurs équipes travaillent ensemble, mais chacune avec un focus différent. Dans ces équipes, nous trouvons, des développeurs logiciels, des “Product Owner”, des “Experience Utilisateur designer”, des “Scrum Master”, etc. Ils travaillent dans le même bureau, sur des tâches communes et construisent ensemble des fonctionnalités complètes. On trouve aussi des rôles de marketing, de support client. Lorsque un nouveau design est demandé, c’est Peter qui est dans la pièce qui s’y colle. Si on hésite sur le but de la fonctionnalité, le Product Owner nous l’explique, et pour voir le résultat, il suffit de se déplacer de 2 mètres pour voir Laura qui développe le code. But : chaque équipe peut donc travailler de manière autonome et rapidement, sans avoir à attendre des décisions ou des résultats d’autres équipes. La proximité et mixité suppriment les malentendus et les tâches en attente. Les problèmes clients sont réglés plus rapidement, l’origine est trouvée plus facilement et toute l’équipe peut se focaliser sur un goulot d’étranglement pour résoudre des bugs ou problèmes. Ces équipes pluridisciplinaires auto-organisées sont fabuleuses.

Binôme | Pairing

Scrum est la méthode agile la plus populaire pour développer du logiciel. Une pratique encore meilleure s’appelle Extreme Programming (XP). Ce qui fonctionne bien et est très apprécié est le “Pairing”. En XP, on parle de “Pair Programming” : deux développeurs se partagent un ordinateur. Un des deux écrit le code (driver) et le second garde la vue d’ensemble (navigator). Les deux partenaires font tourner les rôles régulièrement. “Deux personnes sur un ordinateur c’est du gâchis de ressources et cela revient très cher !” me direz-vous ? On obtient la moitié du code, oui, mais la qualité est fabuleuse, et il n’y a rien de plus stupide que du code inutile. But : A travers le “Pair Programming”, la qualité du code est excellente et aucune ligne n’est inutile. Le code est bien plus maintenable, on évite des îlots de connaissance, car il y a au moins 2 personnes qui connaissent le code. En cas d’absence, maladie, la personne en Pairing peut continuer à développer le code seule ou encore mieux avec une autre personne. Cela rend l’organisation plus rapide, pas plus lente. Les équipes en pair utilisent aussi moins de place. L’étape d’après s’appelle le “Mob Programming” ou plus de 2 personnes travaillent sur le code. Nous appliquons le principe de Binôme pour d’autres tâches et rôles, comme les User Experience designer, les Product Owner, le support client, et d’autres combinaisons. Même au service comptabilité, ils travaillent en binôme!

Espace Ouvert

Nous travaillons très proches les uns des autres au sein des équipes et en dehors. Ce qui aide, c’est l’espace dont nous disposons. De la place pour se parler longtemps, ou juste clarifier un détail. Il y a de l’espace pour discuter en utilisant les tableaux blancs, sans que personne soit dans le passage. Il y a deux longs couloirs, et au milieu de chacun une cuisine, et en bas un restaurant pour le petit déjeuner et le repas du midi. But : Pour ces rencontres de grande richesse, nous conservons des créneaux non occupés. Cela permet de réagir sans pression aux demandes imprévisibles, et d’aider d’autres équipes sans complication. Enfin avoir du temps et de l’espace nous aide à être plus productifs, et d’échanger nous permet d’éviter que tout le monde perde du temps dans les mêmes écueils. L’information coule donc librement, et dessiner demande de la place et l’espace garantit les occasions d’échange.

Propre restaurant

“C’est un restaurant, pas une cantine” : c’est le conseil que l’on donne aux personnes qui viennent y déjeuner, car ce serait vraiment une insulte. Pas seulement pour l’organisation, qui permet à 150 personnes de manger à la carte, mais aussi pour l’équipe qui propose des petits déjeuner et des repas fantastiques le midi, frais, préparés sur place, individuel. Il n’y a pas eu deux fois le même plat. Tout est fait maison, bio et régional quand c’est possible. La coopération avec une liste de fournisseurs de Düsseldorf et des environs rend cela possible. Parfois nous rendons visite aux agriculteurs pour nos faire expliquer comment les aliments sont cultivés. L’équipe en cuisine travaille comme les autres équipes Lean et agile, une fois par semaine, ils se réunissent pour planifier les plats, et toutes les deux semaines, une rétrospective permet de trouver des idées d’améliorations. De nouvelles sources d’inspirations sont livrés à l’équipe par les chefs étoilés que nous invitons régulièrement. Il en résulte un échange décontracté de recettes, ingrédients, de méthodes de travail dans le restaurant. Et pour les collaborateurs c’est l’occasion de déguster des plats préparés par un chef réputé. But : les tables sont installées en longueur, afin de favoriser le contact avec des personnes différentes, ou bien on échange avec un invité, que ce soit des clients, partenaires, ami ou famille des collaborateurs. Les repas sont pour tout le monde sans exception gratuits.

Demo | Synchro Meeting

Nous sommes une dizaine d’équipes qui travaillent plus ou moins indépendamment les unes des autres. Chaque équipe s’organise seule. Au global, nous proposons une vingtaine de mises à jour de logiciel à nos clients, donc il devient facile de perdre la vue d’ensemble. C’est pourquoi, les meeting “Scrum Review” se sont transformés en “Synchro Meeting”. Cela s’appelle Demo, et lors de ces réunions nous arrivons à un même niveau de connaissances. Un jeudi sur deux, on se rencontre à 15h. Chaque équipe présente ce que les clients peuvent mieux faire, nouvellement depuis la dernière Demo. Si quelqu’un montre une nouveauté pas encore abouti, il va récolter des “bouuuuuuhhh”, car lors des Demos, nous voulons que des choses prêtes et fonctionnelles pour le client. Cela se fait avec Google Slides et les équipes travaillent en parallèle sur un document. But : chacun présente en live les nouveautés, cela prend moins de 30 minutes, dans ce temps, les résultats de l’équipe sont présentées à tous. Grâce à ce mécanisme de “Demo”, nous sommes toujours informés des améliorations produits malgré le nombre d’équipes et de développements.

Rétrospectives

S’il y a une seule chose que vous devez retenir de ce livre : “Retro”. Leur importance en termes d’apprentissage et d’amélioration continue ne peut être sous-estimé. Une rétro est un temps partagé à l’écart de tourbillon quotidien et permet de réfléchir au passé récent et des comportements de chacun. Dans sa forme la plus simple, nous répondons aux questions : Qu’est-ce qui a bien marché ? Qu’est-ce qui n’a pas si bien marché ? Que voulons-nous tester ? Essayer, expérimenter ? L’important est que ces rétros aient lieu régulièrement, pas seulement à la fin d’un projet ou “par besoin”. Cela permet d’utiliser directement toutes les nouvelles découvertes, connaissances, et les options d’action et d’améliorer le projet en cours. La plupart des équipes pratiquent ces rétrospectives toutes les deux semaines pendant 60-90 minutes. Le Product Owner fait partie de l’équipe et est présent dans tous les cas. Les rétros fonctionnent mieux lorsqu’elles sont facilitées. Chez nous, c’est le Scrum Master qui facilite. Ce que nous ne faisons pas dans les rétrospectives, c’est de chercher les coupables et les responsables. Le passé ne peut plus être changé. But : lors des rétros, il s’agit de répondre à comment faire mieux dans le futur ? Cela fonctionne seulement lorsque tout le monde parle ouvertement. La confiance et confidentialité sont fondamentales. On applique la règle de Las Vegas : “ce qui se passe en Rétro, reste en Rétro”. Ce qui est dit lors des Rétros n’est pas communiqué à l’extérieur. Seuls les changements que nous décidons sont communiqués. Ces modifications peuvent être de taille modeste ou considérable.

Kanban

En 2010, nous avons débuté à tester les méthodes agiles, nous avons choisi Scrum comme Framework. C’est ce qu’utilise la plupart des équipes, et certaines utilisent Kanban. Kanban permet de voir ou nous nous trouvons. Premièrement, nous visualisons sur un tableau l’avancé du travail, puis deuxièmement, on réduit le nombre de projets en parallèle. Cela réduit le multitâche et augmente la productivité. On observe comment les tâches avancent sur le tableau et permet d’identifier des goulots d’étranglement ou beaucoup de travail s’accumule. De plus en plus, les règles non-dites vont être explicitées. Enfin, la dernière étape est la réflexion régulière et l’amélioration continue des modes de travail en rétrospective. Kanban est une pratique développée par Toyota, pour le contrôle des productions industrielles. Cela marche merveilleusement bien pour les travailleurs du savoir. Chez nous, les administrateurs IT sont les pionniers du Kanban, ils prennent soin de leur flux depuis des années. But : dans le passé, ils accumulaient des piles de tâches aujourd’hui peu de tâches sont en attente. Pour une équipe de 7 personnes, ils disposent de 3 projets en même temps, pas plus ce qui réduit le niveau d’erreur énormément. Entre temps, d’autres équipes utilisent Kanban, le Product Owner a la visibilité sur le portfolio de produits. Le support client organise ainsi toutes ses tâches sur le long terme, tout comme l’équipe du personnel. Kanban fonctionne bien dans des cas concrets très différents.

Do-It-Yourself

DIY est un des piliers de notre philosophie. Si nous achetons ce que les autres achètent, on ne peut vendre que ce que les autres vendent. Nous voulons offrir des produits innovants. Une boite noire ne fait pas partie de notre métier de base. En outre, nous sommes indépendants de fournisseurs externes. Cela est possible seulement si on le fait nous-mêmes. Et donc, nous savons comment cela fonctionne, on peut améliorer, étendre et implémenter n’importe qu’elle idée neuve et décalée. En 2012, lorsque nous sommes devenues opérateurs téléphoniques, nous avons développé beaucoup d’infrastructures nous mêmes, ce qui a ensuite permis d’intégrer les communications sans fil dans notre système virtuel très facilement, sans avoir à changer le type de transmissions. En dehors des produits, on remarque que la mentalité de DIY imprègne notre organisation. Notre équipe IT fait aussi le support IT en interne. Même mieux : le faisait ! Entre temps, tout a été automatisé, donc le support ne demande que peu de personne. Un fournisseur extérieur n’aurait aucune raison de tout automatiser. Les fournisseurs internes qui travaillent sur des projets autres que “j’ai oublié mon mot de passe”, ont ce but d’automatiser le plus. But : un autre département, que les organisations sous-traitent, c’est le support client. C’est une catastrophe ! Car personne mieux que le client ne sait où cela bloque et ce qui est demandé. Lorsque cette connaissance est externalisée à un Call Center, à l’autre bout de la terre ou de la ville, cette connaissance est inutilisée. Nous pouvons donc dans notre cas demander directement au support client qui va développer une solution avec l’équipe produit. Ainsi nous avons décidé de réduire par 2 les demandes de supports client. Et nous l’avons fait en améliorant les produits. Conserver le support client en interne, entre ses mains, est une mine d’or.

Art

Portraits des collaborateurs de Sipgate par Cornelius Quabeck
Portraits des collaborateurs de Sipgate par Cornelius Quabeck

Sur les murs de nos bureaux, les visiteurs tombent sur les petits et gros tableaux affichés. Peintures, photographies, et un choix d’œuvres contemporaines y sont renouvelées. On retrouve les travaux d’Albert et Markus Oehlen, Thomas Struth, David Shrigley, Dirk Skreber, Art Spiegelmann et Andreas Gefeller. Nous montrons ces tableaux pendant la Nuit des musées et ensuite le soir il y a des concerts dans nos bureaux d’organisés, nous accueillons jusqu’à 1000 visiteurs. L’artiste de Düsseldorf Cornelius Quabeck est l’artiste Résident depuis plusieurs années. Il a croqué plus de 130 collaborateurs et les a représentés dans des petits cadres. En plus de l’exposition murale, les portraits sont présentés dans le livre : “Les 117 visages de sipgate”. Il est incroyable de suivre les évolutions du style de Cornelius à travers les années.

Year Book

Le livre annuel : c’était le projet de 2012, ok il n’y en avait pas d’autres, mais quand même. Sous le nom de code “La Ligne Bleue”, se regroupe toutes nos expériences utilisateurs, des photos des designs, les histoires de l’année, et ensemble avec des experts externes, nous avons fait un livre plein de souvenirs. Quelque chose de vrai, de tangible. Ce fut un moment magique, nous avons distribué 2011 aux collègues et pendant les heureux jours qui suivirent la productivité a profondément chuté jusqu’à zéro. Tous le lisaient et cherchaient les blagues, les anecdotes. Depuis il y en a un par an, et il est toujours très attendu. C’est un grand plaisir, même si tout le monde sait que Sigi et Ben seront sur la moitié des photos. Ils savent comment s’y prendre pour apparaître. But : le souvenir du passé commun aide à s’aligner sur le futur. Lorsque l’on lit le livre, on se rend compte du nombre énorme de modifications qui ont eu lieu et que l’on ne mesure pas au quotidien. Toujours de manière “Lean”, nous collectons en fin de mois du matériel pour le livre, pas à la fin de l’année. D’un côté, ce n’est pas un travail épuisant, et on peut se souvenir facilement des détails du dernier mois, plutôt que des 12 derniers. Nous optimisons ainsi le long terme et revenons sur les projets.

Communautés

Actuellement, nous avons des équipes croisées comprenant des développeurs, des designers d’expérience utilisateurs, des Product Owners, des responsables Marketing, des support client. Mais est-ce que l’expertise ne disparaît pas lorsque un designer ne travaille pas avec un designer ? Et comment répandre l’information qui est importante pour un même rôle ? Tous nos produits se partagent la plateforme. Comment coordonner les modifications ? Après beaucoup d’essais, nous avons mis une structure matricielle, avec des “lines managers” qui coordonnent.. NON, c’est une blague ! Pas de matrice, de line manager. Les rôles différents sont dans les équipes interdisciplinaires. Les personnes de même métier sont donc répartis en communautés. La plupart des communautés se retrouvent régulièrement, en salle de réunion. Une fois par semaine, se retrouvent la “Dev Community” des développeurs qui se réserve une salle pour une heure. Il n’y a pas de facilitateur désigné. But : avec 25 à 30 personnes, dans cet espace là nous pouvons prendre des décisions, car tout le monde a développé une expérience en facilitation, et de bon niveau. C’est pourquoi, il y a toujours quelqu’un qui veille à éviter les discussions stériles et demande : “Est-ce que cela fait partie de notre thème?”. Et la communauté peut se focaliser sur son but qui est de trouver un accord ensemble.

Recrutement en binôme

Certaines sociétés ont des départements RH. Nous ne supportons pas le terme. L’équipe du personnel c’est pire. C’est souvent les termes que l’on entend lorsque l’on parle d’embauches. Mais cela ne convient pas. L’équipe s’appelle donc “Que les bons”, ce sont Thu et Carina qui coordonnent les activités liées aux collaborateurs et qui font toute la différence des RH classiques. Nous répondons en 24H aux candidatures. En général, Thu et Carina font appel à deux ou trois collaborateurs pour les aider à décider si un jour d’essai est à planifier et validé comme prochaine étape. Les équipes ne sont pas responsables d’embaucher mais responsables de fournir du feedback régulier pendant les premiers mois de la période d’essai. La partie délicate et dure est la décision de passer d’une période d’essai à une embauche définitive. Les décisions sont discutées tous ensemble, lors d’une réunion ouverte. Celui qui a déjà licencié quelqu’un qui ne convenait pas sait comme ce genre de décision est difficile. But : ce processus permet sur le long terme de prendre de meilleures décisions en termes de collaborateurs.

Peer Feedback | Retour de collègues

Le retour constructif de ses propres collègues qui peuvent évaluer pleinement est utile et très précieux pour permettre à chacun de se développer. Les réunions annuelles avec un manager ne sont pas pertinentes à nos yeux. Ce serait difficile chez nous, car nous n’avons pas de middle management. Comment cela fonctionne t-il ? Nous avons mis en place “feedback pour tous”. Dans ce cadre là, chaque semaine, 5 collègues reçoivent un feedback sur leur travail. Cela correspond à deux feedback par an et par collaborateur. Celui qui est concerné reçoit un message via Thu ou Carina qui peuvent ou non faciliter la séance de feedback. Le reste c’est la personne qui reçoit les retours qui s’en occupe. Enfin, il n’y a pas d’évaluation ou de rapport écrit. Ce feedback est pour chaque individu et ce n’est pas une tâche administrative. Celui qui reçoit le feedback choisit le rendez-vous, invite 3 à 5 personnes pour collecter leurs retours. En général, 3 personnes sont la moyenne. But : la plupart prenne cela comme une chance pour se développer, d’apprendre d’eux-même. C’est pourquoi, ils invitent des personnes de l’équipe, mais aussi d’autres équipes et des personnes ayant des rôles très différents. Deux types de feedback peuvent être sollicités : soit en groupe ou soit à deux en vis-à-vis. Nous regroupons les feedback en trois catégories:

  • “keeps” : ce que le collègue fait de bien ;
  • “ideas” : où il peut s’améliorer ;
  • “highlights” : ce que la personne fait de génial et unique.

Pas de budgets formations ?

Les produits digitaux évoluent très rapidement. Pour rester dans la course, nous devons apprendre plus vite que les autres et implémenter l’appris. Le moyen le plus simple est constitué par les livres. Celui qui souhaite un livre poste un message sur le réseau interne et Pej le commande. Il est disponible deux jours plus tard. Après la lecture, il vient décorer la bibliothèque et est disponible pour tout le monde. “Livres faciles à obtenir” fut notre première étape vers une meilleure formation. En 2015, nous avons acheté pour 11 000€ de livres, cela représente 90€ par employé. Les livres seuls n’ont rien de spectaculaires. Ce qui est spécial chez nous, c’est qu’au moins 2 fois par an nous faisons des séminaires, des formations, des workshops… Chacun définit ses besoins en termes de formation. C’est discuté au sein de l’équipe, pour valider le sujet et les dates. Puis on demande à d’autres qui pourrait être intéressé. Lorsqu’un groupe est formé, l’équipe de comptabilité s’occupe de tout, sans le recours à des autorisations spéciales. En 2015, les dépenses de formation étaient de 524 000€. Cela représente 4 000€ par collaborateur. De la Smashing Conference à San Francisco, en passant par des Workshops sur place, au UX Camp West, il n’y a une seule condition, les nouveautés apprises doivent être transmises de nouveau lors d’un Open Friday, ou via le réseau social de l’organisation.

Transparence totale des chiffres

Lorsque l’on parcourt le couloir, on voit chez nous le travail des autres. Ok nous avons des murs vitrés, mais cela ne marcherait pas si toutes les informations importantes n’étaient pas affichées ou disponible sur des tableaux. On apprend sans effort que la Hotline était à 97% disponible hier. Le plus vieux ticket a 4 heures d’ancienneté. Le diagramme de l’équipe du personnel indique que 7 entretiens ont eu lieu ce mois-ci. L’équipe Marketing affiche sur la porte le nombre de partenaires certifiés pour le CeBit. La différence entre “push” et “pull” est énorme : entre une information que l’on reçoit (push) et celle que l’on est obligé de demander (pull). “push” est beaucoup mieux, lorsqu’il s’agit des données. On apprend des choses que l’on ne savait même pas, et qui peuvent être passionnantes. De plus, notre équipe de “chiffres” produit un rapport ouvert tous les mois sur le développement des produits. Combien avons-nous gagné de clients ? Quel est le revenu ? Ce rapport est accessible par un clique de souris pour tout le monde sans exception, du personnel de cuisine au responsable produit. Si un chiffre n’est pas disponible, on le demande simplement à l’équipe “chiffres”. But : en pratique le rapport détaillé est affiché et tout le monde peut le consulter à l’exception des données personnelles des collaborateurs. L’accès à ces chiffres est utile, pour les équipes afin de voir les décisions des développements produits et du futur de chacun d’entre eux. Enfin ces décisions doivent être bonnes et aller dans le sens de l’organisation.

Enfants

Avant, nous voulions être une vraie entreprise, pas un jardin d’enfants. Cela a changé, aujourd’hui les enfants sont souvent là et les bienvenus en tant qu’invités. Soit une journée entière ou soit une semaine pendant les vacances, ou pour jouer au babyfoot ou bien en fin de journée. Les parents sont seuls responsables de la durée de présence et de la fréquence des visites de leur enfants. Les enfants veulent de toute façon souvent revenir. La raison de ce changement provient du livre “Joy Inc” de Richard Sheridan. Il décrit l’influence positive des bébés sur l’atmosphère de travail dans son entreprise de logiciel. Nous avons suivi son exemple et on a transformé un bureau en salle de jeux. Le couloir de 75m de long est un lieu parfait pour organiser des courses de Bobbycar. Mais comment être sûr qu’aucun conflit n’apparaisse dû aux courses de Bobbycar ou au babyfoot ? Nous ne l’étions pas. Mais nous avions le sentiment que cela pouvait mieux fonctionner, et que cela valait le coût d’essayer et regarder ce qu’il se passe. Et quel est l’effet produit ? Comme l’a décrit Richard, contrairement à ce que l’on peut penser les enfants produisent un effet de calme et de vivant. En même temps les parents ont même ouvert un “Mini-Club” avec une éducatrice pendant les vacances ou lorsque les crèches sont fermées. Il y a même un programme détaillé et complet pendant les vacances, avec visite de Zoo, la Tour Télé… But : les parents sont donc moins soucieux ou inquiets et les enfants sont ravis.

Exactement 40 heures/semaine

Soudain est apparu une pointeuse ! A chaque fois que nous faisons visiter nos locaux, c’est un arrêt inattendu. Une entreprise si différente avec table de Ping-pong, babyfoot, matelas, et… une pointeuse. N’est-ce pas totalement archaïque ? Elle sort du cadre ? C’est justement excellent car cela permet à tout le monde de ne pas faire d’heures supplémentaires. A chaque utilisation, les collaborateurs peuvent lire le nombre d’heures qu’ils ont fait. La semaine de 40 heures ne vient pas des propriétaires d’usines qui se disaient “tiens, ce serait sympa si tous pouvaient finir plus tôt et avoir deux jours de weekend” mais cela vient d’Henry Ford, qui a constaté que les hommes sont productifs pendant 40 heures par semaine. S’ils travaillent plus, cela ne génère pas plus de résultats, voir moins sur du long terme. D’où notre devise : aucune heure supplémentaire. La personne qui dépasse ces heures, sera informée décemment qu’il existe d’autres modes de vie que le travail uniquement. Nous rappelons aux gens de prendre leurs vacances. Elles n’ont pas besoin d’être approuvées, chacun doit décider quand il prend des congés et s’assurer que son absence ne crée aucun problème. Une vérification avec l’équipe est suffisante. But : la pointeuse n’impose pas d’heures d’arrivé et de départ. Chacun peut aller et venir comme il le souhaite, c’est très pratique pour les rendez-vous chez le médecin ou le coiffeur. Il suffit de vérifier avec l’équipe. Pour les Stand-ups, il est important d’être présent, sinon cela rend le travail difficile. Il existe une exception : la hotline, qui est accessible 24/24, et donc requiert deux équipes.

Lean Startup

En 2009, notre flagship sipgate team a pris 3 ans de développement. 3 ans ! C’est une durée très longue, entre le premier pari fait sur une idée de produit… Nous avons eu de la chance car ce produit est une réussite… et si cela n’avait pas été le cas ? Aujourd’hui, nous ne ferions pas du tout la même chose : 3 ans de développement dans le “bleu”, sans savoir si ce produit trouverait un acheteur heureux. Au contraire, nous essayons de tester nos idées le plus tôt, et de les jeter si elles le méritent. Pour chaque fonctionnalité, ou idée de produit nous remplissons une check-list pour ne rien oublier, et on se demande si c’est aligné avec notre stratégie. Quel profit on peut attendre ? Quel problème voulons-nous résoudre ? Pour de merveilleuses solutions, il y n’a souvent pas de problèmes… “C’est stupide”. Beaucoup de nos concepts proviennent du Lean Startup, et en premier lieu le Minimum Viable Product (MVP). Pour chaque idée devenue concrète, nous réfléchissons à la plus petite expérimentation, afin de tester nos hypothèses. Si nous ne savons pas quel thème peut intéresser nos clients? Fax, menu d’appel, fonctionnalité ISDN… et bien on essaye. Nous avons en 5 jours testé 5 pages internet rudimentaires, et nous en avons fait de la publicité. Ensuite nous avons regardé quelle page a été la plus visitée et nous avons orienté nos efforts sur le thème qui a été le plus sollicité. Prenons par exemple ce livre, la première version est sortie en 2 semaines, dans lequel nous avions 22 Work Hacks plus tôt que 25 de prévus. Le texte était plein de fautes, l’ordre des chapitre très différent et il n’y avait pas de section “infos supplémentaires”. Mais la 1ère version imprimée en 20 exemplaires était suffisante pour tester nos hypothèses : Est-ce que le livre intéresse quelqu’un ? Combien de temps lisent les personnes ? Comment agissent les textes et les images ensemble ? A partir du retour des testeurs, nous avons mis à jour plusieurs fois le livre, améliorer, collecter les feedbacks et améliorer.

Portes ouvertes

Nos bureaux sont spacieux et nous y travaillons la journée. Le soir et le weekend, c’et ouvert, nous l’ouvrons pour des spectacles, ou événements. Cela ne coûte rien, mais la condition est que cela doit être amusant et que cela nous donne l’occasion d’apprendre quelque chose. Les groupes de musiques sont les bienvenus, des groupes de la région ou bien le nôtre, qui joue d’ailleurs pour la nuit des musées. En quelques heures, la salle est prête pour un concert. Meet-up, Start-up Week de Düsseldorf, thèmes techniques comme Ansible ou la science des Données. Beaucoup d’événements ont lieu dans nos locaux, que nous ouvrons, sans les organiser. Durant des weekends entiers ont lieu les événements tels que “Beyond Tellerrand”, “Indie Web Camp”, “UX- Camp West”… L’équipe cuisine est sur le pont lors de tous les événements. But : pour nous, ces événements sont une forme d’enrichissement, lors de rencontres, d’échanges avec tous les visiteurs. Souvent, nous partageons les uns les autres sur les développements techniques et les meilleurs méthodes de travail.

Venez nous voir !

A un moment, nous avons eu l’impression de cuire dans notre jus… malheureusement, on n’apprend peu en circuit fermé. La quantité de connaissance et de nouvelles idées est réduite. Dommage. C’est ainsi que depuis 2014, nous avons institué le “Lean DUS”. Chaque mois, nous invitons des speakers pour parler de sujet, chez nous ici, ce qui nous coûte rien. Richard Sheridan, Diana Larsen et Mary Poppendieck sont venus nous rendre visite lors d’une soirée ouverte ou ce fut l’occasion pour tous de se former. En plus de nouvelles idées, nous rencontrons beaucoup beaucoup de nouvelles personnes venues de l’extérieur. Avant l’intervention du speaker, une personne vient nous parler de nouvelles pratiques de travail. Cela s’est tellement déployé que nous sommes même invités à parler à des conférences. Par exemple : “Peer recruiting” et “Open Friday” sont des sujets très demandés. Pour mieux nous connaître, vous pouvez venir nous voir lors de tour de visite que nous organisons régulièrement. Ce livre essaie de remplacer cette visite, mais avec ce livre, nous ne pouvons vous offrir un repas délicieux… donc à vous de choisir : www.sipgate.de/besuch

Auteur(s)

  • Coach professionnel à Munich, spécialisé dans les méthodes agiles, la conduite du changement et les nouveaux modes d'organisation (holacracy).

Voir aussi...

Change The Work produit des contenus de formation et d’inspiration à destination des RH et des managers.

Abonnez-vous à notre newsletter