Eineinhalb Jahre ohne Blog-Eintrag. Damit habe ich selbst einen unserer beliebtesten Kardinalfehler abgeliefert, der uns Software-Menschen so oft begleitet: Mangelnde Kommunikation. Ich habe mich nicht gemeldet, weil es keinen erwähnenswerten Fortschritt gab bzw. ich keine Zeit hatte, diesen zu dokumentieren.
So ziemlich am Anfang meines Berufslebens ging mir das mal ähnlich, jedoch im zeitlich kleineren Rahmen. Die Software, die ich damals betreute, hatte einen Fehler, der schnell behoben werden sollte. Es handelte sich um eine Webanwendung, auf die ich produktiven Zugriff hatte, also stand dem Bugfix technisch nichts im Wege. Ich musste jedoch zuerst den Fehler finden und beseitigen. Ich versenkte mich also in die Tiefen des Codes und analysierte, was das Zeug hielt. Wer das auch schon mal gemacht hat, weiß, dass man dabei oft hochkonzentriert sein muss, um die internen Abläufe der Software zu verstehen, besonders bei „historisch gewachsenem“ Code, dessen Design durch kleine „Ergänzungen“ gerne ein wenig verschleiert wird. Leider kam alle halbe Stunde mein Chef zur Tür rein mit der Frage, wann ich denn fertig wäre. Nach dem dritten Mal verwies ich ihn meines Büros. Begründung: „Wenn Du alle paar Minuten nachfragst, werde ich nie fertig, weil ich mich jedes Mal von vorne in die Materie hineindenken muss! Ich melde mich, wenn ich fertig bin.“
Analyse der unterschiedlichen Motivationen: Mein Chef in der Rolle des Projektleiters wollte einerseits Statusmeldungen, wie weit ich bin, andererseits einen Zeithorizont, wann ich fertig bin. Den Status wollte er wissen, um einschätzen zu können, ob weitere Maßnahmen erforderlich wären. Es wäre ja möglich, dass ich den Fehler nicht so einfach beheben könnte. Der Zeithorizont war wichtig für den Kunden. Ich hingegen wollte meine Ruhe, um mich in die Materie hineindenken und den Fehler nachhaltig beseitigen zu können. Dann würde ich Vollzug melden, und alles wäre gut.
Abstrakt betrachtet wollen Projektleiter also vor allem zwei Dinge, Statusmeldungen zur Einschätzung der aktuellen Situation und einen Zeithorizont. Wozu? Projektleiter stehen selbst unter dem Druck, Termine zu nennen, manchmal nur, weil der Kunde es will, oft aber tatsächlich sinnvoll, weil andere Aktionen vom Zeitplan abhängen. Wenn die aktuelle Situation darauf hindeutet, dass der anfänglich genannte Zeitplan nicht eingehalten werden kann, müssen sie das weitergeben und vielleicht eine Interims-Lösung finden. Dazu wollen sie regelmäßige Statusberichte, um sich selbst ein Bild machen zu können.
Wir Softwareentwickler gelten im Allgemeinen als kommunikationsfaul. Dieser Ruf entsteht vor allem dadurch, dass wir nur Erfolge melden, die wir als erwähnenswert erachten. Wir leben so eine Art Event-basierte Kommunikation. Statusmeldungen behindern uns im Arbeitsfluss, weil wir den Code-Wust verlassen und auf die Metaebene wechseln müssen. Zeitschätzungen geben wir nur dann ab, wenn wir den Lösungsweg kennen und somit in der Lage sind, verlässliche Zahlen zu liefern. Wenn wir den Prozess des Bugfixings betrachten, sehen wir zwei grobe Schritte: Die Analyse und die eigentliche Fehlerbehebung. Erst nach der Analyse kennen wir die Ausgestaltung darauffolgenden Einzelschritte, die da sind: Code ändern, testen, integrieren, raus damit. Dafür können wir gute Zahlen liefern, für die Analyse normalerweise nicht, denn das ist meist nur ein Mittelwert aus früheren Analysen und kann nur durch Erfahrung, entweder mit der konkreten Software oder allgemeiner Berufserfahrung, verkürzt werden.
Ein Vorschlag zur Güte: Melden wir nach der Analyse eine Bearbeitungsdauer, ist das ein einigermaßen belastbarer Wert. Also nehmen wir uns nach der Analyse die Zeit, eine Schätzung vorzunehmen. Dazu brauchen wir zwei Dinge von unserem Projektleiter, nämlich die Freiheit, die Analyse ohne Zeitplan zu beginnen, und die Zeit zum Schätzen, die wiederum die Fehlerbehebung verzögert. Das muss der Projektleiter dem Stakeholder erklären. Verfolgen wir weiterhin die Idee der Event-basierten Kommunikation, können wir auch durch die Festlegung und Bekanntgabe der Prozessschritte für uns ein paar zusätzliche Events auslösen, zu denen wir dann eine Meldung abgeben. Ein Bugtracking-Tools unterstützt uns sogar dabei, wenn wir dieses parallel zur Bearbeitung auch pflegen.
Arbeiten wir agil, können wir normalerweise darauf verzichten, Statusmeldungen „zwischendrin“ abzugeben, da mit einem Daily Standup ein Zeitpunkt festgelegt ist, an dem über den Status gesprochen wird. Da haben alle anwesend zu sein, vor allem diejenigen, die diese Informationen wünschen. Ich bin ein großer Fan „offener“ Dailies, d.h. jeder darf zuhören. Und wenn der Projektleiter (oder wie auch immer die Rolle im konkreten Prozess heißen mag) eine Frage stellt, kann man ihm diese auch beantworten, selbst wenn er im festgelegten Prozess eigentlich nur als Zuhörer vorgesehen ist. Es geht ja nur darum, lange Diskussionen am Board zu vermeiden. Diese werden nachgelagert, falls dazu Bedarf besteht.
Damit ist auch implizit die Frage geklärt, ob Informationen eine Bringschuld oder eine Holschuld sind. Das hängt von der Art der Information ab. Fortschrittsmeldungen sind eindeutig eine Bringschuld, dafür sind wir Entwickler zuständig. Zeitschätzungen typischerweise auch, jedoch muss klar sein, dass eine Schätzung selbst Zeit kostet. Statusmeldungen sind eine Holschuld des Projektleiters (ich bleibe einfach bei dieser Rollenbezeichnung), aber in unserem eigenen Interesse geben wir als Entwickler entweder selbst Bescheid oder wir vereinbaren feste Zeiten, zu denen die Information überbracht wird. Lässt sich der Projektleiter nicht auf diese festen Zeiten ein, muss er auch damit leben können, aus dem Entwickler-Büro geworfen zu werden.
Ähnlich wie in meinem aktuellen Projekt, in dem sich die Kollegin aus dem Fachbereich zwar beschwert hat, nicht über den Status informiert zu werden, sich aber auch nicht auf eine regelmäßige Telefonkonferenz einlassen wollte. Dann muss sie leider damit leben, bei Eintritt eines Events (z.B. Fertigstellung) informiert zu werden und sonst nicht. Schließlich impliziert allein das Wort „regelmäßig“ die Festlegung einer Kadenz.
Das ist wieder ein Grund, warum ich am liebsten agil arbeite. In den meisten agilen Prozessmodellen sind die Kadenzen festgelegt, und dadurch wird die Kommunikation vom Prozess selbst unterstützt. Und eines der Prinzipien hinter dem agilen Manifest lautet: „Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht.“