In der heutigen Arbeitswelt sind wir es gewohnt, komplexe Aufgabenstellungen in kleineren oder größeren Teams zu lösen. Probleme, Aufgaben oder Projekte versuchen wir mal mehr, mal weniger erfolgreich zu strukturieren und die gemeinsame Arbeit daran zu vereinfachen. In der IT ist diese Disziplin der Teamarbeit sicherlich mit am meisten ausgeprägt. Es gibt unzählige Tools die uns bei der Koordination von Aufgaben in Projekten unterstützen. Manchmal gelingt es besser, manchmal aber eben auch schlechter. Warum ist das so? Warum kommen wir immer wieder mal an einen Punkt wo wir uns sagen ‘das hätte eigentlich besser laufen sollen’. Gerade in der IT versuchen wir dann meist mit Hilfe eines neuen Tools das Problem künftig besser in den Griff zu bekommen – oder wenn wir richtig innovativ sind, programmieren wir uns gleich selbst ein solches Tool. Das ist übrigens auch der Grund warum es so extrem viele Projektmanagement Softwarelösungen am Softwaremarkt gibt.
Wenn Projekte scheitern oder Aufgaben nicht erledigt werden, liegt es aber nicht an den eingesetzten Tools. Diese können maximal helfen schneller zu erkennen, dass ein Projekt scheitert oder eine Aufgabe so nicht lösbar ist. Der Grund sind wir Menschen. Wie wir mit einander umgehen, kommunizieren und uns gegenseitig helfen. Es sind Sympathien und Antipathien die uns in der täglichen Zusammenarbeit erfolgreicher oder weniger erfolgreich machen. In ‘modernen’ Unternehmen wird durch Teambuilding Maßnahmen und gemeinsamen Klettertouren versucht dieses Problem in den Griff zu bekommen. Aber wenn ein Projekt zu scheitern droht ist es dafür meist schon zu spät.
Da ich mich selbst viel mit Workflows und Softwarelösungen im Bereich Prozessmanagement befasse, frage ich mich ob es überhaupt eine ‘technische’ Lösung für dieses Problem gibt. Vermutlich nicht da – zum Glück – Computer nicht in der Lage sind unsere Emotionen zu erfassen und verstehen können. Es bleibt also die Frage – wie kann ich selbst in Projekten erfolgreich bleiben. Unabhängig von der jeweiligen zwischenmenschlichen Situation? Eine typische Aussage bei einem Problem lautet zum Beispiel: ‘das hatten wir aber so abgestimmt’ , oder auch ‘das hatten wir so nicht besprochen’. Es wird also häufig die Fähigkeit zur Zusammenarbeit angezweifelt und auf unterschiedlichste Weisen Emotionen ins Spiel gebracht. Ich will hier gar nicht weiter auf die tiefer liegenden Gründe in unserer Psyche eingehen, die verantwortlich sind für solche Situationen. Dominantere Persönlichkeiten können meist besser damit umgehen als weniger dominante Team Mitglieder.
Das technische Problem
Wenn ich jetzt zurückkomme auf die rein technische Lösung meine ich damit die Tools welche wir einsetzen um Probleme zu vermeiden und Projekte erfolgreich zu managen. Wie oben ausgeführt liegt die Qualität des Tools nicht im Tools selbst sondern wird letztlich durch die Kooperationsfähigkeit des Teams beeinflusst – was uns manchmal glauben lässt das eine Tool wäre wesentlich besser als das andere.
Normalerweise arbeiten wir stets nach folgendem Schema:
Wir erstellen eine Liste mit Aufgaben, Fragen, Forderungen oder Vorschlägen. Diese Liste wird Allen zugänglich gemacht. Es wird vereinbart wer sich wann um welchen Punkt kümmert und aktualisieren dann die Liste regelmäßig mit den Ergebnissen.
Das Problem das hier entsteht ist, dass wir uns in der Regel von anderen abhängig machen. Das ist im Grunde zunächst nicht schlimm und natürlich auch die Grundlage von Teamarbeit. Das Problem ist nur, dass wir – je nach Zusammensetzung des Teams und den besagen gegenseitigen Sympathien und Antipathien – uns gegenseitig beginnen blockieren. Das passiert weil es irgendwo diffuse Strömungen von Abneigung, Neid oder Hass gibt. Im Ergebnis erkennen wir nur das wir nicht vorankommen oder uns vorgeworfen wird eine Aufgabe falsch angegangen zu haben. Die zuvor im Team abgestimmte Aufgabenliste hilft jetzt nicht mehr viel. Denn diese lässt in der Regel viel zu viel Interpretationsspielräume offen. Eine Formulierung war missverständlich oder vielleicht sogar fehlerhaft.
Die technische Lösung
Die Lösung dieses Problems besteht im Grunde darin die Abhängigkeiten die entstehen und durch Tools meist formalisiert werden nun aufzulösen. Das klingt zwar zunächst im Lichte des hochstilisierten “Social-Media-Zeitalters” ketzerisch, ist aber möglicherweise der einzige erfolgversprechende Weg. Anstatt darauf zu vertrauen, dass eine gemeinsame Aufgabenliste von allen gleich wahrgenommen, interpretiert und abgearbeitet wird, ist eine persönliche Aufgabenliste der erfolgreichere Weg. Gemeint ist eine Art Logbuch ähnlich dem der früheren Sehfahrer. Logbücher hatten damals die Funktion sämtliche Ereignisse und Abläufe während einer Seereise zu dokumentieren. Eine spontane Abstimmung mit der Admiralität war dem Kapitän eines einzelnen Schiffes damals gar nicht möglich. Dennoch war nach erfolgreicher Ankunft am Heimathafen klar nachvollziehbar was geschehen ist. Für die Planung und Entscheidung künftiger Fahrten waren diese Logbücher die einzige Grundlage. Übertragen auf die IT bedeutet das, dass wir bei der Bearbeitung von Aufgaben zunächst diese unabhängig von anderen Einflüssen betrachten und sämtliche Arbeitsschritte in einer Art persönlichem Logbuch protokollieren. Jede Aufgabe weist also ein Protokoll auf, das alle Tätigkeiten, Ereignisse und Herausforderungen dokumentiert. Interessant ist das wir das selbe von Software erwarten – ein Server der keine Logdateien erzeugt wäre kaum akzeptabel.
Durch ein so aufgebautes Aufgabenmanagement können nun auch die einzelnen Aufgaben in einem Team besser abgestimmt werden, da die Hintergründe zu einer Aufgabe klar und einfach nachvollzogen werden können. Eine Interpretation der Aufgabenstellung durch den Einzelnen ist immer noch gegeben. Aber eine Abstimmung bei einem gemeinsamen Vorgehen erfolgt nun tatsächlich auf den Erfahrungen und Erlebnissen jedes Einzelnen und nicht auf Annahmen über den erwarteten künftigen Verlauf. Aus Sicht eines Softwareentwicklers wird bei diesem Konzept schnell klar das sich diese Aufgabenlisten nicht mehr mit einem einzelnen Excel Sheet lösen lassen 😉
Auf Scrum übertragen entspricht diese Idee einem Backlog mit Protokollfunktionalität..