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

20

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?

Martin Wickman
quelle

Antworten:

20

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.


quelle
2
Guter Punkt; Ich sehe jedoch nicht, wie dies funktionieren kann, wenn es mehrere Teams gibt, mit denen die Architekten zusammenarbeiten.
Sleske
1
"Hey, EA, jetzt sitzt du hier und kommunizierst immer noch mit denselben Leuten. Nur öfter." Wie genau hilft dies, einen der Konflikte zwischen dem EA und den anderen Entwicklern zu lösen?
Izkata
@sleske, warum nicht die "Enterprise Architects" -Gruppe zwischen den Teams aufteilen? oder mehr Architekten beschäftigen? Das Problem ist, dass das Unternehmen SCRUM und agile Teams haben möchte oder etw. Izkata, tägliche Meetings verändern die Kommunikation im Team erheblich. Ernsthaft: Wenn EA das Gefühl hat, ein Teil des DT zu sein und nicht irgendein Haufen außerirdischer Architektur, ist die Chance für einen Kompromiss größer.
1
@ariwez: "Warum nicht die Gruppe" Enterprise Architects "zwischen Teams aufteilen?" Weil wir mehr Teams als Architekten haben; Auch die Architekten arbeiten meist an Problemen, die mehrere Teams betreffen.
sleske
@sleske: "Individuen und Interaktionen über Prozesse und Werkzeuge"
17

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.")

Jonathan Rich
quelle
Es geht nicht um persönliche Zufriedenheit, sondern um Produktivität, Qualität und Wertschöpfung. Ich gehe davon aus, dass die Entwickler in den Teams diese Unterscheidung treffen können.
Martin Wickman
2
Irgendwann traf jemand die Entscheidung, dass sie es nicht können. Deshalb gibt es die Architekten.
Jonathan Rich
4
Momentan arbeite ich an einer Triple-Stack-App auf der Serverseite, die Rails, Java und .NET mischt, was wirklich nicht sehr kompliziert sein musste. Also ja, Gatekeeper können eine gute Sache sein, aber technische Entscheidungen sollten von Entwicklern getroffen werden, die zu einem Konsens gelangen und vom Management genehmigt oder kommuniziert werden, nicht von Nicht-Entwicklern, die während eines Sprints willkürliche technische Entscheidungen treffen oder Entscheidungen des Entwicklerteams von der Seite wischen.
Erik Reppen
4
@erik Und wenn drei separate Teams ihre drei separaten Konsensentscheidungen treffen, erhalten Sie möglicherweise eine Mischung aus Rails, Java und .Net.
MarkJ
@MarkJ Wenn Sie drei separate Teams haben, die isoliert für dieselbe serverseitige Webanwendung arbeiten, haben Sie das verdient, was Sie erhalten.
Erik Reppen
6

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.

Telastyn
quelle
2
Klar, aber umdrehen: Alle Teams dazu zu zwingen, die gleiche beschissene Technologie zu verwenden, ist noch schlimmer (alle gehen den gleichen hässlichen Weg). Während "Vielfalt" zwangsläufig zumindest einige Lösungen hervorbringt, die Erfolg haben werden.
Martin Wickman
2
@MartinWickman Manchmal stehen Geschäftsentscheidungen hinter der Wahl beschissener Technologien. Wenn 80% der Entwickler in einem bestimmten Markt Erfahrung mit beschissener Technologie haben, kann die Verwendung dieser Technologie wirtschaftlich sehr sinnvoll sein, da Sie bei Bedarf Auftragnehmer hinzuziehen können. In einem kleinen Markt finden Sie möglicherweise keine Python-Programmierer, die ihr Geld wert sind.
Jonathan Rich
@ JonathanRich Wenn ich beschissen sage, meine ich beschissen. Dazu gehört, niemanden finden zu können, der es weiß.
Martin Wickman
1
@MartinWickman - Sicher, ich gehe davon aus, dass Ihre designierten Top-Tier-Entwickler (entweder zugewiesen oder selbst organisiert) keine vollständigen Idioten sind.
Telastyn
1
@JonathanRich fehlerhafte Geschäftslogik, IMO. Größere Quantität bedeutet nicht, dass der Qualitätsanteil höher ist, und es sind viel weniger Python-Entwickler erforderlich, um die Arbeit zu erledigen, wenn sie mindestens kompetent sind.
Erik Reppen
5

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.

Euphorisch
quelle
5

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.

Jay S
quelle
4

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.

sleske
quelle
2
Stimmen Sie mit @MartinWickman überein, dass "Grenze" in mehrfacher Hinsicht der Schlüssel ist: Erstens sollten die Meinungen von Architekten in Softwaregrenzen berücksichtigt werden , in denen Komponenten mehrerer Teams zusammenarbeiten. zweitens, dass die Architekten ihre eigene Autoritätsgrenze kennen , so dass sie nicht in die Entscheidungen des Teams eingreifen, solange die Entscheidungen keine Auswirkungen auf die Interoperabilität haben.
Rwong
3

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.

back2dos
quelle
Sie leisten eindeutig mehr als nur Qualitätssicherung. Sie treffen Entscheidungen über den Einsatz von Werkzeugen.
Erik Reppen
@ErikReppen: Ich war etwas unklar. Ich meinte, QA ist das, was sie tun sollen.
back2dos
@ back2dos: Ich denke, Sie müssen die Qualitätssicherung für die Standardisierung ändern. Ich weiß, was Sie sagen, aber QA ist ein völlig anderes Team und verwirrt Ihren Standpunkt.
gbjbaanb
2

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.

Sean McSomething
quelle
"Wenn sich Ihre Architekten erst nach dem Treffen von Entscheidungen einmischen, scheitern sie an Agilität." - Wenn wir diese Aussage umkehren: "Wenn das Team die Architekten nicht in Entscheidungen einbezieht, ist das Team nicht agil." Wenn das Team Entscheidungen trifft, die eine Änderung der Technologie, der vorhandenen Muster usw. betreffen, muss das Team einen Architekten einbeziehen, um sicherzustellen, dass das Gesamtprodukt zusammenhängend bleibt.
Metro Schlumpf
2

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.

Bob Lieberman
quelle
0

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.

Erik Reppen
quelle
Das liest sich eher wie ein Schimpfen als wie eine Antwort.
Bryan Oakley
Jemand muss es tun.
Erik Reppen