zx

Tag: Scrum First Principles

  • 14 Produkt-Backlog Prinzipien, die Ihrem Scrum-Team zum Erfolg verhelfen

    In Kürze: 14 Produkt-Backlog Prinzipien

    Entgegen der landläufigen Meinung hat der Product Owner keine diktatorischen Befugnisse, was die Zusammensetzung und Reihenfolge des Produkt-Backlogs angeht. Stattdessen basiert Scrum auf einem ausgeklügelten System von Checks & Balances, Zusammenarbeit und gemeinsamer Entscheidungsfindung, um das Risiko zu mindern, dass sich der Product Owner in seine Lösung verliebt und nicht in das Problem des Kunden. Erfahren Sie mehr über die wichtigsten Produkt-Backlog Prinzipien: Von der Größe und dem Wachstum des Produkt-Backlogs bis hin zur Frage, ob ein Produkt-Backlog überhaupt notwendig ist. (Einige Lean-Experten bestreiten, dass dessen Existenz gerechtfertigt ist.)

    Produkt-Backlog Prinzipien — Berlin-Product-People.com

    (more…)

  • Retrospektiven-Prinzipien

    TL; DR: 15 Retrospektiven-Prinzipien

    Was halten Sie von der Retrospektive: Eine Routineübung am Ende eines Sprints, unterstützt durch Standardarbeitsanweisungen? Oder ein wichtiger Teil der Bemühungen eines Scrum-Teams um kontinuierliche Verbesserung? Wie Sie vielleicht vermuten, plädiere ich für Letzteres. Meiner Erfahrung nach schöpfen Scrum-Teams das Potenzial von Retrospektiven erst dann voll aus, wenn sie eine Reihe von Retrospektiven-Prinzipien verinnerlichen, in denen das Warum, das Was und das Wie im Wesentlichen beschrieben sind.

    Retrospektiven-Prinzipien — Berlin Product People GmbH

    Für die Geschichtsnerds unter uns: “Molon labe (Ancient Greek: μολὼν λαβέ, romanized: molṑn labé), meaning ‘come and take [them][…]’”

    (more…)

  • Produkt-Backlog Refinement — ein kritischer Erfolgsfaktor für Scrum Teams

    In Kürze: Produkt-Backlog Refinement

    Die Verfeinerung des Produkt-Backlogs ist ein kontinuierlicher Prozess zur Entwicklung von praktikablen und wertschöpfenden Produkt-Backlogs, die es einem Scrum Team ermöglichen, eine Sprintplanung im Prinzip jederzeit durchzuführen. Bei dem Produkt-Backlog Refinement geht es darum, dass sich alle Teammitglieder über das Warum, das Was, das Wie und wahrscheinlich sogar das Wer in Bezug auf die anstehende Arbeit für das aktuelle Produktziel des Scrum-Teams abstimmen. Folglich ist die Verfeinerung des Produkt-Backlogs ein entscheidender Erfolgsfaktor, da dies die Fähigkeit des Teams, regelmäßig wertvolle Inkremente zu liefern, drastisch erhöht.

    Die folgenden 14 Grundprinzipien beschreiben in groben Zügen die Grundlage für einen erfolgreichen Ansatz zum Refinement des Produkt-Backlogs.

    Product Backlog Refinement — ein kritischer Erfolgsfaktor für Scrum Teams — Berlin Product People GmbH

    (more…)

  • Definition of Done: 10 einfache Prinzipien eines kritischen Scrum-Erfolgsfaktors

    In Kürze: Prinzipien der Definition of Done

    Angesichts der Bedeutung einer praktikablen Definition of Done für den Erfolg eines Scrum-Teams hat es mich immer wieder verwundert, wie nachlässig oder unwissend viele Scrum-Teams in Bezug auf ihre Definition of Done sind. Lassen Sie mich daher erste Prinzipien dieses kritischen Scrum-Erfolgsfaktors mit Ihnen diskutieren, die Ihnen helfen werden, die Effektivität, den Teamgeist und die Reputation Ihres Scrum Teams zu verbessern.

    Definition of Done: 10 einfache Prinzipien eines kritischen Scrum-Erfolgsfaktors — Berlin Product People GmbH

    (more…)

  • Agiles Mikromanagement — im Ernst? Making Your Scrum Work #27

    TL; DR: Agiles Mikromanagement

    Bei Scrum gibt es jede Menge Möglichkeiten des Scheiterns. Angesichts der Tatsache, dass Scrum ein Framework mit einem angemessenen, aber kurzen “Handbuch” ist, sollte dieser Effekt niemanden überraschen. Der Scrum Guide weist zum Beispiel deutlich auf die Bedeutung des Selbstmanagements auf der Ebene des Scrum-Teams hin. Dennoch ist die häufigste Ursache für viele misslungene Versuche, Scrum anzuwenden, etwas, das ich als agiles Mikromanagement bezeichne: eine Pseudo-Verpflichtung zu agilen Prinzipien, die immer dann außer Kraft gesetzt wird, wenn es aus der Sicht eines Stakeholders oder Managers vorteilhaft erscheint.

    Erfahren Sie in weniger als zwei Minuten, wie wichtig es ist, dass Scrum-Teams sich selbst managen.

    Agiles Mikromanagement — Making Your Scrum Work #27 — Berlin Product People GmbH

    (more…)

  • Kein Sprint-Ziel — Making Your Scrum Work #26

    In Kürze: Kein Sprint-Ziel

    In einem Scrum-Projekt gibt es viele Möglichkeiten des Scheiterns. Angesichts der Umstand, dass Scrum ein Rahmenwerk mit einem angemessenen, aber kurzen “Handbuch” ist, sollte dieser Effekt niemanden überraschen. Was ist zum Beispiel, wenn es kein Sprint-Ziel gibt – Sprint für Sprint? Was ist, wenn das Scrum-Team immer nur an einer zufälligen Auswahl von Aufgaben arbeitet, die zum Zeitpunkt der Sprintplanung am dringendsten zu sein scheinen?

    Erfahren Sie in weniger als zwei Minuten, wie wichtig das Sprint-Ziel für die sinnvolle Arbeit in einem Scrum-Team ist.

    Kein Sprint-Ziel — Making Your Scrum Work 26 — Berlin Product People GmbH

    (more…)

  • Stakeholder-Vertrauen

    In Kürze: Stakeholder-Vertrauen

    Vertrauen ist der Anfang von allem. Ich zögere, einen alten Slogan eines Bankinstituts zu übernehmen. Im Zusammenhang mit der Entwicklung zu einer lernenden Organisation und dem Streben nach von geschäftlicher Agilität fasst er jedoch die größte Herausforderung perfekt zusammen: Wie können wir die Etablierten der Organisation, die ein Interesse am Status quo haben, davon überzeugen, die neue Arbeitsweise zu akzeptieren? Begleiten Sie mich und erfahren Sie, wie sich Misstrauen manifestiert und was wir tun können, um Stakeholder-Vertrauen zu gewinnen.

    Stakeholder-Vertrauen — Scrum Master Survival Guide — Berlin Product People GmbH

    (more…)

  • Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg

    TL; DR: Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg

    Viele Menschen lehnen die Schätzung von Arbeitspaketen ab, da Schätzungen angeblich Tür und Tor für den Missbrauch von Metriken wie Velocity durch die Manager öffnen und Taylorismus, Mikromanagement und exzessives Reporting durch die Hintertür wieder einführen. Für die Befürworter von #noestimates stehen Schätzungen im Widerspruch zu grundlegenden Ideen der agilen Produktentwicklung wie Selbstmanagement, Ergebnisorientierung oder dem Ausstieg aus der Feature Factory.

    Ich möchte einen anderen, weniger ideologischen Ansatz vorschlagen: Schätzungen sind auf Teamebene nützlich, lassen Sie einfach die Zahlen weg. Warum? Die Schätzung von Arbeitsaufgaben ist ein schneller Weg für ein Scrum-Team, um herauszufinden, ob alle Teammitglieder das gleiche Verständnis über das Warum, das Was und das Wie der anstehenden Arbeit haben. Die resultierenden Zahlen sind jedoch ein reiner Nebeneffekt, der aber wahrscheinlich immer noch zur Information des Teams nützlich ist. (In der Tat sind die Ergebnisse der Schätzungen nicht dazu gedacht, über die Teamebene hinaus verwendet zu werden.)

    Schätzungen sind nützlich, lassen Sie einfach die Zahlen weg — Berlin Product People GmbH

    Übrigens, genauso wie man nicht “nicht kommunizieren” kann, bin ich davon überzeugt, dass Menschen immer “schätzen”, ob sie nun darüber reden oder nicht.

    (more…)

  • Das Wesen von Scrum: Es ist ein Werkzeug; es geht nicht um Liebe oder Hass

    Das Wesen von Scrum: Es ist ein Werkzeug; es geht nicht um Liebe oder Hass

    In Kürze: Das Wesen von Scrum: Es ist ein Werkzeug

    Regelmäßig erscheinen Artikel von Entwicklern, in denen detailliert dargelegt wird, warum “Agile” im Allgemeinen und das Wesen von Scrum im Besonderen unsere kollektive Geringschätzung verdienen.

    Was mir in dieser Diskussion immer aufgefallen ist, ist die Emotionalität der Beteiligten. Tatsache ist, dass Scrum ein Werkzeug ist, das nützlich ist, um eine primäre Aufgabe zu erfüllen: den Kunden von neuen, in komplexen Umgebungen entstehenden Produkten einen Mehrwert zu bieten und gleichzeitig die Risikoexposition eines Unternehmens zu mindern.

    Wenn also Scrum in einer Organisation nicht funktioniert, liegt das vielleicht daran, dass Scrum von vornherein auf die falsche Situation angewendet wird. Oder, dass es mechanisch umgesetzt wird, angetrieben von Leuten, die nicht wissen, was sie tun. (Im Ernst, wie kompliziert kann Scrum schon sein, wenn das Handbuch 18 Seiten umfasst?)

    Die Frage lautet daher: Warum sollte ich ein Werkzeug “hassen”, das für den beabsichtigten Zweck ungeeignet ist oder inkompetent angewendet wird? Würde ich einen Hammer dafür verabscheuen, dass dieser nicht in der Lage ist, eine Schraube präzise in einen Holzbalken zu drehen? Wahrscheinlich nicht, denn der Hammer wurde nicht für diesen Zweck konstruiert, und weder die bloße Willenskraft noch Aufstampfen mit den Füßen werden daran etwas ändern.

    Das Wesen von Scrum: Es ist ein Werkzeug; es geht nicht um Liebe oder Hass

    (more…)

  • Scrum Meistern in 300 Worten

    In Kürze: Scrum Meistern in 300 Worten

    Wie kann man Scrum zum Funktionieren bringen? Lesen Sie weiter, um mehr über meine drei wichtigsten Ziele für Scrum-Master zu erfahren, wenn Sie Scrum meistern wollen.

    Scrum Mastery in 300 Words — Berlin Product People GmbH

    (more…)