"Auf die aktuelle Situation in dem Projekt nicht passen" ist Business-Sprache und bedeutet eigentlich: "Das erscheint uns nicht sinnvoll, hier können wir sparen." Häufig werden dann wichtige inkompatible Rollen in einer Person vereint oder Planungsmeetings, Schätzungsrunden und Feedback-Mechanismen zusammengestrichen - alles Einsparungen, die die Kommunikation innerhalb des Projekts stark einschränken. Gerade in Projekten, bei denen Mitarbeiter zu viel zu tun haben und die unbedingt zu haltenden Termine eigentlich zu knapp sind, sprechen die Sub-Teams weniger miteinander; stattdessen entsteht ein Gegeneinander.

Seit ich als Freiberufler arbeite, sind mir diese Probleme noch einmal bewusster geworden. Denn als Freelancer komme ich oft in Projekte, die schwierig sind und bei denen in einem letzten Rettungsversuch ein paar neue, erfahrene Entwickler dazugeholt werden. Ein Vorgehen, das so verbreitet ist, dass Freiberufler untereinander davon sprechen, "auf tiefrote Projekte gekippt zu werden".

Steigt man in ein solches Projekt ein, sieht man immer wieder die gleichen Probleme - und zwar viel deutlicher als Kollegen, die von Anfang an dabei waren und in der Zeit mit angesehen haben, wie sich die Dinge in die falsche Richtung entwickelt haben, immer nur ein kleines bisschen weiter, kaum wahrnehmbar. Man sieht es an den Kommentaren im Ticketing-System, ob und was da eingetragen wird, am Miteinander in Meetings und wie diese organisiert sind, und daran, wer mit wem überhaupt spricht, einfach so auf dem Gang.

Wenn im Specification Review alles abgelehnt wird

Und man sieht es daran, ob Arbeitsschritte eingebaut und ernstgenommen werden und welche die Kommunikation unterstützen - wie zum Beispiel das Specification Review. Es soll sicherstellen, dass einzelne Arbeitspakete hinreichend eindeutig spezifiziert sind, alle Informationen enthalten, die für eine Umsetzung benötigt werden, und dass abschätzbar ist, wie viel Zeit eine Umsetzung braucht. Im Scrum-Prozess ist dies Teil der Backlog-Pflege, die gemeinsam von Product Owner und dem Entwicklerteam durchzuführen ist.

Wird dem nicht genug Zeit eingeräumt, nehmen sich einzelne Entwickler oft ein Arbeitspaket-Ticket vor, schauen kurz drüber, entscheiden, dass da was fehlt, verpassen ihm den Eintrag "nicht genügend spezifiziert" - und geben es damit an die Kollegen aus der Fachabteilung zurück.

Das ist wenig hilfreich, denn es ist keine fundierte Kritik mit offenen Fragen, sondern eine Ablehnung, aus der die spezifizierende Person nichts lernen kann. Die Chance, dass der zweite Wurf dadurch besser wird, ist gering. Die Folge ist, dass beide Seiten früher oder später voneinander genervt sind: Niemand weiß, was die jeweils andere Person eigentlich will.

Unspezifisches Feedback ist keine Hilfe

Geholfen ist damit niemandem, das Arbeitspaket wird nicht fertig, es wird nur immer wieder blind mehr Zeit investiert: auf der Spezifikationsseite mit dem Fischen im Trüben, was noch fehlen könnte, auf der Entwicklerseite mit dem Durchsehen des Arbeitspakets und dem Versehen mit einem nichtssagenden Kommentar.

Die Folge ist ein verlangsamtes Projekt. Vielleicht steckt es noch nicht ganz fest - es ist aber höchstwahrscheinlich kurz davor.

In manchen Projekten gibt es als Zwischenschritt deshalb die technische Spezifikation. Eigentlich ist die Tech-Spec dafür gedacht, das Design der Software festzulegen, einen Überblick darüber zu geben, was alles zu tun ist, eine zeitliche Abschätzung des Projekts vorzunehmen und damit auch zu zeigen, wie viel ein Projekt oder auch ein Teil eines Projekts kosten wird.