1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Agile…

Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 24.05.22 - 15:37

    Sehr geehrter Herr Heckel,
    Sehr geehrte Damen und Herren,

    nun melde ich mich doch zu Wort, da dieser Artikel zum Thema "Scrum" bzw. "Agile Unternehmen" nicht der Realität in globalen Unternehmen entspricht, die wir als Nicht-Leaders an der tatsächlichen Front(end) erleben müssen. (Zzgl.: KollegINNEN aus Backend, QA, Design, DevOps, Software Architects, Solution Architects und andere fancy Jobtitel, deren Jobbeschreibung keiner eindeutig definieren kann)

    Ausgenommen sind die Hipster-Unternehmungen und -Startups, die sich im aktuellen State und der aktuellen Seed-Phase noch als agile und lean verkaufen müssen, damit sie interessant genug für Ressourcen wirken, die für den geplanten schnellen Wachstum zwecks Scalability benötigen werden.
    Ressourcen in Form von willigen, motivierten,„Visions- und Values-geblendeten“ MitarbeiterINNEN, die dann nach abgeschlossener Arbeit langsam aber sicher wieder abgeschoben werden, damit am Geschäftsjahresende die präsentierten Zahlen vor Stake- bzw. Shareholdern "schwarz" und nicht rot ausfallen. Nennt sich auch „Continuous Faking“.

    Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile“.

    Wie komme ich zu dieser Aussage?

    In meinen 15+ Jahren Erfahrung im Projekt- und Produktmanagement habe ich bisher kein Unternehmen gesehen, wo einer der möglichen verwendbaren roten Fäden funktioniert hat - Begriffe wie „Scrum, Kanban, Scrumban, Kanrum, Kanscrum, Agile“ und die dazugehörigen cool klingenden Teilbegriffe dienen einem Unternehmen nur als Buzzwords für Marketingzwecke und zum Vertrieb eines internen innovativen Images. Unternehmen wollen mit diesen und weiteren Buzzwords vor allem der Jugend und Junggebliebenen beweisen, dass man auch noch hip und innovativ ist - vor allem im Vergleich zu den Global Playern wie Google, Microsoft, Facebook oder Hipster-Unternehmen mit einem „sustainable Mindset“.

    ————

    Argument: Einführung, Integration ohne wirkliches Commitment (Akzeptanz) und globalem Verständnis (vor allem im Management)
    Grund hierfür ist die tatsächliche Integration der einzelnen roten Fäden ohne 100%igem Commitment von jedem einzelnen Mitarbeiter (w/m/d).

    Und dazu zählt auch jeder einzelne Mitarbeiter aus dem Management - CEO, COO, CPO, CVO, CFO, CIO, Head of, Team-Lead, bis zu den betroffenen Persönlichkeiten wie Lead-(Dev, Designer, QA,…) Senior, Professional, Junior, Azubi, Werksstudent, Praktikant.

    Akzeptiert das Management nicht die nötigen Mechanismen des genutzten roten Fadens - dem möglichen kurzfristigen Kontrollverlustes und der nötigen persönlichen Veränderung trotzend (Stichwort: Mindset, Continuous Personal Evolvement) - wird das eigene Unternehmen niemals „agile“ und auf ewig „fragile“ bleiben.

    Jeder einzelne Mitarbeiter muss das Verständnis und die Akzeptanz bezüglich des genutzten roten Fadens aufweisen. Auch das Management, die Stake- und Shareholder.

    Ansonsten kommt es zu:
    - unfertigen und zu kurz getesteten Features, weil das Product Ownership die vom Management unter Druck verlangten Zahlen sonst nicht erfüllt bekommt (auch mit Bezug auf: „Head ofs“ und andere „Leader“). Verschiedene (Prozess- und Leadership-)Rollen werden anhand von Zahlen gemessen und dadurch entsteht eine Abhängigkeit zwischen (Sprint-)Output und den daraus resultierenden Zahlen. Output und Zahlen haben somit einen immensen Impact auf Gehaltsgespräche von Rolle X/Y mit dem Management. Wodurch unrealistische Deadlines und Workarounds entstehen. (Ist das wirklich die Philosophie hinter „agile“?)
    - Workarounds, die auf die schnelle eingebaut werden müssen, um unrealistisch kommunizierte Deadlines einhalten zu können und um Features fertig zu bekommen. Die eingebauten Workarounds wiederum führen zu einer minderwertigen Produkt-(Code)-Qualität. Aus langer Sicht betrachtet führen Workarounds zu Zusatzkosten und enorm hohem nachträglichen Mehr-Invest. Alleine der zeitliche Aufwand für die Einarbeitung und Wartung für solch eine Code-Basis lässt den tatsächlichen Invest um das 3-fache steigen.
    - Deployments von unfertigen oder schlecht und auf die Schnelle getesteten Features, an einem Donnerstag bzw. Freitag.
    - Unnötigem Stress und Druck durch erzwungen/gezwungene Deployments, „weil sonst das Sprintgoal nicht eingehalten wird“
    - Reportings: Dem oberen Management werden all die genannten Punkte oberhalb dieses Aufzählungspunktes NICHT mitgeteilt und transparent dargelegt, aus Angst vor Reputationsverlust und dem Verlieren der eigenen Position. (Stichwort: Continuous Personal Evolvement)

    ————

    Argument: Der Zwang zum Stake- und Shareholder-befriedigenden „Continuous Integration“ und „Continuous Deployment“ (CI/CD)
    Schauen wir uns mal kurz die Bedeutung vom Wort „Continuous“ bzw. „kontinuierlich“ an.

    Adjektiv: „fortdauernd, lückenlos zusammenhängend, gleichmäßig sich fortsetzend, weiter bestehend“
    Beispiel: „eine kontinuierliche Entwicklung"
    Quelle: Google

    Mit dem Ziel des regelmäßigen Release neuer Features zur Befriedigung des Kundenstammes, der Stake- und Shareholder wie auch dem Management wird in Unternehmen die Strategie CI/CD verfolgt, gelebt - und ohne Rücksicht auf jeden einzelnen Mitarbeiter und der internen Produkt-Qualität unter Druck und Zwang durchgesetzt.

    Scalability ist eben wichtiger, als das Wohlbefinden der Mitarbeiter oder der Produkt-Qualität (siehe auch Auflistung unter 1.Grund: „Ansonsten kommt es zu…“)

    Aber ist diese Art der Produkt-Entwicklung wirklich „agile“? Vor allem auch aus langer Sicht betrachtet „sustainable“?

    Nicht wirklich, denn um CI/CD wirklich leben zu können, müssen kontinuierlich auch weitere zusammenhängende Topics lückenlos integriert und weiterentwickelt werden:
    - Continuous Reflection: Kontinuierlich sich selbst und alle Schnittstellen hinterfragen, Feedback und vor allem konstruktive Kritik einholen
    - Continuous Listening: Kontinuierlich über den eigenen rollenspezifischen Tellerrand hinausschauen und hineinzögen bzw. zuhören, um Verständnis aufzubauen.
    - Continuous Understanding: Kontinuierliches Aufbauen und Aktualisieren des persönlichen Verständnisses zu den eigenen rollenbezogenen Schnittstellen. Jede Rolle muss verstehen, wie jede einzelne Schnittstelle funktioniert, arbeitet, arbeiten möchte und muss das Verständnis mitbringen, was eine Schnittstelle benötigt, um die individuelle Arbeit erfolgreich abschließen zu können. (=Requirements Engineering)
    - Continuous Personal Evolvement: Persönliche kontinuierliche Weiterentwicklung von Mindsets, Softskills, Hardskills, beginnend „von oben nach unten“

    ————

    Argument: Nicht nur Development hat eine „Definition of Ready“ und „Definition of Done“
    Jeder Prozessschritt und jede dazugehörige verantwortliche Rolle bzw. Rollengruppe hat eine individuelle „Definition of Ready“ und „Definition of Done“. Aber bis heute werden diese Definitionen nur im Development-Bereich festgelegt und dokumentiert.

    Was ist mit Product Ownership, Design (UI/UX am besten einzeln verfassen), Backend, Frontend, QA, Marketing, Sales, Management?

    Das ist nicht „agile“, sondern der Fokus im heutigen „Agile“ wird hauptsächlich nur auf die Entwicklung gesetzt. Denn aus der Sicht vom Management und den Stake- bzw. Shareholdern „sind die Entwickler für den greifbaren und ersichtlichen Output verantwortlich“.

    Die Planung, Vorbereitung, Konzeption und vor allem die Prozessschritte nach der Entwicklung erhalten kontinuierlich zu wenig Aufmerksamkeit (Stichwort: QA).

    Alleine für die interne Transparenz, einer effizienten Kommunikation, für erfolgreiches CI/CD/CR/CL/CU/CPE und einer klaren einmaligen Definition „Wie ein Feature entwickelt wird und wann wer was zum erfolgreichen Abschließen der individuellen Arbeit benötigt?“

    ————

    Argument: Der zeitliche tägliche Invest pro einzelnem Mitarbeiter (w/m/d)
    Wir haben folgende offizielle Meetings, bei einem 2 Wochen Sprint. Das „+“ symbolisiert Durchschnittswerte, d.h. normalerweise fallen die Meetings meist länger aus, als angegeben. Sind ja „agile“ Meetings:
    - 10x Daily: „15+ min“ x „je Mitarbeiter“
    - 3x Refinement: „8+ min“ x „je Ticket“ x „je Mitarbeiter“
    - 1x Sprint (Output) Review: „60+ min“ x „je Mitarbeiter“ x „je Stake- bzw. Shareholder“ (optional: x „je Manager“)
    - 1x Retrospective: „10+ min“ x „je Topic“ x „je Mitarbeiter“
    - 1x Sprint (Output) Planning: „90+ min“ x „je Mitarbeiter“

    Ist das wirklich „agile“? Sind das wirklich nötige Meetings?

    Die „Retro“ ist definitiv wichtig und von höchster Wichtigkeit, denn nur über solche Meetings entwickeln sich Teams weiter (Stichwort: Continuous Personal Evolvement). Mit einem Spritzer Ehrlichkeit, vollster Transparenz und Vertrauen ist die „Retro“ der wohl beste Output eines jeden Sprints.

    Aber ohne die Teilnahme vom Management, den Head ofs und Leadern auch nicht mehr, als eine Arbeitsbeschaffungsmaßnahme. Erstellte „Action Items“ auf einem Miro-Board führen nicht gleichzeitig zur Veränderung und Optimierung des Management- und Leadership-Mindsets oder zum nötigen Scrum-, Kanban-, Scrumban-, Kanrum-, Rumban-Commitment.

    Das Repräsentieren des (Sprint-)Outputs bzw. des Output-Fakes (meist auf der lokalen Dev-Maschine gezeigt) ist auch ein gewinnbringendes und motivationsteigerndes Meeting. Wäre dieses Meeting ehrlich und in Gänze transparent, vor allem wenn ein Sprint auch mal komplett in die Hose ging, hätte dieses Meeting nochmals einen zusätzlichen positiven Effekt bezüglich des internen als auch extern repräsentierten Images.

    In den anderen Meetings wird pro Mitarbeiter meist zu 90% geschwiegen, sowohl im Video-Call, als auch persönlich.

    ————

    Argument: Heutiges „Agile“ basiert auf „agilen“ Zahlen
    Storypoints, Velocity, Burnup- bzw. Burndown-Charts und weitere KPIs zur Effizienz- und Erfolgsdarstellung eines Sprints bzw. Projektes sind wie auch der erste Startup-Prototyp - Fakes - und daher rational betrachtet für Auswertungen, Audits und Management-Reportings unbrauchbar.

    Außer: Das interne Projekt-Team und Product-Ownership committed sich darauf…:
    - …über Storypoints nicht die Komplexität, sondern die genauen „Mann“tage anzugeben
    - …beim Sprint-Planning pro Ticket passgenaue Storypoints je verfügbare Ressourcen zu setzen
    - …das Sprint-Ende nicht zu faken, in dem Storypoints kurz vor Sprint-Stop manipuliert werden
    - …das Sprint-Ende nicht zu faken, in dem zusätzliche Storys über den Sprint fertiggestellt werden

    Demnach sind Belegungen in Zahlenform mit Bezug auf die Effizienz und das Erfolgreichen eines z.B. Scrum-getriebenen Projektes nicht glaubhaft.

    ————

    Argument: Unterstützende Projekt-Management Tools, die in der Produkt-Entwicklung nichts zu suchen haben (sollten)
    Jira, Asana, Basecamp, Trello, MeisterTask, Monday usw. sind Tools, die heutzutage Verwendung in der Entwicklung von Produkten finden und dem Projekt und Projekt-Team als digitale Unterstützer dienen - dienen sollten.

    Projekt-Management ist aber nicht gleich Produkt-Management. Das sind zwei Paar Schuhe.

    Möchte man nun (mindestens) eines dieser Tools mit Scrum, CI/CD und der rationalen Produkt-Entwicklungs-Realität vereinen, braucht es Monate und/oder immens viel monetären Invest, bis mit einer wirklich erfolgreichen Umsetzung und Entwicklung eines Produktes begonnen werden kann - inklusive Commitment einer jeden Rolle im Entwicklungs-Prozesses, zuzüglich dem Management.

    Aber da Unternehmen egal welcher Größe dafür kaum bis keine Zeit (=Geld) investieren wollen - nicht nur, weil Stake- bzw. Shareholder einem sonst die Nackenhaare rasieren…ist und bleibt man nur auf dem Papier „agile“.

    ————

    Ist das wirklich „agile“? Gibt es überhaupt „agile Unternehmen“?

    Das kann nur jedes Unternehmen, dessen Management, Leadership-Team und Mitarbeiter selbst beantworten.

    Wie auch die KPIs verschiedener roter Fäden für „agile Unternehmen“ werden die Meinungen vor allem auch mit Bezug auf mein Kommentar sehr „agile“ ausfallen.

    Ich für meinen Teil freue mich jetzt schon auf Feedback oder konstruktive Kritik.

    Dann gibt es gemeinsam was zum Challengen :-D

    In diesem Sinne,

    Ihr Patric Betz

  2. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Serenity 24.05.22 - 18:14

    um es kurz zu machen: Dir fehlt das Verständnis zu Scrum, Kanban und besonders zu Agil.

    Du hast dir irgendwas zusammgengespinnt, was agil, kanban und scrum bedeutet. Nur weil du oder deine Firma das nicht richtig oder ansatzweise richtig machen.

    Und deine 15+ Jahren Berufserfahrung scheinen keinen hohen Wert zu haben. Ich spiele seit 30+ Jahren Schach und bin nicht besser als Magnus Carlsen.

  3. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 24.05.22 - 19:33

    Erst einmal Danke für deine Antwort, auch wenn Sie beleidigend und alles andere als konstruktiv ist.

    Du kennst mich nicht und kannst daher nicht wissen, wie hoch der Wert meiner 15+ Jahre Berufserfahrung ausfällt geschweige denn wie stark/schwach mein Verständnis zum Thema "Agile" in besagten Jahren gereift oder eben nicht gereift ist.

    Vielleicht kannst du dir ja ein wenig mehr Zeit nehmen und mir bzw. auch anderen LeserINNEN genauer erläutern, was mir in Sachen "Verständnis zum Thema Agile" fehlt? Wäre eine Win-Win Situation für alle.

    Liebe Grüße und noch einen tollen Abend,

    Patric

  4. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: ayngush 25.05.22 - 08:41

    Vergiss es. Scrum ist in erster Linie eine Religion.

  5. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 09:07

    ayngush schrieb:
    --------------------------------------------------------------------------------
    > Vergiss es. Scrum ist in erster Linie eine Religion.

    Würd ich jetzt nicht 100%ig sagen.

    Aber Scrum wird einem halt mittlerweile in vielen Firmen aufgezwungen, weil es von allen "offiziell sehr erfolgreich" genutzt wird. Auch von der Konkurrenz.

    Und damit das eigene Unternehmen im Vergleich zur Konkurrenz nicht an Reputation und Image verliert, werden Scrum oder andere rote Fäden schnell schnell eingeführt.

  6. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: supersux 25.05.22 - 09:48

    PatricBetz schrieb:
    --------------------------------------------------------------------------------
    > Erst einmal Danke für deine Antwort, auch wenn Sie beleidigend und alles
    > andere als konstruktiv ist.
    >
    > Du kennst mich nicht und kannst daher nicht wissen, wie hoch der Wert
    > meiner 15+ Jahre Berufserfahrung ausfällt geschweige denn wie stark/schwach
    > mein Verständnis zum Thema "Agile" in besagten Jahren gereift oder eben
    > nicht gereift ist.
    >
    > Vielleicht kannst du dir ja ein wenig mehr Zeit nehmen und mir bzw. auch
    > anderen LeserINNEN genauer erläutern, was mir in Sachen "Verständnis zum
    > Thema Agile" fehlt? Wäre eine Win-Win Situation für alle.
    >
    > Liebe Grüße und noch einen tollen Abend,
    >
    > Patric

    Um ehrlich zu sein, kann man den Vorposter durchaus verstehen, das man nicht wirklich Lust hat auf die teilweise fundamentalen Gedankenfehler einzugehen, wenn diese sich in einer (mal mehr oder weniger) polemisch verfassten Wall-of-Text verbergen. Auch wenn es Schade ist, das hierbei durchaus valide Argumente ebenfalls hinten runter fallen.

  7. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: GwhE 25.05.22 - 09:55

    Wie gesagt, anstatt soviel halb wissen zu verbreiten, wäre meine empfehlenung auch erstmal sich richtig mit der Materie zu beschäftigen. Zuhören und verstehen sind in egal welchem Umfeld immer wichtig.

    Aber um die Kritik zusammen zu fassen. Ja das Management und Projektleiter haben einen Kontrollverlust im Agilen Umfeld. Ist das schlimm Nein, werden dadurch Management und Projektleiter überflüssig Nein (keine Angst niemand will dir deinen Job wegnehmen).

    Allein das eine Daily länger als 15 min geht zeigt das ihr Scrum nicht verstanden habt, bzw wahrscheinlich dem armen Schwein nicht vertraut.

  8. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 10:43

    GwhE schrieb:
    --------------------------------------------------------------------------------
    > Wie gesagt, anstatt soviel halb wissen zu verbreiten, wäre meine
    > empfehlenung auch erstmal sich richtig mit der Materie zu beschäftigen.
    > Zuhören und verstehen sind in egal welchem Umfeld immer wichtig.
    >
    > Aber um die Kritik zusammen zu fassen. Ja das Management und Projektleiter
    > haben einen Kontrollverlust im Agilen Umfeld. Ist das schlimm Nein, werden
    > dadurch Management und Projektleiter überflüssig Nein (keine Angst niemand
    > will dir deinen Job wegnehmen).
    >
    > Allein das eine Daily länger als 15 min geht zeigt das ihr Scrum nicht
    > verstanden habt, bzw wahrscheinlich dem armen Schwein nicht vertraut.

    Guten Morgen GwhE,

    auf welcher Basis machst du "Halbwissen" fest und wie kommst du darauf, dass ich mich nicht mit der Materie auskenne? Kannst du das näher erläutern?

    Wäre auch interessant zu erfahren, wie du darauf kommst, dass das Management bzw. Projektleiter überflüssig sei. Das ist keine Behauptung meinerseits.

    Dass es dem allgemeinen Management inklusive Projektleitung und Product Ownership an Grundverständnis in alle Richtungen fehlt (Design-, Development- und QA-Prozess, Stichwort: Requirements Engineering) - das ist meine Behauptung bzw. eines meiner Argumente.

    Dieses Grundverständnis ist immens wichtig, nicht nur fürs Schreiben von User Storys (Tickets, Issues, Tasks, Todos), sprintspezifischen effizienten Output oder der generellen Produkt-Qualität.

    Siehe: „Wie ein Feature entwickelt wird und wann wer was zum erfolgreichen Abschließen der individuellen Arbeit benötigt?“

    Und zum Thema "Daily Dauer 15+min":
    Mir ist zu 100% bewusst, welche Ziele vom Daily verfolgt werden. Effizienter Teamaustausch, so dass jedes individuelle Team-Mitglied auf dem aktuellen Stand der Dinge ist - Scrum Master und PO natürlich auch, wobei der Fokus klar auf dem Team liegt.

    Werden Blocker kommuniziert, dient der Scrum Master unter anderem als Kommunikator, wobei gemeinsam als Team eine Lösung gefunden wird.

    Super Kommunikations- und Interaktions-Medium: Aber wieso so steif und eben gerade nicht agil auf die Time-Box von 15 Minuten verharren? Um dann aktiv anschließende Einzelgespräche nach dem Daily starten zu lassen.

    Das ist total unflexibel und nimmt dem ganzen Medium die Menschlichkeit.

    Vielleicht will sich ein Mitarbeiter etwas länger mitteilen und nicht unter Druck täglich 3 Fragen beantworten.

    Stimmt: "Weil die Zeit für etwas längeren intensiven, spaßigen und vor allem menschlichen Austausch fehlt. Für diese Art der Kommunikation und Interaktion gibt es ja die Sprint Retro, die komischerweise auch einer Time-Box folgt".

    Und ja: Arbeit sollte Spaß machen und Menschen, selbst EntwicklerINNEN, wollen sich mitteilen und gehört werden - UND vor allem das Gefühl vermittelt bekommen, dass sie tatsächlich gehört werden.

    Nur irgendwelche Action Items auf Miro-Postits schreiben, das nach wenigen Tagen wieder in Vergessenheit gerät, ist da wenig unterstützend.

    p.s.: Bevor wieder dieselben Behauptungen in den Raum gestellt werden. Nein, ich bin bei meinem aktuellen Arbeitgeber sehr glücklich, der selbst das Thema Agile täglich hinterfragt und optimiert. Nein, mir fehlt keinerlei Wissen zum Thema Scrum, Kanban bzw. iTil - liegt unter anderem auch daran, dass ich gerade selbst ein Hipster-Startup im Projekt- und Produkt-Managementbereich gründe.

  9. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 10:52

    supersux schrieb:
    --------------------------------------------------------------------------------
    > PatricBetz schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Erst einmal Danke für deine Antwort, auch wenn Sie beleidigend und alles
    > > andere als konstruktiv ist.
    > >
    > > Du kennst mich nicht und kannst daher nicht wissen, wie hoch der Wert
    > > meiner 15+ Jahre Berufserfahrung ausfällt geschweige denn wie
    > stark/schwach
    > > mein Verständnis zum Thema "Agile" in besagten Jahren gereift oder eben
    > > nicht gereift ist.
    > >
    > > Vielleicht kannst du dir ja ein wenig mehr Zeit nehmen und mir bzw. auch
    > > anderen LeserINNEN genauer erläutern, was mir in Sachen "Verständnis zum
    > > Thema Agile" fehlt? Wäre eine Win-Win Situation für alle.
    > >
    > > Liebe Grüße und noch einen tollen Abend,
    > >
    > > Patric
    >
    > Um ehrlich zu sein, kann man den Vorposter durchaus verstehen, das man
    > nicht wirklich Lust hat auf die teilweise fundamentalen Gedankenfehler
    > einzugehen, wenn diese sich in einer (mal mehr oder weniger) polemisch
    > verfassten Wall-of-Text verbergen. Auch wenn es Schade ist, das hierbei
    > durchaus valide Argumente ebenfalls hinten runter fallen.

    Guten Morgen supersux,

    welche Gedankenfehler meinst du genau? Würde mich brennend interessieren, wo ich ins fundamentale Fettnäpfchen getreten hab.

    Dass mein Text polemisch (scharf, unsachlich) bzw. übertrieben verfasst ist, liegt schlichtweg an meiner Persönlichkeit. So war ich schon immer. Nur der etwas schlechtere Wortwitz ist hinzugekommen :-)

    Aber ich habe (hoffentlich) niemanden persönlich angegriffen - was ja einer der fundamentalen Grundsätze der Polemik ist. Oder hast du dich persönlich angegriffen gefühlt?

    Wenn ja, tut mir das ehrlich gesagt leid, weil das ist nicht mein Ziel. Alleine aus dem Aspekt heraus, dass ich dich persönlich nicht kenne.

  10. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Trollversteher 25.05.22 - 10:59

    Nun ja, auch wenn eine Vielzahl an Entwicklern diesen Eindruck bestätigen - es geht auch anders und dann funktioniert es richtig gut, und deutlich besser als jede traditionelle "Wasserfall" Entwicklungs-Methode - wenn eben alle, inklusive Management mitspielen - das erlebe ich gerade in meinem Projekt (holländischer Kunde, möglicherweise spielt dabei die liberale niederländische Mentalität eine Rolle) - ist allerdings nach vielen Jahren in diversen agilen Projekten auch bei mir das erste Mal, dass alles wirklich gut umgesetzt wird und in der Praxis richtig funktioniert.

  11. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Trollversteher 25.05.22 - 11:00

    "Scrum-Hating" aber ganz offensichtlich auch...

  12. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Serenity 25.05.22 - 11:13

    PatricBetz schrieb:
    --------------------------------------------------------------------------------
    > Erst einmal Danke für deine Antwort, auch wenn Sie beleidigend und alles
    > andere als konstruktiv ist.
    >
    > Du kennst mich nicht und kannst daher nicht wissen, wie hoch der Wert
    > meiner 15+ Jahre Berufserfahrung ausfällt geschweige denn wie stark/schwach
    > mein Verständnis zum Thema "Agile" in besagten Jahren gereift oder eben
    > nicht gereift ist.

    Doch, genau das kann ich anhand deines langen Textes oben drin machen. Du hast ja viel behauptet. Die Zusammenfassung habe ich dementsprechend in den ersten Post niedergeschrieben.

    > Vielleicht kannst du dir ja ein wenig mehr Zeit nehmen und mir bzw. auch
    > anderen LeserINNEN genauer erläutern, was mir in Sachen "Verständnis zum
    > Thema Agile" fehlt? Wäre eine Win-Win Situation für alle.

    Ich habe nichts davon, dir alles zu erklären. Es ist damit keine Win-Win-Situation, weil mir das zu viel Zeit kostet. Aber ich nehme mal was aus deinem letzten Post als Beispiel.

    > Dass es dem allgemeinen Management inklusive Projektleitung und Product Ownership an
    > Grundverständnis in alle Richtungen fehlt (Design-, Development- und QA-Prozess, Stichwort:
    > Requirements Engineering) - das ist meine Behauptung bzw. eines meiner Argumente.
    >
    > Dieses Grundverständnis ist immens wichtig, nicht nur fürs Schreiben von User Storys (Tickets,
    > Issues, Tasks, Todos), sprintspezifischen effizienten Output oder der generellen Produkt-
    > Qualität.

    Es ist nirgendwo in Scrum beschrieben, dass du User Stories schreiben musst. Es ist nichtmal beschrieben, wie du Anforderungen spezifizieren musst. User Stories haben eine mittlere "Auflösung" an Informationsgrad für Anforderungen. Anforderungen werden häufig als User-Stories definiert, ist aber kein Muss.
    Ich bin übrigens PO gewesen und habe auch eine IREB Zerrtifizierung. Aber ein Muss ist das nicht. Es es Teil der empirischen Entwicklung. Gerade von dir mit wenig/falscher Erfahrung solltest du das nicht verurteilen.

    >Mir ist zu 100% bewusst, welche Ziele vom Daily verfolgt werden. Effizienter Teamaustausch, so
    > dass jedes individuelle Team-Mitglied auf dem aktuellen Stand der Dinge ist - Scrum Master
    > und PO natürlich auch, wobei der Fokus klar auf dem Team liegt.

    Falsch. Der PO und der Scrum Master müssen nicht am Daily teilnehmen. Das steht auch im Scrum Guide. Es handelt sich um ein täglichen Austausch zwischen den Developers. Der Scrum Master hilft/unterstützt nur bei der Durchführung. Für den PO oder Scrum-Master ist das kein Austausch.

  13. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Serenity 25.05.22 - 11:20

    Letztendlich ist es mir auch egal. Es gibt gute Gründe, warum agile Entwicklung, Scrum und Kanban einen weite Verbreitung auf den Markt haben. Dazu musst man sich einlassen oder nicht.

    Ein Boomer, der damit ein Problem hat, stört micht nicht. Ich bin ein experte im klassischen und agilen Projektmanagement. Ich finde beides gut, hat seine Vor- und Nachteile. Aber um das einzusehen, musst man beides verstehen.

  14. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: GwhE 25.05.22 - 12:00

    Es gab hier schon sehr gute Artikel die eine Einführung in das Themen Gebiet geben wirklich empfehlenswert. Dort werden viele deiner sogenannten Argumente wiederlegt. Die anderen Argumente beziehen sich ja eher auf die Qualität, und gerade da sage ich je mehr Verantwortung in die Teams kommt desto besser wird die Qualität. Und nein nur weil ein Manager über jeden Schrift bescheid weiß ( bzw meint es selbst besser zu können) und meint den Prozess aktiv lenken zu können schraubt die Qualität nicht automatisch hoch ( Es mag dazu auch Ausnahmen zu geben).

    Und dann nochmal, um das selbe Verständnis zu bekommen. Der Kern von Scrum ist der Sprint, dort macht das Team das versprechen gegenüber PO ( der stellvertretender für alle Stackeholder steht). Der Sprint ist heilig, und dann während einen Sprint sich mitteilen müssen ist absolut unötig. Entweder man schaft die Anforderungen, dann wird es im Review vorgestellt oder man schaft es nicht, dann kann man in der Retro rausfinden warum nicht. Daily kann man auch länger 3 fragen machen, aber länger als 15 min ist unötig weil sich dann die meisten Leute langweiligen. Wenn ich mich ausheulen möchte gibt es den Scrum Master. Wenn ich fachlich weiter kommen will mache ich einen Termin einem Kollegen aus um im Pair programming oder in einer Brainstorm session weiter zu kommen. Aber wichtig ist ich als Entwickler kann sehr gut abschätzen was in 2 Wochen leisten kann und kann mich voll auf die Aufgaben konzentriert.

  15. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 12:07

    Serenity schrieb:
    --------------------------------------------------------------------------------
    > PatricBetz schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Erst einmal Danke für deine Antwort, auch wenn Sie beleidigend und alles
    > > andere als konstruktiv ist.
    > >
    > > Du kennst mich nicht und kannst daher nicht wissen, wie hoch der Wert
    > > meiner 15+ Jahre Berufserfahrung ausfällt geschweige denn wie
    > stark/schwach
    > > mein Verständnis zum Thema "Agile" in besagten Jahren gereift oder eben
    > > nicht gereift ist.
    >
    > Doch, genau das kann ich anhand deines langen Textes oben drin machen. Du
    > hast ja viel behauptet. Die Zusammenfassung habe ich dementsprechend in den
    > ersten Post niedergeschrieben.
    >
    > > Vielleicht kannst du dir ja ein wenig mehr Zeit nehmen und mir bzw. auch
    > > anderen LeserINNEN genauer erläutern, was mir in Sachen "Verständnis zum
    > > Thema Agile" fehlt? Wäre eine Win-Win Situation für alle.
    >
    > Ich habe nichts davon, dir alles zu erklären. Es ist damit keine
    > Win-Win-Situation, weil mir das zu viel Zeit kostet. Aber ich nehme mal was
    > aus deinem letzten Post als Beispiel.
    >
    > > Dass es dem allgemeinen Management inklusive Projektleitung und Product
    > Ownership an
    > > Grundverständnis in alle Richtungen fehlt (Design-, Development- und
    > QA-Prozess, Stichwort:
    > > Requirements Engineering) - das ist meine Behauptung bzw. eines meiner
    > Argumente.
    > >
    > > Dieses Grundverständnis ist immens wichtig, nicht nur fürs Schreiben von
    > User Storys (Tickets,
    > > Issues, Tasks, Todos), sprintspezifischen effizienten Output oder der
    > generellen Produkt-
    > > Qualität.
    >
    > Es ist nirgendwo in Scrum beschrieben, dass du User Stories schreiben
    > musst. Es ist nichtmal beschrieben, wie du Anforderungen spezifizieren
    > musst. User Stories haben eine mittlere "Auflösung" an Informationsgrad für
    > Anforderungen. Anforderungen werden häufig als User-Stories definiert, ist
    > aber kein Muss.
    > Ich bin übrigens PO gewesen und habe auch eine IREB Zerrtifizierung. Aber
    > ein Muss ist das nicht. Es es Teil der empirischen Entwicklung. Gerade von
    > dir mit wenig/falscher Erfahrung solltest du das nicht verurteilen.
    >
    > >Mir ist zu 100% bewusst, welche Ziele vom Daily verfolgt werden.
    > Effizienter Teamaustausch, so
    > > dass jedes individuelle Team-Mitglied auf dem aktuellen Stand der Dinge
    > ist - Scrum Master
    > > und PO natürlich auch, wobei der Fokus klar auf dem Team liegt.
    >
    > Falsch. Der PO und der Scrum Master müssen nicht am Daily teilnehmen. Das
    > steht auch im Scrum Guide. Es handelt sich um ein täglichen Austausch
    > zwischen den Developers. Der Scrum Master hilft/unterstützt nur bei der
    > Durchführung. Für den PO oder Scrum-Master ist das kein Austausch.

    Schade, dass du die Auflösung deiner nicht gerade konstruktiven Gedanken aus deinem ersten Post als Zeitverschwendung siehst. Ich wollte einfach verstehen, warum du mich teilweise direkt angreifst und meine Erfahrung in Frage stellst, nur weil ich aus deiner Sicht offensichtlich ein "Boomer" bin, was definitiv nicht der Fall ist.

    Ich arbeite seit Jahren im Scrum-Umfeld, ich verstehe den roten Faden hinter Scrum - stelle aber das agile Konstrukt von heute (ein wenig polemisch) in Frage, mit Argumenten, die ich bisher über meine gemachten Erfahrungen erleben durfte/musste.

    Dieser und schon ein vorherig erschienener Artikel auf golem.de haben mich ermutigt, mal meine Realität als Entwickler niederzuschreiben und zu veröffentlichen - weil "Agile" bzw. "Scrum" überspitzt gesagt als Allheilmittel für den Projekt-Erfolg präsentiert werden, was aus meinen gemachten Erfahrungen einfach nicht die Realität widerspiegelt.

    Natürlich profitieren viele Agenturen, Consulting-Firmen, Schulungszentren und bestimmte Personengruppen vom agilen Arbeiten. Und natürlich gibt es auch das eine oder andere Unternehmen, das offizielle Erfolge durch agiles Arbeiten erzielt.

    Aber ist dem wirklich so? Oder werden die vermeintlichen Erfolge eben nur positiv nach außen getragen, kommuniziert und zwecks Reputation positiv verkauft?

    Gute Frage - nächste Frage.

    Was mich mal brennend interessieren würde - da du schon jahrelange Erfahrung als Product Owner sammeln konntest.

    - Wie hast du denn deinen täglichen Arbeitsalltag als PO strukturiert?
    - Auf welcher Basis (Fachbereich, Business vs. Technik) hast du denn Storys strukturiert und verfasst?
    - Wie liefen denn die Story Refinements grundsätzlich ab? Kam es oft zu Story-Anpassungen bzw. Story-Aufteilungen zwecks Komplexität?

  16. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 12:22

    GwhE schrieb:
    --------------------------------------------------------------------------------
    > Es gab hier schon sehr gute Artikel die eine Einführung in das Themen
    > Gebiet geben wirklich empfehlenswert. Dort werden viele deiner sogenannten
    > Argumente wiederlegt. Die anderen Argumente beziehen sich ja eher auf die
    > Qualität, und gerade da sage ich je mehr Verantwortung in die Teams kommt
    > desto besser wird die Qualität. Und nein nur weil ein Manager über jeden
    > Schrift bescheid weiß ( bzw meint es selbst besser zu können) und meint den
    > Prozess aktiv lenken zu können schraubt die Qualität nicht automatisch hoch
    > ( Es mag dazu auch Ausnahmen zu geben).
    >
    > Und dann nochmal, um das selbe Verständnis zu bekommen. Der Kern von Scrum
    > ist der Sprint, dort macht das Team das versprechen gegenüber PO ( der
    > stellvertretender für alle Stackeholder steht). Der Sprint ist heilig, und
    > dann während einen Sprint sich mitteilen müssen ist absolut unötig.
    > Entweder man schaft die Anforderungen, dann wird es im Review vorgestellt
    > oder man schaft es nicht, dann kann man in der Retro rausfinden warum
    > nicht. Daily kann man auch länger 3 fragen machen, aber länger als 15 min
    > ist unötig weil sich dann die meisten Leute langweiligen. Wenn ich mich
    > ausheulen möchte gibt es den Scrum Master. Wenn ich fachlich weiter kommen
    > will mache ich einen Termin einem Kollegen aus um im Pair programming oder
    > in einer Brainstorm session weiter zu kommen. Aber wichtig ist ich als
    > Entwickler kann sehr gut abschätzen was in 2 Wochen leisten kann und kann
    > mich voll auf die Aufgaben konzentriert.

    Danke für diese tolle Antwort, GwhE. Schön rational und konstruktiv. Top!

    "...Manager...Prozess aktiv lenken zu können"
    => Ganz deiner Meinung! Das führt nämlich meistens zu den Punkten die ich unter "Ansonsten kommt es zu:" genannt hab.

    "Sprint ist heilig"
    => Absolut! Dennoch kommt es in agilen Unternehmen leider immer noch viel zu häufig zu Störungen von außen (Stakeholder, Management, Leaders, POs). Aber mit dem richtigen internen Standing und einem breiten Commitment zum agilen Arbeiten von allen, passiert das nicht.

    "...mitteilen wollen...ausheulen...Mitteilungs-Termine machen..."
    => Unter anderem soll Scrum auch die Kommunikation und Interaktion zwischen Rollen und Teams agiler und effizienter gestalten, oder habe ich das falsch verstanden?
    Damit vor allem keine Kommunikations-Inseln entstehen, das Teamgefühl und somit die Team-Motivation stetig steigt und jede Rolle weiß, wie der aktuelle Stand vom Sprint ist und wie der kommenden (Sprint-)Output ausfällt - auch zwecks Review. Oder?

  17. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 12:26

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > Nun ja, auch wenn eine Vielzahl an Entwicklern diesen Eindruck bestätigen -
    > es geht auch anders und dann funktioniert es richtig gut, und deutlich
    > besser als jede traditionelle "Wasserfall" Entwicklungs-Methode - wenn eben
    > alle, inklusive Management mitspielen - das erlebe ich gerade in meinem
    > Projekt (holländischer Kunde, möglicherweise spielt dabei die liberale
    > niederländische Mentalität eine Rolle) - ist allerdings nach vielen Jahren
    > in diversen agilen Projekten auch bei mir das erste Mal, dass alles
    > wirklich gut umgesetzt wird und in der Praxis richtig funktioniert.

    Hallo Trollversteher (by the way - geiler Nickname :-D ),

    erst einmal freu ich mich riesig für dich/euch, dass Agile gut bei euch funktioniert.

    Was mich wirklich interessieren würde ist - wie ist denn das Unternehmen bzw. das Projekt grundsätzlich aufgestellt?

    Wie läuft bei euch Scrum ab? Interner Prozess? Verwendete Tools? Verwendete Rollen?

    Interessiert bestimmt auch andere LeserINNEN. Musst ja keine Namen nennen ;-)

    Losgelöst davon, danke dir für den tollen Kommentar!

  18. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: supersux 25.05.22 - 12:50

    PatricBetz schrieb:
    --------------------------------------------------------------------------------
    > supersux schrieb:
    > ---------------------------------------------------------------------------
    > Dass mein Text polemisch (scharf, unsachlich) bzw. übertrieben verfasst
    > ist, liegt schlichtweg an meiner Persönlichkeit. So war ich schon immer.
    > Nur der etwas schlechtere Wortwitz ist hinzugekommen :-)
    > Aber ich habe (hoffentlich) niemanden persönlich angegriffen - was ja einer
    > der fundamentalen Grundsätze der Polemik ist. Oder hast du dich persönlich
    > angegriffen gefühlt?
    > Wenn ja, tut mir das ehrlich gesagt leid, weil das ist nicht mein Ziel.
    > Alleine aus dem Aspekt heraus, dass ich dich persönlich nicht kenne.

    Nein. Polemik muss auch nicht zwangsläufig eine Person angreifen, sie kann durchaus auch -wie hier- auf eine Sache gemünzt sein.

    > welche Gedankenfehler meinst du genau? Würde mich brennend interessieren,
    > wo ich ins fundamentale Fettnäpfchen getreten hab.

    Ehrlicherweise wüsste ich nicht, wo ich im Detail anfangen sollte. Auf jedes Argument einzeln einzugehen und zu hinterfragen, warum deiner Meinung nach z.B. CI/CD nur die Shareholder/Stakeholder befriedigen soll und nichts zur Produktqualität beiträgt oder warum StoryPoints/Velocity überhaupt jmd. außerhalb des Teams etwas angehen sollten und man lieber wieder in Personentage schätzen sollte, finde ich in dem Kontext eher nicht zielführend.


    Deshalb versuche ich es mal etwas allgemeiner zu formulieren. Als größten Fehler empfinde ich ehrlich gesagt deinen "All-or-Nothing Ansatz" und die gleichzeitige Verwechslung/Vermischung bzw. Gleichsetzung von einzelnen agilen Praktiken mit firmenweiter/ echter Business Agilität. Letztere ist aber nun mal leider niemals per BigBang erreichbar und der Weg dahin ist lang, steinig und ehrlich gesagt in den meisten Fällen auch niemals vollkommen erreichbar. Aber hier gilt auch wie so oft: der Weg ist das Ziel und irgendwo muss man den ersten Schritt tun. Was spricht also dagegen, erst im kleinen anzufangen und dann nach und nach auszuweiten? und hey, wenn man nun noch immer wieder schaut was im eigenen Unternehmen funktioniert & was nicht und vor dem nächsten Schritt entsprechend nachjustiert...wow, voll verrückt, oder? ;-)

  19. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: Trollversteher 25.05.22 - 12:52

    >Hallo Trollversteher (by the way - geiler Nickname :-D ),

    Haha, ja, der ist schon uralt, aber irgendwie finde ich ihn immer noch passend :D

    >erst einmal freu ich mich riesig für dich/euch, dass Agile gut bei euch funktioniert.
    >Was mich wirklich interessieren würde ist - wie ist denn das Unternehmen bzw. das Projekt grundsätzlich aufgestellt?

    Wie genau meinst Du das konkret?

    >Wie läuft bei euch Scrum ab? Interner Prozess? Verwendete Tools? Verwendete Rollen?


    Also zunächst mal ist es kein 100% Scrum "by the book" sondern ein an Scrum angelehnter, angepasster Prozess. Als einzige "feste" Rollen - bei dem Projekt handelt es sich um die Entwicklung von Firmware/Steuerungssoftware für Windkeaftanlagen, wobei zum einen der Altbestand "gepflegt", also Fixes und Updates für Bestandskunden erstellt sowie Featurewünsche realisiert werden müssen, als auch Prototypen-Entwicklung für neue zukünftige Modelle - wobei diese beiden Felder grob auf zwei unterschiedliche Teams aufgeteilt sind - diejenigen die überwiegend für den Bestand zuständig sind, arbeiten nach einer an Kanban angelehnten Methode, unser Team, das vorwiegend für die Prototypenentwicklung sowie Weiterentwicklung bestehender Produkte verantortlich ist, arbeitet dabei nach einer an Scrum angelehnten Methode. Einzige "feste" Rollen sind dabei der Scrum-Master sowie diverse Project-Owner die sich zum einen aus einem Mitglied des mittleren Managements und zum anderen aus den Systemingenieuren, welche für die technische Entwicklung zuständig sind und häufig die Requirements für die Software vorgeben. Ein wirklich ausschlaggebender Punkt für das gute Funktionieren ist dabei imho, neben dem commitment im Team, dass auch das Management den Prozess ernst nimmt, und sich *tatsächlich * darauf beschränkt, zwar Prioritäten für die definierten Arbeitspakete vorzugeben, aber ansonsten dem Team beim Organisieren und Umsetzen der Arbeit den nötigen Freiraum lässt, ohne ständig "dazwischen zu grätschen".

    Als Haupt-Tools setzen wir Jira, Confluence und Gitlab ein. Für die Verwaltung und Erstellung der Releases der genutzten Module war früher noch Jenkins im Einsatz, das wurde aber nach und nach durch eine Gitlab-Pipeline ersetzt. Für die Kommunikation wird das Übliche (Teams, Outlook) verwendet.

    >Interessiert bestimmt auch andere LeserINNEN. Musst ja keine Namen nennen ;-)
    >Losgelöst davon, danke dir für den tollen Kommentar!

    Danke für die tolle und sachliche Antwort! Ist heutzutage bei weitem nicht selbstverständlich, dass man (eigentlich) gegensätzliche Position so sachlich und mit Interesse statt instinktiver Abwehrhaltung diskutiert!



    1 mal bearbeitet, zuletzt am 25.05.22 12:56 durch Trollversteher.

  20. Re: Scrum, Kanban, Scrumban, Kanrum usw. sind nicht "Agile", sondern "Fragile"

    Autor: PatricBetz 25.05.22 - 13:23

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Hallo Trollversteher (by the way - geiler Nickname :-D ),
    >
    > Haha, ja, der ist schon uralt, aber irgendwie finde ich ihn immer noch
    > passend :D
    >
    > >erst einmal freu ich mich riesig für dich/euch, dass Agile gut bei euch
    > funktioniert.
    > >Was mich wirklich interessieren würde ist - wie ist denn das Unternehmen
    > bzw. das Projekt grundsätzlich aufgestellt?
    >
    > Wie genau meinst Du das konkret?
    >
    > >Wie läuft bei euch Scrum ab? Interner Prozess? Verwendete Tools?
    > Verwendete Rollen?
    >
    > Also zunächst mal ist es kein 100% Scrum "by the book" sondern ein an Scrum
    > angelehnter, angepasster Prozess. Als einzige "feste" Rollen - bei dem
    > Projekt handelt es sich um die Entwicklung von Firmware/Steuerungssoftware
    > für Windkeaftanlagen, wobei zum einen der Altbestand "gepflegt", also Fixes
    > und Updates für Bestandskunden erstellt sowie Featurewünsche realisiert
    > werden müssen, als auch Prototypen-Entwicklung für neue zukünftige Modelle
    > - wobei diese beiden Felder grob auf zwei unterschiedliche Teams aufgeteilt
    > sind - diejenigen die überwiegend für den Bestand zuständig sind, arbeiten
    > nach einer an Kanban angelehnten Methode, unser Team, das vorwiegend für
    > die Prototypenentwicklung sowie Weiterentwicklung bestehender Produkte
    > verantortlich ist, arbeitet dabei nach einer an Scrum angelehnten Methode.
    > Einzige "feste" Rollen sind dabei der Scrum-Master sowie diverse
    > Project-Owner die sich zum einen aus einem Mitglied des mittleren
    > Managements und zum anderen aus den Systemingenieuren, welche für die
    > technische Entwicklung zuständig sind und häufig die Requirements für die
    > Software vorgeben. Ein wirklich ausschlaggebender Punkt für das gute
    > Funktionieren ist dabei imho, neben dem commitment im Team, dass auch das
    > Management den Prozess ernst nimmt, und sich *tatsächlich * darauf
    > beschränkt, zwar Prioritäten für die definierten Arbeitspakete vorzugeben,
    > aber ansonsten dem Team beim Organisieren und Umsetzen der Arbeit den
    > nötigen Freiraum lässt, ohne ständig "dazwischen zu grätschen".
    >
    > Als Haupt-Tools setzen wir Jira, Confluence und Gitlab ein. Für die
    > Verwaltung und Erstellung der Releases der genutzten Module war früher noch
    > Jenkins im Einsatz, das wurde aber nach und nach durch eine Gitlab-Pipeline
    > ersetzt. Für die Kommunikation wird das Übliche (Teams, Outlook)
    > verwendet.
    >
    > >Interessiert bestimmt auch andere LeserINNEN. Musst ja keine Namen nennen
    > ;-)
    > >Losgelöst davon, danke dir für den tollen Kommentar!
    >
    > Danke für die tolle und sachliche Antwort! Ist heutzutage bei weitem nicht
    > selbstverständlich, dass man (eigentlich) gegensätzliche Position so
    > sachlich und mit Interesse statt instinktiver Abwehrhaltung diskutiert!

    Wow, danke dir für den schnellen und gehaltvollen Input. Vor allem zur Frage "Wie läuft bei euch Scrum ab?". Top! Definitiv auch interessant für alle anderen!

    Losgelöst davon bin ich ein großer Fan von konstruktiver Kritik oder allgemeinem Feedback. Feedback aber auch Kritik bringen meine Denke und mich weiter. Ist nicht immer angenehm - gerade bei kritischen Diskussionen. Aber immer vielversprechend und gewinnbringend, meiner Meinung nach. Vor allem, wenn man gegensätzlicher Meinung ist, und dann gemeinsam doch Synergien feststellt :-D

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Teamleiter Chassis Controls (m/w / divers)
    Continental AG, Frankfurt
  2. IT-Produktverantwortliche/IT- -Produktverantwortlicher (m/w/d) Referat Projekt- und Portfoliomanagement
    GKV-Spitzenverband, Berlin
  3. Software Engineer (m/w/d) ServiceNow
    Interhyp Gruppe, München
  4. VIP Support (w/m/d)
    Bechtle Onsite Services GmbH, Hamburg

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (stündlich aktualisiert)
  2. (stündlich aktualisiert)
  3. 3,49€
  4. 71,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Halbleiterfertigung bei TSMC: Wie Moore's Law künftig weiterleben soll
Halbleiterfertigung bei TSMC
Wie Moore's Law künftig weiterleben soll

Bei TSMCs 3-nm-Fertigungsprozess N3 gibt es neue Ideen. Für die Steigerung der Rechenleistung wird auch das Packaging immer bedeutender.
Ein Bericht von Johannes Hiltscher

  1. Halbleiterfertigung & TSMC Übertriebene Transistor-Skalierung
  2. Halbleiterfertigung TSMCs N2-Prozess nutzt Nanosheets
  3. Halbleiterfertigung TSMC plant 2-nm-Fertigung ab 2025

Macbook Pro M2 (2022) im Test: Neues Macbook, neues Glück?
Macbook Pro M2 (2022) im Test
Neues Macbook, neues Glück?

Das Macbook Pro bekommt als erstes den M2-Chip. Im Test stellt sich Apples SoC als tolle Evolution heraus, die im alten Chassis gefangen ist.
Ein Test von Oliver Nickel

  1. Apple & Chipkrise Halbe SSD im Macbook Pro ist viel langsamer
  2. Notebook Eine zweite Chance für ein 2007er Macbook Pro
  3. Mac Attack Apple plant 15-Zoll-Macbook-Air und neues 12-Zoll-Modell

Technics EAH-A800 im Praxistest: Tolle faltbare Alternative zu Sonys Oberklasse-Kopfhörer
Technics EAH-A800 im Praxistest
Tolle faltbare Alternative zu Sonys Oberklasse-Kopfhörer

Technics' neuer ANC-Kopfhörer EAH-A800 ist eine der besten Alternativen zu Sonys Oberklasse-Kopfhörer WH-1000XM5. Im Bereich Akkulaufzeit liefert er sogar Spitzenleistung.
Ein Test von Ingo Pakalski