Wir haben Spaß an der Sache und wir möchten möglichst viel Zeit damit verbringen und möglichst wenig Zeit mit dem umständlichen Drumherum: komplizierte Angebote, Verträge, Pitches, Präsentation, komplizierte schriftliche Absicherungen, Politik, etc. Unsere Kunden vertrauen uns und wir vertrauen unseren Kunden. Uns ist wichtig, in dieses Vertrauen und die Vertrautheit zu investieren. Viele der Gedanken, Ideen und Konzepte die grundlegend für das Denken und Handeln von Klickmeister sind, zielen auf Vertrauen und Vertrautheit ab.

Wir halten uns an Absprachen und sind offen und ehrlich zu unseren Kunden und innerhalb des Teams. Wir versprechen nur Dinge, die wir halten können. Das heißt nicht, dass wir keine Zusagen machen, denn das Team/ der Kunde braucht Zusagen, um sich sicher zu fühlen und orientieren zu können. Aber wenn wir Zusagen machen, halten wir diese ein. Bedingte Zusagen oder kleinere Schritte sind auch in Ordnung.

Wir stehen voll und ganz hinter dem agilen Manifest:

Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge

Der Mensch steht im Fokus und der direkte Austausch ist wichtiger als Formalismen. Das heißt, jeder noch so ausgefeilte und gut dokumentierte Prozess kann ein persönliches Gespräch nicht ersetzen. Der persönliche Austausch ist super wichtig, hilft dem Einzelnen, hilft dem Team und hilft dem Projekt. Dabei sind handelnde Personen für uns nicht nur Teil einer Prozesskette, sondern Menschen mit Bedürfnissen und Zielen. Es hilft enorm, diese Menschen zu kennen und sich für diese zu interessieren. Je größer die Vertrautheit und damit das Vertrauen, desto einfacher die Kooperation. Und das wirkt sich positiv auf das Arbeitsklima und das Projekt aus.

Funktionierende Software ist wichtiger als umfassende Dokumentation

Konkrete Arbeitsergebnisse statt Checklisten, Slidedecks oder lange E-Mails. Gerade in großen Organisationen mit klassischer Projektkultur fließt oft mehr Zeit in die Erstellung von Slidedecks für Lenkungsausschüsse als in die Erledigung der eigentlichen Aufgabe, oder wie ein Kunde neulich so schön sagte: «hier haben wir mal wieder mehr Manager im Projekt, als Leute, die am Produkt arbeiten … ». Wir wollen das möglichst viel unserer Zeit und damit auch ein möglichst großer Teil des Budgets im Arbeitsergebnis sichtbar wird. Darauf müssen wir achten. Wenn ein 3-minütiges Telefonat die Sache auch klärt, ziehen wir es der E-Mail vor, an der wir 15 Minuten sitzen würden. Wenn der PO oder Sponsor Input für seine Präsentation braucht, fragen wir, ob Stichpunkte reichen, usw.

Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlung

Der Kunde nimmt in der Arbeit unserer Teams eine zentrale Rolle ein. Er ist mit seinen Bedürfnissen und Problemen wichtiger Teil des Teams. Eine (persönliche) Auseinandersetzung mit dem Kunden ist dabei wichtiger als ein formaler und möglichst wasserdichter Vertrag. Auch mit diesem Punkt stellt das agile Manifest den direkten Austausch über Formalien. Das Ziel ist, dass wir zusammen mit dem Kunden und anderen Prozessbeteiligten an einem Strang ziehen und uns als ein Team verstehen. Denn letztlich gibt es eine direkte Abhängigkeit. Wir wollen nicht in einen wir-gegen-die Modus kommen. Man merkt das in Projekten sehr schnell, wenn versucht wird «Papierlagen» aufzubauen, auf die sich dann zurückgezogen und berufen wird, auf deren Basis Dinge eingefordert werden. Das heißt nicht, dass wir nichts aufschreiben und dokumentieren wollen, aber es heißt, dass wir kein Papier erzeugen wollen, gegen dass dann gearbeitet werden muss. Es ist wichtig mit Individuen zu interagieren und Individuen zu adressieren. Sobald wir abstrahieren, bildet sich ein wir-und-die, oder schlimmer: wir-gegen-die. An diesem Punkt wird Kooperation schwieriger. Sprecht also von und mit Individuen statt von «den Übersetzern», «der GL» oder «der IT».

Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans

Wir sind als Organisation und Team sehr beweglich und anpassungsfähig. Jedoch bedeutet das nicht, dass wir keinen Plan haben, willkürlich, sprunghaft oder chaotisch arbeiten. Wir sind auf ein Ziel fokussiert, weichen aber auch gerne vom eigentlichen Plan ab, wenn es für uns und das Projekt sinnvoll ist und es Aussicht auf einen höheren Wertbeitrag gibt. Superwichtig! Ein Plan soll uns eine Struktur geben, um ein Ziel zu erreichen. Das Ziel ist es, dem Ziel möglichst nahe zu kommen und nicht den Plan zu befolgen. Das ist ein grundlegender Unterschied. Oftmals ist die Haltung folgende: wir haben ein Ziel und machen einen Plan, um dieses Ziel zu erreichen. Ab dann wird nur noch der Plan verfolgt. Dabei wird das Ziel manchmal aus dem Auge verloren. Wir lernen unterwegs und das verändert den Plan und manchmal auch das Ziel.

Wir respektieren und wertschätzen andere, deren Arbeit und Arbeitsergebnisse. Auch wenn andere vielleicht anders agieren, als wir es uns wünschen würden. Wir machen uns über andere, deren Verhalten und deren Arbeit nicht lustig oder machen sie klein, sondern nehmen sie ernst und schätzen sie wert. Das gleiche gilt auch für uns und unsere eigene Arbeit. Es hilft davon auszugehen, dass die anderen auch meist das Beste geben oder gegeben haben, was sie in dem konkreten Rahmen leisten konnten. Ein kleiner Ausdruck der Wertschätzung (Fachwort: Lob) macht die Welt meist ein kleines Stückchen besser, freut den anderen und wirkt wie ein Schmiermittel für Teams und Projekte.

Die Leute müssen Bock haben, mit uns zu arbeiten.

Wir versuchen uns so aufzustellen und zu verhalten, dass andere gerne mit uns arbeiten. Das kann auf sehr unterschiedliche Arten geschehen und diese haben keinen Anspruch auf Ausschließlichkeit, sondern können beliebig kombiniert werden. Birger hat mal ziemlich am Anfang von Klickmeister die Unterteilung von Mitarbeitern und Teammitgliedern in Energiebringer und Energieverbraucher in unsere Köpfe gebracht. Diese ist natürlich sehr kurz gegriffen und nimmt das Gegenüber sicherlich nicht in seiner Vielschichtigkeit war. Aber es ist trotzdem eine hilfreiche Art der Betrachtung, die nicht nur im professionellen, sondern auch im privaten Kontext angewendet werden kann.

Wir sollten immer Energiebringer sein! Energie kann von uns auf verschiedene Arten ins Team, ins Projekt oder ins Meeting gegeben werden. Hier ein paar Beispiele: gute Laune, positive Ausstrahlung, ernsthafte Auseinandersetzung mit dem Projektgegenstand, Motivation des Teams, Sichtbarmachung von Schwierigkeiten, Vertrauen geben …

So hat es zumindest Stromberg formuliert. Nicht alles, was wir machen ist supercool und macht irre Spaß. Wir sollten versuchen, dass es so ist, bzw. der Anteil an Dingen, die uns happy machen/ befriedigen möglichst groß ist. Aber es wird niemals alles sein. Das müssen wir akzeptieren. Wenn wir jedoch merken, dass wir keinen Bock mehr auf Klickmeister haben: bitte rechtzeitig melden, denn wir können doch vergleichsweise viel verändern. Nicht alles und oftmals nicht sofort, aber mit ein bisschen Vorlaufzeit doch einiges.

Unsere Kundenbeziehungen und damit auch unsere Projekte sind sehr langfristig. Somit arbeiten wir sehr oft im Bestand und selten auf der grünen Wiese. Es ist hilfreich, das zu verstehen und auch zu akzeptieren, gerade wenn man recht frisch im Job ist, denn anders als in der Hochschule, haben wir selten die Möglichkeit den TechStack zu ändern oder im nächsten Projekt einfach mal einen anderen Stack zu nutzen. Vieles ist historisch gewachsen und lässt sich nicht so schnell ändern.

Code, Technologie und Vorgehen verändern sich gerade in unserer Branche extrem schnell. Die das-müsste-man-eigentlich-komplett-neu machen Mentalität ist hier häufig wenig hilfreich. Das Projekt, was vor ein paar Jahren vielleicht noch auf Basis von Framework X der heiße Scheiß war, möchte heute keiner mehr mit der Pinzette anfassen. Aber wenn wir es heute komplett refactoren, wird in ein paar Jahren genau das gleiche passieren. Das heißt nicht, dass wir kein Refactoring machen wollen, ganz im Gegenteil, aber wir machen es aus einer wirtschaftlichen Motivation des Kunden heraus und nicht ausschließlich um die Developer Experience zu verbessern.

Es hilft sich zu vergegenwärtigen, dass das Team, welches das Produkt zur Zeit X erstellt hat, nach bestem Wissen und Gewissen gehandelt hat (→ siehe Wertschätzung), dass die eingesetzte Technologie, so sie ihren Zweck erfüllt, sinnvoll und angemessen ist. Und es hilft sich darüber im Klaren zu sein, dass alles, was wir heute bauen spätestens in 10 Jahren ein «eieiei» bei uns hervor ruft, denn nachher ist man immer schlauer und eigentlich-müsste-man-das-kompett-neu-machen 😉.

Wir mögen unsere Freiräume. Wir können uns leider nicht immer alles aussuchen (Tasks, Aufträge, Arbeitszeiten, Kooperationspartner, etc.). Trotzdem haben wir recht große Freiräume. Der größte Freiraum ist sicherlich die zeitliche und räumliche Flexibilität. Wir haben uns als Klickmeister seit 2010 sehr stark virtualisiert und mit der C-19 Pandemie sind auch unsere Kunden deutlich ortsunabhängiger geworden. Diese Flexibilität können und wollen wir erhalten und nutzen. Zuhause arbeiten, vom Büro aus arbeiten, vom Ferienhaus arbeiten. Alles machbar.

Wir machen Web und web-basierte Software. Am Ende des Tages möchten unsere Kunden lauffähige, nutzbare und gute Produkte von uns bekommen. Ein schöner Job, bei dem man, wenn alles gut läuft auch schon mal Flow-Erlebnisse haben kann. Das ist schön, macht Spaß und hilft dem Produkt.

Das funktioniert aber nur, wenn wir ausreichend zusammenhängende Zeiten habe, um in den Tunnel zu kommen. Jedes Meeting, jeder Chat, jedes Pling lenkt ab. Daher versuchen wir uns möglichst viel Zeit zu blocken. Meetings und Absprachen sind super wichtig, aber neigen dazu, als wichtiger eingeschätzt zu werden, als Flow-Entwicklungszeit. Das ist aber nicht so. Wenn wir keine Zeit zum konzentrierten entwickeln haben, werden wir am Ende kein Produkt in den Händen halten, egal wie gut wir uns abgesprochen haben.

Miriam hat mal den schönen Satz geprägt: «Ich arbeite hier nicht in der Notaufnahme.» Und das stimmt. Natürlich machen wir total wichtige Sachen, aber in der Regel hängen keine Menschenleben daran. In unserem Kontext sind alle Termine von Menschen gemacht. Sie folgen keinen Naturgesetzen und sind somit änderbar. Wir wollen langfristig mit Freude an der Sache arbeiten. Und wir müssen selbst darauf achten. Besser ein «Kein Problem, das Feature können wir übernächste Woche liefern.» als ein «Ja ok, ich guck mal, dass ich das irgendwie bis Dienstag hinbekomme». Unvereinbarkeiten sollen und dürfen explizit gemacht werden: «Wenn das Dienstag fertig sein soll, müssten X und ich das am Sonntag machen, ist das wirklich so wichtig?» oder «Wenn das am Dienstag fertig sein soll, müssen wir dies oder jenes erst mal liegen lassen, passt das?». Ein Nein ist eine legitime Antwort. Und wir müssen dieses Nein in der Regel nicht kleinteilig begründen.

Druck von außen versuchen wir intern zu minimieren - eine rationale Betrachtung von Sachverhalten hilft dabei oft - und: wir geben den Druck nicht an Dritte weiter. Wir wollen nicht getrieben werden, und das wollen andere auch nicht. Über Prioritäten kann man sachlich informieren und diese begründen. Es muss nicht unnötig Cortisol ausgeschüttet werden.

Sprache hat einen verblüffenden Einfluss auf das Denken und damit auch auf das Handeln. Wir versuchen professionell zu agieren. Leider werden in Meetings und anderen Kommunikationssituationen, interessanterweise gerade von Entwicklern, häufig Begrifflichkeiten genutzt wie: basteln, frickeln, fummeln, wimmsen, kloppen, tackern, usw. … «Ich hab da schon mal was gebastelt.», «Wir müssen da nur noch die Daten rein kloppen.», «Da muss ich nur noch die Overlays rein tackern.», klingt natürlich ein bisschen heiter, ist aber wenig wertschätzend und professionell.

Wir prüfen die Angemessenheit der Begriffe, die wir verwenden. Wir müssen unsere Arbeit nicht, durch komplexe Sprache und Begriffe unnötig verkomplizieren, aber wir sollten eine werthaltige, verständliche und professionelle Sprache in freundlicher, verbindlicher und entspannter Tonalität nutzen. Bitte keine Amtssprache. Danke!

Wir sollten versuchen unsere Arbeitszeit so positiv wie möglich zu gestalten. Wenn uns etwas dazu fehlt, dann sprechen wir es an und versuchen es zu verbessern. Es ist erst mal egal, ob es um andere Projekte, eine andere Struktur des Team Meetings, mehr oder weniger Arbeitszeit, Hard- oder Software oder ein HomePod geht. Es geht sicherlich nicht alles, aber fragen kostet nichts. Defizite die wir nicht kennen, können wir nicht ausgleichen.

Wir wollen besser werden, beim Coden, beim Konzeptionieren, beim Umgang im Team, usw. Jede Idee, wie wir als Organisation oder wie einzelne Teams, Projekte etc. besser werden könnten, hilft. Wir nutzen Meetups, Workshops, Gespräche und Fortbildungen. Gerade Meetups geben Ideen, Inspiration und helfen bei der Einordnung der eigenen Stärken und Schwächen.

Wir teilen unser Wissen im Team. Wir versuchen wichtige Projekte mit Fahrer:in und Beifahrer:in zu machen. Wir wollen bei jedem wichtigen Projekt in der Lage sein, Fahrer:in und Beifahrer:in zu tauschen und es sollte möglich sein, dass der Fahrer in Urlaub ist oder krank wird. Dafür ist nicht die Geschäfts- oder Teamleitung verantwortlich sondern jeder Fahrer selbst. In regelmäßigen Abständen sollte bitte jeder seine Projekte und Themen und überprüfen, ob es entsprechende Beifahrer:innen gibt und ob diese in der Lage sind, eigenständig im Projekt zu agieren. Falls nicht: ermächtigen wir sie oder ihn dazu.

E-Mails

Wir brauchen uns in der Regel nicht großartig nach allen Seiten absichern. Dies ist ein Grund mehr, E-Mail Verteiler möglichst klein zu halten. Dann bekommen wir auch selber weniger Mails. Wenn wir E-Mails verfassen ist die Tonalität freundlich, professionell (aber nicht förmlich), entspannt, prägnant und verständlich. Bei komplexen Themen ist es sehr hilfreich sein Gegenüber, oder die wichtigsten Adressaten vorab telefonisch vorzuwarnen oder abzuholen, gerade wenn die Mail an mehrere Leute geht. Wir verwenden keine Versalien im Betreff! Niemals!

Sprechen hilft

E-Mails sind toll. Aber für viele Dinge komplett ungeeignet. In einem Telefonat oder Voice-Chat lassen sich viele Dinge einfacher, entspannter, heiterer und wesentlich schneller klären oder erklären.

Strategisches Duzen

Wir versuchen Duz-Siez Gefälle in Teams zu vermeiden. Das geht nicht immer, aber oft. Ziel sollte daher sein: wenn einer von uns den Kunden duzt - dann duzen alle. Das Du baut Distanz ab und ist einer partnerschaftlichen Zusammenarbeit förderlich. Falls wir in der Kommunikation unsicher sind, fragen wir im Team oder beim Kunden selbst z.B. «ich hoffe es ist o.k., wenn ich das Du verwende, sonst bitte beschweren … ».

Jedes Meeting braucht ein Ziel. Jeder sollte vor einem Meeting wissen, was sein Ziel ist. Wenn man das nicht weiß, ist man vielleicht gar nicht relevant für das Meeting. Das Beste an Meetings ist, dass man ein bisschen Smalltalk machen und die Leute besser kennen lernen kann. Nutzt das! Also nicht kommen, «Hallo» sagen, Rechner aufklappen und E-Mails checken, sondern kommen, «Hallo» sagen und ein bisschen quatschen. Es hilft immer!

Wir achten darauf, in nicht zu vielen Meetings zu sitzen und die Meetingtaktung maximal die Hälfte unserer Arbeitstage diktiert. Von Meetings ist noch kein Softwareprojekt fertig geworden.

Bei wichtigen Meetings sprechen wir uns vorab mit den wichtigen Leuten ab und vermeiden Überraschungen im Meeting selbst. Oftmals ist es sehr hilfreich ein problematisches oder wichtiges Thema mit dem «größten Widersacher/ Zweifler/ Gegner» durch zu sprechen.

Der Witz bei Dailys: sie finden jeden Tag statt. Wer hätte es gedacht. Sie sollten möglichst kurz sein. Wir achten darauf, dass wir uns kurz fassen und nur Dinge besprechen, die mehrere Teilnehmer betreffen. Alles andere klären wir außerhalb von Dailys. Wir weisen darauf hin, wenn ein Daily zu lange dauert oder Themen besprochen werden, die nicht ins Daily gehören. Alles was länger als 20 min dauert bremst. Wir sind im Daily wach, haben den Finger am Mute Button und lesen keine Mails oder anderes Zeug parallel!