Scrum und die Rolle des Architekten
Die Grundidee von Scrum ist leicht zu vermitteln. Die wichtigsten Rituale lassen sich schnell erlernen. Die Umsetzung ist bekanntlich schwierig und erfordert viel Übung. Die ersten Stolpersteine, die nach meiner Erfahrung in der Praxis bei Softwareprodukten auftreten, lassen sich auf wenige Widersprüche kondensieren, die im Zusammenhang mit der Rolle des Architekten oder dessen Aufgaben stehen:
Die iterative und inkrementelle Entwicklung einerseits und der Wunsch nach einer nachhaltigen Softwarearchitektur, die nur dann möglich ist, wenn die ggf. notwendigen größeren Umbauten als erstes angegangen werden und dadurch eben kein schneller Mehrwert für den Kunden geschaffen wird.
Das eigenverantwortliche und selbst-organisierende Vorgehen von Scrum Teams einerseits und das gemeinsame Arbeiten an einem einzigen großen Produkt, das einheitlich mit mehreren Teams entwickelt werden soll (Toolchain, Compiler, Versionskontrollsystem, CI/CD, usw.) und dadurch die Selbstbestimmung des Teams unterwandert wird.
Die Aufgabe eines Architekten wird in der Regel so interpretiert, dass sie vorgibt, wie das Gesamtdesign aussehen muss und oft auch noch obendrein, nach welchen Paradigmen und mit welchen Tools gearbeitet werden muss. Es ist also genau diese Rolle, die sich bei Punkt 1 und 2 auf die Seite der "Nicht-Agilisten" schlagen müsste, sollte man denken. Egal ob die Teammitglieder nun eher pro oder kontra Agilität sind, so oder so werden die naheliegenden Fragen lauten, ob es in Scrum überhaupt einen Architekten geben darf und wenn ja, sollte er oder sie dann nicht wenigstens Teil des Teams sein und eher als Coach auftreten und nicht als Entscheider?
Wenn ich mit diesen Fragen konfrontiert wurde, dann war es sehr oft problemlos möglich, den Teams schnell aufgrund der eigenen Historie aufzuzeigen, dass es nicht möglich ist, ein komplexes Produkt komplett am Reißbrett durchzuplanen. Nahtlos daran anschließend gibt es im kollektiven Gedächtnis einer Entwicklungsabteilung auch immer Erinnerungen an groß angelegte fundamentale Umbauarbeiten der Architektur und des Designs zu finden, die sich im Nachhinein in der Realisierung als viel zeitaufwendiger als gedacht darstellten, die sich nicht komplett zu Ende umsetzen ließen und die darüberhinaus auch noch das eigentliche geplante Ziel nicht erreichten.
Daran entspinnt sich dann eigentlich immer eine mehr oder weniger laute Kritik am bisherigen Architekten, der keine gute Arbeit geleistet haben soll, oder die Idee einer offensichtlich notwendigen grundsätzlichen Abkehr von dieser Rolle.
In der Regel bleiben als Ergebnis solcher Diskussionen mehr oder weniger zwei Meinungen übrig:
Im wesentlichen ist ein Architekt überflüssig, denn es funktioniert einfach nicht, große Umbauten erst am Reißbrett auszuarbeiten und daher machen wir solche "Großbaustellen" auch einfach gar nicht mehr auf.
Ein Architekt ist weiterhin nötig, denn sonst behält niemand den Überblick über das Design und die Codebasis und das führt zu einem qualitativ schlechten Produkt, das nur schwer zu warten und zu erweitern ist.
Tatsächlich sind diese zwei Positionen nicht nur nicht weit voneinander entfernt, sondern widersprechen sich eigentlich kaum: Personen, die zur Meinung 1 tendieren, räumen in der Regel sehr schnell ein, dass die Qualität des Produktes natürlich nicht leiden darf und daher "natürlich" eine Abstimmung zwischen Entwicklern aller Teams weiter gegeben sein muss. Personen der zweiten Gruppe wiederum, haben gar kein Problem damit, dass es nicht "den einen" Architekten geben muss, sondern dass diese Aufgabe natürlich gerne von Mitgliedern aus allen Teams mit übernommen werden kann.
An dieser Stelle reift dann meist auch schon von ganz alleine die Erkenntnis bei beteiligten Architekten, dass es für sie ein großer Vorteil ist, gar nicht mehr ganz alleine für das Gesamtdesign verantwortlich sein zu müssen, sondern dass es viel praktischer und auch beruhigender ist, dafür mit Entwicklern aller Teams zusammenarbeiten zu können.
Dann ist es meist schon geschafft: die Teammitglieder einigen sich auf eine regelmäßige Abstimmung über geplante Vorhaben, die Auswirkungen auf die gesamte Codebasis oder Vorgehensweise haben werden, und die Architekten sind dabei zugegen und agieren mehr als Coach und Mentor denn als Entscheider. Ob Architekten dann formal noch diesen Titel behalten, ob sie formal Teil eines Teams sind oder nicht, oder ob sie gar mit dem Titel "Entwickler" darin aufgehen, kann man von Fall zu Fall mit den Beteiligten abstimmen und so auf persönliche Befindlichkeiten Rücksicht nehmen.
Solche Diskussionen sollten keinesfalls sich selbst überlassen werden und sollten sehr gut vorbereitet und moderiert werden, denn persönliche Befindlichkeiten zwischen Beteiligten können natürlich bei dieser Gelegenheit ans Tageslicht kommen und leidenschaftlich geführt auch leicht die Stimmung vergiften. Solche Konflikte, die mit der eigentlichen Sache nichts zu tun haben, sollten kanalisiert und in einem separaten Gespräch adressiert und geklärt werden.