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

Teil 7: Bewährte Praktiken

In den vorangegangenen Blogbeiträgen dieser Serie haben wir die Rolle der technischen Leiter (und insbesondere der Technical Product Owner [TPO]) in einem agilen Softwareentwicklungsprozess erörtert. Seitdem haben wir mehrere Fragen erhalten. Die wichtigste Frage war: "Ich arbeite in einem klassischen Architekturteam. Die Entwicklungsteams arbeiten agil. Wie kann ich mich stärker in die Teams einbringen?". In diesem Beitrag möchte ich mich auf einige Best Practices konzentrieren: Wie können Sie sich als TPO stärker einbringen und die Teams dabei unterstützen, bessere Qualität zu liefern?

Der technische Leiter für das Coaching

Teams sind selbstorganisiert und sehr gut in der Lage, Entscheidungen zu treffen. Sie können jedoch die Erfahrung des TPO nutzen, um die richtigen Entscheidungen zu treffen. Wie ich in dem Beitrag über den TPO beschrieben habe, bin ich der Meinung, dass der TPO als Coach für die Teams fungieren sollte. Für einen TPO (und Product Owner) reicht es aus, den Teams bei der Entscheidungsfindung zu helfen. Aber wie können Sie als TPO das tun?

Beginnen Sie mit der Verbesserung von DONE

Die Qualität von Teams basiert auf dem, was sie liefern. Um den Output zu verbessern, müssen die Teams nur die Dinge tun, die wirklich notwendig und technisch richtig sind. Die Verwendung einer komplizierten Software-Architektur für eine einfache Funktion ist Over-Engineering. Over-Engineering sollte vermieden werden. Als coachender TPO können Sie die Teams anleiten, die Dinge richtig zu tun. Ein technischer Leiter hat 2 Schwerpunkte. Den einen auf die Zukunft: Welche Epen müssen implementiert werden? Der andere auf die Teams: Woran arbeiten sie und machen sie die Dinge richtig? Beginnen Sie mit dem Fokus auf die Teams. Helfen Sie ihnen, die richtigen Entscheidungen zu treffen und ihre Geschwindigkeit zu erhöhen. Da Sie nicht vollständig Teil der Teams sind, können Sie objektiv sein und die Teams bei ihren Entscheidungen unterstützen. Stellen Sie also Fragen wie: Warum möchten Sie dieses Framework verwenden? Warum diese Art von Architektur? Wie können wir diese Annahme konkreter machen?

Danach zielen Sie auf den Input der Teams ab

Wenn die Teams die Dinge richtig machen, können Sie auf den Input der Teams hoffen. Normalerweise basieren die funktionalen Anforderungen auf einer Vision, wie eine Anwendung aussehen und was sie leisten soll. Als TPO sollten Sie eine Architektur entwickeln, die die Umsetzung dieser funktionalen Anforderungen ermöglicht. Schnitzen Sie diese Architektur nicht in Stein. Gestalten Sie sie agil: Legen Sie den Rahmen fest (aber nicht im Detail), besprechen Sie ihn mit den Teams, dem Product Owner (PO), anderen Architekten und dem Chief Technical Product Owner (CTPO). Sie sind vielleicht derjenige, der diese Architektur initiiert, aber Sie sind nicht der Eigentümer. Sie sind nur der Vermittler. Es ist sowohl für Sie als TPO als auch für das Team wichtig, sich dessen bewusst zu sein. Auf diese Weise können Sie sicherstellen, dass das Team die Verantwortung für die technischen Entscheidungen und die Architektur gemeinsam mit Ihnen übernimmt. Dies wird zu einer besseren, tatsächlich implementierten Architektur führen. Eine Architektur kann nicht gleich in der ersten Iteration eines Projekts vollständig implementiert werden. Sie wird in der Regel in einem iterativen Prozess implementiert. Daher ist es wichtig, dass Sie mit den Teams und anderen Beteiligten eine ständige Diskussion darüber führen, wie die Architektur umgesetzt werden soll. Das Letzte, wovor Sie Angst haben sollten, ist die Änderung der Architektur.

Diskutieren Sie technische Engpässe

Die Teams tun also das Richtige und die Architektur wächst. Die Aktivitäten zur Erreichung dieses Ziels sind hauptsächlich intern ausgerichtet: auf die Teams. Aber für einen technischen Leiter, insbesondere einen TPO und CTPO, ist es auch wichtig, den Blick nach außen zu richten: auf kommende Epen. Diese Epen, also die neuen funktionalen Anforderungen, können sich auf die technischen Aspekte der zu entwickelnden Anwendung auswirken. Genau wie bei den Teams können Sie die Entscheidungen gegenüber dem PO und dem Management reflektieren. Es ist wichtig, die Probleme, die sich ergeben, mit dem Product Owner, dem Management und anderen Beteiligten zu besprechen, damit sie angegangen werden können. Besprechen Sie, wie die Probleme angegangen werden können und welche Auswirkungen sie auf den Fortschritt und die funktionalen Anforderungen haben. Dies ist wichtig, da ein PO wahrscheinlich weniger Verständnis für die technischen Auswirkungen der Entscheidungen hat, die er gerne treffen würde. Auf der Grundlage des geschäftlichen Nutzens und der technischen Auswirkungen kann eine gut durchdachte Entscheidung getroffen werden.

Danke

Dies war unser letzter Beitrag in dieser Serie. Vielen Dank, dass Sie die Beiträge gelesen haben. Sowohl Adriaan als auch mir hat es Spaß gemacht, sie mit anderen Kollegen zu diskutieren und sie zu schreiben. Wir hoffen, dass wir Ihnen mit dieser Serie Denkanstöße für die Rolle der technischen Leiter und insbesondere des klassischen Architekten in einem agilen Entwicklungsprozess gegeben haben.

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