Wie können Architekten mit selbstorganisierenden Scrum-Teams arbeiten?

Eine Organisation mit einer Reihe von agilen Scrum-Teams hat auch eine kleine Gruppe von Mitarbeitern, die als "Enterprise Architects" eingesetzt werden. Die EA-Gruppe fungiert als Kontrolle und Gatekeeper für Qualität und Einhaltung von Entscheidungen. Dies führt zu Überschneidungen zwischen der Teamentscheidung und den EA-Entscheidungen.

Beispielsweise möchte das Team möglicherweise Bibliothek X oder REST anstelle von SOAP verwenden, aber der EA genehmigt dies nicht.

Dies kann nun zu Frustrationen führen, wenn Teamentscheidungen außer Kraft gesetzt werden. Weit genug entfernt kann dies möglicherweise zu einer Situation führen, in der die EA-Mitarbeiter alle Macht "ergreifen" und sich das Team demotiviert und überhaupt nicht sehr agil fühlt.

Die Scrum Guides haben dazu folgendes zu sagen:

Selbstorganisierend: Niemand (nicht einmal der Scrum-Master) teilt dem Entwicklungsteam mit, wie das Product Backlog in Inkremente potenziell freigebbarer Funktionen umgewandelt werden kann.

Ist das vernünftig? Sollte das EA-Team aufgelöst werden? Sollten sich die Teams weigern oder einfach befolgen?

Ein Entwicklungsteam besteht aus 3 bis 9 Personen mit funktionsübergreifenden Fähigkeiten, die die eigentliche Arbeit erledigen

Scrum Master sollte "Enterprise Architect" einladen, Teil des Projektteams zu werden. Dann wäre die Kommunikation zwischen Architekt und Programmierer hervorragend.

Die Wahl der verwendeten Technologie ist Teil der Softwareanforderungen, dh es ist Teil der Funktionsanforderung, dass Sie bestimmte Technologien aus irgendeinem Grund nicht verwenden.

Die Architekten sprechen für die Systeme und die Codebasis, weil die Systeme und die Codebasis nicht für sich selbst sprechen können. Einen Architekten zu haben, ist im Allgemeinen im langfristigen Interesse eines Unternehmens, insbesondere eines Unternehmens, das auf selbst erstellte Software setzt.

Die Architekten sagen den Entwicklern nicht, wie sie den Rückstand in Inkremente (Sprints) umwandeln sollen, sie sagen, welche Technologien verwendet werden können und welche nicht. Sie verschmelzen zwei verschiedene Themen.

Die Lösung besteht darin, nichts zu ändern. Wenn Ihre Teams frustriert werden, weil die Architekten zu restriktiv oder zu aufdringlich sind, ist dies ein Personalproblem, das nichts mit SCRUM zu tun hat und das mit den Geschäftsinteressenten als ein Problem der Mitarbeiterzufriedenheit und, wenn möglich, des Endergebnisses aufgegriffen werden sollte ("Es dauert x%länger, Features zu entwickeln, yweil der Architekt zuns Turbo Pascal nicht zulässt.")

Diese Art von Dingen ist notwendig, um das Gleichgewicht zwischen der Notwendigkeit eines großen Teams für die Erledigung des Projekts und der Notwendigkeit, agile Teams klein zu halten, zu halten.

Im Allgemeinen setzt sich das "Team Lead Scrum" aus einem Mitglied zusammen, das aus jedem der kleineren Teams gewählt wird. Dies bietet einen Teil der selbstorganisierenden Natur sowie eine Art der Repräsentation, sodass Entscheidungen der hochrangigen Gruppe von der agilen Gruppe akzeptiert werden.

In Ihrem speziellen Szenario sollte etwas unternommen werden, um die Demotivierung des agilen Teams zu stoppen, aber wahrscheinlich nicht die Rebellion oder die einfache Akzeptanz. Das Team muss erkennen, dass Sie da sind, um gute Software zu entwickeln, und nicht, um Ideale zu verwirklichen. Es wird zu einer schlechteren Software führen, wenn mehrere Teams unterschiedliche Technologien einsetzen, um ähnliche Aufgaben im selben Projekt zu erledigen. Wenn mehrere Teams im selben Projekt unterschiedliche Codierungsstandards verwenden, führt dies zu einer schlechteren Software.

Sie müssen sich also einig werden, wie das Projekt funktionieren soll. Das Team Lead Scrum wird an anderen Stellen effektiv eingesetzt. Möglicherweise müssen Sie etwas anders machen oder untersuchen, warum Ihre Gruppe es nicht effektiv macht.

Die Frage ist: Was ist der Grund, warum dieses Architektenteam existiert? Ich kann mir nur vorstellen, die Interoperabilität zwischen verschiedenen Teams durchzusetzen. Oder die Teams arbeiten an verschiedenen Teilen eines einzelnen Produkts und dieses Architektenteam sorgt dafür, dass alle Teile zusammenarbeiten.

Ich glaube wirklich nicht, dass dieses Schema in einer agilen Umgebung gut funktionieren kann, aus genauen Gründen, die Sie sagen. Die verschiedenen Teams sollten in sich geschlossen sein, ebenso wie ihre Inputs und Outputs. Das Einschränken ihrer Ausgaben sollte daher nur Teil der Anforderungen an die Eingabe sein. Diese Einschränkungen sollten jedoch vernünftig sein. So etwas wie "Bibliothek X darf nicht verwendet werden" ist keine gute Voraussetzung, aber die Angabe "Die Anzahl der verwendeten Bibliotheken von Drittanbietern muss auf ein Minimum beschränkt werden" oder "Das Hinzufügen neuer Bibliotheken, die nicht in anderen Teams verwendet werden, sollte beschränkt werden." sollte gut sein.

Dann würde ich das Architektenteam über alle Teams hinweg auflösen und ihre Expertise in Fragen der Architektur einsetzen. Wenn sie Teil des Teams werden, können sie Probleme, die das Team hat, besser erkennen und haben möglicherweise bessere Ideen oder fundiertere Meinungen zu Veränderungen in den Kernbereichen der Architektur. Es sollte auch den Architekten in allen Teams empfohlen werden, miteinander zu kommunizieren, um sicherzustellen, dass die Architektur in allen Teams konsistent bleibt.

Die Gruppe von Scaled Agile Framework spricht sehr gut darüber. Die meisten von uns befassen sich mit der Teamebene, aber bei der Skalierung müssen wir erkennen, dass es auch auf der Programm- und Portfolioebene Rollen gibt. Architekturentscheidungen müssen in der gesamten Organisation getroffen werden, und dies sollte sich auf die Vorgänge auf den unteren Ebenen der Organisation auswirken. Es ist nichts falsch daran, architektonische Entscheidungen zu treffen!

In diesem Zusammenhang ist Dean Leffingwells kürzlich erschienenes Buch über Agile Software-Anforderungen eine gute Lektüre zu diesem Thema. Ich habe es selbst gelesen.

Wir haben auch mehrere agile Teams (manche haben Kanban, manche Scrum) und Architekten. Die Architekten sind für die Infrastruktur verantwortlich, die alle unsere Produkte umfasst (Hilfsbibliotheken, Authentifizierung, Build-Infrastruktur) usw. Sie treffen technische Entscheidungen, implementieren aber auch Dinge, hauptsächlich Infrastrukturkomponenten.

Das funktioniert gut und es gibt normalerweise keinen Konflikt. Ich glaube, ein entscheidender Punkt ist:

Die Architekten haben keine formelle Autorität über die Teams und können sie nicht einfach außer Kraft setzen. Normalerweise treffen die Architekten Entscheidungen, die für alle Produkte gelten, und die Teams treffen Entscheidungen für ihr Produkt. Wenn es einen Konflikt gibt, müssen Architekt und Team lediglich eine Einigung erzielen oder zum Management eskalieren (obwohl dies selten vorkommt).

Ich denke, es ist wirklich wichtig, Architekten und Entwickler zu Gleichgesinnten zu machen. Beide arbeiten auf ein gemeinsames Ziel hin, nur in verschiedenen Bereichen. Wenn niemand den anderen "überstimmen" kann, ist die Zusammenarbeit besser.

Ich sehe hier keinen Konflikt. Soweit ich weiß, ist der EA (so pompös ein Titel, wie ich denke) nur für die Qualitätssicherung gedacht. Jeder sollte sich dessen bewusst sein.

Sie sollten berücksichtigen, dass in jeder Entwicklungsmethodik (die es verdient, als eine betrachtet zu werden) das Sammeln von Anforderungen ein entscheidender Schritt ist, sei es iterativ oder im Voraus.

Einige dieser Anforderungen werden durch Unternehmensrichtlinien festgelegt. Und diese setzen die Grundregeln:

• Das Team muss sich wie bei allen anderen Anforderungen an sie halten. Eine Infragestellung der Politik liegt dann einfach außerhalb des Projektbereichs und sollte separat behandelt werden.
• Die Aufgabe der EA ist es, diese Anforderungen durchzusetzen und nicht ihre persönliche Fantasie aufzuerlegen. Sie mögen X nicht, dann ist das ihre persönliche Meinung. Nicht mehr, nicht weniger. Behandle es wie jede andere Meinung. Wenn der EA jedoch nachweisen kann, dass die Verwendung von X gegen eine bestehende Anforderung verstößt, hat er das Recht, die Verwendung von X zu verbieten. Wenn er eine praktikable Alternative kennt und das Team dies nicht tut, ist er berechtigt, diese durchzusetzen.

Aber so oder so ist eine Anforderung entweder erfüllt oder nicht. Wenn es schwierig ist, diese Entscheidung zu treffen, fehlt die Anforderung, und Sie müssen sie wiederholen, um (im weiteren Sinne) wirklich überprüfbar zu werden. Sie sollten dies als eine Wiederholung der Anforderungen behandeln.

Ihr Architekt sollte Entscheidungen Ihrer agilen Teams nicht außer Kraft setzen. Ihr Architekt sollte diese in die Anforderungen / Geschichten aufnehmen, die an die Teams weitergeleitet werden. Sie sollten die Teams auf dem Laufenden halten, wenn sich die Projektlandschaft ändert und neue Interoperabilitätsanforderungen eingeführt werden.

Architekten, die Aufträge erteilen und technische Entscheidungen überprüfen, sind ein kultureller Mangel. Sie sehen sich selbst als "Chef", anstatt nur ein gemeinsames Ziel / eine gemeinsame Vision zu verfolgen und getrennte Teams auf derselben Seite zu halten. Agile Methoden basieren auf Kommunikation und Kontakt. Wenn sich Ihre Architekten erst nach dem Treffen von Entscheidungen einmischen, sind sie nicht agil.

Martin, ich glaube, Sie haben ein falsches Verständnis davon, wie ein sich selbst organisierendes Team in seiner Umgebung funktioniert.

Sie haben den Scrum-Leitfaden zitiert: "Niemand (nicht einmal der Scrum-Master) teilt dem Entwicklungsteam mit, wie das Product Backlog in Inkremente potenziell veröffentlichbarer Funktionen umgewandelt werden kann."

Dies ist keine Lizenz für das Scrum-Team, um zu tun, was es will (solange es liefert), ohne die Technologie- und Geschäftsanforderungen des gesamten Unternehmens und die Anforderungen der anderen Teams zu berücksichtigen.

Sicher können Stakeholder ihren Einfluss missbrauchen. Dies ist eine der Herausforderungen bei der Zusammenarbeit, und sie ist sicherlich nicht auf die EA beschränkt. Die Zusammenarbeit endet jedoch nicht an der Grenze des Teams.

Wasserfall oder Scrum (das scheint, als würde man zwei mischen, was ja nicht funktionieren wird), das klingt für mich in erster Linie nach einer ziemlich sinnlosen Managementebene. Gatekeeper bei Technologieentscheidungen sollten leitende Entwickler sein, der Gesamtmanager der Entwicklung, dessen Aufgabe es sein sollte, Entwicklerpräferenzen davon abzuhalten, Ihre App zu einer Hydra von Technologieentscheidungen zu machen, und wer auch immer das Budget hat, um die potenzielle Rechnung zu begleichen.

Nichts ist für mich nach wie vor verblüffend, wie wenn Nicht-Entwickler tatsächlich die Qual der Wahl haben, Technologieentscheidungen zu treffen, ohne auch nur die tatsächlichen Leute zu konsultieren, die unter den Folgen dieser Entscheidungen zu leiden haben.