»Wir glauben, dass es so funktionieren müsste, also machen wir es auch so. Und Glaubensdinge sollte man sowieso nicht in Frage stellen.« Wen wollt ihr eigentlich verarschen? Eure Kunden, euch selbst, eure Geschäftsleitung? Sie glauben wahrscheinlich, dass ich hier gerade völligen Quatsch schreibe. Sie werden sich wundern, in wie vielen Unternehmen (und damit meine ich nicht die kleinen Hinterzimmer-Entwicklerbuden) nach dem theologischen Prinzip gearbeitet wird.
Es ist vollkommen selbstverständlich, dass auch der erfahrenste Softwareentwickler nicht alles wissen kann. Ich habe damit kein Problem. Wenn mir ein Mitglied meines Teams sagt, dass er noch nicht wisse, wie er eine bestimmte Anforderung umsetzen könne, dann bekommt er von mir die Antwort, dass er das bitte recherchiert, das mit einem Kollegen gemeinsam ansieht und dann eine Testballon startet, bevor wir irgendetwas vollkommen Neues und Ungetestetes in unseren Code integrieren. Wenn es eine größere Sache ist, kann man vielleicht sogar über einen Explorationssprint nachdenken.
Ich bin kein großer Freund davon, während eines laufenden Projekts Forschungssprints einzufügen. Diese Dinge brechen den Rhythmus und sind nicht planbar. Kein Mensch kann sagen, ob eine Woche ausreichen wird, schließlich handelt es sich um ein Forschungsprojekt. Meistens reicht es vollkommen aus, wenn sich ein oder zwei Kollegen aus einem Sprint zurückziehen und sich mit der Recherche und dem Testen neuer Technologien befassen, während der Rest des Teams am Projekt weiterarbeitet.
Zum einen sollte der Product Owner vorausschauend genug geplant haben (auch unter Miteinbeziehung des Entwicklungsteams), um technologische Hindernisse identifiziert zu haben, bevor sie akut werden. Zum anderen sollte das Backlog genug Alternativen aufweisen, um auch im Fall der Fälle, wenn man in eine technologische Sackgasse läuft, einen anderen Themenkomplex vorzuziehen, der hoch genug priorisiert ist.
Gehen wir also davon aus, dass der Product Owner gut geplant hat, und dass ein technisches Problem von einem Teammitglied gelöst werden soll, bevor es die Entwicklung behindert. In diesem Fall übernehme ich es ins Backlog und versuche gemeinsam mit dem Entwickler eine sehr grobe zeitliche Einschätzung. Es ist hilfreich, wenn sich der Kollege schon kurz in das Thema eingelesen hat, trotzdem bleibt nur eine vage Einschätzung, ob wir mit einem Tag Forschung oder einer Woche rechnen. Mit dieser Unsicherheit müssen wir leben. Zur Sicherheit gebe ich noch einen Zeitpuffer dazu, auch wenn das in Scrum eigentlich nicht üblich ist. Es ist mir lieber, wenn das Team früher mit den Anforderungen im Sprint fertig ist, so dass ich vielleicht noch eine Aufgabe hineinnehme, als dass ich unfertige Anforderung eines Sprints in den nächsten überführen muss. Im allgemeinen plane ich zwei oder drei Sprints im voraus.
Wenn das zu erforschende Thema von allgemeinerem Interesse ist, setze ich einen Schulungstermin für das Team an. Die dafür geplante Zeit wird selbstverständlich von der Sprintzeit abgezogen. Wir verfolgen immer das Ziel, neue Erkenntnisse allen zur Verfügung zu stellen, daher sollten regelmäßige gegenseitige Schulungen unserer Entwicklerkollegen sowieso Bestandteil Ihrer Planung sein.
Und was hat das alles mit dem theologischen Prinzip zu tun?
Was denken Sie, wie oft übernehmen Softwareentwickler Codeschnipsel und Beispiele, die sie in irgendwelchen Blogs oder Foren gefunden haben, ungetestet und unkommentiert in working Code? Sie halten das für die Ausnahme? In diesem Fall muss ich Sie enttäuschen. Das geschieht sehr viel häufiger als Sie denken. Ein Entwickler hat wenig Zeit, der Termin drückt, ein Problem tritt auf, also sucht er die Lösung bei Big Brother Google, findet einen Blog, kopiert den Code und fügt ihn ein. Auch Entwickler, die wissen, dass das keine gute Idee ist, haben das schon gemacht.
In einem gut sortierten Scrum Projekt sollten wir zumindest dafür gesorgt haben, dass die Kollegen keinen Zeitdruck spüren, dennoch kann es vorkommen, dass jemand irgendwo auf ein kleineres Problem stößt, dass er nicht lösen kann. Die Kollegen können ebenfalls nicht helfen, die Anforderung wurde auf einen Tag geschätzt, der Entwickler ist schon etwas länger damit beschäftigt. Die Verlockung ist dann groß, die vermeintliche Lösung des Problems aus dem Netz zu suchen und einzufügen.
Natürlich gehören diese Dinge ins Daily Scrum. Dort müsste der Entwickler lediglich sagen, dass er bei Anforderung XY auf ein Problem gestoßen sei, dass er nicht sofort lösen könne. Er müsse sich da in ein Thema einlesen, etwas testen und alles schließlich einbauen. Die Sache würde länger dauern als geplant. Vollkommen in Ordnung, alle Beteiligten wissen, woran sie sind. Leider denken manche Entwickler, dass von Ihnen erwartet wird, alles möglichst schnell in Ordnung zu bringen. Sie geben dann ungern zu, dass sie ein Problem nicht ohne Weiteres lösen können und suchen dann nach vermeintlich schnellsten Lösung.
Daher mein ganz dringender Rat: Kommunizieren Sie Ihrem Team gegenüber frühzeitig und glaubhaft, dass es kein Problem ist, wenn jemand eine Schwierigkeit im Detail nicht im Vorfeld erkannt hat und eine Sache einmal länger dauert als gedacht, weil man Dinge recherchieren und testen muss, bevor man sie in working Code überführt. Wir bemühen uns, das zu vermeiden, aber wir wissen, dass wir das nicht immer vermeiden können.
Dazu stellen wir noch zwei ganz einfache Regeln auf:
1. Es kommt nichts in den Code, was wir nicht vollkommen verstehen.
2. Es kommt nichts in den Code, was nicht getestet ist.
