Agile Skalierung illustriert

Поділитися
Вставка
  • Опубліковано 15 вер 2024
  • Luna möchte Agilität unternehmensweit skalieren, aber wie könnte das aussehen?
    Jetzt kostenlos verfügbar:
    Luna - Das Buch zum Film
    www.it-agile.de...
    Illustration: Nicole Küblböck
    Sprecher: Fabian Dittberner
    Text: Urs Reupke

КОМЕНТАРІ • 19

  • @MarcelVanHove
    @MarcelVanHove 10 років тому +2

    Ich mag Luna! Wunderbares Video, Danke!

    • @UrsReupke
      @UrsReupke 10 років тому

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

  • @DanielDubbel
    @DanielDubbel 10 років тому

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

  • @healthpit
    @healthpit 4 роки тому

    Ein richtig gutes Video!

  • @wolf-gideonbleek2929
    @wolf-gideonbleek2929 4 роки тому

    Sehr, sehr cool!

  • @TheKiwiHH
    @TheKiwiHH 10 років тому +1

    Coole Zeichnungen - selbst gemacht oder hattet Ihr Hilfe?

    • @UrsReupke
      @UrsReupke 10 років тому +3

      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.

  • @steffenwinkler393
    @steffenwinkler393 10 років тому +1

    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
      @stefanroock5330 10 років тому +3

      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.

  • @Knacki42
    @Knacki42 9 років тому +1

    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
      @stefanroock5330 9 років тому +1

      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
      @Knacki42 9 років тому

      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
      @stefanroock5330 9 років тому +1

      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.

  • @darwinjoker6973
    @darwinjoker6973 6 років тому

    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
      @UrsReupke 6 років тому

      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?

  • @deralexist
    @deralexist 10 років тому

    Hi
    super Video!
    Ca 4.25 was wird abwechselnd gemacht?

    • @UrsReupke
      @UrsReupke 10 років тому +2

      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.