Happy Birthday, Teamworkblog

Das Teamworkblog wird 10 Jahre alt. Das ist eine Gelegenheit, um hinter die Kulissen zu blicken und die Frage zu stellen, ob wir weiter schreiben sollen.

Wie fing alles an?

Foto von cottonbro von Pexels

Am 1. Januar 2012 hat Wolf den ersten Beitrag im Teamworkblog veröffentlicht. Wir hatten damals die Idee, gemeinsam ein Blog zu betreiben. Damit solche Ideen nach dem ersten Enthusiamus nicht gleich wieder sterben, hatten wir zunächst 52 Ideen gesammelt. Wir wollten wissen, ob wir ein ganzes Jahr mit Beiträgen füllen können. Das hat bekanntlich geklappt: über 770 Beiträge sind seit in den 10 Jahren entstanden. Seitdem erstelle ich am Ende eines Jahres einen Redaktionsplan. Ich frage ab, wer wie viele Beiträge schreiben möchte und mache daraus eine Liste. Manchmal bleiben Lücken, aber die füllen sich auch irgendwie.

Wir wollten das Teamworkblog bewusst nicht als Blog einer Firma betreiben. Uns war wichtig, dass wir unterschiedliche Sichten auf Arbeiten in einem Team darstellen und dass die Autor:innen gemeinsame Werte teilen.

Für Suchmaschinenoptimierung ist das natürlich eine Katastrophe: es gibt keine eindeutigen Schlüsselwörter für unser Blog; es gibt kein klares Firmenprofil. Wir haben alle Tracker, die wir abschalten können, herausgenommen. Wir schalten hier keine Anzeigen. Trotzdem haben die Zugriffszahlen über die Jahre zugenommen. (Ich gehe davon aus, dass der Großteil der Zugriffe von Suchmaschinen und weniger von Menschen kommen.)

Monatliche Zugriffe 2012-2021

Was ist unser Ziel?

Wir haben schnell festgestellt, dass wir durch das Teamworkblog nicht reich werden. Es kamen keine Aufträge allein auf Grund unserer Blogbeiträge herein. Anzeigen und Werbebeiträge wollten wir nicht schalten. Es gibt da auch das ganz praktische Problem: Nach welchem Schlüssel sollten wir die Erlöse auf die Autor:innen verteilen?

Weshalb bloggen wir dann? Ich kann für die Beiträge von Wolf und mir sprechen. Unsere Beiträge sind ein Schaufenster in unsere Werkstatt. Sie zeigen, woran wir arbeiten und mit welchen Themen wir uns beschäftigen. (Das Praxisbuch Informationsmanagement ist zum Beispiel eine überarbeitete Sammlung von Beiträgen.) Viele meiner Beiträge sind aus Beratungssituationen heraus entstanden. Ich habe Dinge für Kunden zusammengefasst, damit sie es noch einmal nachlesen oder an Kolleg:innen weiterleiten können.

Für meine Beiträge sind mit folgende Punkte wichtig:

Ich möchte meine Arbeitsergebnisse teilen. Ich habe viele Dinge von anderen Leuten nutzen dürfen. Deswegen möchte ich auch etwas zurückgeben.
Es soll klar sein, wer mein Denken beeinflusst. Deswegen gehören in die Beiträge Angaben zur Literatur oder anderen Quellen.
Bei aller Liebe zu Methoden und handwerklichen Details: es geht mir um gesellschaftliche Verantwortung.
Eine gute Lesbarkeit, d. h. ein Flesch-Grad um die 60 oder noch höher und beim Blablameter will unter 0,3 bleiben.

Was haben wir erreicht?

Auf Grund unserer Beratungs- und Trainingstätigkeit sind viele Beiträge zum Thema Agiles Arbeiten und Scrum entstanden. Da sind wir offensichtlich eine Stimme, die gehört und zitiert wird. Die Beschreibung des Ubongo Flow Games ist der am häufigsten aufgerufene Beitrag.

Ich freue mich, dass wir über die Jahre mehr Autor:innen gefunden haben, die ihr Wissen teilen.

Der größte Erfolg ist für mich aber ein anderes Blog, das des Forums Agile Verwaltung. Wolf hat unsere Arbeitsweise mit zum Forum genommen, dort zu großer Blüte geführt und viele Menschen inspiriert.

Wie geht es weiter?

Es gibt noch genug Themen, die wir in unserer Gesellschaft angehen müssen. Keiner kann die Probleme allein lössen. Wir können es zusammen tun und die Lösungen, die von diversen Teams entwickelt werden sind besser, als Lösungen von Einzelpersonen oder von homogenen Teams. Aber Teamarbeit kann auch anstrengend und kräftezehrend sein. Deswegen lohnt es sich, Zeit für das Nachdenken über die einge (Team-) Arbeit zu reservieren.

Wir werden also weiter über Konferenzen, Bücher, Arbeitsweisen und Tools schreiben. Es motiviert uns, wenn unsere Beiträge geteilt und zitiert werden.

Wenn unter unseren Leser:innen eine Person ist, die selbst überlegt ein Blog zu betreiben, ist hier unser Rat: Tut es einfach. Schreiben macht Spass. Etwas Planung und ein paar Gleichgesinnte machen es noch etwas einfacher.

In diesem Sinne wünsche ich im Namen aller Blogger:innen hier unseren Leserinnen und Lesern einen guten Start ins Jahr 2022. Möget Ihr im Team Eure Ziele finden und erreichen.

Euer Jan Fischbach

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Agile Sternbilder: Die Entdeckung kosmischer Agilitäts-Superkräfte

Hast du dich je gefragt, ob dein Sternzeichen deine Fähigkeiten in einer agilen Arbeitsumgebung beeinflusst? In diesem Blogpost tauchen wir ein in die faszinierende Welt der Astrologie und ihre mögliche Verbindung zu modernen Arbeitsweisen. Entdecke, wie die Sterne deine agilen Stärken prägen könnten. Ob überzeugter Agilist oder neugieriger Sternzeichenliebhaber – dieser Artikel kann dir neue Perspektiven eröffnen und vielleicht sogar dein nächstes Teamprojekt inspirieren!

Building Bridges

How many times have I rolled my eyes at the assertion, “But, you can’t build a bridge with Scrum”? The claim annoys as much for its misunderstanding of Scrum as for its naïve view of projects. Curiously enough, I recently discovered support for Scrum in a recent book about big projects. Maybe you can build a bridge with Scrum after all.

Den passenden Job finden

Hier teile ich, wie ich daran arbeite, endlich den richtigen Job zu finden. Kleingedrucktes: Dieser Artikel richtet sich (natürlich) an jene, die gerade in der luxuriösen Position sind, dass sie nicht jedes Angebot annehmen müssen. Anstatt von Engagement zu Engagement zu hetzen und frustriert zu sein über Konzernstrukturen, fehlende Ausrichtung und die Erkenntnis, dass in einem selbst beständig die Hintergrundfrage nagt, ob es das ist, womit man seine immer knapper werdende Lebenszeit wirklich verbringen möchte, gibt es manchmal auch die Möglichkeit, die nächste berufliche Station etwas nachhaltiger auszusuchen - auch, um tatsächlich (etwas) mehr beitragen zu können.

Prozessorientierte Dokumentation - Wie geht das?

Bestimmte Softwareprodukte brauchen eine Dokumentation, damit neue Anwender:innen schnell lernen, wie sie mit der Software arbeiten können. Aber wie entsteht diese Dokumentation? Wie lange dauert das?

Die Microsoft Teams-Not-To-Do-Liste

Viele hoffen, dass es für die Einrichtung von Microsoft Teams den Königsweg gibt, den perfekten Plan – doch den gibt es leider (oder glücklicherweise?) nicht. Genauso wenig, wie es jemals einen Masterplan für die Organisation von Gruppenlaufwerken gab, gibt oder je geben wird. Was gut und vernünftig ist hängt von vielen Faktoren und ganz besonders den Unternehmensprozessen ab. Sicher ist nur eines: Von alleine entsteht keine vernünftige Struktur und schon gar keine Ordnung. Dafür braucht es klare Entscheidungen.

Agilität ist tot. Ausgerechnet jetzt?

Agilität wird zurückgefahren, Hierarchien kehren zurück. Doch ist das wirklich der richtige Weg in einer Welt, die immer unberechenbarer wird? Oder erleben wir gerade eine riskante Rolle rückwärts?

Wie beschreibt man einen Workshop für eine Konferenz?

Konferenzen bieten immer ein gutes Forum, um sein Wissen und seine Erfahrungen zu teilen. Was für die Vortragenden selbstverständlich scheint, ist für die Besucher:innen oft unverständlich. Wie können Vortragende ihren Workshop in 2-3 Sätzen beschreiben, damit die Besucher:innen schnell einschätzen können, er sich für sie lohnt?

Gemeinsam eine Anwenderdokumentation erstellen

Unternehmenssoftware ist ein wichtiges Bindeglied zwischen Anwenderinnen und Anwendern, den Unternehmensprozessen und den Ergebnissen. Normalerweise schreibt der Hersteller der Software die Dokumentation für diejenigen, die die Software benutzen. Wenn die Software allerdings stark angepasst wurde, muss die Dokumentation von denen kommen, die die Prozessmaschine am besten verstehen - den Anwenderinnen und Anwendern. Wie könnte man das praktisch machen?

Der Softwareeisberg, die Softwarepyramide - Wie sprechen wir über neue Software?

Software ist aus den Geschäftsprozessen vieler Unternehmen nicht mehr wegzudenken. Sie verwaltet Kunden- und Produktdaten. Sie automatisiert Abläufe und verhindert Fehler. Aber Software veraltet. Was machen wir, wenn wir Unternehmenssoftware erneuern müssen? Von den ersten Konzepten bis zum ersten Release ist es ein weiter Weg, mit vielen Entscheidungen. Wie sprechen wir über diese Entscheidungen?

Das Teamwork-Blog

Dieses Blog durchsuchen