Serie: Wie kann man die Architekturabteilung töten? Teil 3

Teil 3: Der technische Product Owner

Rückblickend

In den vorherigen 2 Beiträgen haben wir das agile Organisationsmodell und einige technische Rollen in diesem Modell beschrieben. In diesem Beitrag werden wir uns mit der Rolle des Technical Product Owner beschäftigen. Ich werde sie mit dem vergleichen, was wir inzwischen als "klassischen Architekten" bezeichnen.

Der klassische Architekt

Viele Architekten sind nicht in den Prozess der Softwareentwicklung involviert. In der Regel stehen sie an der Seitenlinie und beobachten das Spiel. Ihre Art der Kommunikation erfolgt über Dokumente. Diese Dokumente sind das Ergebnis eines separaten Prozesses zur Gestaltung der Software, bevor die Entwickler mit dem Bau begonnen haben. Durch diese Art der Kommunikation sind diese klassischen Architekten eher präskriptiv als kooperativ. Aus diesem Grund werden sie manchmal eher als Berater denn als Menschen gesehen, die einen Mehrwert für den Prozess und das Unternehmen schaffen. Auf diese Weise stellen sich die Architekten selbst ins Abseits, obwohl Architektur notwendig ist. In einem agilen Prozess ist dieses Verhalten eindeutig ein Problem. Die Teams konzentrieren sich auf die Funktionalität und streben nach Selbstorganisation, um weiterhin Software liefern zu können. Ein Teil davon ist die Architektur. Sie werden die Software liefern, ob ein Architekt beteiligt ist oder nicht.

Der technische Product Owner

Um einen Mehrwert für den Entwicklungsprozess schaffen zu können, müssen Architekten ihr Verhalten ändern. Um zu veranschaulichen, in welche Richtung das geht, haben wir uns die Rolle des Technical Product Owner (TPO) ausgedacht. Was sind die wichtigsten Merkmale eines TPO in einem agilen Entwicklungsprozess?

Ein TPO ist Teil des Prozesses. Als solcher steht er nicht an der Seitenlinie, sondern er ist dort, wo das Geschehen stattfindet: auf dem Spielfeld. Anders als ein klassischer Architekt betrachtet der TPO den Prozess nicht aus der Ferne, sondern seine Augen sind in 2 Richtungen gerichtet. Die eine Richtung ist die Zukunft: welche Projekte auf der Portfoliowand und welche Epen müssen umgesetzt werden. Das ist wichtig, denn der TPO muss wahrscheinlich einiges in die Wege leiten und zusammen mit anderen Interessengruppen und den Teams die User Stories READY machen. Die andere Richtung ist die Gegenwart: Woran arbeiten die Teams gerade und wie kann er die Teams anleiten, die richtigen Dinge FERTIG zu machen. Ein TPO ist für die architektonischen Grenzen verantwortlich, innerhalb derer die Teams arbeiten können. Während der klassische Architekt sich eher wie ein Berater verhalten würde, übernimmt der TPO die Verantwortung. Die architektonischen Grenzen basieren auf den nicht-funktionalen Anforderungen des Unternehmens und anderer technischer Interessengruppen, wie der Betriebsabteilung. Während der Product Owner (PO) die eher funktionalen Anforderungen für das Team ausarbeitet, liegt der Schwerpunkt des TPO auf den nicht-funktionalen Anforderungen. Das liegt daran, dass der TPO über mehr technisches Wissen verfügt als der durchschnittliche PO. Dieser Mangel an Wissen auf Seiten des PO war einer der Hauptgründe für die Einführung der Rolle des TPO. Anders als der klassische Architekt ist ein TPO nicht direktiv. Stattdessen fungiert er als Vermittler und Coach für die Teams. Die Teams sind selbstorganisiert und sehr gut in der Lage, Entscheidungen zu treffen. Diese Entscheidungen bewegen sich innerhalb der vom PO und TPO vorgegebenen Grenzen. Für einen TPO (und PO) reicht es aus, ihnen bei diesen Entscheidungen zu helfen. TPOs sind selbst in virtuellen Teams organisiert. Für einen TPO ist es wichtiger, mit den agilen Teams zusammen zu sein als mit seinen Kollegen. Natürlich treffen sie sich, um die neuesten Entwicklungen in den Teams zu besprechen oder um eine Entscheidung über die Architektur zu treffen (z.B. aufgrund einer geänderten nicht-funktionalen Anforderung). Aber ihr primärer Platz ist in den Teams.

Was kommt als nächstes?

Ein TPO ist also so etwas wie ein PO für technische Dinge. Seine Hauptaufgabe ist es, User Stories BEREIT zu machen und den Teams dabei zu helfen, User Stories FERTIG zu machen. Aber wie kommt man von vagen Ideen zu konkreten Anwenderberichten? In vielen Unternehmen ist eine bestimmte Einstellung erforderlich, um Ideen an die Portfolio-Wand zu bringen und von Ideen zu User Stories zu gelangen. Unser nächster Blog-Beitrag wird genau das zum Thema haben. Wie kann der Chief Technical Product Owner dem Unternehmen helfen, von der Idee zur User Story zu gelangen? Bleiben Sie dran und schreiben Sie uns, wenn Sie möchten.

Mehr aus dieser Serie

    
How to Kill the Architecture Department - Part 1
    
How to Kill the Architecture Department - Part 2
    
How to Kill the Architecture Department - Part 3
    
How to Kill the Architecture Department - Part 4
    
How to Kill the Architecture Department - Part 5
    
How to Kill the Architecture Department - Part 6
    
How to Kill the Architecture Department - Part 7