Kommentierte Links (LXVIII)

Bild: Unsplash / Dayne Topkin - Lizenz

[Edit: Der erste verlinkte Artikel war ursprünglich ein anderer, der aber mittlerweile gelöscht wurde]

• Anthony Mersino: Stop Snowplowing in Agile

  Am Anfang von Beratungs- und Projekteinsätzen gibt es immer wieder Momente in denen sich Probleme kondensiert zu erkennen geben. Anthony Mersino hat einen solchen erlebt als er bei einem Kunden erfuhr, dass die Sprintumfänge dort nach dem "Schneepflugsystem" festgelegt werden, was sich vielleicht als "Bugwellensystem" ins Deutsche übersetzen lässt. Dabei wird die nicht geschaffte Arbeit der Vergangenheit einfach zu den nächsten Sprints dazuaddiert, wodurch der "Schneehaufen" den die Teams vor sich herschieben immer grösser wird, bis sie darin stecken bleiben. Im Artikel werden das Phänomen und seine negativen Auswirkungen noch mit mehr Details beschrieben, alleine die Metapher ist aber gut genug um sie sich zur zukünftigen Verwendung zu merken.
  

• Maarten Dalmijn: A pretty burn down chart usually means ugly Scrum

  Ein Artikel bei dem die Überschrift eigentlich schon alles aussagt, zumindest für den der sich mit dem Thema beschäftigt hat. Der häufigste  Grund dafür, dass Burn Down-Charts sich entlang der Ideallinie bewegen ist, dass alles wie geplant abgearbeitet wird. Der Grund dafür, dass nach Scrum gearbeitet wird ist aber, dass sich in einem komplexen Umfeld nicht alles wie geplant umsetzen lässt. Dass sich das beisst ist offensichtlich, und doch gibt es immer wieder Teams die auf ihre schönen Burndowns stolz sind. Maarten Dalmijn nennt vier wahrscheinliche Gründe dafür: Methodismus, kein Streben nach neuen Erkenntnissen, fehlende Lernbereitschaft, Risikoaversität. Nichts worauf man stolz sein sollte.
  

• Avi Siegel: How to Choose a Product Prioritization Framework
  

  Ein hilfreicher Text für Product Owner oder Teams die sich mit dem Priorisieren schwertun. Avi Siegel erklärt in ihm zuerst einige der verbreitetsten Priorisierungsmethoden: Aufwand/Ertrag-Matrix, RICE Score (Reach, Impact, Confidence, Effort), ICE Score (Impact, Confidence, Ease), Weigted Scoring (relative Gewichtung), Kano-Modell (Notwendigkeits/Begeisterungs-Matrix) und MoSCoW-Methode (Must have/Should have/Could have/Won’t have). Als nächstes versucht er alle genannten Ansätze in dem Zusammenzubringen was er sein "Meta-Framework" nennt. In der Anwendung stelle ich mir dieses Meta-Framework kompliziert vor, es sich anzuschauen hilft aber auf jeden Fall dabei die verschiedenen Dimensionen von Priorisierung besser zu verstehen.
  

• Lisa Crispin: Shifting left & right in our continuous world

  Wie Lisa Crispin es hier selbst sagt: die Begriffe "Shift Left" und "Shift Right" sind zu unklar definiert und werden daher zu oft falsch verstanden. In ihrer Definition beziehen beide sich darauf, dass die Qualitätssicherung aus ihrem Organisations- und Prozessphasen-Silo ausbricht und sich gemeinsam mit den (im klassischen Aufbau) vor- und nachgelagerten Einheiten zu crossfunktionalen Teams vereinigt. Vorgelagert sind dabei Design und Entwicklung, nachgelagert Release und Betrieb. Interessant ist dabei ihre Art das im DevOps/ContinuousX-Loop zu visualisieren. Etwas das man für Workshops mitnehmen kann.
  

• Erich Bühler: Dealing with Psychopaths and Narcissists during Agile Change

  Zu den Missverständnissen denen Gegner (und Befürworter) der agilen Frameworks regelmässig erliegen gehört, dass Veränderungen in Richtung Agilität zumindest auf den unteren Hierarchieebenen immer mit Offenheit (wenn nicht sogar Begeisterung) aufgenommen werden, da den Teams schliesslich mehr Freiheiten und weniger unbegründete Anweisungen gegeben werden. Die Realität ist leider häufig eine andere, immer wieder gibt es die sprichwörtlichen toxischen Personen an denen sich alles aufreibt. Erich Bühler nimmt sich dankenswerterweise dieses oft verschämt verschwiegenen Themas an.
  

Produktziel und Produktvision

Bild: Pixabay / Larisa K. - Lizenz

Seit November 2020 muss die agile Community mit einer Begriffsverwirrung leben. Das in diesem Monat veröffentlichte Update des Scrum Guide führte einen neuen, bis dahin kaum bekannten Begriff ein: das Produktziel (Product Goal). Verwirrend ist das deshalb, weil es (ausserhalb von Scrum) einen sehr ähnlichen und bereits etablierten Begriff gibt, die Produktvision (Product Vision). Ist das jetzt das Gleiche? Gibt es Unterschiede? Wenn ja welche? Schauen wir uns die Begriffe an.

Die Ursprünge der Produktvision verlieren sich irgendwo im Dunkel der Geschichte, bereits in rückwirkend digitalisierten Fachartikeln findet man sie aber wieder, z.B. 1984 im Harvard Business Review als "Vision for the Product". Konkretisiert wurde sie später in verschiedenen Formen, unter anderem 1991 von Geoffrey Moore in Crossing the Chasm (als "Product Elevator Pitch") und 1995 von Michael McGrath in Product Strategy for High Technology Companies (als "Strategic Vision").

Die Gemeinsamkeit dieser Ansätze ist, dass sie die Produktvision im Sinn eines Leitsterns, Fernziels oder Idealtypus definieren, also als etwas was in der Realität kaum zu erreichen ist. Der damit verbundene Zweck ist, dass durch eine Ausrichtung an dieser Vision kontinuierlich in eine gleichbleibende Richtung gearbeitet werden kann, was sowohl durch Abarbeiten eines langfristigen Plans möglich ist (im Wasserfall-Vorgehen) als auch durch kurzfristiges Optimieren der jeweils nächsten Schritte in Richtung des Langfristziels (agiles Vorgehen).

Im Unterschied dazu kann das im Scrum Guide beschriebene Produktziel explizit erreicht werden. Der in diesem Zusammenhang entscheidende Absatz lautet "The Product Goal is the long-term objective for the Scrum Team. They must fulfill (or abandon) one objective before taking on the next.", wodurch klar wird, dass eine Beendigung der Arbeit am Produktziel möglich ist. Eine Zwangsläufigkeit dass das in absehbarer Zeit geschieht ist das zwar nicht (theoretisch sind Produktziele möglich die erst in Jahrzehnten erreichbar sein werden) grundsätzliche Abschliessbarkeit sollte aber gegeben sein.

Der Differenzierung sollte damit klar sein: die Produktvision ist der führende, aber letztendlich unerreichbare Leitstern, das Produktziel der ferne aber (theoretisch) erreichbare Abschluss aller Arbeiten die für ein Produkt nötig sein werden.

Absehbar ist aber auch: So hilfreich diese begriffliche Unterscheidung für das Verständnis auch sein mag, in der Realität dürfte sie nur selten vorgenommen werden. Es werden wohl nur die methodenbegeisterten Teams sein die in ihrem Backlog eine Differenzierung zwischen Produktvision und Produktziel vornehmen, die meisten werden nur einen der Begriffe verwenden oder sie synonym gebrauchen - was angesichts der grossen Schnittmengen auch unproblematisch sein sollte. Wichtig ist nur, die Unterscheidung zu kennen, um bei Bedarf beides einsetzen (oder den Unterschied erklären) zu können.

Evil User Stories

Bild: Unsplash / Lukas Eggers - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind in der Regel aus der Sicht des Nutzers formuliert (so genannte User Stories), und die fertigen Ergebnisse werden zusammen mit ihm getestet und besprochen. Was bei all dem aber zu bedenken ist -  manchmal lassen Benutzer sich zu Aktionen hinreissen die sie besser unterlassen hätten, und von denen das System sie abhalten sollte. Lassen sich auch derartige "verhindernde Funktionen" als User Story formulieren?

Bevor wir darauf eingehen eine kurze Sinnfrage: wenn ein Nutzer eine bestimmte Aktion nunmal durchführen will, warum sollte man ihn davon abhalten? Weiss er nicht am besten was richtig für ihn ist? Die Antwort darauf: leider nicht immer, und ein wie es der Zufall will gibt es auch ein aktuelles Beispiel dafür. Um zu zeigen wie produktiv sie im Home Office war veröffentlichte eine niederländische Ministerin auf Twitter einen Screenshot von einer EU-Ministerrunde an der sie gerade teilnahm. Da dieser in seiner URL den Konferenzdienst und den Zugangscode anzeigte war es für jeden ihrer Twitter-Follower möglich ebenfalls an dem Meeting teilzunehmen. Und ein Journalist gönnte sich den Spass und machte genau das.

Dit was de oorspronkelijke foto die vanaf het account van minister Bijleveld werd gedeeld, met daarin de meeting-ID en vijf cijfers van de pincode.

Het was een zescijferige pincode. Ik joinde met de naam 'admin'. pic.twitter.com/Fztrbqm5FR

— Daniël Verlaan (@danielverlaan) November 20, 2020

Zurück zur Ausgangsfrage. Lassen sich User Story formulieren die zwar aus Nutzerperspektive geschrieben sind aber ein fahrlässiges Verhalten wie das der niederländischen Ministerin verhindern sollen? Natürlich geht das, es fühlt sich aber künstlich an. "Ich als Videokonferenz-Teilnehmer möchte daran gehindert werden Zugangsdaten zu veröffentlichen, damit kein Unbefugter teilnehmen kann" ist kein Satz oder Wunsch den ein echter Mensch jemals äussern würde.

Ein besserer Ansatz wäre es sich den Benutzer/User aus einer anderen Perspektive vorzustellen. In UX-Design und Software-Test gibt es den Typus des "Evil User", der sich dadurch auszeichnet, dass er Funktionen immer wieder so benutzt wie sie nicht gedacht sind und dadurch Fehlfunktionen und falsche Ergebnisse erzeugt. Wichtig ist dabei, dass er das (meistens) nicht aus bösem Willen tut sondern aus Unkenntnis und ohne zu wissen was er anrichtet - wie im Fall der oben genannten Ministerin.

Vom Evil User zur User Story ist es jetzt nur noch ein kurzer Sprung. "Ich als Videokonferenz-Teilnehmer möchte Screenshots mit allen sichtbaren Informationen veröffentlichen, damit jeder sehen kann was ich mache". Mit solchen Anforderungen in ein Refinement zu gehen kann wertvolle Diskussionen ermöglichen. Für den Fall dass jemand etwas Derartiges tut (verhindern kann man es nicht) welche Informationen sind dann öffentlich sichtbar? Welche davon sind sicherheitsrelevant? Und wie könnte man sie unkenntlich machen?

Aus derartigen Diskussionen können sich dann die Akzeptanzkriterien der Evil User Story ergeben, die in diesem Fall negativ formuliert sind, da sie ja das "bösartige" Nutzerverhalten eindämmen sollen. Angelehnt an den oben genannten Fall könnte etwa eines sein, dass weder auf der Website des Video-Calls noch in der URL Zugangsdaten sichtbar sein dürfen.

Als letztes noch ein Tip aus der Praxis: es macht Sinn die Evil User Stories im Backlog mit einer besonderen Kennzeichnung zu versehen. Wenn das nicht passiert besteht das Risiko, dass das Team vergessen hat, dass es sich bei einer älteren Story um eine zu verhindernde Aktion handelt und diese dann in der Weiterentwicklung nicht verhindert sondern erleichtert oder sogar erst ermöglicht. In solchen Fällen steckt eine feine Ironie: das Team ist dann der Evil User seines eigenen Prozesses.

Update des Scrum Guide 2020

Grafik: Wikimedia Commons / Huluvu424242 - CC BY-SA 4.0

Nach drei Jahren ist es wieder soweit, der Scrum Guide hat ein Update erhalten. Nachdem im Vorfeld lediglich bekannt war, dass die neue Version kürzer werden würde als die alte, gab es gespannte Neugier auf das was wegfallen würde und das was dazukommt. Das Warten hat ein Ende, schauen wir uns an wie es gekommen ist.

Die offensichtlichste Neuerung dürfte das Produktziel sein, dass jetzt Teil des Product Backlogs ist. Im weitesten Sinn vergleichbar mit der Produktvision beschreibt es das langfristige Ziel auf das das Scrum Team hinarbeitet und auf das sich das gesamte restliche Product Backlog ausrichten soll. Es wird auch klar herausgestellt, dass es nur ein einziges Produktziel geben soll, womit auch die Hauptmotivation seiner Einführung klar sein dürfte - zusammengewürfelte Sammelsurium-Backlogs sollen unmöglich gemacht werden.

Bei den Rollen gibt es keine wirklichen inhaltlichen Änderungen, allerdings wurden vor allem beim Scrum Master Formulierungen so geändert, dass bestimmte (Fehl-)Interpretationen nicht mehr möglich sind. Es ist jetzt noch deutlicher, dass er nicht nur für das Team zuständig ist sondern für die gesamte Organisation und deren Weiterentwicklung in Richtung Agilität. Zum ersten mal ist er nicht mehr dafür zuständig Impediments selbst zu beseitigen, er muss nur noch dafür sorgen, dass irgendjemand es tut. Und seine Rolle in der Retrospektive ist jetzt deutlich weniger dominant formuliert. Angepasst wurde auch ein Grenzwert: statt 11 soll ein Scrum Team nur noch bis zu 10 Mitglieder haben.

Bei den Meetings hat sich vor allem das Planning in seinem Ablauf verändert. Neben die Phasen in denen der Umfang und die Art der Umsetzung diskutiert werden (früher Planning I und Planning II) tritt eine vorgelagerte dritte (bzw. der neuen Reihenfolge nach erste) Phase in der die Sinnfrage nach dem Zweck des Sprints gestellt und mit dem Sprintziel beantwortet wird. Ebenfalls erwähnenswert: die seit 2017 ohnehin nicht mehr verpflichtenden drei Fragen sind jetzt endgültig aus der Beschreibung des Daily Scrum verschwunden.

Eher für den englischen Sprachraum von Bedeutung dürfte das Ersetzen des Begriffs Self-Organizing durch Self-Managing sein. Die Intention einer klareren Betonung der Selbstbestimmung ist klar, im Deutschen dürfte diese Differenzierung aber kaum einen Unterschied machen¹. Auch die Unterscheidung zwischen Role (aus dem Scrum Guide entfernt), Responsibility und Accountability dürfte in Deutschland nur von akademischem Interesse sein.

Zuletzt kommen noch verschiedene redaktionelle Änderungen dazu, zum Teil in Form von klareren Formulierungen, etwa bei den Artefakten Product Backlog, Sprint Backlog und Increment, von dem z.B. jetzt klarer ist, dass es (zum Teil) auch vor Sprintende geliefert werden kann, etwa im Rahmen von Continuous Delivery. Gleichzeitig wurden an einigen Stellen unnötig detaillierte Beschreibungen entfernt, der offensichtlichste Fall dafür dürfte der Sprint-Abbruch sein, der von einem Absatz auf eine Zeile zusammengeschrumpft ist.

Fazit: mit dem Produktziel gibt es eine grosse Änderung die Scrum noch einmal in die richtige Richtung schieben kann, alleine dafür hat sich das Update gelohnt. Der Rest ist gut aber nice to have. Mal sehen wie lange es bis zum nächsten Update dauert.

¹Nachtrag: nach einigen Diskussionen zu dem Thema - ja, der 2017er Scrum Guide sagte "Self-organizing teams choose how best to accomplish their work" während der 2020er Scrum Guide sagt "Scrum Teams are [...] self-managing, meaning they internally decide who does what, when, and how." Wie oben gesagt, die Intention einer klareren Betonung der Selbstbestimmung ist klar, einen Paradigmenwechsel erkennt man hier aber vor allem dann wenn man unbedingt einen erkennen will. Auch in der 2017er Version war die Erstellung der (Sprint-)Ziele schon etwas was das Scrum Team selbst gemacht hat.

Woran man erkennt, ob ein Unternehmen wirklich nutzerzentriert ist

Bild: Pexels / Fauxel - Lizenz

Eine der Gemeinsamkeiten praktisch aller agil aufgestellten Organisationen ist die Nutzerzentrierung. Die Anforderungen sind aus der Sicht des Nutzers formuliert (🡒 User Stories), die schnelle Fertigstellung und Auslieferung neuer Features soll diese möglichst schnell zu ihm bringen, die Durchführung von Sprint Reviews. A/B-Tests, etc. soll sein Feedback möglichst schnell einsammeln. Was bei all dem aber zu bedenken ist - Anforderungstypen, Lieferzyklen und Meetingtypen sind nur Formalien, für das wirkliche Vorhandensein von Nutzerzentrierung können sie lediglich als Indikator dienen. Um festzustellen, ob die wirklich gegebem ist, gibt es aber einen anderen, bemerkenswert einfachen Weg: man muss sich nur ansehen, mit welcher Software eine Firma ihre eigenen Mitarbeiter arbeiten lässt.

Um zu verstehen warum das so ist, ein bisschen Kontext: es gibt heute keine Firma mehr, in der ohne Software gearbeitet werden kann. Oft findet die Arbeit direkt am Computer statt (z.B. in Banken und Verlagen), selbst wenn das nicht der Fall ist, finden aber begleitende Prozesse digital statt, von der Arbeitszeiterfassung über die Buchung von Dienstreisen und Fortbildungen bis hin zur Suche von Informationen im Intranet. Dafür ist zum Teil intern entwickelte Software im Einsatz, zum Teil auch solche, die eingekauft wurde.

Noch ein bisschen mehr Kontext: Nutzerzentrierung ist eine Haltung, die sämtliche Prozesse immer von eben dem Nutzer aus denkt. Er und seine Bedürfnisse stehen im Mittelpunkt, und zwar auch dann, wenn derjenige, der die Anwendung für ihn entwickelt, ein Monopolist ist, der Aussehen und Verhalten neuer Funktionen aufzwingen kann. Das heisst natürlich nicht, dass es nicht immer wieder Gründe geben kann, sich im Anwendungsdesign gegen die Wünsche des Nutzers zu entscheiden - nur sollte man dann so ehrlich sein und nicht mehr von Nutzerzentrierung sprechen.

In vielen Organisationen, die sich nach aussen nutzerzentriert geben, ist aber genau das der Normalfall. Da sich die eigenen Mitarbeiter nicht zur Wehr setzen können, indem sie zu anderen Produkten wechseln, wird ihnen zugemutet mit Software zu arbeiten, für die sich bei freier Auswahl niemand entscheiden würde. Umständlich und unintuitiv in der Bedienung, mit langsamen Lade- und Verarbeitungszeiten und hoffnungslos veraltetem Look & Feel ist sie in solchen Fällen ein laut und häufig verfluchtes Hassobjekt, das handfeste negative Folgen mit sich bringt. Zunächst sinkende Effizienz und Effektivität, aber auch sinkende Wertschätzung und Loyalität der Angestellten zum eigenen Unternehmen.

Umgekehrt kann moderne, einfach bedienbare, die Arbeit erleichternde und auf Basis von Feedback weiterentwickelte Software wesentlich dazu beitragen, dass das Verhältnis zwischen einem Unternehmen und seinen Angestellten ein gutes ist. Zum Einen weil die Mitarbeiter das Gefühl haben, dass ihnen für ihre Arbeit die richtigen Werkzeuge gegeben werden (und dass auch in diese investiert wird), zum Anderen weil sie sehen, dass ihre Rückmeldungen ernst- und angenommen werden.

Zuletzt kommt noch ein weiterer, nicht zu unterschätzender Aspekt dazu, der uns wieder zum Anfang dieses Artikels zurückbringt: die Mitarbeiter sehen, wie ernst ihre Firma die öffentlich propagierte Nutzerzentrierung wirklich meint. Wenn sie das Gefühl haben, dass diese auch tatsächlich im Unternehmen gelebt wird, ist die Wahrscheinlichkeit gross, dass sie sich auch selbst entsprechend verhalten. Wenn sie umgekehrt den Eindruck bekommen, dass Nutzerzentrierung nur ein Selbstdarstellungs-Buzzword ist, wird auch das sich im eigenen Verhalten niederschlagen.

Am Ende ist es ein von vielen Unternehmen verkannter Zusammenhang - wer glaubt Nutzerzentrierung nur nach aussen leben, nach innen aber unterlassen zu können, riskiert, dass er sie in beiden Dimensionen verliert.

Visualized Continuous Delivery

Schon ein paar Jahre alt, aber noch immer bemerkenswert. In diesen kleinen Kunstwerken stecken genug Details und Informationen um sich erstaunlich lange darin zu vertiefen. Man kann der Urheberin nur dankbar sein, dass sie es der Allgemeinheit zur Verfügung gestellt hat.

 

Grafiken: Nhan Ngo - CC BY SA 3.0

Before Chaos, during Chaos, after Chaos

Eigentlich bin ich kein Fan davon in einem Arbeitskontext den Begriff  "Chaos" zu verwenden, da er in meinem Verständnis einen Zustand beschreibt in dem Arbeiten eigentlich nicht mehr möglich ist. "Chaos Engineering" hat sich allerdings mittlerweile als Name für ein bestimmtes Vorgehen durchgesetzt, auf das sich ein näherer Blick lohnt. Gut, dass Nora Jones, eine der Verfasserinnen des gleich benannten Buchs, regelmässig Vorträge zu diesem Thema hält.

Sehenswert ist dieser Vortrag aber nicht nur weil Jones erklärt was Chaos Engineering ist, er ist auch deshalb wichtig weil sie in ihm unterstreicht, dass der ganze Ansatz nur wenig bringt wenn er nur von wenigen Experten und Enthusiasten angewandt wird. Erst wenn sich die gesamte Produktentwicklung an den "Chaos-Experimenten" beteiligt entfaltet sich die ganze Wirkung.

Crossfunktionale Teams (III)

Bild: Pexels / Tom Fisk - Lizenz

Wenn man sich in Firmen umhört die sich dem agilen Arbeiten verschrieben haben dann gehört das Bekenntnis zu den crossfunktionalen Teams mittlerweile zum Standard. Es ist weitgehend anerkannt, dass nur eine Einheit die alle zur Produktherstellung nötigen Skills enthält schnell auf Änderungen reagieren kann ohne auf Zulieferungen warten zu müssen, und dass solche Einheiten auch wesentlich besser darin sind die dabei entstehenden Aufwände zu schätzen kommt noch dazu. Es ist also alles gut. Oder?

Zugegeben, die Frage war rhetorisch. Tatsächlich ist in den meisten Fällen noch nicht alles gut, ein näherer Blick zeigt warum. In agilen Teams wird die Crossfunktionalität (ohne bösen Willen, bzw. durch fehlendes Verständnis) meistens auf Entwickler-Spezialisierungen reduziert.¹ Ein so verstandenes Team besteht dann etwa aus zwei Frontend-Entwickler, zwei Backend-Entwicklern und zwei Testern. Crossfunktional? Ja, aber nur innerhalb eines Silos. Das reicht nicht.

Was in solchen Konstellationen zur Crossfunktionalität im eigentlichen Sinn fehlt ist die Einbeziehung derjenigen Organisationsbereiche die man als "Upstream" und "Downstream" bezeichnet. Gemeint sind damit die Menschen (oder Kompetenzen) mit denen auch die der Entwicklung vor- und nachgelagerten Tätigkeiten entlang der Bearbeitungskette durchgeführt werden können.

Upstream (stromaufwärts) befindet sich zum Beispiel das Anforderungsmanagement, also vereinfacht gesagt die Menschengruppe die den Kontakt zu Auftraggebern und Nutzern hat. Da dieser Kontakt nötig ist um regelmässiges Anwender-Feedback zu erhalten gehört diese Kompetenz genauso in die Teams wie der nächste Schritt, die Konzeption, in dem Business Analysten, Architekten, UX-Designer und ähnlichr Rollen bereits für die Entwicklung wichtige Entscheidungen treffen.

Anders strukturiert aber genauso wichtig ist der Bereich Downstream (stromabwärts). In ihm befinden sich Kompetenzen wie Integrationsmanagement, Testmanagement, Releasemanagement und Rolloutmanagement, ohne die neue Features nicht auf Produktions- oder Abnahmeumgebungen gelangen können. Da aber erst dort der Anwenderkontakt stattfindet (der die zwingende Voraussetzung für das folgende Feedback ist) gehört auch das ins Team.

Wichtig zum richtigen Verständnis ist dabei: es sind die Kompetenzen die in die Teams gehören und nicht notwendigerweise die Rollen. Architektur, UX-Design und Testmanagement können in den meisten Fällen auch vom Entwicklungsteam verantwortet werden (was übrigens Architekten, UX-Designer und Testmanager nicht überflüssig macht sondern deren Rolle in Richtung Coaching und Servant Leadership verändert).

Und um auf eine an dieser Stelle häufig geäusserte Sorge einzugehen: ja, auch aus Governance- und Compliance-Sicht ist ein derartig crossfunktionales Team in der Regel zulässig und arbeitsfähig. Man muss sich nur darauf einlassen wollen.

¹Wobei derartige Teams bei genauerer Betrachtung meistens nicht wirklich agil agieren

Das Problem mit SAFe (I)

Bild: Piqsels - Lizenz