Im Jahr 1995 gründeten Philipp Bosch, Matthias Pigulla und ich zusammen mit anderen eine Schülerzeitung am Clara-Schumann-Gymnasium in Bonn, die wir "Clarasil" nannten. Wir waren damals in der 10. Klasse, kurz vor den Sommerferien erschien unsere erste Ausgabe. Wenig später bekam Philipp sein erstes Modem und schaute sich in den Mailboxen der Region um. Von dort aus war es nicht weit bis zum World Wide Web, das damals in den Kinderschuhen steckte: erst 1993 war der erste Webbrowser auf den Markt gekommen. Philipp begann als Tüftler sofort damit, zu ergründen, wie man eine Website erstellt, und erstellte einen ersten Auftritt für Clarasil.

1996 startete "Schulen ans Netz", eine Initiative der Deutschen Telekom und des Bundesministeriums für Bildung und Forschung, die allen Schulen einen Internetzugang ermöglichen sollte. Auf einer großen Fachtagung in der Telekom-Zentrale in Bonn sollten sich Lehrer und andere Experten aus ganz Deutschland über die Möglichkeiten austauschen, das Internet in Schulen zu nutzen. Der damalige Pressereferent der Deutschen Telekom hatte die Idee, für die Fachtagung eine Online-Berichterstattung zu organisieren – und kontaktierte die Clarasil-Redaktion, da wir ja bereits Erfahrung mit dem Internet hatten. Für die Programmierung der Website hatte er eine Internetagentur aus Bremen gewonnen. Das kränkte uns natürlich in unserer Ehre und die Gestaltung der Website fanden wir langweilig. So kam es, dass unsere Redaktion am ersten Tag der Fachkonferenz nicht nur Artikel schrieb, sondern Philipp, Matthias und ich parallel bis in die Nacht hinein daran arbeiteten, ein neues Design für die Website zu entwickeln und umzusetzen. Als wir die neue Seite am nächsten Morgen den Verantwortlichen für die Fachtagung präsentierten, waren sie so begeistert, dass sie uns auf die Bühne baten, um uns den versammelten Teilnehmern der Konferenz vorzustellen. Schließlich verkörperten wir genau das, was der Verein erreichen wollte: Schüler, die Medienkompetenz für das Internet zeigten.

Die Konferenz hatte noch eine wesentliche Nachwirkung: Der Verein "Schulen ans Netz" kontaktierte uns im Anschluss mit der Anfrage, ob wir nicht auch die Vereinswebsite neu gestalten könnten. Wir sagten zu und vereinbarten einen Preis von 2500 DM (gut 1250 €). So hatten wir im Herbst 1996 unseren ersten kommerziellen Auftrag und beschlossen kurzerhand, dass wir eine Firma gründen müssten. Gesagt, getan: Im Dezember 1996 gingen wir zum Gewerbeamt der Stadt Bonn und meldeten eine GbR zur Entwicklung von Websites an. Matthias und ich waren gerade volljährig geworden, Philipp musste noch von seiner Mutter begleitet werden.

Die ersten Kunden

Nachdem die Website für Schulen ans Netz fertig war, hatten wir viele Anfragen aus dem engeren Familien- und Bekanntenkreis. So entwickelten wir eine Website für den Deutschen Juristinnenbund, dessen Geschäftsführerin Philipps Mutter war, und für die Junge Presse Nordrhein-Westfalen, deren Vorstandsmitglieder unser Schülerzeitungsseminar als Referenten betreut hatten. Und über die Junge Presse wiederum kamen wir in Kontakt mit dem Gründer eines Startups für Börsennachrichten, wallstreet:online. Kurz zuvor war die Deutsche Telekom an die Börse gegangen und hatte für ihre "Volksaktie" ein deutschlandweites Börsenfieber angeheizt – entsprechend groß war der Bedarf an Information und Austausch. So saßen wir tagsüber im Unterricht und programmierten nachmittags und manchmal nachts an einem Redaktionssystem für die Nachrichten, an einem Diskussionsforum für 300.000 Mitglieder, einem Live-Chat, Kursdiagrammen und vielem mehr, was wallstreet:online sich ausdachte. Gleichzeitig mussten wir den Serverbetrieb aufbauen und skalieren, denn die Website machte damals schon mehrere 100 GB Traffic pro Monat (und würde damit heute noch zu unseren größten Kunden gehören).

In diese Zeit fiel es auch, dass ein übermüdeter webfactorianer nach Mitternacht das Kommando rm -rf * ~ eingab und damit den kompletten Quellcode für die Benutzerverwaltung und das Diskussionsforum löschte. Eigentlich wollte er nur aufräumen und die beim Bearbeiten automatisch erstellten Kopien jeder Datei löschen, aber das unachtsam eingefügtes Leerzeichen hinter dem * führte dazu, dass der Befehl sich auf alle Dateien erstreckte. Ich weiß nicht mehr, wie wir es geschafft haben, das Diskussionsforum dann innerhalb von kurzer Zeit neu zu schreiben. Aber ich weiß, dass wir uns an diesem Tag geschworen haben, nie wieder ohne Backups zu arbeiten.

Abitur und Zivildienst

Im Sommer 1998 machten wir Abitur und waren froh, nicht weiter den halben Tag in der Schule sitzen zu müssen. Ein weiterer Kunde stieß über unsere Kontakte vom Schülerzeitungsseminar zu uns: Projekt PR, eine Bonner Agentur, die unter anderem die AIDS-Kampagne der Bundeszentrale für gesundheitliche Aufklärung und den Bundestagswahlkampf der Grünen betreut hatte und nun eine Website brauchte. Das sollte großen Einfluss auf unsere Entwicklung haben.

Wir waren eine Web-Agentur mit einem großen Kunden, der uns beachtliche Webhosting-Umsätze bescherte, und brauchten natürlich endlich ein Büro, denn wir wollten Kundentermine nicht weiter in unseren Kinderzimmern oder in Cafés wahrnehmen. Also hatten wir uns auf die Suche gemacht und von einer Dachetage über einer kleinen Autowerkstatt neben dem Rotlichtviertel bis hin zu einer repräsentativen Büroetage vis-a-vis des Poppelsdorfer Schlosses alle möglichen Büros angeschaut. Möglicherweise hätten wir die repräsentative Büroetage für damals 6000 DM Monatsmiete gemietet und es wäre unser Ruin gewesen – wenn nicht der Geschäftsführer von Projekt PR uns überzeugt hätte, in sein Büro mit einzuziehen. Die Agentur hatte sich gerade von 15 auf 3 Mitarbeiter verkleinert und hatte dementsprechend Platz übrig. Und sie hatte einen Kopierer, ein Sekretariat und eine Kaffeemaschine. So kamen wir an unser erstes Büro in der Lessingstraße 60 in der schönen Bonner Südstadt.

Im Spätsommer begannen wir drei dann unseren Zivildienst – weit verstreut: Philipp in einem Bildungswerk in der Eifel, Matthias in einer Bonner Klinik und ich in der invidivuellen Schwerstbehindertenbetreuung. Ich hatte die webfactory-freundlichsten Arbeitszeiten: Auf 4 Tage Dienst rund um die Uhr folgten 12 Tage frei, die ich natürlich nutzte, um das schöne Büro zu genießen. Während unserer Abwesenheit freuten wir uns über den Sekretariatsservice von Projekt PR, der uns auf ein ganz neues "Professionalitäts-Level" brachte.

In dieser Zeit besuchte uns auch ein Filmteam, um uns als Musterbeispiel für Erfolge des Programms Schulen ans Netz zu portraitieren. Für diesen Film mussten wir dann auch ganz schnell ein Firmenschild haben und entschieden uns, den Freiraum auf dem Schild von Projekt PR für einen webfactory-Aufkleber zu nutzen. Dieses Schild sollte dann für 10 Jahre so bleiben.

wfDynamic

Fast alle unserer frühen Kunden wollten Nachrichten auf ihrer Website veröffentlichen. Für jede Meldung immer eine handgebaute HTML-Seiten zu erstellen, war eine ziemlich zähe, langweilige, aber gleichzeitig zeitkritische Aufgabe. Da wir für für wallstreet:online bereits Erfahrungen mit Datenbanken gemacht hatten, entschieden wir, dass wir für alle unsere Kunden ein Redaktionssystem anbieten wollten, über das sie ihre Nachrichten selbst einpflegen könnten. Da jeder Kunde ein bisschen anders war, sollte es von Beginn an für individuelle Datenbankstrukturen anpassbar sein.

Projekt PR war dann der erste Kunde, der auf seiner Website nicht nur Textmeldungen veröffentlichen wollte, sondern Referenzen mit Bildern, z. B. von Plakatmotiven. Die Herausforderung nahmen wir an und lernten erst, wie man Dateien über ein Webformular hochlädt und in eine Datenbank speichert und dann, wie man diese Dateien automatisch in eine fürs Web passende Auflösung herunterrechnet.

Für den nächsten Kunden wollten wir dann noch Texte in eine Hierarchie bringen, also nicht nur eine Liste von Pressemitteilungen oder Referenzen pflegbar machen, sondern eine ganze Seitenstruktur.

Fertig war wfDynamic, ein Redaktionssystem, mit dem man die komplette Struktur der Seite anlegen und bearbeiten, Bilder hochladen und beliebige Inhaltstypen pflegen konnte. Und wfDynamic bescherte uns jede Menge Kunden.

Übrigens kam von Projekt PR schon damals die Idee, dass wir das System nicht gegen einen Einmalbetrag, sondern für eine Monatsmiete abgeben sollten. So ist die Finanzierung der Weiterentwicklung jederzeit gesichert. Und www.projekt-pr.de ist unsere dienstälteste, seit 1999 unverändert in Betrieb befindliche Website.

Studium und erste Mitarbeiter

Nach dem Zivildienst begannen zwei von uns ein Studium an der Universität Köln: Matthias in Wirtschaftsinformatik und ich in Betriebswirtschaftslehre. Philipp entschied sich, die Stellung im Bonner Büro zu halten.

Im Zuge der damals herrschenden Goldgräberstimmung am "Neuen Markt" der Deutschen Börse gewannen wir die auf Investor Relations spezialisierte Agentur Haubrok als Kunden. Für Haubrok realisierten wir nicht nur die Unternehmenswebsite, sondern auch eine Kontaktverwaltungslösung mit Newslettersystem, die wir wfContacts tauften und die inzwischen auf wfDynamic basiert. Haubrok brachte uns zudem in Kontakt mit verschiedenen Kunden, die im Zuge ihres Börsengangs neue Websites brauchten.

Ende 1999 fanden wir es an der Zeit, uns eine neue, "erwachsenere" Rechtsform zu geben, und gründeten zum 01.01.2000 die webfactory GmbH mit Philipp, Matthias und mir als gleichberechtigten Anteilseignern.

Im Jahr 2000 stellten wir dann unseren ersten Mitarbeiter ein, um unsere Arbeit auf mehr Schultern verteilen zu können. Leider lief die Zusammenarbeit nicht so gut, wie wir uns das vorgestellt hatten, sodass wir uns nach einem halben Jahr wieder trennten. Die Idee personeller Verstärkung ließ uns aber nicht los, und so stellten wir 2001 erneut einen Webentwickler ein, Christian, der uns für mehrere Jahre unterstützte und verschiedene bis heute aktive Websites mit entwickelte, darunter www.buechi-yachting.com.

JUGEND für Europa

Im Jahr 2001 beauftragte uns die Nationalagentur für das EU-Aktionsprogramm JUGEND mit der Entwicklung eines Online-Fortbildungskalenders für Fachkräfte der Jugendarbeit. Jeder, der eine entsprechende Fortbildung organisierte, sollte diese selbst eintragen können. JUGEND für Europa, die Nationalagentur, würde die Angebote dann prüfen und freischalten und Interessierte sollten sich online dafür anmelden können.

Aus dieser Zusammenarbeit entstand unsere bis heute intensivste Kundenbeziehung. Zunächst entwickelten wir 2003 eine Gruppe von mehreren unterschiedlich gestalteten Websites mit einheitlichem Content-Management-System für verschiedene Zielgruppen des Förderprogramms JUGEND. Eine davon war der Youthreporter, eine Blogplattform für jugendliche Teilnehmer des Förderprogramms hinzu, die 19 Jahre lang aktiv bleiben sollte und über die fast 13.500 Beiträge veröffentlicht wurden.

Später entwickelte JUGEND für Europa das Konzept für ein europaweites Instrument zur Anerkennung nicht-formalen Lernens: Den Youthpass. Youthpass beschreibt zum einen einen Prozess, wie Projekte der internationalen Jugendarbeit so organisiert werden können, dass die Teilnehmer sich ihrer eigenen Lernerfahrungen bewusst werden. Er bietet aber zugleich auch ein Zertifikat, über das diese Lernerfahrungen dokumentiert werden können. Hierfür entwickeln wir seit 2006 die technische Plattform auf www.youthpass.eu. Youthpass ist offizieller Bestandteil des Förderprogramms und jeder Teilnehmer hat das Recht auf ein Zertifikat. Bis heute sind fast 1,5 Millionen Youthpass-Zertifikate über das System erstellt worden. Seit 2020 befinden wir uns in einem intensiven Weiterentwicklungs- und Modernisierungsprozess.

2009 entwickelten wir für JUGEND für Europa zudem ein Online-Anmeldesystem für die Buchung der Begleitseminare, an denen Freiwillige im Europäischen Freiwilligendienst (heute Solidaritätskorps) teilnehmen. Organisationen, die einen Freiwilligen betreuen, können sich online in dem System registrieren und ihren Freiwilligen für die passenden Seminare anmelden. Dabei wird automatisch berücksichtigt, für welche Seminare noch Plätze frei sind. Die Seminarveranstalter können sich dann über wfDynamic fertige Teilnehmerlisten für ihre Seminare herunterladen. Bis heute wurden über 8000 Freiwillige über das System zu ihren Seminaren angemeldet.

Aus einer internationalisierten Version des Fortbildungskalenders entstand 2001 das Webportal SALTO-YOUTH.net, das die Zusammenarbeit und Vernetzung zwischen Fachkräften der Jugendarbeit in ganz europa unterstützt.

Ruhrtriennale

Über die Zusammenarbeit mit Haubrok kamen wir 2002 in Kontakt mit der prominenten Werbeagentur Boros, die für einen Kunden ein Content-Management-System suchte. Bei dem Kunden handelte es sich um die Ruhrtriennale, ein neu geschaffenes Kulturfestival, das Industriebrachen im Ruhrgebiet mit neuem Leben erfüllte. Boros entwickelte das Webdesign, wir die dahinterliegende Software. Die Ruhrtriennale betreuten wir über vier Intendanzen hinweg (Gerard Mortier, Jürgen Flimm, Willy Decker, Heiner Goebbels) bis 2015.

wfDynamic 3

Aufgrund von verschiedenen Kundenwünschen entschieden wir uns, wfDynamic von Grund auf neu zu entwickeln und mit professionellen Redaktionsfunktionen auszustatten. Die Ruhrtriennale sollte das erste Projekt werden, für das die Version 3 unseres Content-Management-Systems zum Einsatz kam. Kern des Systems war eine Hierarchie von Seiten, die in verschiedenen Versionen existieren konnten, mit einem Freigabeworkflow. Sämtliche Inhalte sollten in beliebig vielen Sprachen angelegt werden können. Dafür opferten wir die Flexibilität im Datenmodell. Es war durch die kompliziertere Datenbankstruktur wesentlich weniger einfach als in wfDynamic 2, neue Datentypen anzulegen. Zugleich war die Ausgabe der in wfDynamic erfassten Inhalte wesentlich umständlicher und rechenaufwändiger, da zum Beispiel für den Aufbau einer Seite mit einer Navigation und einer Liste von Terminen zunächst für eine große Zahl von Datensätzen die richtige, freigegebe Version in der richtigen Sprache geladen werden musste.

Letztendlich war die Entwicklung von Systemen auf Basis von wfDynamic 3 unverhältnismäßig viel teurer als auf Basis von wfDynamic 2, sodass wir nur wenige Kunden für das neue System gewinnen konnten. Schließlich entschieden wir uns, in Zukunft wieder auf Basis von wfDynamic 2 weiterzuentwickeln. Aus wfDynamic 3 übernahmen wir Innovationen, die sich bewährt hatten – unter anderem das bis heute aktuelle, fensterbasierte User Interface.

Azubis in der webfactory

2005 entschieden wir uns, unseren ersten Auszubildenden zum Fachinformatiker für Anwendungsentwicklung aufzunehmen. Matthias war fast fertig mit seinem Wirtschaftsinformatik-Studium und fühlte sich reif für die Weitergabe seines Wissens. Per war in Rekordzeit mit der Ausbildung fertig und legte Anfang Januar 2007 seine Abschlussprüfung ab. Die positive Erfahrung bestärkte uns darin, direkt im Sommer 2007 unseren zweiten Auszubildenden aufzunehmen. Diesmal entschieden wir uns gemeinsam mit Søren, dass er ein Mediengestalter für Digital- und Printmedien werden würde. Auch Søren war von Beginn an eine große Bereicherung des Teams, sodass wir direkt 2008 mit Herman einen weiteren Azubi zum Mediengestalter aufnahmen und 2010 dann parallel einen angehenden Fachinformatiker, Simon, und Jessica als angehende Mediengestalterin. 2011 legten wir nach mit Benjamin als weiterem Fachinformatiker und Marc als weiterem Mediengestalter. 2016 folge noch Konstantin, ein weiterer Fachinformatiker und 2018 kamen schließlich Jano als Fachinformatiker und Lukas als Mediengestalter, sodass wir bis heute 10 junge Menschen ausgebildet haben.

Der Gemeinsame Bundesausschuss

Im Jahr 2006 gewannen wir eine Ausschreibung für die technische Implementierung der Website des Gemeinsamen Bundesausschusses (G-BA). Der G-BA ist das Gremium, in dem Ärzte- und Krankenhausvertreter mit den Krankenkassen und Patientenvertretern über den Leistungskatalog der gesetzlichen Krankenversicherung in Deutschland entscheiden. Diese Entscheidungen sollten öffentlich auf der Website dokumentiert werden. Der G-BA war 2004 ins Leben gerufen worden und hatte schon einige hundert Entscheidungen getroffen, die alle manuell und ohne strukturierte Erfassung auf die Website hochgeladen worden waren. Dementsprechend hoch war der Veränderungsdruck. Die Agentur für Wissenschaftskommunikation Bosse und Meinhard hatte für die Website eine ausgeklügelte Informationsarchitektur entwickelt, die es nun technisch umzusetzen galt.

Bis heute basiert die Website www.g-ba.de auf dieser Informationsarchitektur und auf dem damals entwickelten Datenmodell und Programmcode, obwohl sie inzwischen gestalterisch mehrfach gerelauncht und erweitert wurde.

Für den G-BA entwickelten wir in den Folgejahren auch weitere Anwendungen, unter anderem ein Extranetsystem, das heute von 8 verschiedenen Abteilungen genutzt wird und den Versand von Tausenden von CD-ROMs an die Entscheidungsträger im Vorfeld der Gremiensitzungen einsparte. Auch weitere Websites und Anwendungen entstanden für den G-BA, unter anderem ein Online-Tool für Krankenhäuser zur Erfassung der Meldebögen für die Festlegung des sogenannten Systemzuschlags (systemzuschlag.g-ba.de), ein Online-Bestellsystem für Druckerzeugnisse (druckerzeugnisse.g-ba.de) und die Website des Innovationsausschusses beim G-BA (innovationsfonds.g-ba.de).

Umbau in Bonn und Standort Berlin

Im Jahr 2007 stellten wir fest, dass unser unser Teppichboden inzwischen zu fleckig war, und beschlossen, zu renovieren. Und wenn man Teppiche tauscht, muss man nicht nur das ganze Büro leer räumen, sondern wird automatisch mit der Frage konfrontiert, ob man anschließend die gleichen Möbel wieder an ihre alten Stellen stellen möchte. Und so wurde daraus unser bis dahin größtes internes Projekt: Das neue webfactory-Büro, das wir 2008 mit einer großen "11 Jahre"-Party einweihten.

Kurze Zeit später entschied sich unser Gründungsmitglied Philipp Bosch, seinen Lebensmittelpunkt nach Berlin zu verlegen und wir eröffneten dort eine kleine Ein-Mann-Dependance. Leider stellte sich das nicht als dauerhaft zufriedenstellende Lösung heraus, eine Person in Berlin und 5 Kollegen in Bonn, und Philipp entschied sich schweren Herzens, die webfactory zu verlassen.

Webanwendung "Sicherer IT-Betrieb"

2010 gewannen wir den Auftrag, für das Informatikzentrum der Sparkassenorganisation eine Webanwendung zu entwickeln, über die Sicherheitsaudits in Banken durchgeführt werden sollten. Ein großes Projekt mit einem hohen Anspruch, für das wir uns mächtig ins Zeug legten. Wir entwickelten eine Anwendung, über die hunderte Fragen, die eine Bank im Rahmen der Auditierung beantworten musste, über mehrere Stufen an denjenigen Sachbearbeiter delegiert werden konnten, der sie am besten beantworten konnte. Hatte der seine Antwort fertiggestellt, reichte er sie bei der Person ein, die die Frage an ihn delegiert hatte, und diese dann wiederum bei ihrem Vorgesetzten – die ganze Delegationskette entlang bis zum Leiter des Audits. Das Webbasierte Audit sahen wir als unser Meisterstück der Webentwicklung.

Personelle Veränderungen

2011 überschritten wir dank unserer vielen Azubis erstmalig die Schwelle von 10 Mitarbeitern. Wir brauchten zum einen mehr Platz, zum anderen mussten wir uns besser koordinieren. Wir stellten daher im Laufe des Jahres zwei Projektmanager ein. Und wir nutzten die Gelegenheit, dass die Weinhandlung gegenüber umzog, zur Erweiterung unserer Räumlichkeiten: Das webfactory-Lab war geboren.

2013 verließ uns unser erster Auszubildender Per nach 8 Jahren toller Zusammenarbeit, um sich neuen Herausforderungen zu stellen. Immerhin nicht ohne uns direkt zwei neue Mitarbeiter zu vermitteln, die er beim "Code and Coffee" kennengelernt hatte. Einer der beiden war Malte, der erste Diplom-Informatiker im webfactory-Team.

2014 verließ uns dann auch unser zweiter Auszubildender Søren, um auf Wanderschaft zu gehen. Nach Stationen bei Sapient Nitro (heute PublicisSapient) und Chefkoch konnten wir ihn 2017 überzeugen, zu uns zurückzukehren – bereichert um jede Menge Erfahrungen aus unterschiedlichsten Großprojekten.

Kurz nach Sørens Weggang konnten wir Stefan als neuen Frontend-Entwickler gewinnen, der unser Team seitdem verstärkt.

2014 war insgesamt ein turbulentes Jahr, in dem wir kurzzeitig Angst um unsere Existenz hatten (verschiedene Kunden hatten Aufträge zurückgestellt) und uns im Sommer daher schweren Herzens entschieden, zwei betriebsbedingte Kündigungen auszusprechen. Damit uns das nie wieder passiert, haben wir uns entschieden, Rücklagen aufzubauen, um Durststrecken überwinden zu können. Und hierfür vor allem besser und realistischer zu kalkulieren und abzurechnen als vorher. Es entstand unser T-Shirt-Größen-Verfahren für die Aufwandsschätzung.

Unternehmenswert Mensch

Ein schwelender Konflikt und schlechte Stimmung im Team brachten uns 2016 in Kontakt mit der Psychologin und Prozessberaterin Lucie Lewandowski und diese wiederum mit dem Förderprogramm "Unternehmenswert Mensch", das zum Ziel hat, Unternehmen dabei zu unterstützen, mitarbeiterorientierte und wertschätzende Führung zu etablieren. Natürlich waren wir vorher schon davon überzeugt, dass die webfactory super mitarbeiterorientiert wäre – aber bei der Prozessberatung, im Rahmen derer wir uns über mehrere Monate regelmäßig mit "unserer Psychologin" trafen, haben uns rückblickend extrem weitergebracht und uns für vieles die Augen geöffnet. Zum Beispiel dafür, dass es Unterschiede zwischen Geschäftsführern und dem Rest des Teams gibt, die nicht einfach weggehen, indem man sagt "wir sind hier alle gleich". Oder, dass man nicht allein dadurch ein diverses Team hat, dass man sagt, dass jeder machen kann, was er will und sein kann, wie er will. Oder, dass man auch bei internen Prozessen dafür sorgen muss, dass sie nicht ergebnislos im Sand verlaufen. Die bis heute prägendsten Ergebnisse der Beratung sind die soziokratische Entscheidungsfindung, die explizite Ermächtigung des Teams, dass jeder alles kaufen darf, was er braucht (mehr zu den beiden Punkten im Artikel über unsere Unternehmenskultur) und unser monatliches "Interne Baustellen"-Meeting (hierzu mehr in "Unser Besprechungs-Stundenplan"). Und, nicht zu vergessen: dass wir zu Beginn jeder Besprechung "ankoppeln", also jeder kurz berichtet, wie es ihm geht.

Staatsoper Berlin und Staatstheater Darmstadt

Kaum schließt sich eine Tür im Leben, öffnet sich eine neue: Das Marketing-Team der Ruhrtriennale hatte Ende 2014 nach über 13 Jahren Zusammenarbeit entschieden, sich einen neuen Partner für die Betreuung der Website zu suchen. Doch wir hatten nicht lange Zeit, den Verlust unseres Kultur-Kunden zu betrauern: im Frühjahr 2015 meldete sich die Staatsoper Berlin bei uns. Deren Marketingleiterin war dem Intendanten Jürgen Flimm von der Ruhrtriennale an die Staatsoper gefolgt und hatte die Zusammenarbeit mit uns in bester Erinnerung. Und so kamen wir zu der Ehre, zunächst eine Website für die Staatskapelle Berlin unter Daniel Barenboim zu entwickeln (pünktlich zu deren 450-jährigem Jubiläum) und anschließend die Website der Staatsoper Berlin auf das für die Staatskapelle konzipierte Content-Management-System auf der Basis von wfDynamic umzustellen.

Noch bevor die Website der Staatsoper online ging, entschied sich auch das Staatstheater Darmstadt zu einem Relaunch seiner Website auf Basis von Symfony und wfDynamic. Da wir nun drei Theaterwebsites entwickeln mussten, entschieden wir uns, hierfür ein wiederverwendbares Softwarepaket zu entwickeln: Es entstand das "Bacchus-Bundle", das die Kernfunktionalität für eine Theaterwebsite bündelt. Die Pflege von Produktionen und Terminen sowie Spielstätten, Künstlern und Besetzungen und die Generierung von Spielplänen muss nun nicht mehr für jedes Theater individuell programmiert werden, sondern steht über das Paket zur Verfügung. Auch Schnittstellen zu verschiedenen Ticketsystemen (Eventim Inhouse und Bilettix) sowie der Dispositionssoftware Theasoft haben wir inzwischen für die Theater realisiert und pflegen mit beiden Häusern eine intensive Zusammenarbeit bei der Weiterentwicklung der Onlineangebote. Das schöne am Bacchus-Bundle ist, dass diese Weiterentwicklungen allen zu Gute kommen.

Kaffee-Sponsoring auf Konferenzen

Die Projektlage Anfang 2017 war somit sehr erfreulich – leider verließen uns im ersten Halbjahr drei Mitarbeiter, und das, nachdem bereits im Sommer 2016 ein Entwickler aus Bonn weggezogen war und daher den Arbeitgeber wechseln musste (es war vor Corona und 100% remote arbeiten war damals bei der webfactory noch unvorstellbar). Vor diesem Hintergrund entschieden wir, dass unsere gerade neu angeworbene Kollegin Eva, die ihre Promotion in Biologie zu Gunsten der webfactory aufgegeben hatte, erst einmal intensiv um neue Mitarbeiter werben sollte. Ihr erstes Projekt war die Organisation eines Kaffeestandes auf der FrOSCon 2017, einer renommierten Open Source-Software-Konferenz in Sankt Augustin bei Bonn. Hierfür arbeiteten wir mit Ruth Außenhofer zusammen, die einen exzellenten Baristaservice betreibt. Und natürlich musste es stilvoll zugehen, daher ließen wir in Italien Cappuccinotassen mit webfactory- und FrOSCon-Logo produzieren.

Da die Zusammenarbeit uns sehr viel Spaß gemacht hatte, entschieden wir uns, im Frühjahr 2018 einen Schritt weiterzugehen und auch den Kaffeestand auf der Symfony Live zu übernehmen, die damals im Phantasialand stattfand, einem großen Freizeitpark zwischen Bonn und Köln. Leider fand die Symfony Live danach nicht mehr im Rheinland statt sondern zog nach Berlin – für uns ein Grund abzuspringen, denn der Organisationsaufwand war ohnehin eigentlich zu hoch für eine kleine Firma wie uns, und auch Ruth wäre mit ihrer Kaffeemaschine vermutlich nicht nach Berlin gereist.

Citylight-Werbung um neue Mitarbeiter

Für die Mitarbeitergewinnung hat sich ein anderes Instrument besser bewährt: Anfang 2018 schalteten wir sogenannte Citylight-Poster an Bonner Bus- und Bahnhaltestellen. Unter anderem am Uni-Hauptgebäude, am Bonner Hauptbahnhof und am Konrad-Adenauer-Platz in Beuel. Und siehe da: Das Plakat in Beuel war der letzte Schubs, den ein Mitschüler unseres ehemaligen Auszubildenden Benjamin brauchte, um sich endlich bei uns zu bewerben. Wenige Wochen später durften wir Martin als neuen Softwareentwickler im Team begrüßen.

Ganz ohne Werbung, sondern durch reines Vitamin B, kamen zwei andere geschätzte Kollegen zu uns ins Team: Ich hatte zum 100-jährigen Jubiläum meiner früheren Schule, des Bonner Clara-Schumann-Gymnasiums, angefangen, im Schulchor mitzusingen. Dort sang ich mit Jano zusammen im Tenor. Und in der Mittagspause eines Probenwochenendes kamen wir darauf zu sprechen, dass er plante, Informatik zu studieren und schon jede Menge Erfahrung mit PHP und Linux hatte. Ich erzählte natürlich, dass ich in einer Webagentur arbeite, die auf PHP spezialisiert ist, und wir händeringend neue Kollegen suchen. Es dauerte nicht lange, bis Jano als Werksstudent bei uns anfing und sich schließlich sogar entschied, sein Studium aufzugeben zugunsten einer Ausbildung bei uns.

Lukas hingegen erwähnte gegenüber dem Freund seines Vaters, dass er sich für Gestaltung interessierte – und der Freund seines Vaters war ein guter Freund unseres Teammitglieds Stefan. So kam es dazu, dass Lukas nach der Schule ein Praktikum bei uns machte (mehr dazu im seinem spannenden Praktikumsbericht) und sich schließlich entschied, eine Ausbildung zum Mediengestalter bei uns zu absolvieren. Dafür nahm er nach reiflicher Überlegung sogar eine Fernbeziehung in Kauf. Glücklicherweise hat die Beziehung die räumliche Trennung gut überstanden und Lukas lebt inzwischen dank Homeoffice wieder mit seiner Freundin zusammen im Sauerland.

Das neue webfactory-Büro

Da auch Søren inzwischen zur webfactory zurückgekehrt war, war uns unser Büro nun langsam zu klein. Und auch hier half uns das Schicksal, unsere Trägheit zu überwinden: Das Haus in der Lessingstraße 60 wurde an einen neuen Eigentümer verkauft, der nicht nur sehr genaue Vorstellungen mitbrachte, was wir in unseren Kellerräumen lagern dürften und was nicht, sondern kurze Zeit später auch unsere Miete drastisch erhöhen wollte. Daher begannen wir, uns auf Immobilienbörsen nach anderen Mietobjekten in der Nähe umzuschauen – und wurden in der Heinrich-von-Kleist-Straße fündig. Das neue Büro, lustigerweise direkt neben meinem früheren Kindergarten gelegen, war gerade frisch saniert und schlug Matthias und mich direkt bei der ersten Besichtigung in seinen Bann. Es war mit 220qm fast doppelt so groß wie das alte Büro und sollte somit genug Platz für die weitere Entwicklung bieten.

Kurzerhand  unterschrieben wir den Mietvertrag, aktivierten unsere Lieblingshandwerker Mark Hesterbrink und Michael Schuh, damit sie möglichst viele Möbel sowie die lieb gewonnene Beleuchtung aus dem alten ins neue Büro transferieren konnten, und zogen im September 2019 um.

Ab nach Hause!

Der Umzug war gerade rechtzeitig abgeschlossen, um uns noch einige Monate im neuen Büro zu lassen, bevor es im März 2020 hieß: Ab nach Hause! Die Corona-Infektionszahlen gingen gerade durch die Decke und die Bundesregierung rief dazu auf, soweit irgend möglich im Homeoffice zu arbeiten. Wir fanden uns zu einer Teambesprechung zusammen, entschieden, dass wir das möglich machen wollten, und meldeten am 10. März via Twitter:

Wir haben entschieden, Verantwortung zu übernehmen und ab heute geschlossen im Home Office zu bleiben. Die COVID-19 Gefahr für jeden Einzelnen von uns ist gering aber jeder kann dafür Sorge tragen, nicht zum Spreader zu werden: Für unsere (älteren) Mitbürger, Freunde, Familien!

Nach einer kurzen Umgewöhnung stellten wir fest, dass wir im Homeoffice als Team extrem produktiv sein können, und fanden in Form von täglichen Google Meet-Videokonferenzen auch einen guten Weg, intensiven Kontakt zu halten. Eine Nebenwirkung: Alle Kunden hatten plötzlich auch Videokonferenz-Ausrüstung, sodass wir uns so oft sehen konnten wie nie zuvor. Telefonkonferenzen gehören seitdem der Vergangenheit an – warum auch telefonieren, wenn man sich stattdessen per Video in die Augen sehen kann?

Erfahrungen mit Arbeitskräftemigration

Da wir nun schon seit Jahren personelle Verstärkung suchten, entschieden wir uns Anfang 2020 für ein besonderes Experiment: Über private Beziehungen hatten wir Kontakt zu Amitay, einem kubanischen Informatiker, der in Mexiko arbeitete und Interesse hatte, nach Deutschland zu kommen. Auch wenn er kein Deutsch sprach und keine Erfahrungen mit unserem Technologie-Stack hatte, entschieden wir uns, ihn anzusprechen. Was man nicht kann, kann man lernen, dachten wir – und Amitay war Feuer und Flamme, es auszuprobieren.

Nun stand zunächst ein intensiver Meinungsbildungsprozess in der webfactory an. Schließlich hatten wir noch nie jemanden im Team gehabt, der kein Deutsch sprach, und es gab unterschiedliche Meinungen dazu, wie gut unsere Teammeetings unter diesen Voraussetzungen funktionieren würden. Wir entschieden uns, es zu versuchen. Bezüglich der Sprache überlegten wir uns die Regelung, dass wir die ersten 8 Wochen ausschließlich Englisch sprechen würden und dann Woche für Woche ein Teammitglied auf Deutsch wechseln würde, sodass nach einigen Monaten wieder jeder in seiner Sprache sprechen könnte und Amitay, dem wir parallel Deutschkurse finanzierten, einen weichen Übergang haben würde. Fachliche Besprechungen in Projekten würden wir natürlich weiterhin auf Englisch machen und in anderen Besprechungen bei Bedarf übersetzen.

Wir lernten, dass es im Prinzip dank des "Blue Card"-Programms der EU nicht schwer ist, für Arbeitskräfte ein Visum für die Einreise nach Deutschland zu bekommen. Es gab noch ein paar kleinere Stolpersteine auf dem Weg, aber trotz der Reisebeschränkungen und eingeschränkter Öffnungszeiten der Botschaften mitten im ersten Corona-Jahr konnten wir Amitay im Januar 2021 am Flughafen Frankfurt in Empfang nehmen.

Leider ist er inzwischen nicht mehr in unserem Team, sondern hat sich entschieden, zu einer anderen Bonner Firma zu wechseln, in der er wieder in seiner gewohnten Programmierumgebung (C#/.net) entwickeln kann. Aus meiner Sicht haben wir die Sprachbarriere gut gemeistert, auch wenn ich es als überraschend schwierig empfunden habe, Software-Entwurfsfragen auf Englisch zu diskutieren – und das, obwohl wir uns täglich auch mit Kunden auf Englisch abstimmen. Auch die technische Einarbeitung in PHP und Symfony hat gut funktioniert. Trotzdem habe ich das Gefühl, dass das zu viel Fremdheit auf einmal war. Ein fremdes Land und eine fremde Sprache sind schon eine ganz schön große Umgewöhnung, man sollte das vielleicht nicht auch noch mit einem fachlichen Sprung ins kalte Wasser verbinden.

Open Source Software veröffentlichen zahlt sich aus

2012 hatten wir im Rahmen unserer Bemühungen, für alle unsere Bestandskunden eine Weiterentwicklung ihrer Produkte auf Basis von Symfony zu ermöglichen, das Legacy Integration Bundle als Open Source-Software veröffentlicht (mehr dazu auf der Leistungsseite "Langlebige Softwareprodukte"). 8 Jahre später erhielten wir eine Bewerbung eines begeisterten Nutzers. Fabian plante seinen Umzug nach Bonn und war fest entschlossen: "Wenn ich mal in Bonn arbeite, möchte ich zur webfactory". Er hatte das Legacy Integration Bundle bei seinem früheren Arbeitgeber kennengelernt und offenbar einen guten Eindruck von uns gewonnen.

Gut war auch unser Eindruck von Fabian und so zögerten wir nicht lange, ihn ins Team aufzunehmen.

Kinder in der webfactory

Stand heute sind 5 Kinder von webfactory-Kollegen zur Welt gekommen: Felix, Florentine, Lasse, Timo und Aino. Wir freuen uns sehr, sie im erweiterten Team zu haben. Dank dieser Kinder haben wir jede Menge Arbeitszeitmodelle ausprobiert: Mein Geschäftsführer-Kollege Matthias teilte sich die Elternzeit zu gleichen Anteilen mit seiner Frau und reduzierte seine Wochenarbeitszeit für mehrere Jahre auf 50%. Ich selbst nahm mir einen Tag pro Woche frei und kam auf 80%. Stefan übernahm den größeren Anteil der Betreuung seiner Tochter und reduzierte auf 40%. All das ließ sich gut einrichten und ich freue mich, dass wir so viel Zeit mit unseren Kindern verbringen konnten.

Schade nur, dass wir noch keine Frauen mit Kindern im Team haben. Aber was nicht ist, kann ja vielleicht noch werden!

Weitere Kunden

Abschließend möchte ich noch einige Kunden erwähnen, die bisher keinen Platz in diesem geschichtlichen Abriss hatten, aber trotzdem zu wichtig sind, um den Artikel schon an dieser Stelle zu beenden.

Zum einen ist da die Agentur Euro-Informationen, für die wir seit dem Jahr 2000 verschiedene Websites entwickelt haben, die teilweise durch Fördermittel, teilweise durch Werbung oder Provisionen finanziert wurden. Die größte davon ist www.krankenkassen.de. Eine Website, die über 10 Jahre lang aus technischer Perspektive einfach nur vor sich hin funktionierte und Anzeigenerlöse generierte, bis wir einen Online-Wechselservice umsetzten. Seitdem kann man über die Website die Krankenkasse wechseln und die Abhängigkeit von Werbeerlösen ist weggefallen. Der Wechselservice ist so erfolgreich, dass er inzwischen um API-Schnittstellen zu großen Krankenkassen erweitert wurde, über die die Wechselanträge direkt ins IT-System der Krankenkasse übertragen werden, sowie um eine Lösung, mit der man die Anträge direkt online unterschreiben kann.

Dann wäre da noch der Deutsch-Südafrikanische Reisedienst (DSAR), ein kleiner Bonner Reiseveranstalter, der uns im Frühjahr 2017 kontaktierte. Die Firma war ausgelastet und die Kunden zufrieden mit dem Webangebot, aber der Inhaber wollte die Website technisch und gestalterisch modernisieren und das umfangreiche Wissen der Firma über das südliche Afrika ins Netz bringen. In der Anfrage hieß es:

Meine Idealvorstellung ist eine contentbasierende Plattform, in der wir all das Wissen erfassen können, welches wir über unser Zielgebiet (das südliche Afrika) haben. Also keine Infohäppchen, sondern eher eine wie ein Wiki vernetzte Struktur, in der der potentielle Kunde sich fundiert über Individualreisen durch das südliche Afrika informieren kann. Trotzdem soll es optisch inspirieren und muss am Ende natürlich einen Teil der Besucher davon überzeugen, eine Reise bei uns zu buchen.

Im Grunde nicht anders als in der Open Source Entwicklung: Ich präsentiere unser Wissen um das Zielgebiet (also den Source Code) und verdiene an den Kunden, die keine Zeit haben, sich die Reise selber zusammen zu stellen. Zumal wir mehr Erfahrung und die besseren Tools haben.

Diese Philosophie war uns natürlich ausgesprochen sympathisch. Spannend war auch, dass der DSAR bereits eine ganze Reihe an internen Softwaretools entwickelt hatte, darunter einen Reiseplaner, in dem alle Unterkunftsdaten hinterlegt waren und über den individuelle Reiseverläufe visualisiert werden können. Die Touren aus diesem System kann der DSAR nun über eine Schnittstelle direkt auf der Website veröffentlichen und sie werden dort in einem Zeitstrahl präsentiert (ein Beispiel: die zweiwöchige Namibia-Rundreise). Da wir 2017 beim besten Willen keine Zeit hatten, haben wir den DSAR gebeten zu warten. Und im Januar 2018 konnte es dann endlich losgehen. Der DSAR ist insofern besonders, als er einer unserer wenigen Kunden ist, die über ihre Website tatsächlich unmittelbar Geld verdienen müssen – und das als Kleinunternehmen, für das ein ein solches Projekt eine beachtliche Investition ist. Und er ist auch besonders dadurch, dass er als Reiseveranstalter durch Corona massiv betroffen war und das komplette Geschäft pausieren musste. Glücklicherweise hat der DSAR die Pandemie gut überstanden und freut sich, jetzt wieder Reisegäste nach Afrika bringen zu können. Last but not least: der DSAR ist der erste Kunde, dem wir Zugriff auf sein GitHub-Repository gegeben haben (mehr zum Hintergrund auf der Seite "Offene und vertrauensvolle Zusammenarbeit"). Ursprünglich vor allem, damit der technisch bewanderte Kunde die im Code hinterlegten logischen Regeln selbst einsehen und über den Pull-Request-Mechanismus von GitHub Änderungen vorschlagen konnte, doch diese Art der Zusammenarbeit hat sich so gut angefühlt, dass wir sie inzwischen allen Kunden nahelegen.

Schließlich gibt es da unter unseren Kunden noch die Nationale Leitstelle Ladeinfrastruktur. Sie übernimmt im Auftrag der Bundesregierung die wissenschaftliche Begleitforschung für den Ausbau der Ladeinfrastruktur für Elektro-Autos. Das Forscherteam hatte uns gefunden über eine Suche nach den Stichworten "Agil" und "Symfony" und sich bereits auf unserer Website informiert. Als dann die Anfrage kam, waren wir natürlich direkt auf einer Wellenlänge. Und das Projekt brauchte auch tatsächlich einen sehr agilen Prozess: Es musste eine komplett neue Software entwickelt werden und der Projektzeitraum war auf knapp 6 Monate begrenzt. Auch die Aufgabenstellung war spannend: Die Forschungsarbeit sollte unter anderem auf der Auswertung der Ladedaten an einer großen Zahl von Ladestationen unterschiedlichster Betreiber basieren. Die Betreiber erhielten staatliche Förderung für den Aufbau der Ladestationen und waren im Gegenzug verpflichtet, jedes halbe Jahr die Ladedaten zu übermitteln. In der ersten Runde war das per Mail erfolgt, die Leitstelle hatte also hunderte Excel-Dateien mit teilweise unterschiedlichen Strukturen erhalten, die sich nur mit enormem personellen Aufwand zusammenführen ließen. Die Aufgabe bestand nun darin, einen Online-Prozess für den Upload der Excel-Dateien umzusetzen und die Daten dabei in eine Datenbank zu übernehmen, auf deren Basis die Forschung stattfinden konnte. Zusätzlich werden für jede Ladestation auch noch über 60 Stammdaten erhoben (zum Beispiel, wie der Stellplatz markiert ist und welche Bezahlverfahren unterstützt werden). Ein Projekt genau nach unserem Geschmack, und eine extrem fokussierte und konstruktive Zusammenarbeit. Einen Namen für das System dachte sich mein Kollege Matthias aus: OBELIS, kurzform für Online-Berichterstattung Ladeinfrastruktur (inzwischen als OBELIS öffentlich Teil einer Familie von Angeboten). Zum Abschluss des Projekts gab es eine große Überraschung: Eine OBELIS-Torte für die webfactory!

Die webfactory ist ein kundenorientiertes Unternehmen, und ein mitarbeiterorientiertes Unternehmen obendrein. Oder andersherum? Mitarbeiter- und Kundenorientierung ist uns gleichermaßen wichtig. Ich glaube, wenn man den Begriff menschenorientiert verwendet, trifft das die Sache ganz gut. Für mich bedeutet es, dass wir sowohl unseren Mitarbeitern als auch unseren Kunden jeden Wunsch erfüllen – solange es sich möglich machen lässt, ohne jemanden zu beeinträchtigen.

Ein Beispiel: Anfang 2020 haben wir in unserer Mitarbeiterzufriedenheitsumfrage herausgefunden, dass unsere Arbeitszeiten nicht für jeden im Team gut mit seinem persönlichen Biorhythmus vereinbar sind. Eigentlich hatten wir bereits volle Flexibilität bei der Arbeitszeit – nur dummerweise ein freiwilliges tägliches Standup-Meeting um 9:45 Uhr. Die Eulen unter uns stellte das aber vor die Wahl, entweder ihre Kollegen nicht regelmäßig zu sehen oder zu einer Zeit mit der Arbeit zu beginnen, zu der sie am liebsten schlafen würden. Was aber hat eine Firma für einen Vorteil davon, wenn ihre Mitarbeiter zu Zeiten arbeiten, zu denen sie nicht ihre optimale Leistung bringen können? In einem internen Projekt haben wir dann einen neuen Besprechungsrhythmus erarbeitet, evaluiert und umgesetzt. Unsere morgendlichen Standups sind einem Daily Café zur Mittagszeit gewichen. Da ist jeder wach. Und Kundentermine hatten wir zu dieser Zeit ohnehin selten.

Ein weiteres Beispiel: Am 10. November 2022 (einen Tag vor Beginn der Karnevalssaison hier im Rheinland) hatten wir ein erstes Gespräch mit unserem Kunden über eine Website für neue Fördermöglichkeiten der EU. Die erste Antragsfrist für den Erhalt der Förderung stand fest, es war der 23. Februar 2023. Damit die potenziellen Antragsteller sich vorher noch über das Programm informieren konnten, war es für unseren Kunden wichtig, die Website möglichst schon im Januar zu veröffentlichen. Es blieben also ungefähr 8 Wochen Zeit. Das Design sollte von der Corporate Design-Agentur des Kunden beigesteuert werden. Allerdings hatte die noch gar nicht mit der Arbeit begonnen. Dank der eingespielten Zusammenarbeit mit unserem Kunden und seiner Designagentur ist es gelungen, die Website www.erasmusplus-sport.de pünktlich am 17.01.2023 zu launchen – und das trotz Krankheiten und ohne, dass einer von uns die traditionell freie Zeit zwischen Weihnachten und Neujahr opfern musste. Unser Kunde schreibt:

[...] danke für die großartige Umsetzung des Designs ins Web. Danke fürs Einrichten des Backends mit all den damit verbundenen Neuerungen im CMS. Danke für den Kampf mit diversen Endgegnern (z.B. Hero-Gestaltung [...]) und vor allem Dank dafür, dass ihr kein einziges Mal gesagt habt: „Das geht zeitlich nicht.“ (Also, ich hätte es verstanden…) ;-)

Soziokratische Entscheidungen

Fast alles, was die webfactory betrifft, entscheidet bei uns das Team gemeinsam – von Arbeitszeiten und Besprechungsterminen über die Einrichtung der Büroräume bis hin zum Gehaltsmodell. Dass wir dafür nicht wochenlange basisdemokratische Diskussionen führen müssen, ermöglicht uns ein ausgeklügelter Entscheidungsprozess: Beim soziokratischen Konsent wird über eine Entscheidungsvorlage in einem strukturierten Prozess beraten und jede Meinung wird gehört. Wenn es Einwände gibt, versuchen wir, einen verbesserten Vorschlag zu entwickeln. Die Entscheidungsvorlage ist angenommen, sobald es keinen schwerwiegenden Einwand gibt. Vorteil davon: Jeder im Team hat de facto ein Vetorecht und nichts kann über seinen Kopf hinweg entschieden werden. Es muss aber auch keine demokratische Mehrheit gefunden werden, sondern das Design des Prozesses ist "fortschrittsorientiert".

Anschaffungen? Fortbildungen? Entscheide selbst!

Nicht alles braucht einen Teamentscheid. Über Anschaffungen entscheidet grundsätzlich jedes Teammitglied eigenverantwortlich, ebenso über den Besuch von Fortbildungen. Hierbei gibt es kein Budgetlimit. Warum? Weil es keinen Vorteil hat, teure Arbeitszeit der Geschäftsführung oder gar des gesamten Teams dafür zu verwenden, zu entscheiden, ob A sich einen neuen Bürostuhl anschaffen darf (und welches der beste wäre) oder B einen neuen Kopfhörer. Wir sparen also jede Menge Zeit und mentale Energie und ermöglichen gleichzeitig jedem und jeder, mit den Tools zu arbeiten, die sie für sich am besten finden. Übrigens hat noch niemand diese weitreichende Teamermächtigung ausgenutzt und sich z. B. einen Porsche auf Firmenkosten angeschafft. Oder ein Alpaka.

Pull-Prinzip für die Aufgabenverteilung

Bei uns gibt es niemanden, der anderen Aufgaben zuweist. Stattdessen machen wir, hauptsächlich über ein sogenanntes Kanban-Board, für alle transparent, welche Aufgaben zu erledigen sind. Jeder zieht sich dann nach Fertigstellung einer Aufgabe eine neue Aufgabe aus der Warteschlange.

Dieses Prinzip unterstützt aus meiner Sicht eine Zusammenarbeit auf Augenhöhe, denn es gibt nicht mehr denjenigen, der Aufgaben verteilt, und denjenigen, der Aufgaben empfängt. Es verhindert auch, dass einzelne Mitarbeiter überlastet werden, weil sie mit zu vielen Aufgaben betraut werden. Durch die hohe Transparenz verhindert es zugleich, dass Aufgaben "verhungern", also nicht erledigt werden. Und natürlich verhindert es auch, dass Mitarbeiter nichts zu tun haben, weil niemand ihnen Aufgaben zuweist.

Ergänzend zum Pull-Prinzip beraten wir bei größeren Projekten, die für einige Zeit mehrere dezidierte Kollegen brauchen, im Team, wer dieses Projekt am besten übernehmen kann und möchte.

Urlaub? Sag' einfach Bescheid

Schon viel länger als die oben erwähnte Ermächtigung für Kaufentscheidungen gibt es bei uns die Freiheit, Urlaub zu nehmen, wann man möchte. Der Urlaubsprozess ist einfach: Überlege, wann du Urlaub machen willst, welche Dinge dem entgegenstehen könnten (z. B. ob du schon die Fertigstellung eines Projekts zugesagt hast, dessen Launchtermin mitten im Urlaubszeitraum liegt) und schreib dann eine Mail ans Team, von wann bis wann du weg bist.

Diesen Prozess haben wir schon seit Jahrzehnten und er hat noch nie zu Problemen geführt. Schließlich sind wir ein Team von 10 Kollegen, (fast) jeder kann (fast) jedes Projekt betreuen und an Tagen, wo drei Viertel des webfactory-Teams freinehmen, gibt es in der Regel auch nicht viele Kundenanfragen.

Qualität

Ein großer Aspekt unserer Unternehmenskultur ist der Qualitätsanspruch. Wir reden immer eher mit unseren Kunden über höhere Budgets oder das Weglassen weniger wichtiger Features, als aus Budget- oder Termingründen qualitativ schwache Lösungen zu akzeptieren. Das zahlt sich nicht nur für das Produkt aus (siehe "Langlebige Softwareprodukte"), sondern es ist auch ein wichtiges Signal an das gesamte Team: Jeder wird darin bestärkt, sein Bestes zu geben. Und wenn man interne Tools, unsere Open Source-Pakete oder die Dokumentation in unserem Wiki verbessert, gibt es dafür Lob von den Kollegen.

Aus Fehlern wird man klug

Wir reden offen über Fehler und Probleme. Niemand wird für Fehler angegriffen oder zurechtgewiesen. Schließlich ist es am besten, wenn nicht nur man selbst aus seinen eigenen Fehlern lernen kann, sondern direkt das ganze Team. Meist hat dann auch noch jemand eine Idee, was man verändern könnte, um diese Art von Fehler für die Zukunft unwahrscheinlicher zu machen.

Wertschätzende und gewaltfreie Kommunikation

Dumme Fragen gibt es bei uns nicht. Jeder hat andere Stärken und jeder steht auch irgendwann mal auf dem Schlauch. Wir helfen uns gegenseitig und gehen immer davon aus, dass der andere das Beste wollte. Das hilft uns, uns nicht mit internen Spannungen aufzuhalten, sondern uns ganz auf unser gemeinsames Ziel zu konzentrieren: Die besten Softwareprodukte zu entwickeln und dabei jeden Tag Freude an der Arbeit zu haben.

Flexible Arbeitszeiten und -umfänge

Jede und jeder arbeitet, wann es für sie oder ihn am besten passt. Wir haben keine Regeln, die das einschränken, stattdessen haben wir Prozesse, die asynchron, also ohne gleichzeitige Anwesenheit funktionieren. Dazu gehören z. B. ein Teamchat und die Kommunikation über GitHub Pull Requests. Wir haben auch intensiv daran gearbeitet, mit unseren Kunden andere Kontaktwege als Telefonanrufe zu etablieren – zum Beispiel, in dem wir versprechen, dass E-Mails genau so schnell und zuverlässig bearbeitet werden wie Anrufe. Da nun nicht mehr die Erwartung besteht, einen bestimmten Ansprechpartner in einem bestimmten Zeitfenster telefonisch erreichen zu können, sind wir mit der Arbeitszeit sehr flexibel. Und die Tatsache, dass die Kolleg:innen diese Flexibilität auch nutzen, führt sogar dazu, dass die Erreichbarkeit sich auf Unternehmensebene verbessert hat: Denn auch eine E-Mail, die am Wochenende oder spät Abends eingeht, bekommt so gelegentlich noch eine schnelle Antwort.

Generell sind unsere Arbeitszeiten meist noch klassisch auf Montag bis Freitag gleichverteilt, es gab aber auch schon persönliche Experimente mit einem "Weekend Wednesday", also dem Tausch von Mittwoch gegen Samstag.

Die Flexibilität gilt auch für die gewünschte Wochenarbeitszeit: Jeder Mitarbeiter kann über diese frei entscheiden. Wir hatten in der Vergangenheit Kollegen, die Elternzeit genommen und dafür auf 2 Tage pro Woche reduziert haben, ebenso wie Musiker, die gerne eine 3-Tage-Woche arbeiten wollten. Unsere Geschäftsführer arbeiten übrigens in Teilzeit mit 80% bzw. 90%.

Remote First

Wir waren immer der Ansicht, dass wir vor Ort am besten zusammenarbeiten können und Homeoffice auf einen Tag pro Woche beschränkt bleiben sollte. Dann kam Corona und wir haben uns angepasst. Seit März 2020 arbeitet unser Team fast vollständig von zu Hause aus, und die Zusammenarbeit läuft besser denn je. Unser schönes, gerade 2019 frisch bezogenes Büro steht trotzdem zur Verfügung – für alle, die einen Tapetenwechsel zwischen Wohnen und Arbeiten bevorzugen.

Unsere Prozesse sind aber seit Corona "Remote First", das bedeutet für uns, dass wir Kollegen, die nicht vor Ort im Büro sind, keinesfalls benachteiligen wollen. Daher finden zum Beispiel alle Teammeetings als Videokonferenz statt, egal wie viele Kollegen im Büro sind.

Damit ermöglichen wir auch ganz neue Arbeitsmodelle: 2022 hat zum Beispiel der erste Kollege sein Büro spontan für zwei Wochen in ein Ferienhaus in Griechenland mit Blick aufs Meer verlegt.

30-Stunden-Woche

Wir haben lange über dieses Thema nachgedacht. Es gibt verschiedene Studien, die nahelegen, dass der Mensch nicht in der Lage ist, mehr als 6 Stunden am Tag konzentriert zu arbeiten (eher sogar deutlich weniger). Und dennoch fühlte es sich radikal an, die logische Konsequenz daraus zu ziehen und die tägliche Arbeitszeit auf 6 Stunden zu reduzieren. Verliert man da nicht möglicherweise 25% der Arbeitsleistung? Der Umzug ins Homeoffice während der Corona-Pandemie hat dann den entscheidenden Impuls gegeben, denn plötzlich verlor die Unterscheidung zwischen Anwesenheitszeit und dokumentierter Arbeitszeit ihren Sinn. Wir hatten vorher die Regel, dass man beim Kommen und Gehen seine Arbeits- und Pausenzeit erfasst und dass man einen möglichst hohen Anteil der Anwesenheitszeit, mindestens aber 70%, auf konkrete Tätigkeiten nachweist. Nur diese nachgewiesene Arbeitszeit konnten wir Kunden in Rechnung stellen. Im eigenen Zuhause fühlte es sich aber sinnlos an, zu entscheiden, wann man "auf der Arbeit" ankommt und wann man geht. Nachdem wir das ein gutes Dreivierteljahr gemacht hatten und es uns allen auf die Nerven gegangen war, haben wir entschieden, die Erfassung der Anwesenheitszeit abzuschaffen und die Quote der nachzuweisenden Arbeitszeit auf 75% zu erhöhen. Und plötzlich hatten wir unsere 30-Stunden-Woche.

Man könnte das nun als Augenwischerei abtun – aber dagegen sprechen die Zahlen aus unserer Evaluation: ein Dreivierteljahr nach der Umstellung fühlten sich 80% der Mitarbeiter erholter als früher, 90% fühlten sich produktiver, ebenfalls 90% bejahten die Frage, ob es sich auch tatsächlich so anfühlte, als ob sie weniger arbeiten als früher. Nur 10% (eine Person) hatte das Gefühl, dass es nach der Umstellung länger dauert, ein Projekt fertigzustellen. 80% des Teams bestätigten, nach Feierabend mehr Energie zu haben als früher – andererseits hatten nur 40% das Gefühl, wenn sie Feierabend machen, könnten sie häufig auch noch produktiv weiterarbeiten. Und unter dem Strich waren 90% sehr zufrieden mit der reduzierten Arbeitszeit (Bewertung von 5 oder 6 auf einer Skala von 0-6).

Und mit nunmehr 2 Jahren Erfahrung kann ich auch aus Geschäftsführer-Sicht sagen, dass das Modell ein voller Erfolg ist. Sowohl die Qualität unserer Produkte und der Zusammenarbeit mit unseren Kunden als auch das Klima im Team haben sich in dieser Zeit aus meiner Sicht hervorragend entwickelt.

Gehaltstransparenz

Seit 2017 sind alle unsere Gehälter im Team transparent. Das ist für uns schon so selbstverständlich, dass ich fast vergessen hätte, es zu erwähnen – aber immerhin haben wir die ersten 20 Jahre unserer Firmenlebens die Gehälter vor dem Team "geheim gehalten" (und ich wage die Vermutung, dass das in den meisten Firmen auch heute noch so gehandhabt wird).

Die Gehaltstransparenz hat zunächst einmal dazu geführt, dass unsere Gehaltsverteilung als fairer wahrgenommen wurde. Die Unterschiede waren offensichtlich deutlich geringer, als einige im Team gedacht hatten. Sie hat außerdem ermöglicht, dass wir im Team über die Gehaltshöhe reden und darüber, wovon das Gehalt abhängen sollte. Als nächsten Schritt nach der Veröffentlichung der Gehälter haben wir Anfang 2018 ein Gehaltsmodell und einen Gehaltserhöhungsprozess entwickelt.

Automatische Gehaltserhöhungen

Im Laufe der Jahre hat sich gezeigt, dass das Gehaltsmodell einige Schwachstellen hatte, insbesondere für sehr erfahrene Entwickler und langjährige Teammitglieder. Ende 2021 hat daher eine Arbeitsgruppe damit begonnen, ein neues Gehaltsmodell zu entwickeln. Ein Ziel der Arbeitsgruppe war, mit einem Mindestmaß an Einstufungs- und Bewertungsrunden auszukommen, denn diese haben sich als schwierig zu realisieren und häufig frustrierend herausgestellt.

Wir konnten uns bis heute noch nicht auf ein vollständiges neues Gehaltsmodell einigen, haben aber zum 1.1.2023 das alte Modell abgeschafft und jährliche automatische Gehaltserhöhungen für alle eingeführt, deren Höhe es unseren jüngsten Kollegen in Aussicht stellt, im Laufe ihrer Karriere auf das Niveu ihrer heutigen erfahrensten Kollegen zu kommen. Ich bin gespannt, wann wir hier im Blog unser fertiges neues Modell vorstellen können.

Was sonst noch war

• Einen Einblick in unsere Teamkultur gibt auch Eva in ihrem Artikel wfLeaks: Eine Mitarbeiterin packt aus!
• Bis 2020 hatten wir die Tradition, im Team reihum zu kochen und jeden Mittag gemeinsam zu essen. Und natürlich hatten wir ein ausgeklügeltes System, um Fairness beim Kochen zu garantieren. Der Artikel Wenn die Küchenglocke ruft ist eine Erinnerung.

Besonders freuen wir uns, wenn unsere Kunden uns berichten, wie zufrieden sie mit wfDynamic sind.

Hier nun das Feedback von Laura:

Wir nutzen wfDynamic für fünf Anwendungsfälle:

• Support der NutzerInnen unserer Online-Plattform für die Berichterstattung zu geförderten Ladesäulen (wir nennen es unsere „Wartungsklappe“)
• Versenden von Erinnerungs-Emails zur Berichterstattung an die NutzerInnen
• Export ausgewählter Felder unserer Datenbank per Knopfdruck als CSV-Dateien für unser Reporting
• Erweiterung von Auswahllisten für verschiedene Drop-Down-Felder unserer Online-Plattform
• Anpassung/Erweiterung der Regeln zur Verifizierung von zugelassenen Förderkennzeichen

Seit März 2019 nutzen wir wfDynamic mittlerweile schon und unser Fazit ist:

• guter Überblick: Durch wfDynamic können wir uns immer schnell einen Überblick verschaffen, was der aktuelle Stand bei der Berichterstattung ist (z.B. wie viele Accounts angelegt wurden, bei wie vielen NutzerInnen die Daten bereits vollständig eingetragen wurden etc.).
• Support leisten geht schnell und easy: Wenn eine Nutzer sich bei einem Problem mit seiner Berichterstattung bei uns meldet, können wir seine Angaben einsehen und somit schnell die Ursache seiner Schwierigkeiten identifizieren. Man kann auch notwendigen Anpassungen der Angaben (z.B. bei Feldern, die der Nutzer nach einmaliger Eingabe selbst nicht mehr anpassen kann) schnell und einfach vornehmen, ohne ein SQL- oder Datenbank-Profi sein zu müssen.
• effizienter und flexibler E-Mail-Versand: Für die E-Mails, die wir regelmäßig an die NutzerInnen versenden, können wir die Vorlagen und Verteiler immer wieder nutzen, aber auch flexibel anpassen. Man kann den E-Mail-Entwurf auch direkt in wfDynamic zwischenspeichern, falls er im Team noch abgestimmt werden soll.

Uns erleichtert wfDynamic tagtäglich die Arbeit, da die Funktionalitäten genau unseren Anforderungen entsprechen. Das Interface ist auch sehr übersichtlich und leicht in der Handhabe. Daher klare Empfehlung an alle Administratoren von Datenbanken!"

In diesem Zuge wollen wir uns nochmal für das Vertrauen und die nette Zusammenarbeit bedanken!

Assume we have a macro that simplifies some output task. For the sake of simplicity, let‘s have it print a simple list.

{% macro list(items) %}
<ul>
  {% for item in items %}
    <li>{{ item }}</li>
  {% endfor %}
</ul>
{% endmacro %}

This macro might be used to show a list with a book‘s title and author in the admin backend of an online book shop.

{{ _self.list([book.title, book.author])}}

So far, everything is fine.

Thanks to Twig‘s autoescape feature, this code is protected from XSS attacks: Even when an attacker can supply arbitrary values for book.title or book.author , Twig will make sure the htmlspecialchars() function is applied to make the values safe for use in HTML.

You can try the example in a Twig fiddle.

Adding HTML with Good Intentions™

Now, assume we‘re tasked to make the author‘s name editable. We add functionality somewhere to do that, and we‘d like to allow the user to jump to that edit from right from our list.

We might change the macro invocation to look like this:

{{ _self.list([
    book.title,
    book.author ~ '<a href="#">edit</a>'
])}}

We give it a shot by reloading the page in the browser, or by looking at the updated fiddle.

We immediately recognize our mistake, since the <a href="#">...</a> link is printed as-is in the page. Right, that autoescape feature! What do we need to do?

Let‘s update our macro, since we know we want to include HTML in the output.

{% macro list(items) %}
<ul>
  {% for item in items %}
    {# Use |raw for HTML passthrough #}
    <li>{{ item | raw }}</li>
  {% endfor %}
</ul>
{% endmacro %}

Another quick refresh (fiddle) shows us that now it‘s working as expected. Let‘s commit and we‘re done.

What just happened

By applying the |raw filter in our macro, we have declared that whatever value the item variable contains, it is safe to use as-is in the current context. It will turn off Twig‘s autoescaping at the point where the list items are printed.

We have shifted responsibility for proper escaping from Twig to the developer using our macro. And that not only affects the item where we add the HTML link, which might be fixed like so:

{{ _self.list([
    book.title,
    book.author|e ~ '<a href="#">edit</a>'
])}}

Note I‘ve added |e , the shorthand for the escape filter, to do HTML escaping before concatenating the author name with the HTML markup.

This, of course, falls short, since we need not only escape the book.author item, but also book.title .

Even worse, when our macro is a re-used component being called from various places, we‘d need to have this escaping applied to all inputs supplied to the macro, which might be a lot of work to find and update.

You probably would take a step back and find some other way to solve your current task without doing such a change. Maybe you‘d just stop using the macro in the current situation and duplicate the code in this one spot. If… you are aware of it.

You ain‘t gonna notice (in time)

The challenge, in my opinion, is that you are likely not going to notice the problem you just created. It takes a lot of awareness to understand the subtle implications of the change.

This is may not only be an issue for less experienced developers or template designers. Imagine the template not being as simple as in the above example, but a bit more cluttered. For example, the list macro might need to also deal with array keys and blend in CSS classes (maybe taken from a second parameter) as well. That gives a lot of distraction also for more experienced Twig users and you might easily miss the important point.

Also, since Twig – and proably other template engines as well – do a great job at producing „safe“ output most of the time nowadays, when it comes to HTML and XSS we have become a bit more negligent or less well trained than some of us might have been a decade ago.

To make matters worse, nothing will point you to the problem in the short run. Whilst the initial HTML that you added showed up in the output and immediately reminded you of „fixing“ it, the XSS loophole is lurking in your template with no indications of a problem. The „lorem ipsum“ style data you will typically use during development and also during automated tests (functional or acceptance) is most likely not suited to find XSS exploits like this.

Here is a fiddle where an author attended a creative writing course and changed their name afterwards, to better illustrate the problem. Imagine an admin user of your online book shop visiting a page where the above macro is used: You‘re not seeing anything – no „funny looking“ author name. Yet, JavaScript is executed in the background in the context of your admin‘s session.

A more robust pattern

Here is another way how you could have written the previous change in Twig.

{% set author_with_link %}
    {{ book.author }} <a href="#">edit</a>
{% endset %}
{{ _self.list([book.title, author_with_link])}}

The interesting thing about this is that you can keep the list macro as-is, without adding |raw in it.

When Twig processes the {% set … %}...{% endset %} section, it will apply autoescaping as usual. The book.author value will have HTML escaping applied before being printed, and literal HTML markup in templates is safe by default.

Now, the author_with_link variable does not contain a simple string, but an instance of a special class in Twig. It will feel like a string for most purposes, so you can pass it around, concatenate it with other strings or pass it through filters.

As long as you use it unchanged, Twig will „remember“ that output escaping has been applied to this piece of HTML already. You can verify in this fiddle that in fact, the HTML link is printed as plain HTML, whereas HTML markup in the book.author data is escaped.

Conclusion

Be careful when you apply the |raw filter in Twig. It shifts the responsibilty for applying appropriate output encoding from Twig to you, the template developer.

When using |raw , especially in centralized places like includes or macros, make sure everyone passing in data is aware of their obligation to apply appropriate escaping. This may be a break in backwards compatibility for the include/macro.

Glitches in output escaping are likely to go unnoticed for a long time, since you don‘t typically test with the necessary inputs, unless doing security audits.

Doing string concatenation operations with HTML snippets in Twig may be a sign of danger. Even tough it may take a few more lines of code to write and variable names to come up with, writing markup in Twig and capturing it with {% set … %} may help you to stay on the safe side, especially when passing data along afterwards.

Wir haben die bei uns davon betroffenen Systeme inzwischen auf neue Softwarestände aktualisiert, mit denen das Problem gelöst ist. Die Aktualisierung erfolgte auf bekannte, saubere Systemzustände.

Anzeichen für ein tatsächliches Ausnutzen der Schwachstelle auf unseren Systemen liegen nicht vor. Allerdings hat unser Monitoring-System einige entsprechende "Scans" dokumentiert.

Sollten sich weitere für unsere Kunden relevante Informationen ergeben, werden wir diesen Blog-Eintrag aktualisieren.

Update 17.12.2021

Inzwischen ist eine weiteres Advisory unter der Nummer CVE-2021-45046 publiziert worden: Unter bestimmten Umständen und Konfigurationen waren die Korrekturen, die zur Beseitigung der 1. Schwachstelle veröffentlicht wurden, nicht ausreichend bzw. konnten erneut umgangen werden.

Unsere Systeme sind von dieser zweiten Lücke nicht betroffen.

Dieses Modell hatte sich über Jahre bewährt, trotzdem gab es das Bedürfnis nach Veränderung:

Zum einen hatte sich in unserer Mitarbeiter-Zufriedenheitsumfrage herausgestellt, dass die Besprechungstermine nicht für alle Kolleg:innen gut zu ihrem Biorhythmus passten. Besonders das Standup um 9:45 Uhr setzte einen Fixpunkt zum Beginn des Arbeitstages, der für einige früher lag, als sie eigentlich anfangen wollten. Die Kolleg:innen hatten also nur die Wahl, das Standup zu verpassen, oder für das Standup früher aufzustehen, als sie eigentlich wollten.

Zum anderen war die allgemeine Besprechung am Freitagnachmittag zunehmend unbeliebt. Genauer gesagt: Der Wochenrückblick mit Vorstellung der besonders erwähnenswerten abgeschlossenen Aufgaben ("Spotlights in der Done-Spalte") funktionierte gut, aber für die ausgiebige Besprechung weiterer Themen war es den Frühaufstehern im Team dann schon zu spät; die Besprechungszeit lag zudem unmittelbar vor dem Wochenende – was dazu führte, dass Elan und Energie für komplizierte Themen häufig nicht mehr ausreichten.

Als ersten Schritt zu einem neuen Meeting-Zeitplan haben wir eine Teamumfrage gemacht. Jeder war eingeladen, seinen persönlichen Chronotyp zu bestimmen und anschließend anzugeben, wie viel Schlaf er braucht, wann er aufstehen und ins Bett gehen möchte, wann er sich am produktivsten fühlt und in welche Stunden des Tages er am liebsten seine Arbeitszeit legen würde. Ergebnis: Einige wollten sehr früh anfangen und früh aufhören zu arbeiten, andere am liebsten erst um 12 Uhr Mittags anfangen und bis in den Abend arbeiten.

Der Zeitpunkt 12 Uhr lag bei fünf Kollegen innerhalb der gewünschten Arbeitszeit und bei den restlichen fünf sehr nah dran. Zugleich war er bei den wenigsten mitten in einem produktiven Zeitfenster; bei einigen war es der gewünschte Arbeitsbeginn und bei anderen lag er kurz vor der Mittagspause.

Wir haben daher diesen Zeitpunkt als guten Meetingtermin identifiziert und als erstes Experiment für einen Zeitraum von einem Monat versucht, unser Daily Standup auf 12 Uhr zu verschieben. Für die meisten derjenigen, die ihren Arbeitstag nicht erst um 12 Uhr beginnen wollten, fühlte es sich aber nicht gut an, sich zur Halbzeit des Tages und unmittelbar vor der Mittagspause zu der Frage auszutauschen, "was habe ich für heute vor?". Daher haben wir als nächsten Schritt ungefähr einen Monat lang ausprobiert, ein Standup zur alten Zeit um 9:45 Uhr zu machen und ein zweites Standup um 12 Uhr. Jedem war freigestellt, ob er gar nicht, an einem der beiden oder an beiden Standups teilnehmen wollte. Das Ergebnis war eine ziemlich klare Trennung im Team: Diejenigen, denen das 9:45-Uhr-Standup gut passte, trafen sich um 9:45 Uhr. Diejenigen, die länger schlafen wollten, trafen sich um 12 Uhr. Einen Austausch zwischen den Gruppen gab es kaum.

Schließlich brachte uns eine Google-Suche nach "Standup Times Diversity" zu einem Artikel mit dem Titel Daily Meetings with Remote Teams (Stand-ups Don’t Work, But Daily Cafes Do). Dort wird – vor dem Hintergrund einer ähnlichen Situation, was die Arbeitzeiten angeht – ein tägliches "Café" als Alternative zu Standup-Meetings vorgestellt.

Die Idee fanden wir so gut, dass wir sie ausprobieren wollten. In unserem 3-Personen-Projektteam haben wir uns dann ausführlich Gedanken gemacht, wie ein solches Format bei uns funktionieren könnte und welche Risiken bestehen. Das Meeting sollte sich einerseits nicht überflüssig anfühlen, andererseits aber auch nicht zu lang werden.

Wir haben während der Planungsphase in einer Teamumfrage erfragt, wie das Team zu unseren "Ankoppel-Runden" steht, mit denen wir bisher schon Montags und Freitags die größeren Meetings begonnen hatten (was das genau ist, erfahrt ihr gleich). Die Antwort war sehr positiv, sodass wir uns entschieden haben, dass eine solche Runde auch Bestandteil des neuen Mittags-Meetings sein sollte.

Wir sind zu folgendem Konzept gekommen:

• Die Meetings haben eine Timebox: Sie sollten maximal 30 Minuten dauern.

• Die Teilnahme ist freiwillig. Essen und Trinken während des Meetings ist willkommen.

• Teammitglieder können Themen einbringen. Diese sollten vorab per Mail angekündigt werden, damit jeder, der sich für das Thema interessiert, teilnehmen kann. Insbesondere gilt dies natürlich, wenn eine Entscheidung getroffen werden soll.

• Die Themen werden in der Regel in der Reihenfolge behandelt, in der sie eingebracht wurden (tatsächlich gab es in den letzten drei Monaten selten mehr als ein Thema pro Tag, häufig sogar gar keines).

• Es gibt eine "Ankoppel-Runde", in der jeder reihum kurz die Frage "Wie bin ich hier?" beantwortet (also wie geht es mir gerade, was beschäftigt mich). Dabei fängt ein beliebiges Teammitglied spontan an und nominiert dann das nächste.

• Am Ende des Meetings machen wir eine Schnellumfrage über das Chatfenster, bei dem jeder auf Kommando, also gleichzeitig, eine Bewertung des Meetings abgibt zwischen 1 ("Zeitverschwendung") und 5 ("Froh, dass ich dabei war"). Diese Umfrage lassen wir aber ausfallen, wenn es kein Thema gab und das Meeting nur aus der Ankoppel-Runde bestand.

• Es gibt einen Moderator und einen Protokollanten. Außerdem haben wir ein "ELMO-Signal" ("Enough said, let's move on") definiert: Wenn es jemandem zu langsam vorangeht, hält er eine Kaffeetasse, ein Glas oder Ähnliches in die Kamera. Das kam allerdings in den ersten Monaten so selten vor, dass es im Team schon in Vergessenheit geraten ist.

• Das tägliche Standup haben wir verschriftlicht und in einen Chatkanal #standup verlagert. Das hat den Vorteil, dass es asynchron stattfindet und jeder zu seinem persönlichen Arbeitsbeginn seine Pläne und Wünsche für den Tag dort kommunizieren kann.

Die Ankoppel-Runde war ursprünglich für den Beginn des Meetings geplant. Wir haben sie aber inzwischen ans Ende gestellt, da wir den Eindruck hatten, dass sich in dieser Runde auch Gesprächsthemen für allgemeinen Austausch ("Socializing") ergeben. Dadurch, dass die Runde jetzt am Ende stattfindet, müssen wir diesen Austausch dann nicht für das Besprechungsthema des Tages abbrechen, sondern geben dem Team die Möglichkeit, auf Wunsch "open end" weiterzusprechen.

Wir haben dann festgestellt, dass das neue Meetingformat sogar flexibel genug ist, um unsere Montags-Wochenplanungs-Besprechung und unsere Freitags-Wochenrückblicks-Besprechung mit aufzunehmen. Montags haben wir also das feste Thema "Termine der Woche und Überblick über die Doing-Spalte" und Freitags das feste Thema "Spotlights der Woche in der Done-Spalte". Dienstags bis Donnerstags sind die Termine frei für andere Themen.

Insgesamt funktionieren die Besprechungen sehr gut. Sie dauern Montags meist um die 20 Minuten, Freitags eher 30 Minuten und Dienstags bis Donnerstag ist es sehr unterschiedlich, abhängig davon, wie viele da sind und ob es Themen gibt. Häufig sind wir nach 5-10 Minuten fertig; als wir letztens eine Präsentation und anschließenden Austausch zum Konzept für die Überarbeitung der webfactory.de-Startseite hatten, haben wir uns 45 sehr kurzweilige und ergebnisreiche Minuten genommen.

Erstaunlich schwer fand ich die Umstellung vom alten Rhythmus auf den neuen Rhythmus, da wir natürlich das ganze Team damit zufriedenstellen wollten. Ein Mehrheitsentscheid schied daher aus; er hätte wahrscheinlich sogar zu einem Votum für 9:45 Uhr auf Kosten der Spätaufsteher geführt. Wir haben daher sehr viel mit Online-Umfragen gearbeitet und z. B. während des Experimentzeitraums für die Mittagsmeetings jede Woche eine Standardumfrage zur Zufriedenheit mit den Meetings dieser Woche gemacht. Die Zufriedenheit war von Beginn an sehr hoch, obwohl es immer auch wortstarke Skeptiker gab, die den alten Zeitplan klar bevorzugten.

Nachdem wir 3 Monate experimentell mit den 12 Uhr-Meetings gearbeitet hatten, haben wir schließlich einen Teamentscheid vorbereitet, indem wir eine abschließende Widerstandsabfrage durchgeführt haben. Jeder konnte auf einer Skala von 0 (niedrigster Widerstand) bis 10 (höchster Widerstand) angeben, wie groß sein innerer Widerstand gegen eine Rückkehr zum alten Besprechungs-Stundenplan ist und wie groß sein Widerstand gegen die neuen Mittags-Meetings ist. Das Meinungsbild war sehr eindeutig: Gegen den alten Zeitplan hatten viele eher mittlere bis große Widerstände, gegen das neue System gab es fast keinen Widerstand; die schlechtesten Bewertungen lagen bei 5 von 10 möglichen Widerstandspunkten bei zwei Personen.

Hier die Ergebnisse im Diagramm:

Auf Basis dieser Umfrage war es dann leicht, einen Konsententscheid zu treffen: Es gab keinerlei Einwände gegen eine formale Beendigung des Experiments und die dauerhafte Umstellung auf das neue System.

Die neue Flexibilität des Arbeitsbeginns schätze ich persönlich sehr und die Meetings sind in meiner Empfindung insgesamt sehr viel besser und energetischer geworden. Auch wenn es sich anfangs für einige merkwürdig anfühlte, die gemeinsame Arbeitswoche erst am Montagmittag zu beginnen, und für andere ebenso merkwürdig, sie schon am Freitag um 12:30 Uhr zu beenden, hat sich das Konzept aus meiner Sicht sehr bewährt. Insgesamt gibt es eher selten konkrete Besprechungsthemen Dienstags bis Donnerstags, aber die Tatsache, dass wir drei feste Besprechungstermine haben, die wir für solche Themen nutzen können, und dass die Themen damit nicht zwischen Wochenrückblick und Wochenende besprochen werden müssen, hat die Qualität und das Energielevel der Diskussionen deutlich verbessert.

Die täglichen Meetings mit Ankoppel-Runde haben für uns zudem etwas mehr sozialen Austausch in die Remote-Arbeitswelt gebracht. Denn das tägliche Standup war rein arbeitsbezogen und technisch; eine Frage "Wie geht's mir" hatten wir vorher nur Montags und Freitags in den Besprechungen.

Die Anwesenheit ist wechselnd, aber generell eher hoch (> 75%) – insbesondere, wenn Themen besprochen werden, sind häufig fast alle da. Montags und Freitags liegt die Anwesenheit bei nahe 100% (Urlaube, Krankheiten, wichtige Termine natürlich ausgenommen).

An dieser Stelle möchte ich einen Dank aussprechen an Lucie Lewandowski, die uns als Organisationsentwicklerin im Rahmen eines Beratungsprojekts im Förderprogramm "unternehmensWert: Mensch" vor vielen Jahren mit soziokratischer Entscheidungsfindung vertraut gemacht hat und über die wir auch das Ankoppeln zum Beginn einer Besprechung kennen- und schätzen gelernt haben.

Dank auch an meine Kollegen Eva und Malte, mit denen ich das hier vorgestellte Konzept gemeinsam entwickelt und eingeführt habe.

webfactory: Hallo ihr Lieben! Als erstes würde mich mal interessieren, wie ihr beiden Neuen auf die webfactory aufmerksam geworden seid. Ihr kommt ja ursprünglich gar nicht aus Bonn…

Fabian: Ich bin tatsächlich durch das Github Profil auf die webfactory aufmerksam geworden, da ich in meiner alten Agentur mit einem eurer Open-Source Pakete gearbeitet habe.

Amitay: I heard about webfactory through Isis, Sebastian's wife. She is a friend of mine since University in 2001.

***

webfactory: Und was hat euch dann dazu bewogen, euch in der webfactory zu bewerben?

Fabian: Für mich war es ausschlaggebend, Kolleg*innen zu finden, welche ebenfalls gerne mit PHP in Kombination mit Symfony arbeiten. Zudem konnte ich durch den Blog bereits weitere Eindrücke über die Unternehmenskultur herausfinden, welche mich ebenfalls zu einer Bewerbung bewogen haben (Mitgestaltung am Unternehmen, Gehaltstransparenz, technische Kompetenz).

Amitay: I have been planning to move to Germany for many years. Then I heard about webfactory and found out that this is a great software company. Then it was like getting two things at once: Living in a great country and working in a very good software company.

***

webfactory: Wie war denn der Bewerbungsprozess für euch? Ihr habt ja während der ganzen Zeit keinen von uns persönlich getroffen. Wie liefen die Bewerbungsgespräche ab?

Fabian: Ich war erstaunt darüber, dass ich noch am selben Tag eine Antwort erhalten habe. Etwas ungewöhnlich war, dass ich insgesamt drei Bewerbungsgespräche hatte. Jede*r potenziell neue Kolleg*in hatte somit die Möglichkeit mich kennenzulernen (und anders herum). Man merkte sofort, dass die Einstellung eines neuen Kollegen eine Teamentscheidung ist und keine, die die Geschäftsführung ohne Rücksprache trifft. Das hat mir sehr gut gefallen. Aufgrund der Corona-Krise haben wir alle Gespräche online abgehalten, was aber in keiner Weise ein Problem für mich darstellte.

Amitay: The interviews for me were online. I met all of my colleagues in a few interviews (like 3 or 4). I got the chance to meet them and see how they work. I learned about all of the human values and decided to come here. Then my webfactory colleagues decided to accept me and here I am.

Man merkte sofort, dass die Einstellung eines neuen Kollegen eine Teamentscheidung ist und keine, die die Geschäftsführung ohne Rücksprache trifft. Das hat mir sehr gut gefallen.

webfactory: Wie habt ihr euch dabei gefühlt? War es komisch für euch, den Bewerbungsprozess via Videochat zu durchlaufen? Habt ihr darin irgendwelche Nachteile oder vielleicht sogar Vorteile gesehen?

Fabian: Natürlich ist ein Bewerbungsgespräch per Videochat ganz abseits der Norm, aber gerade in einer technischen Branche kein Hindernis. Es zeigte mir, dass das Unternehmen sich an die neue Corona-Situation gut anpassen konnte. Ein Vorteil war natürlich, dass ich mir die lange Anfahrt (250 km) sparte. Ich denke, Amitay geht es da ähnlich wie mir, gerade weil es bei ihm ein paar Kilometer mehr waren… Und natürlich konnte ich so auch meine Jogginghose anbehalten ;-) Als Nachteil sehe ich aber ganz klar, dass ich das webfactory Büro nicht direkt kennenlernen konnte.

Amitay: I felt very good in the process. I think that online meetings are very advantageous and practical, since you don't need to transport anywhere. Can you imagine that I needed to come from Mexico for a meeting? Hahaha.

Ich persönlich finde, dass man in einem richtigen Treffen noch einen besseren Eindruck von der Person gewinnen kann und besser merkt, ob die "Chemie" stimmt.

webfactory: Ihr beiden Geschäftsführer – und auch die anderen im webfactory Team – standet dabei ja quasi „auf der anderen Seite“. Wie lief der Bewerbungsprozess aus eurer Sicht ab? In den letzten Jahren habt ihr euch ja immer persönlich mit Bewerber*innen zum Kennenlernen und Beschnuppern getroffen. Hat sich das für euch jetzt irgendwie anders angefühlt?

Matthias: Im Prinzip lief der Prozess genauso ab wie bei den Bewerbungen in der Zeit davor, nur halt über eine Videokonferenz. Ich persönlich finde, dass man in einem richtigen Treffen noch einen besseren Eindruck von der Person gewinnen kann und besser merkt, ob die "Chemie" stimmt. Aber unbestreitbar hat auch eine Videokonferenz Vorteile, gerade wenn man auch mal zwei oder drei Gespräche an verschiedenen Tagen führen möchte und der/die Bewerber*in dafür keine Anreise braucht.

Sebastian: Mein Gefühl ist, dass die Online-Bewerbungsgespräche mit weniger Stress verbunden sind und es leichter ist, sich auf das Wesentliche zu konzentrieren. Viele Dinge werden auch einfacher, z. B. braucht man sich keine Gedanken über die Sitzordnung zu machen und das Vorstellen von Arbeitsbeispielen ist durch Screensharing sehr einfach. Natürlich ist es noch einmal etwas anderes, wenn man der Person dann in echt gegenübersteht, aber ich hatte mitnichten den Eindruck, dass unsere Auswahlentscheidungen durch die Verlagerung in Videokonferenzen schlechter waren – eher im Gegenteil.

webfactory: Wenn ihr zukünftig die Wahl hättet – würdet ihr irgendeine Variante bevorzugen, also entweder das „persönliche“ Kennenlernen und Treffen im realen Leben oder vielleicht sogar die virtuelle Variante?

Fabian: In den meisten Fällen würde ich das persönliche Kennenlernen vor Ort bevorzugen, gerade weil man die Möglichkeit hat, auch das potenzielle neue Büro kennenzulernen. Die virtuelle Variante ist natürlich dann von Vorteil, wenn ich eine Fahrt zum Bewerbungsgespräch, aufgrund der Entfernung, auf zwei Tage aufteilen müsste.

Amitay: I like the virtual variant.

Matthias: Meine Präferenz wäre die "persönliche" Variante, wenn keine gewichtigen praktischen Gründe entgegenstehen. "Virtuell" ist aber definitiv kein Problem.

Sebastian: Ich würde bei online bleiben, zumindest für den Großteil der Gespräche und wenn die Bewerberin oder der Bewerber nicht in der Nähe wohnt. Die Bürobesichtigung ist natürlich ein klarer Vorteil des Kennenlernens vor Ort, aber dafür reicht auch ein einzelner Termin.

Mein Gefühl ist, dass die Online-Bewerbungsgespräche mit weniger Stress verbunden sind und es leichter ist, sich auf das Wesentliche zu konzentrieren.

webfactory: Richtig spannend wurde es dann aber natürlich, nachdem feststand, dass wir zwei neue Teammitglieder haben würden. Zu dem Zeitpunkt war uns ja bereits klar, dass auch der Einarbeitungsprozess (größtenteils) remote würde stattfinden müssen. Wie seid ihr da im Vorfeld mit umgegangen? Was für Gedanken habt ihr euch gemacht? Hattet ihr Sorgen, dass etwas nicht funktionieren könnte?

Fabian: Tatsächlich habe ich mir am Anfang schon einige Sorgen um das Onboarding gemacht. Wie steht es um die Erreichbarkeit bei Problemen? Wie lerne ich die neuen Kund*innen und ihre Projekte kennen? Wie findet das Socialising mit meinen neuen Kolleg*innen statt? 

Amitay: I was worried (and still am) about the German language. I trust in my capabilities as a software developer and I know that I can learn PHP in a relatively short amount of time. So, my only concern is regarding the language, which I am working on to master.

Matthias: Gerade am Anfang muss man ja eine Menge erklären. Ich persönlich kann das am besten, wenn ich dazu auch mal ein paar Dinge schnell auf ein Blatt zeichnen oder kritzeln und damit verdeutlichen kann. Ich habe mir daher einen Apple Pencil fürs iPad zugelegt und ein paar Apps durchprobiert, mit denen man einfach und flüssig zeichnen und gleichzeitig auch noch live teilen kann. Aber Einarbeitung besteht ja nicht nur aus den einigermaßen planbaren, fachlichen Inhalten. Es gehört auch viel "beschnuppern" und Kennenlernen im Team dazu, das man weniger erzwingen kann. Das passiert meistens und am besten an der Kaffeemaschine, beim gemeinsamen Mittagessen oder sogar, wenn man jemandem beim Kochen über die Schulter schaut. Alles das hatten wir seit letztem Jahr nicht.

Sebastian: Ich habe mir da im Vorfeld keine Gedanken zu gemacht, sondern die Situation auf mich zukommen lassen. Wir hatten Anfangs auch den Plan, die ersten Wochen Einarbeitung in Präsenz zu machen. Das hat dann aber die zweite Corona-Welle zunichte gemacht.

***

webfactory: Matthias und Sebastian, ihr habt einige Wochen damit verbracht, die Einarbeitungsphase vorzubereiten. Worum genau ging es da?

Matthias: Wir haben versucht, uns erstmals einen umfassenden und schriftlich festgehaltenen Überblick über alle Themen, fachliche Inhalte, Abläufe etc. zu verschaffen, die uns als Unternehmen "besonders" machen. Also im Prinzip alles das, was selbst jemand, der/die mit einer guten Ausbildung und Kenntnis unseres Tech Stacks zu uns kommt, nicht wissen kann, weil es unsere besondere Situation, Kund*innen oder eigene Tools betrifft. Das war eine überraschend lange Liste! Für alle Themen haben wir versucht, eine*n „Themenpat*in" zu finden. Also im Prinzip die Person, die das einzelne Thema am besten kennen sollte. Im besten Fall sollte diese Person dann auch die Einarbeitung in das jeweilige Thema machen. Und mit der Liste wollten wir nachhalten, ob und wer schon in den Genuss dieser Einarbeitung gekommen ist. Tatsächlich haben wir gemerkt, dass manche Themen selbst für Mitarbeitende, die schon länger dabei sind, noch neu sind.

Einarbeitung besteht ja nicht nur aus den einigermaßen planbaren, fachlichen Inhalten. Es gehört auch viel "beschnuppern" und Kennenlernen im Team dazu, das man weniger erzwingen kann.

webfactory: Irgendwann war der große Tag ja dann da. Wie lief der erste Arbeitstag aus eurer Sicht?

Fabian: Den ersten Arbeitstag habe ich zusammen mit Matthias im Büro (natürlich mit Masken) verbringen können. Er erklärte mir jegliche neue Software von Trello bis Fogbugz. Im Daily-Standup haben sich sogar meine Kollegen mit Matthias und mir solidarisiert und ebenfalls die Masken (virtuell) aufgezogen, was uns beiden ein verstecktes Lächeln zauberte.

Amitay: My first day was very exciting and still is, mainly for two reasons: I was living in Germany and I was at Sebastian's house. It was very nice to be able to work in person with one of my colleagues, I really enjoyed it. Sebastian has helped me a lot!

Matthias: Tatsächlich haben wir Fabian schon ein Mal vor dem ersten Arbeitstag getroffen, als wir Büroschlüssel etc. übergeben haben. Diese Gelegenheit konnten wir dann ausgiebiger zum Quatschen nutzen. Der erste Arbeitstag war aber dann seitdem das einzige Mal, dass wir beide physisch zusammen vor einem Rechner sitzen konnten. Wir haben die Zeit vor allem fürs "Bootstrapping" verwendet, also sicherzustellen, dass Fabian einen Rechner hat, mit dem er Zugriff auf alle notwendigen Tools hat und dass von da an die Remote-Arbeitsweise funktionieren kann. Leider bin ich Amitay bisher noch nie persönlich begegnet.

Sebastian: Auch Amitay und ich haben die erste Zeit in Präsenz zusammengearbeitet, allerdings ohne weitere Kolleg*innen – Hilfe bei den letzten Einrichtungsaufgaben mussten wir also von remote einholen.

webfactory: Wie ging es in den Wochen danach mit der Einarbeitung weiter? Gab es irgendein System, nach dem ihr vorgegangen seid?

Fabian: Da Matthias in der ersten Zeit mein Hauptansprechpartner war, haben wir uns morgens immer darüber abgestimmt, was heute auf meiner Onboarding-Liste steht. Hier konnten wir Schritt für Schritt neue Themen angehen.

Amitay: In my case, Sebastian and Jano helped me a lot. Jano helped in my first project and Sebastian has been mentoring me in all of the projects I have worked on. I also received help from the rest of my teammates.

Matthias: Ich habe die "Mentor"-Rolle für Fabian übernommen und in den ersten Wochen versucht, die wichtigsten Themen unserer Einarbeitungs-Liste mit ihm durchzugehen. Soweit möglich haben wir immer versucht, das direkt im Kontext von "richtigen" Projekten zu tun.

Sebastian: Ich war der "Mentor" für Amitay. Auch wir haben uns passende Kundenaufträge gesucht, um verschiedene Themen anzugehen. Die waren erstaunlich leicht zu finden – ich meine, es gab einige Anfragen, die schnell bearbeitet werden mussten und die einen guten Überblick über unsere Systemlandschaft boten.

***

webfactory: Früher, als wir alle noch gemeinsam im Büro gearbeitet haben, war es ja relativ einfach Fragen an die Kolleg*innen zu stellen. Gerade in der Einarbeitungsphase kommen ja besonders viele Fragen auf. Wie funktionierte das in euren ersten Wochen – wie habt ihr miteinander Kontakt gehalten?

Fabian: In Slack hatte ich die Möglichkeit Matthias direkt eine Nachricht zukommen zu lassen oder in einem unserer Teamchannels allgemeine Fragen zu stellen. Natürlich ist dies anders, als mal eben schnell eine Frage durchs Büro zu werfen, aber aufgrund der Teamchannels haben viel mehr Kolleg*innen die Möglichkeit, eine Frage beantworten zu können, als wenn ich die Frage nur meinem/meiner Büronachbar*in gestellt hätte.

Amitay: I was lucky to be able to work together with Sebastian. I also used Slack to ask my other colleagues. Everyone answered my questions and helped me a lot!

Matthias: Ich habe mir sehr viel Zeit genommen, mit Fabian direkt zusammenzuarbeiten. Oft haben wir mehrere Stunden am Tag direkt miteinander telefoniert und dabei auch einen geteilten Bildschirm verwendet. Im Endeffekt ist das eigentlich schon so, als würde man direkt nebeneinander sitzen. Allerdings ist es doch mehr eine 1:1-Situation, d. h. es kommen nicht mal zufällig andere Kolleg*innen vorbei, oder man geht gemeinsam in die Küche und trifft dort die anderen.

Sebastian: Amitay und ich haben auch viele Stunden täglich gemeinsam gearbeitet. Ich hatte den Eindruck, dass Fragen auch im Chat gut funktionieren. Im Grunde war das auch vor Corona schon unser Arbeitsmodus. Man ist nicht einfach im Büro rumgelaufen und hat eine*n Kolleg*in angesprochen, sondern hat im passenden Chat-Kanal gefragt.

***

webfactory: Was würdet ihr sagen, waren die größten Schwierigkeiten bei der remote-Einarbeitung?

Fabian: Definitiv das Socialising mit meinen neuen Kolleg*innen.

Amitay: None for me. I had time to read, study, code and learn a lot.

Matthias: Nicht die fachlichen Inhalte, die kann man gut geplant und über gemeinsame Telefonate und geteilte Bildschirme vermitteln. Es ist das Zwischenmenschliche und Soziale, das zur Teambildung dazugehört und das nicht so einfach passieren kann.

Sebastian: Die größte Schwierigkeit sehe ich darin, dass eine höhere Eigeninitiative und ein bisschen mehr Mut gefragt ist. Wenn jemand an einer Frage festhängt und nicht weiterweiß, sieht man das ja häufig schon an der Körperhaltung. In einer Präsenzsituation ist die Chance dann groß, dass ein/e Kolleg*in das bemerkt und die hilfesuchende Person aktiv anspricht. In einer Remote-Zusammenarbeit gibt es das nicht, es muss immer eine aktive Kommunikation stattfinden.

Die größte Schwierigkeit sehe ich darin, dass eine höhere Eigeninitiative und ein bisschen mehr Mut gefragt ist.

webfactory: Seht ihr auch Vorteile darin, jemanden remote einzuarbeiten?

Amitay: For me it is the same like any other meeting. You have the great advantage not having to transport yourself to a place and you can work from home.

Sebastian: Screensharing mit Audioübertragung in Slack war für mich eine Entdeckung, die ich ohne Remote-Zusammenarbeit nicht gemacht hätte. Ich finde es wesentlich angenehmer, auf diesem Weg auf den Bildschirm meines/meiner Kolleg*in schauen zu können und sogar Dinge dort markieren zu können, als physisch nebeneinander auf den gleichen Bildschirm zu schauen. Ich erinnere mich auch nicht, vor Corona so oft mit Kolleg*innen zusammen auf einen Bildschirm geschaut zu haben, wie seitdem wir im Homeoffice sind.

***

webfactory: Vielleicht könnt ihr noch ein bisschen was zu den technischen Hilfsmitteln erzählen, derer ihr euch für die Einarbeitung bedient habt

Matthias: Wie schon oben erwähnt fand ich es sehr hilfreich, mit Tablet und Stift eine Art virtuelles, gemeinsames Whiteboard haben zu können. Das ist aber nicht nur für die Einarbeitung wertvoll, sondern hat sich seitdem auch in vielen weiteren Teambesprechungen und Gesprächen mit Kund*innen bewährt.

Sebastian: Ich fand das Screensharing mit Markierungsmöglichkeit in Slack sehr gut, und für asynchrone Zusammenarbeit Pull Requests in GitHub. Die habe ich erst durch die Einarbeitung von Amitay richtig häufig genutzt.

webfactory: Wenn ihr zukünftig die Wahl hättet, welche Variante würdet ihr denn bevorzugen: Remote Einarbeitung oder doch wieder im direkten Miteinander, so wie früher – oder ist vielleicht sogar beides gleich gut oder schlecht?

Fabian: Wenn ich die Wahl hätte, würde ich für die Einarbeitungsphase das direkte Miteinander bevorzugen. Ich möchte aber die Remote-Einarbeitung gar nicht schlecht reden, für die Corona-Situation war es die beste Möglichkeit.

Amitay: For the training period, it is better to have a direct mentor or work together with someone else. This work can also be done remotely, although it will be a bit better to do it in person, but remotely works as well (you only need to synchronize your work hours and work at the same time).

Sebastian: Ich glaube, dass es schon gut ist, wenn das Team sich auch persönlich sieht – gerade am Anfang der Zusammenarbeit. Für die fachliche Einarbeitung spielt das, finde ich, keine Rolle. Die geht remote genau so gut. Um sich menschlich kennenzulernen, gerade auch diejenigen, die nicht in Projekten zusammenarbeiten, ist Präsenz im gemeinsamen Büro sehr hilfreich.

***

webfactory: Fabian und Amitay: Wie lange seid ihr jetzt schon in der webfactory?

Fabian: Ich seit Oktober 2020 bei der webfactory.

Amitay: Since February 1st, 2021.

***

webfactory: Wir haben ja jetzt viel über die eher konkret arbeitsbezogenen Einarbeitungsprozesse gesprochen. Wenn man neu in einem Team ist, kommen aber ja auch soziale Faktoren hinzu. Man kennt niemanden, ist – wie in eurem Fall – vielleicht sogar neu in der Stadt. Man könnte ja zumindest mal davon ausgehen, dass ein remote-Kennenlernen hier massive Nachteile mit sich bringt. Wie war das für euch?

Fabian: Ich glaub, dass was am Ende das Socialising im Remote ausgemacht hat, sind die Möglichkeiten in unseren Dailies Kolleg*innen zu Hören und zu Gesicht zu bekommen. Was natürlich hinten runterfällt sind Dinge wie z.B. gemeinsame Mittagspausen oder ein Plausch nach Feierabend.

Amitay: It worked for me. I can work with my colleagues without knowing them. I mean, I respect a teammate and I can work with him/her without knowing him/her. I only need to know that he/she is from my team, and gladly I will work with that person. That's how I started working with all of you and that is how I got to know you and enjoy being here.

***

webfactory: Wie viele Teammitglieder*innen habt ihr denn bis heute mal persönlich, also nicht nur virtuell, gesehen?

Fabian: Ich konnte sieben Kolleg*innen in Natura kennenlernen – und "Bürohund" Gamma.

Amitay: I have meet Sebastian and Martin.

***

webfactory: Und wie war das für euch, Matthias und Sebastian? Habt ihr euch hier eigentlich Sorgen gemacht, dass „die neuen“ sozial irgendwie auf der Strecke bleiben?

Matthias: Ja, das ist weiterhin meine große Sorge. Für beide war der Wechsel zu uns auch mit einem Wechsel des Wohnorts verbunden. Da möchte man doch auch die neue Stadt und Umgebung erkunden, neue Leute kennenlernen etc. und das wäre viel einfacher, wenn man das auch mal mit den Kolleg*innen zusammen nach Feierabend oder in einer ausgedehnten Mittagspause im Bonner Hofgarten oder so tun könnte.

Sebastian: Ich denke auch, dass die Kombination mit dem Wohnortwechsel besonders schwierig ist, also wenn die Kolleg*innen erstmal die einzigen sozialen Kontakte sind, die man in der neuen Umgebung hat.

Wenn man sich täglich über Video sieht, fühlt es sich auch gar nicht so an, als hätte man keinen Kontakt.

webfactory: Vermisst ihr den persönlichen Kontakt zu den anderen Teammitgliedern?

Fabian: Natürlich. Aber umso mehr freue ich mich auf ein gemeinsames Treffen im webfactory Büro.

Amitay: Yes. I think it will be great to meet in the office, but I also enjoy a lot working at home, so it is like a crossed feeling.

Sebastian: Ja und nein. Ich fühle mich, was die Arbeit angeht, im Homeoffice sehr wohl. Wenn man sich täglich über Video sieht, fühlt es sich auch gar nicht so an, als hätte man keinen Kontakt. Aber ich wünsche mir schon, dass das gemeinsame Büro in der Zukunft wieder eine Rolle spielt.

***

webfactory: Habt ihr denn das Gefühl, dass man sich im Team dennoch ganz gut kennt mittlerweile – oder bleibt da irgendwie das Gefühl, dass man einander doch fremder ist, als wenn man täglich gemeinsam im Büro wäre?

Fabian: Da ich mit Matthias die letzten Monate viel zusammen arbeiten konnte, konnte ich auch ihn schon sehr gut kennenlernen. Ich gehe ganz stark davon aus, dass ich diese persönliche Ebene mit jedem meiner Kolleg*innen auch Remote aufbauen kann, wenn es die Möglichkeit gibt, in zukünftigen Projekten zusammenzuarbeiten.

Amitay: I have the feeling that I know everyone. Everyday we have our meetings and I feel like I know all of my colleagues.

Sebastian: Mein Eindruck ist, dass manche eine Bürosituation schon eher dafür nutzen, auch mal über Dinge jenseits des aktuellen Projekts zu sprechen, und ihre Kolleg*innen dann besser kennen lernen. In der Remotesituation muss man sich da bewusster drum bemühen. Ich glaube aber nicht, dass eine Zusammenarbeit in Präsenz "automatisch" und für jeden zu besserem Kennenlernen führt.

webfactory: Viele im Team haben sich in den letzten Monaten dafür ausgesprochen, das remote-Arbeiten beizubehalten. Die webfactory hat sich offiziell zu einer „remote first“ Agentur bekannt. Nun haben die anderen Teammitglieder natürlich auch den direkten Vergleich dazu, wie es früher war. Wie steht ihr neuen Mitarbeiter denn dazu?

Fabian: Da sich meine aktuelle Lebenssituation verändert hat und ich wieder umziehen werde, werde ich dieses Angebot ebenfalls nutzen. Ich finde es daher super, dass die webfactory selbst nach der Pandemie Homeoffice anbieten wird. Dennoch denke ich, dass es wichtig ist, Tage zu finden, in denen man sich als Team vor Ort verabredet.

Amitay: I totally agree on continuing to work remotely. I really like it!

***

webfactory: Würdet ihr, Matthias und Sebastian, noch einmal Mitarbeiter remote einstellen?

Matthias: Ja, gerade weil wir ja jetzt noch besser wissen, was auf uns zukommt.

Sebastian: Ja.

***

webfactory: Hat sich vielleicht sogar insgesamt eure Sicht auf die Mitarbeiter*innensuche verändert? Früher haben wir ja schon eher Leute angestellt, die auch in Bonn gelebt haben oder bereit waren, hierher zu ziehen. Mittlerweile gibt es schon zwei Teammitglieder, die gar nicht mehr in der Stadt wohnen. Könntet ihr euch auch vorstellen, jemanden einzustellen, der oder die vielleicht in einer anderen Stadt oder gar in einem anderen Land lebt und von dort aus für uns arbeiten möchte?

Matthias: Ich finde die Vorstellung im Moment noch schwierig, obwohl wir de facto längst dort angekommen sind. Wir müssen dann mindestens mal einige Arbeit investieren, in der sozialen Anbindung besser zu werden, vielleicht über regelmäßig organisierte, wirkliche Treffen und Events.

Sebastian: Ich bin gespannt, wie sich unsere Zusammenarbeit in den nächsten Monaten verändert und wie eine Hybridsituation (manche im Büro, manche im Homeoffice) funktioniert. Mit "remote first" haben wir ja schon die Absicht erklärt, alle Prozesse und Meetings so zu organisieren, dass Kolleg*innen, die nicht präsent sind, nicht benachteiligt werden. Wie das in der Praxis funktioniert, muss sich aber noch zeigen. Davon hängt dann denke ich auch ab, wie wir grundsätzlich zu neuen Kolleg*innen stehen, die physisch weiter weg sind. Die erfolgreiche Remote-Zusammenarbeit im letzten Jahr hat uns aber definitiv gezeigt, was möglich ist.

***

webfactory: Ihr könntet ja auch darauf bestehen, dass die Teammitglieder*innen vor Ort Präsenz zeigen (und in Bonn leben) müssen. Wieso tut ihr das nicht?

Matthias: Die Präsenz "vor Ort" an sich ist in unserer Branche doch wirklich nicht entscheidend. Vielleicht ist sie einfach aus historischen Gründen noch etwas überbewertet oder wird von vielen Arbeitgeber*innen – oder eher Vorgesetzten – aus anderen Gründen erwartet? Wir haben jedenfalls gesehen, dass es vielen Mitarbeiter*innen hilft und sie auch glücklicher und weniger gestresst macht, wenn sie ihre Arbeitszeiten etwas freier und verteilter organisieren können. Auf der anderen Seite setzt das aber auch voraus, dass alle damit umgehen können: Es verlangt von den Mitarbeiter*innen viel mehr, im virtuellen Raum präsent zu sein und die Kommunikation aufrecht zu erhalten. Ich muss mich selbst organisieren können und werde mehr an sichtbaren Ergebnissen gemessen als nur daran, jeden Tag im Büro zu erscheinen.

Die Präsenz "vor Ort" an sich ist in unserer Branche doch wirklich nicht entscheidend.

webfactory: Wenn ihr jetzt mal ein Fazit ziehen würdet, wie sähe das aus? Haben sich eure Erwartungen oder vielleicht sogar Befürchtungen bewahrheitet? Was hat euch überrascht?

Fabian: Meine Befürchtungen haben sich definitiv nicht bewahrheitet. Das Onboarding verlief ausgesprochen gut über Remote.

Amitay: Yes! webfactory exceeded my expectations.

Matthias: Alle Umbrüche seit Anfang 2020 haben uns gezeigt, dass wir viel flexibler und besser mit den Herausforderungen umgehen können, als ich persönlich zu Anfang gedacht hätte. Etwas überrascht hat mich, wie viele Routinen und Abläufe wir seitdem aufgegeben oder komplett geändert haben. Ein wenig Rückkehr zum alten "normal" wünsche ich mir schon, aber wir werden bestimmt nicht wieder alles so machen wie vorher. Dafür haben einige Dinge auch zu gut funktioniert und sich manche Freiheiten bewährt.

Sebastian: Ich bin auf jeden Fall sehr zufrieden, wie die Integration von Fabian und Amitay ins Team funktioniert hat. Auch insgesamt hat die Remote-Zusammenarbeit wesentlich besser funktioniert, als ich mir das jemals hätte vorstellen können. Wir haben auch unsere Kund*innen so oft gesehen wie nie zuvor, weil wir gezwungen waren, die Videokonferenz als Medium zu nutzen. Früher haben wir Kund*innen in der Regel entweder persönlich getroffen oder Telefonkonferenzen gemacht. Die Telefonkonferenz ist absolut ausgestorben, weil Video viel besser ist.

Update 10.09.2021: Nach vielen Jahren Stabilität haben wir den Besprechungsrhythmus nun verändert. Die grundsätzlichen Informationen in diesem Artikel sind natürlich weiterhin relevant. Zum neuen Besprechungsrhythmus haben wir heute gebloggt: Nur mittags Meetings oder: Das "Daily Café" in der webfactory.

Wir beginnen mit ein paar grundsätzlichen Erkenntnissen, die dem Kalender zugrunde liegen. Anschließend stellen wir unsere internen Teambesprechungen vor: die Wochenplanung, die Daily Standups und der Wochenrückblick sowie die "Internen Baustellen" und die Geschäftsführungsbesprechungen. Im letzten Teil gehen wir dann auf unsere regelmäßigen Kundenbesprechungen ein: Den Jour Fixe in Fokusprojekten sowie die Backlog-Abstimmungen.

Die Basics: Warum machen wir das alles?

Ein paar Grundüberlegungen haben uns bei der Entwicklung des unseres Terminkalenders geleitet.

Was ist schlecht an Besprechungen?

Besprechungen kosten Arbeitszeit, die nicht für die eigentliche Tätigkeit (z. B. Programmieren) zur Verfügung steht.

Sie kosten zudem Energie und Kraft, gerade wenn sie lang sind, und sie können langweilen. Das passiert vor allem dann, wenn nicht alle Teilnehmer das gleiche Interesse an den besprochenen Themen haben, oder wenn sie inhaltlich nicht von der Stelle kommen und sich "im Kreis drehen".

Alleine die Terminfindung für eine Besprechung kann hohen Koordinationsaufwand verursachen, insbesondere wenn ein gemeinsamer Termin für viele Teilnehmer gefunden werden muss.

Was ist gut an Besprechungen?

Der Hauptvorteil an Besprechungen ist, dass persönliche Treffen der Kommunikationskanal mit der höchsten Bandbreite sind. D. h. man hört die Worte, sieht gleichzeitig Mimik und Gestik des Gegenübers und kann direkt Rückfragen stellen oder durch Mimik Feedback geben (Cockburn 2007, S. 124 f.). Das ist wertvoll, wenn mit dem Kunden gemeinsam konzeptionelle Fragen diskutiert werden oder Feedback zu Zwischenständen eingeholt wird, aber auch, wenn wir uns untereinander darüber austauschen, wie es uns geht und was uns beschäftigt.

Projektbesprechungen sind häufig auch ein Ort für zufälligen Erkenntnisgewinn: Während man über eine konkrete Frage mit dem Kunden spricht, bemerkt man, dass man eine Anforderung an anderer Stelle falsch verstanden hatte – oder findet eine viel einfachere Lösung als geplant, weil klar wird, dass eine als hart erachtete Anforderung gar nicht wichtig ist.

Besprechungen können ein schneller, einfacher Weg sein, um mehrere Personen gleichzeitig über ein Thema zu informieren. Voraussetzung dafür ist allerdings, dass das Thema für alle Teilnehmer relevant ist oder die Information kurz gehalten werden kann, sonst führen Vorträge schnell zu Langeweile und Unaufmerksamkeit.

Zu guter Letzt: Die Tatsache, dass feste Besprechungstermine vereinbart und bekannt sind, führt zu einer Reduktion der ungeplanten Kommunikation. Bevor wir unsere festen Freitagsmeetings hatten, sind Teamdiskussionen häufig spontan beim Mittagessen entstanden und haben ungeplant einen großen Teil des Nachmittags eingenommen. Jetzt kann man ein Besprechungsthema auf die Tagesordnung für das Teammeeting setzen und hat bis dahin sogar noch Zeit, eine vorbereitende E-Mail zu schreiben, was die Qualität der Besprechung verbessert. In den (Fokus-) Kundenprojekten haben wir einen ähnlichen Effekt beobachtet: Da alle wissen, dass es zweimal pro Woche feste Besprechungstermine gibt, rufen Kunden uns nicht mehr zwischendurch an, wenn sie neue Ideen fürs Projekt haben, sondern sammeln sie bis zum nächsten Jour Fixe – und umgekehrt müssen wir unsere Kunden nicht mit Anrufen unterbrechen, um Fragen zu klären.

Feste Termine, (fast) ohne Wenn und Aber

Unsere Termine haben ein festes Zeitraster. Das ist hat mehrere Vorteile:

• Es ist sichergestellt, dass die Besprechungen stattfinden und man sie nicht "vor sich herschiebt" (z. B. einen Abstimmungstermin mit dem Kunden erst vereinbart, wenn man glaubt, ganz fertig zu sein).

• Der Koordinationsaufwand ist minimal, weil jeder die Termine im Kalender hat und seine sonstige Planung darauf ausrichten kann.

Was für ein großer Vorteil das ist, merken wir jedes Mal, wenn jemand auf die Idee kommt, doch eine Verschiebung für einen einzelnen Termin vorzuschlagen – plötzlich fängt das Suchen im Kalender nach freien Zeitfenstern an und ein aufwändiger Abstimmungsprozess.

Aus diesen Gründen haben wir auch die Regel, dass alle grundsätzlich Termine stattfinden, egal wer anwesend ist. D. h. es kommt auch vor, dass bei unserer "interne Baustellen"-Besprechung, die wir später noch genauer vorstellen, drei Kolleg*innen in Abwesenheit der Mehrheit des Teams über das weitere Vorgehen entscheiden oder die Wochenplanung zu zweit erfolgt. Im Bezug auf die internen Baustellen und die Wochenrückblicks-Workshops haben wir uns anfangs die Frage gestellt, welche Entscheidungen das Team eigentlich treffen darf, wenn es nicht vollzählig ist. Dazu haben wir keine formale Entscheidung getroffen, aber es gab auch noch keinerlei Konflikt, weil jemand sich übergangen fühlte. Wichtig scheint uns da Fingerspitzengefühl und Rücksichtnahme im Team und auch eine gute Kommunikation über die geplanten Themen und Entscheidungen zu sein.

Eine Ausnahme gibt es: Termine, die auf Feiertage fallen, werden verschoben, und zwar von Montags auf den ersten Arbeitstag in der Woche und von Freitags auf den letzten Arbeitstag. Ob die Dienstags- und Donnerstagstermine in Kundenprojekten verschoben werden oder ausfallen, entscheiden wir mit dem Kunden je nach Projektlage.

Die Teambesprechungen in der webfactory

Nach den ganzen Vorüberlegungen werden wir jetzt endlich konkret und stellen wie versprochen unseren Besprechungs-Stundenplan vor. Wir starten mit unseren internen Besprechungen.

Unsere Arbeitswoche wird eingerahmt von zwei Besprechungen, an denen in der Regel das gesamte Team teilnimmt: Der Wochenplanung am Montag Morgen und dem Wochenrückblick am Freitag Nachmittag.

Wochenplanung

Termin: Montags 9:45 Uhr. Dauer: 15-30 Minuten

Die Wochenplanung dient dazu, uns über die Termine und Aufgaben der Woche abzustimmen und uns einen Überblick über den aktuellen Status unserer Projekte zu verschaffen. Im Zentrum der Wochenplanung steht unser unternehmensweites Kanban-Board in Trello.

Tagesordnung der Wochenplanung:

• Ankoppeln ("Wie bin ich heute hier?"/"Wie war mein Wochenende/mein Start in die Woche?") – kurzes Statement von allen Teilnehmern. Wir haben festgestellt, dass es schön ist, wenn man weiß, ob die Kollegen gerade voller Energie sind oder einen schlechten Start hatten, und darauf Rücksicht nehmen kann.

• Lob aus Lob-Kasten verteilen. Wir haben einen (inzwischen virtuellen) Lobkasten, in dem jeder eine Notiz hinterlässt, der sich über einen Kollegen gerade besonders gefreut hat. Montags wird das Lob dann im Kreis des Teams vorgelesen.

• Anwesenheit/Termine durchsprechen, ggf. vervollständigen. Alle Termine, Urlaube oder sonstige Abwesenheiten haben eine Karte auf dem Kanban-Board. Wir gehen die Planung für die Woche kurz durch, damit jeder Bescheid weiß.

• Individuell Überblick über die Doing-Spalte gewinnen: Sind noch Aufgaben in Doing, die in Vergessenheit geraten sind und Aufmerksamkeit brauchen? Was kann schnell erledigt werden? Was ist vielleicht schon fertig und versehentlich noch nicht in Done gezogen?

• Wer braucht jemand anderen, um bei einer Aufgabe weiterzukommen? Bei der Wochenplanung ist eine gute Gelegenheit, sich mit anderen zu verabreden, um ein Problem zu lösen.

• Wer braucht noch Fokus für die Woche? Eine Frage, die bei uns schon seit langem meist niemanden mehr betrifft. Falls jemand nicht weiß, was er sinnvollerweise tun sollte, können wir das an dieser Stelle klären.

• Möchte jemand am Freitag einen Vortrag oder Workshop halten oder ein Projekt vorstellen? Ein kurzer Stupser, eventuell für Freitag eine Präsentation vorzubereiten, die man immer schon halten wollte.

Im Anschluss an die Wochenplanung findet üblicherweise noch eine Besprechung des aktuellen Fokusprojekt-Teams zum Fokusprojekt statt sowie bilaterale Besprechungen zwischen denjenigen, die in der Besprechung angemeldet haben, dass sie Hilfe/Abstimmung brauchen.

Für die Moderation haben wir eine Checkliste auf einer wöchentlich automatisch für das Meeting generierten Trello-Karte, sodass jeder im Team das Meeting moderieren kann.

Wochenrückblick

Termin: Freitags 14:30. Dauer: ca. 1 Stunde

Unser Workshop am Freitag dient dem Rückblick auf die Woche sowie Präsentationen und Diskussionen im Team zu Themen, die persönlich im Kreis des gesamten Teams besprochen werden sollen.

Die Tagesordnung:

• Protokollant bestimmen (wir führen jedesmal Protokoll, damit Abwesende nachlesen können und wir eine Gedächtnisstütze haben)

• Spotlights der Done-Spalte: Auf unserem Kanban-Board können wir erledigte Aufgaben, mit einem "Spotlight"-Label versehen. Alle Spotlights werden Freitags kurz vorgestellt – das betrifft z. B. Dinge, über die man sich besonders gefreut hat, aber auch Fallen, vor denen man andere warnen möchte, kurz: Alles, was in Done ist und irgendwie noch mal erwähnt werden soll,

• Gefühlslage: Wie hat sich meine (Arbeits-) Woche angefühlt? Wie zufrieden bin ich?

Diese Standard-Tagesordnung kann bei Bedarf um weitere Punkte ergänzt werden, z. B. die Vorstellung eines Projekts oder eines Tools, oder auch Teamentscheide und -diskussionen. Insbesondere bei Teamdiskussionen hat es sich bewährt, diese gut vorzubereiten (z. B. durch eine vorbereitende E-Mail ans Team, in der man die Idee skizziert, über die man gerne sprechen möchte, oder die Entscheidung, die man treffen möchte).

Die Tagesordnung ist wie bei der Wochenplanung eine Checkliste auf der Trello-Karte für den Wochenrückblick. Diese Karte wird schon eine Woche vor der Besprechung automatisch erzeugt, sodass jeder im Laufe der Woche die Möglichkeit hat, Themen hinzuzufügen.

Daily Standup

Termin: Dienstag bis Freitag 9:45 Uhr. Dauer: 5-10 Minuten

Jeder berichtet kurz, woran er heute arbeiten wird und ob ihn oder sie etwas blockiert bzw. er Unterstützung braucht. Gelegentlich gibt es Unterstützung und Hinweise auch sofort, wenn jemand anders aus der Runde das Problem schon kennt. Im Anschluss klären einzelne Teilnehmer (z. B. Product Owner/Projektmanager und Entwickler oder Backend und Frontend) häufig noch konkrete Fragen aus Projekten, die am Tag vorher aufgetreten sind.

Auch die Teilnahme an Meetings (z. B. Projekt-Jour-Fixe) wird häufig im Standup abgesprochen.

Das Standup hat aus meiner Sicht folgende Funktionen:

• Es regt dazu an, sich vorher Gedanken zu machen, was man für den Tag plant

• Es ist eine Möglichkeit für andere, zu merken, wenn ich in einer Aufgabe feststecke, und mir Hilfe anzubieten

• Es ist ein Synchronisationspunkt (im Anschluss ist Zeit, spontan konkrete Fragen zu besprechen, ohne den Kollegen aus der Arbeit zu reißen)

Früher haben wir auch die Frage gestellt "was habe ich gestern getan", aber das hatte wenig Nutzen und machte das Standup langatmig.

Interne Baustellen

Termin: jeden ersten Freitag des Monats 10 Uhr. Dauer: 1-1,5 Stunden

Einmal im Monat haben wir eine besondere Besprechung. Sie trägt den sperrigen Namen "Status 'Interne Baustellen' und ggf. Entscheidung über das nächste ToDo". Die Idee hinter dieser Besprechung ist, sicherzustellen, dass wir Themen und Prozesse, die für uns als Firma oder Team intern wichtig sind, nicht vergessen. In Kundenprojekten gibt es ja jemanden von außen, der im Zweifel daran erinnert, dass er etwas braucht – bei internen Projekten passiert es leicht, dass sie weniger Aufmerksamkeit bekommen, als sie bräuchten.

Interne Baustellen sind oder waren beispielsweise "Mitarbeitersuche", "Hosting-Umzug nach Frankfurt", "Arbeitszeitverkürzung (aka 30-h-Woche)", "webfactory-Website" oder "Was wir in allen Kundenprojekten berücksichtigen wollen".

Für die Besprechung haben wir folgenden Ablauf festgelegt:

3 Zeiteinheiten à 25 Minuten mit je 5 Minuten Pause (in der Pause sollte nicht weiter diskutiert werden). Jede Timebox endet pünktlich. Die Moderation dieser Meetings wechselt und der Protokollführer ist immer der Moderator des nächsten Meetings.

1. Begrüßung: Kurzer Überblick über das Meeting, Klärung, wer Protokoll schreibt und wer auf die Zeit achtet (kann der Moderator selbst sein)

2. Status der aktuellen internen Baustellen (sollten die im letzten Meeting besprochenen und ggf. zwischendurch ungeplant begonnenen sein). Pro Baustelle:

   1. Kurzer Rückblick auf den Stand beim letzten Meeting durch den Moderator (anhand des Protokolls)

   2. Bericht über den aktuellen Stand durch den Kapitän (also denjenigen, der die Verantwortung für das Thema übernommen hat)

   3. Feedback-/Frage-/Meinungsrunde

3. Möchte jemand neue Themen vorstellen, die wir ins Backlog aufnehmen sollten?

4. Wollen wir neue Themen beginnen? Wenn ja welches und wer übernimmt die Kapitänsbinde und wer ist beteiligt? Wie geht es los? Erstes Brainstorming/"Briefing" durch das gesamte Team direkt im Meeting?

5. Abschluss (Alles gesagt? Brauchen wir mehr Zeit und wenn ja, wann geht es weiter? Protokoll vollständig/Aufgaben klar?)

Wir versuchen, nicht mehr als drei interne Baustellen gleichzeitig zu bearbeiten – also neue interne Baustellen erst dann anzufangen, wenn eine alte abgeschlossen ist.

Das monatliche Meeting stellt zwar nicht automatisch sicher, dass es zwischen den Besprechungen tatsächlich auch weitergeht, aber es schafft Aufmerksamkeit für die Themen, die wir uns als Team vorgenommen haben zu bearbeiten. Und es stellt einen Ort dar, wo wir als Team gemeinsam entscheiden, ob wir ein Thema anfangen wollen.

Die Besprechung ist stärker und anders strukturiert als unsere anderen Besprechungen. Das hat den Grund, dass wir früher gerade bei den internen Themen, die alle angehen, leicht in lange Diskussionen geraten sind. Das strenge Timeboxing mit Pflichtpausen hat uns sehr dabei geholfen, in solchen Diskussionen innezuhalten und ein bisschen Abstand zu gewinnen.

Geschäftsführungs-/Strategie-Jour-Fixe

Termin: Mittwochs. Dauer: ca. 2 Stunden

Ursprünglich hatte ich diesen Termin gar nicht auf dem Schirm für diesen Beitrag, aber tatsächlich ist er für uns nicht unwichtig: Eine feste Besprechungszeit jede Woche für die Geschäftsführung, in der wir an Führungsthemen arbeiten.

Wir haben fast keine formale Hierarchie in der Firma, es gibt nur die beiden Gründer und Geschäftsführer und "alle anderen". Da die webfactory sehr teamorientiert aufgestellt ist und die meisten Entscheidungen durch das ganze Team getroffen bzw. getragen werden, haben wir Gründer uns lange auch als ganz normale Teammitglieder gesehen, mit den gleichen Rechten und Pflichten wie alle anderen. Dabei haben wir übersehen, dass das zumindest in unserer aktuellen Aufstellung als GmbH mit zwei Gesellschafter-Geschäftsführern de facto nicht so ist und wir zwangsläufig eine andere Stellung als die anderen haben. Da immer wieder Themen aufkommen, die im Geschäftsführerkreis abgestimmt oder bearbeitet werden müssen, haben wir diesen jetzt einen festen regelmäßigen Termin eingeräumt, was sich sehr bewährt hat. In den Besprechungen ist regelmäßig ein Vertreter des Teams dabei, der nicht der Geschäftsführung angehört.

Kundenbesprechungen

Neben den internen Besprechungen haben wir auch regelmäßige Kundenbesprechungen.

Jour-Fixe in Fokusprojekten

Termin: Dienstags und Donnerstags 10:30 Uhr. Dauer: ca. 1 Stunde.

Ein Fokusprojekt ist für uns ein Projekt, auf das die Firma sich gerade fokussiert und an dem sie mit einem Team von mehreren Entwicklern arbeitet. Wir versuchen aufgrund unserer Teamgröße von insgesamt 10 Personen, nicht mehr als ein Fokusprojekt gleichzeitig zu bearbeiten, um uns auf dieses wirklich konzentrieren zu können und im Team noch Kapazität übrig zu behalten, parallel Ad-Hoc-Aufgaben für unsere anderen Kunden erledigen zu können. Typischerweise teilen wir das Team immer auf in eine Fokusprojekt-Fraktion und eine Ad-Hoc-Fraktion. Die Aufteilung wechselt im Laufe des Jahres.

Teilnehmer am Fokusprojekt-Jour-Fixe sind immer diejenigen Entwickler, die dem Kunden etwas präsentieren möchten und Feedback brauchen oder Fragen zur Aufgabenstellung haben und zusätzlich grundsätzlich eine Person, die Hauptansprechpartner für den Kunden ist und Kontinuität sicherstellt.

Die Themen für den Jour-Fixe sammeln wir vorab als Checkliste auf einer Projektmanagement-Trello-Karte, die wir für das Fokusprojekt in der Doing-Spalte unseres Kanban-Boards haben.

Jeder Entwickler stellt seine Fragen grundsätzlich selbst und bekommt auch die Antwort aus erster Hand. Dieses Vorgehen ist unsere Näherung an das vierte der zwölf Prinzipien hinter dem Agilen Manifest: "Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten." Für Projekte unserer Größenordnung ist eine tägliche Zusammenarbeit mit dem Kunden nicht erforderlich bzw. findet vorrangig in einer Konzeptionsphase am Anfang des Projekts statt. Die enge Abstimmung zweimal pro Woche hat sich aber sehr bewährt und erfüllt aus unserer Sicht den Zweck des Prinzips ziemlich gut.

Den Jour-Fixe am Dienstag nutzen wir auch zur Präsentation des aktuellen Budgetstands. Da wir Projekte in der Regel mit einem agilen Festpreis oder nach Aufwand abrechnen, gibt dies dem Kunden jederzeit den Überblick über das noch verfügbare Budget und Eingriffsmöglichkeiten, wenn er Prioritäten anders setzen möchte.

Backlog-Abstimmung

Termin: Individuell vereinbart, 10:30 oder 14:30 Uhr. Dauer: ca. 1 Stunde.

Derzeit haben wir eine lange Warteliste für Ad-Hoc-Aufgaben (Aufträge mit einer Größenordnung von unter 10 Personentagen). Wir arbeiten grundsätzlich first-in-first-out, d. h. neue Aufgaben reihen sich am Ende der Liste ein.

Um trotzdem sicherzustellen, dass wir die Aufgaben entsprechend ihrer Priorität für den Kunden abarbeiten, hat es sich für uns bewährt, uns einmal monatlich mit jedem Kunden abzustimmen. Wir bereiten dafür einen Auszug aller Aufgaben des Kunden aus unserem Backlog vor, aus dem die jeweilige Position der Aufgabe in der Warteliste hervorgeht. Wir können dann über die als nächstes Anstehenden Aufgaben sprechen und der Kunde bekommt auch die Möglichkeit, Aufgaben im Backlog zu tauschen, um dringendere Arbeiten auf Kosten weniger dringender Arbeiten zu beschleunigen.

Fazit

Für uns hat sich der Besprechungskalender in der aktuellen Form sehr bewährt. Er stellt sicher, dass jedes Thema seine Zeit hat, nichts zu kurz kommt und wir uns gleichzeitig auch nicht in Dinge vergraben. Auch wenn es viele feste Termine sind, nimmt ja lange nicht jedes Teammitglied an jeder Besprechung teil, sodass reichlich Zeit für konzentrierte Arbeit bleibt.

Worauf wir noch keine Antwort gefunden haben, ist eine Zeit für das Standup, an der wirklich jeder teilnehmen kann. Gerade seitdem wir im Corona-bedingten Homeoffice sind, experimentieren einige mit einer Verschiebung des Arbeitstages hin zu deutlich späterem Arbeitsbeginn. Die sieht man dann manchmal nur Montags oder Freitags, was ich persönlich schade finde. Für andere hingegen ist 9:45 schon fast die Mitte des Arbeitstages.

Wie laufen Besprechungen bei euch? Habt ihr mehr oder weniger Termine? Andere Themen? Wir freuen uns, von euch zu hören.

On GitHub, deploy keys are SSH keys that can be associated with a single repository and granted read-only or read/write permissions. With deploy keys, you don’t need a particular user account to access the repository. Having the key itself suffices – the key is the authentication and authorization token at the same time.

To limit exposure in case such a key is lost, GitHub enforces a policy that a particular SSH key can only be used as deployment key for a single repository.

This becomes an issue when you want to work with several Git repositories at a time, using different deploy keys: When ssh has several keys available, it will try each of them in turn. The first known key will be accepted by GitHub servers for the SSH connection itself. But (some of) the subsequent Git commands run over the SSH connection will fail, since the SSH key is not authorized for the particular repository. You will see an error like

fatal: Could not read from remote repository.
Please make sure you have the correct access rights and the repository exists.

As long as you’re running git commands one by one, you can use the GIT_SSH  environment variable to pass additional arguments to SSH and select the right key for a particular repository. However, when using package managers like Yarn, NPM or Composer that might need to clone several repositories, this won’t work.

Using virtual GitHub.com subdomains?

In this situation, people have suggested (here, there, elsewhere...) to make up (nonexistent) GitHub.com subdomains and use those in repository URLs. Then, additional ssh  configuration could be used to map these names back to github.com  as hostname while at the same time specifying the SSH key to use.

The downside of this approach is that these made-up domain names become part of your dependency declaration file, essentially forcing everyone to provide the same mapping in their SSH config files to be able to install dependencies.

Use key comments to find matching keys in the SSH agent

Thus, I would like to suggest another approach: Put all keys, including GitHub deployment keys, into the SSH key agent. Then, make Git use a wrapper script around ssh  to select the right key.

We will use SSH key comments to record the name of the repository that a key belongs to. And we will use the fact that  ssh -i  can point to a file with a key's public part, and that this key will be tried first even if all private keys and handled by the SSH agent.

So, let’s create a dedicated deploy key first:

ssh-keygen -C "Deploy key for git@github.com/your-org/your-repo.git" -f keyfile …

Add your usual arguments ( -t ed25519 -a 100 , maybe?) to create a new SSH key in keyfile . The key's public part will be put into keyfile.pub , and the key's comment will be set to contain your repository name. As this is a deploy key, don't set a passphrase.

Setup the deploy key at GitHub.com according to their deploy key documentation. Repeat this for every repository in question, and don't forget to use different keyfiles.

Next, make sure you have the SSH agent running, or start it with eval `ssh-agent -s` . Add all your key files to it by running ssh-add keyfile keyfile2 … . You can use ssh-add -L  to list all keys currently loaded into the agent.

The Wrapper Script

Put the following wrapper script somewhere:

#!/bin/bash

# The last argument is the command to be executed on the remote end, which is something
# like "git-upload-pack 'webfactory/ssh-agent.git'". We need the repo path only, so we
# loop over this last argument to get the last part of if.
for last in ${!#}; do :; done

# Don't use "exec" to run "ssh" below; then the trap won't work.
key_file=$(mktemp -u)
trap "rm -f $key_file" EXIT

eval last=$last

# Try to pick the right key
ssh-add -L | grep --word-regexp --max-count=1 $last > $key_file

ssh -i $key_file "$@"

(I've put this into a Gist, so you can also  wget https://gist.githubusercontent.com/mpdude/e56fcae5bc541b95187fa764aafb5e6d/raw/676626f0f8009d8b47743417dba436483cd929c6/ssh-deploy-key-wrapper.sh && chmod +x ssh-deploy-key-wrapper.sh ).

Export the GIT_SSH  environment variable to point to this wrapper script. Now, whenever Git needs to execute ssh , it will start this script instead.

The script will go through the keys currently loaded into the ssh-agent  and grep  the first one that matches the your-org/your-repo.git  part from the current repository URL. This is where the key comment we set up above comes into play.

The key's public part is then put into a temporary file and passed to the actual ssh  invocation. As a result, this key will be tried first, and the private key part will still be provided by the SSH agent.

Den restlichen Tag über war damals die Stimmung im Büro etwas gedrückt – oder vielleicht kam es mir auch nur so vor. Ursprünglich hatten wir jedenfalls vorgehabt, um die Mittagszeit herum bereits nach Hause zu gehen, aber dann zogen sich die vorher noch zu erledigenden Arbeiten doch noch über den Tag – und fast schon schien es, als ob mindestens Einzelne nicht so richtig bereit waren, Abschied zu nehmen. Zu diesem Zeitpunkt war uns vermutlich allen schon bewusst, dass wir uns auf lange Sicht nicht mehr so persönlich begegnen würden, wie noch an diesem Tag. Das Wort „Monate“, schwebte auch da schon im Raum.

Viel vorzubereiten hatten wir im Grunde genommen nicht. Wir machten uns Gedanken darüber, wie die Pflanzen in unserer Abwesenheit versorgt werden, dass wir unseren wöchentlich gelieferten Obstkorb abbestellen müssen und sprachen darüber, dass man zumindest ab und an irgendwie nach der Post sehen müsste. Wir legten einige grobe Regeln für die zukünftigen Arbeitstage fest: Dass sich jeder von uns bis 09:45 Uhr täglich via unserem Arbeits-Chat auf Slack melden würde, zum Beispiel. Dann richteten wir auf den Computern noch Möglichkeiten zum Screensharing ein und viel mehr war dann auch gar nicht mehr zu tun.

Seit dem 10. März diesen Jahres haben wir uns also nicht mehr persönlich gesehen. Viele Wochen sind seitdem vergangen und somit ist es an der Zeit, einmal über unsere Erfahrungen zu berichten: Wie leicht gelang uns der Übergang von Präsenz- zu remote-Firma? Wie geht es uns insgesamt mit dieser neuen Arbeitssituation? Und: Wird dieses unfreiwillige Experiment unsere zukünftige Zusammenarbeit verändern?

Um ein genaueres Bild von der Stimmung und den Meinungen im Team zu bekommen, haben wir mittels Google Forms eine kleine Umfrage durchgeführt. Schauen wir uns die Daten doch nun einmal im Detail an:

In Abbildung 1 sehen wir, dass der Übergang ins Homeoffice einigen im Team gar keine Probleme bereitet hat („die Umstellung aufs Homeoffice ist mir schwer gefallen“), aber die Empfindungen diesbezüglich durchaus gemischter Natur waren. Dass uns als Firma insgesamt der Übergang gut gelungen ist, scheinen allerdings alle (antwortenden) Teammitglieder so zu sehen („die Umstellung aufs Homeoffice hat insgesamt für die Firma gut funktioniert“). Ebenso sehen wir hohe Zustimmungswerte bei „Im Homeoffice kann ich mich gut konzentrieren" (schlechtere Werte wurden vom Team teilweise durch die problematische Kinderbetreuungssituation begründet) und „Ich finde, die Kommunikation untereinander funktioniert auch von zu Hause aus gut“.

Dennoch vermisst ein Großteil der Antwortenden den direkten Kontakt untereinander, wie Abbildung 2 zeigt („Ich vermisse den direkten Kontakt zu meinen KollegInnen“). Überraschend gespalten ist das Team bei dem (nicht ganz ernst gemeinten) Thema: „Ich vermisse die Kaffeemaschine im webfactory-Büro“. Auf Rückfrage erklärten sich einige damit, dass der Kaffee zuhause eben auch recht gut wäre. Na ok. Das können wir wohl so akzeptieren. Das Büro an sich wird dann scheinbar sogar noch weniger vermisst, als die Kaffeemaschine („Ich hoffe, dass wir bald alle wieder ins Büro zurückkehren werden“). Ein spannendes Ergebnis: Niemand scheint so richtig dringend wieder das Homeoffice verlassen zu wollen. Besonders toll auch: Das Vertrauen, dass wir ineinander haben, denn bei: „Ich vertraue meinen KollegInnen/MitarbeiterInnen, dass sie auch im Homeoffice gute Arbeit leisten“, erzielen wir durch die Bank sehr hohe Werte.

Besonders auffällig: Bei fast allen haben sich im Homeoffice die Arbeitszeiten geändert (Abb. 3) und der Großteil von uns hat sogar die persönliche Meinung zum Thema „Arbeiten im Homeoffice“ geändert (Abb. 4). Auf Rückfrage erklärten manche Kollegen, dass sie nicht damit gerechnet hätten, dass es so gut laufen würde, oder dass sie sich im Homeoffice so gut würden konzentrieren können. Ein einzelner (ehemaliger) Homeoffice-Gegner hat seine ablehnende Haltung zum Thema sogar mittlerweile vollkommen revidiert. Positiv heben einige im Team hervor, dass sie sich ihre Arbeitszeit freier einteilen können. Somit fangen manche Eulen beispielsweise später an zu arbeiten (die obligatorische Meldung bis 09:45 Uhr im Teamchat hatte sich dann auch innerhalb von Tagen ganz automagisch erledigt), andere fangen früher an oder machen zwischendurch lange Pausen. Als Schattenseite davon merken Einzelne allerdings an, dass sich der Arbeitstag dadurch insgesamt in die Länge zieht und mindestens einem fällt es zumindest zeitweise schwer, einen Absprung zu finden.

Insgesamt zeigt sich nach den letzten Wochen aber, dass wir erstaunlich gut mit der veränderten Situation zurechtkommen. Ich persönlich gehe davon aus, dass dieses Erlebnis unsere Arbeitsweise langfristig beeinflussen wird, auch wenn sich noch zeigen muss, wie unsere Zukunft im Detail aussehen wird. Manche Teammitglieder wünschen sich, zumindest ab und an, die Möglichkeit, die KollegInnen auch einmal wieder persönlich zu sehen oder ihre Arbeit im Büro zu verrichten. Andere träumen bereits davon, die Welt zu bereisen und von Unterwegs zu arbeiten oder haben für sich festgestellt, dass sie eigentlich gar nicht mehr so richtig ins Büro zurückkehren wollen und der eingesparte Pendelweg eine echte Erholung ist. Auch die Möglichkeit full-remote Kräfte einzustellen, scheint nun nicht mehr ganz fern jeglicher Vorstellung zu sein. Abbildung 5 zeigt allerdings, dass sich so ganz konkret doch niemand vollständig vom Büro distanzieren möchte. Entsprechend nicht ganz ernst gemeint, wurde sogar hier und da schon diskutiert, ob wir das Büro überhaupt noch brauchen. In guter Gesellschaft wären wir mit einer (optionalen) full-remote Firma zumindest: die bekannte social media Plattform Twitter hat bereits angekündigt, nicht mehr zu ihrer vorherigen Präsenzkultur zurückkehren zu wollen.