Architekten und Scrum: 2. die agilen Werte

Dieser Blog ist der zweite einer Reihe von Blogs, in denen ich die Rolle der Architekten in Scrum untersuchen werde. Letzte Woche habe ich mit den vergessenen Fragen von Scrum begonnen. In diesem Blog werde ich mich eingehender mit dem Agilen Manifest und den agilen Werten befassen. Architekten und die agilen Werte Der größte Teil der Literatur über die Rolle von Architekten in einem agilen Kontext konzentriert sich auf den agilen Fluss selbst und darauf, wie Architekten es vermeiden können, diesen Fluss zu stören. Mike Cohn macht in seinem Buch "succeeding with agile" einen Unterschied zwischen codierenden und nicht codierenden Architekten. Darin stellt er fest, dass die codierenden Architekten weniger Schwierigkeiten haben werden, ihre neue Rolle im agilen Entwicklungsprozess zu finden. Ein Architekt innerhalb eines Teams muss selbst codieren können. Er ist ein Teammitglied, das im Vergleich zu anderen Teammitgliedern mehr Erfahrung in der Strukturierung der zu entwickelnden Anwendung hat. Durch die Nutzung dieser Erfahrung kann er dem Team einen Mehrwert bieten. Scrum hat keine besondere Rolle für nicht-codierende Architekten. Es stellt sich die Frage, ob das wirklich so ist. Die Rolle der Architekten in einer agilen Umgebung sollte zumindest den agilen Werten aus dem agilen Manifest folgen. Die Untersuchung dieser Werte führt zu Leitlinien, die Architekten befolgen müssen, um für das Unternehmen von optimalem Wert zu sein.

1. Individuen und Interaktionen vor Prozessen und Tools Der erste agile Wert besagt, dass wir es mit Menschen und der Art und Weise ihrer Kommunikation zu tun haben. Prozesse und Tools können in bestimmten Situationen hilfreich sein, sollten aber nie überbewertet werden. Die obligatorischen dicken Architekturdokumente zu Beginn eines Projekts oder die langwierigen Überprüfungsverfahren von Dokumenten sind Beispiele dafür, dass Prozessen und Tools zu viel Aufmerksamkeit geschenkt wurde. In einer Scrum-Umgebung ist das nicht möglich. Daher müssen Architekten ihren Schwerpunkt von der schriftlichen auf die mündliche Kommunikation verlagern. Sie müssen so viel wie möglich persönlich mit allen Beteiligten im Unternehmen kommunizieren. Architekten müssen in der Lage sein, mit dem Product Owner ebenso gut zu kommunizieren wie mit den einzelnen Mitgliedern der Teams. Die Kommunikation muss in beide Richtungen erfolgen, so dass der Architekt von den Ideen anderer profitieren kann. Architektur-Frameworks wie TOGAF können verwendet werden, aber nur, wenn sie dem Architekten helfen, die Botschaft zu vermitteln. Die Methode kann niemals die Aktivitäten vorschreiben, die der Architekt durchführen sollte.
2. Arbeitssoftware statt umfassender Dokumentation In der Vergangenheit haben Architekten dies aus der Distanz zu den Bauherren getan. Die Kommunikation über umfangreiche Entwurfsdokumente hat sich als nicht besonders effektiv erwiesen. Obwohl die Architekten selbst sehr stolz auf die von ihnen erstellten Dokumente sein können, wird dies in einer Umgebung mit Scrum nicht funktionieren. Die Einführung von Scrum in einem Unternehmen zwingt die Architekten dazu, sich mehr auf den kommunikativen Teil ihrer Arbeit zu konzentrieren: Ein Architekt muss sich mehr auf das Zeichnen von Skizzen konzentrieren. Er muss mit allen Beteiligten über die Skizzen sprechen. Die Skizzen an die Bemerkungen der Kunden und Lieferanten anpassen. Passen Sie die Skizzen an die Ideen des Entwicklungsteams an. Aber auch die Skizzen an die Hindernisse, die bei der Umsetzung festgestellt wurden, was sie realitätsnäher macht. Die Verwendung von Skizzen hilft dem Architekten, mit allen Beteiligten eine gemeinsame Sichtweise über das Design der Software zu entwickeln, was die Qualität der entwickelten Software erhöht.
3. Zusammenarbeit mit dem Kunden statt Vertragsverhandlungen Architekten spielen eine wichtige Rolle bei der Abstimmung von IT und Geschäft. In Unternehmen mit einer komplexen Multisystemumgebung und mehreren agilen Teams sollten die Architekten dem Product Owner sehr nahe stehen und ihm dabei helfen, aus den Anforderungen im Product Backlog einen maximalen Geschäftswert zu schaffen. Indem er die Lösung skizziert und einen Einblick in die Komplexität dieser Lösung gibt, kann der Architekt dem Product Owner helfen, seine Prioritäten noch besser zu setzen, und die Teams mit den Ergebnissen dieser globalen Designdiskussionen unterstützen. Eine effektive Beziehung zwischen dem Product Owner und dem Architekten kann mit weniger Aufwand mehr Geschäftswert schaffen.
4. Reagieren auf Veränderungen statt Befolgen eines Plans Der Architekt muss in der Lage sein, auf tägliche Veränderungen zu reagieren. Der beste Weg, um die täglichen Schwierigkeiten zu erfahren, die zu Änderungen führen können, ist die Nähe zum Entwicklungsteam. Der Architekt sollte bei allen praktischen Designfragen zu Rate gezogen werden können. Der Architekt muss seine eigenen Entwürfe für die Zukunft ständig anpassen. Der Architekt sollte in der Lage sein, einige seiner Ideen loszulassen, wenn sie sich als sehr schwierig in der Ausführung erweisen.

Nach diesen agilen Prinzipien muss der Architekt mehr denn je mit allen Beteiligten kommunizieren und interagieren. In seiner Kommunikation sollte er Skizzen anstelle von großen Dokumenten verwenden. Sein Arbeitsplatz sollte sich in der Nähe der Teams befinden und er sollte täglich mit dem Product Owner sprechen. Das meiste davon ist darauf ausgerichtet, den "Herzschlag" der Scrum-Teams zu stärken. Er kann der Software mehr Qualität verleihen und die Teams durch intelligentes Design beschleunigen. Meiner Meinung nach fehlt jedoch etwas. Was ist also die fehlende Zutat, die Architekten wirklich erfolgreich machen könnte? Im Blog der nächsten Woche gebe ich Ihnen meine Antworten darauf.