Agile Skalierung illustriert

[@DanielDubbel]

Tolles Video und super Überblick - vielen Dank dafür.

[@wolf-gideonbleek2929]

Sehr, sehr cool!

[@MarcelVanHove]

Ich mag Luna! Wunderbares Video, Danke!

[@UrsReupke]

Danke für das Lob. Deine Filme waren uns Inspiration.

[@healthpit]

Ein richtig gutes Video!

[@deralexist]

Hi super Video! Ca 4.25 was wird abwechselnd gemacht?

[@UrsReupke]

Vielen Dank. Abwechselnd macht sie die horizontale und vertikale Skalierung: Sie gründet stückweise neue Teams (vertikale Skalierung) und dehnt die entlang der Wertschöpfungskette (horizontale Skalierung) aus. Wenn sie's nicht macht, muss sie am Ende das Marketing an einen sehr großen bestehenden Entwicklungsapparat angliedern, und das erhöht den Integrationsschmerz.

[@darwinjoker6973]

wie macht ihr das mit einem 24/7 Support oder mit dem Support vom Rechenzentrum ? sollen die auch jeweils in den einzelnen Scrum Teams vertreten sein ? dann wird das ganz schön redundant und teuer ....

[@UrsReupke]

Du hast recht, wenn jedes Team seinen eigenen Support macht, dann ist das teurer als wenn es eine zentrale Anlaufstelle gibt. Den 24/7-Support für einzelne missionskritische Softwareprodukte haben wir dennoch schon in Scrum-Teams erledigt, das klappt gut, und hat für den Kunden den Vorteil, dass er sofort mit jemandem spricht, den er kennt und der sich mit der Sache auskennt. Damit das funktioniert, braucht es natürlich eine Übereinkunft, dass der Kunde nicht wegen Trivialitäten anruft. Infrastruktur wird ja eher nicht von (skalierten) Scrum-Teams betrieben, deswegen hätten wir auch kein Team, dass den Support übernehmen kann. Macht ihr das mit Scrum? Wie funktioniert es?

[@TheKiwiHH]

Coole Zeichnungen - selbst gemacht oder hattet Ihr Hilfe?

[@UrsReupke]

Selbst gemacht, alles ist live aufgenommen. Nicole (im Bild) hat Kunst studiert, sie ist "Bachelor of Fine Arts in Design and Production", und unterstützt uns unter anderem mit Visual Facilitation und Visual Recording - wenn Sie nicht gerade in Neuseeland Filme dreht.

[@Knacki42]

Schönes Video. Trotzdem: Crossfunktionale Teams sind nicht unbedingt besser. Gerade in der SW Entwicklung gibt es nun mal Spezialisten (Frontend, Mobile, Backend). Jeder kann alles (aber nix richtig) vs. Spezialisten für Komponenten.

[@stefanroock5330]

Cross-Finktionales Team bedeutet, dass alle Fähigkeiten im Team sein müssen, die für die Produktentwicklung notwendig sind. Im Team sind Spezialisten damit problemlos möglich - und auch in der agilen Welt üblich.

[@Knacki42]

Stefan Roock Ich weiß was "Crossfunktionales Team" bedeutet und habe auch schon in solchen gearbeitet. Und natürlich gibt es immer Spezialisten im Team (Designer, Qualitätsmanager, Frontend Programmierer). In SAFe beispielsweise gibt es ja auch Teams die in Containern arbeiten und eben nicht crossfunktional aber trotzdem agil. Das bedingt natürlich zusättzliche Abstimmungsmeetings und so weiter.

[@stefanroock5330]

Michael Knoll Dann verstehe ich Deinen ursprünglichen Punkt vielleicht nicht richtig. Worauf willst Du hinaus? Ich stimme zu, dass cross-funktionale Teams nicht immer die beste Lösung sind - nämlich dann nicht, wenn das Umfeld stabil und die Aufgaben repetitiv sind.

[@steffenwinkler393]

Eine Aussage ist, Kommunikation zwischen den Teams ist teuer, deswegen kommuniziert man nicht und implementiert Redundanzen. Das ist kurzsichtig und klingt nach Script kiddie oder Copy/Paste. Redundanzen werden richtig teuer und lähmen den Fortschritt, weil man jedes neue Feature oder jeden Bug in jeder Redundanz einpflegen muss.

[@stefanroock5330]

Jedes Team sollte Redundanzen in seinen Modulen vermeiden. Das geht mit moderaten Kosten. Wenn die Teams passend geschnitten sind, gibt es nur geringes Redundanzrisiko. Will man alle Redundanzen zwischen allen Teams (z.B. zwischen 15 Teams) komplett vermeiden, wird das sehr teuer aufgrund der notwendigen Koordination. Lässt man alle Redundanzen bestehen, erzeugt das ebenfalls Kosten. Es geht um die Optimierung der Gesamtkosten und dieses Optimum liegt in den meisten Kontexten bei keinem der Extreme. Ausführlichere Diskussion gibt es in der Agile Review 1/2014.