Hören Sie auf, Ihre Tickets vorzuführen

Die Demo beginnt in sechs Minuten. Jemand sucht nach einem Testkonto. Jemand anderes fragt, in welcher Umgebung der neueste Build liegt. Die Person, die präsentiert, hat Jira geöffnet und nach Erledigt gefiltert, was nun offenbar die Agenda zu sein scheint. Es gibt vierzehn Tickets, drei verschiedene Präsentierende und keine offensichtliche Antwort auf die Frage, die ein Stakeholder gleich stellen wird: „Was können unsere Nutzer jetzt tun, was sie vorher nicht konnten?"

So endet gutes Engineering in einer schlechten Demo. Ein Entwickler erklärt eine knifflige Implementierung, klickt sich durch einen neuen Bildschirm und übergibt an die nächste Person. Alle haben hart gearbeitet. Alle sind höflich. Am Ende weiß das Publikum, dass Dinge abgeschlossen wurden, muss aber möglicherweise noch selbst herausfinden, warum irgendetwas davon wichtig ist.

Bessere Vorbereitung beginnt früher als beim Prüfen der Bildschirmfreigabe. Sie bedeutet, die abgeschlossene Arbeit mit einem Problem zu verbinden, das die Leute erkennen, zu zeigen, was sich geändert hat, und Raum für eine nützliche Rückmeldung zu schaffen. Eine längere Probe der Ticketliste bringt Sie dort nicht hin.

Mit der Änderung beginnen, die jemand erkennen kann

Ein Tickettitel ergibt Sinn für die Leute, die zwei Wochen damit verbracht haben, darüber zu diskutieren. Stakeholder haben diesen Kontext möglicherweise nicht. „Bulk-Approval-Endpunkt hinzufügen" sagt ihnen, was das Team gebaut hat. Es erklärt nicht, wessen Tag schwierig war, welcher Teil jetzt anders ist oder was ungelöst bleibt.

Stellen Sie sich ein Team vor, das ein Einkaufstool für Abteilungsleiter entwickelt. Die alte Demo beginnt mit einer Ticketnummer, erwähnt den neuen Endpunkt und zeigt eine Auswahlcheckbox. Der Präsentierende genehmigt drei Anfragen. Es funktioniert. „Fragen?" wird mit der Art von Stille beantwortet, die Menschen dazu bringt zu prüfen, ob sie noch stummgeschaltet sind.

Dieselbe Arbeit könnte anders eingeführt werden: „Ein Manager, der einen Stapel routinemäßiger Anfragen prüft, muss derzeit jede einzeln öffnen und genehmigen. Wir haben eine Möglichkeit hinzugefügt, geeignete Anfragen zusammen zu genehmigen. Ich zeige diesen Pfad, dann was passiert, wenn eine Anfrage eine individuelle Prüfung benötigt. Wir möchten Ihre Hilfe beim Überprüfen, ob die Eignungsregeln zu Ihrer tatsächlichen Arbeitsweise passen."

Jetzt haben die Klicks einen Zweck. Das Publikum kann das Verhalten anhand einer Situation prüfen, die es versteht. Jemand könnte darauf hinweisen, dass Anfragen von einem neuen Lieferanten immer eine separate Prüfung benötigen. Das ist eine nützliche Entdeckung, auch wenn sie die Demo weniger aufgeräumt macht.

Das Team sollte auch präzise über seine Belege sein. Eine funktionierende Bulk-Aktion zu zeigen, belegt, dass die Fähigkeit existiert. Es belegt nicht, wie viel Zeit Manager sparen werden, ob sie sie nutzen werden oder ob sich Genehmigungen verbessern werden. Das sind Dinge, die nach der Nutzung zu untersuchen sind. „Wir erwarten, dass dies repetitive Schritte reduziert" ist eine ehrliche Erklärung der Absicht. „Wir haben Manager produktiver gemacht" braucht Belege, die die Demo allein nicht liefern kann.

Technische Arbeit verdient dieselbe Klarheit

Dieser Ansatz sollte eine Review nicht in einen Schönheitswettbewerb für sichtbare Features verwandeln. Ein Sprint, der für Verbesserung von Wiederherstellung, Sicherheit oder Wartbarkeit aufgewendet wurde, kann enorm wichtig sein. Niemand muss einen neuen Button erfinden, um das zu rechtfertigen.

Für eine Wiederherstellungsänderung zeigen Sie das Fehlerszenario, wie das System jetzt reagiert und was der Test demonstriert. Für ein Dependency-Upgrade erklären Sie, welches Risiko es adressiert und wie die Kompatibilität geprüft wurde. Verbinden Sie die Engineering-Arbeit mit der Konsequenz, die sie ändern soll, unter Verwendung der verfügbaren Belege und mit Klarheit über deren Grenzen.

Sich auf eine Unterhaltung vorbereiten

Wissen Sie, wer zuhört. Ein Business-Publikum braucht möglicherweise die Auswirkung auf einen Workflow und die Entscheidung, die es ermöglicht. Ein technisches Publikum muss möglicherweise Implementierungsentscheidungen und Trade-offs prüfen. Mit beiden im Raum beginnen Sie damit, warum die Änderung wichtig ist, und liefern dann die Tiefe, die für die Prüfung nötig ist.

Wenn Sie nur zehn Minuten haben, entscheiden Sie, welchen Business Value das Publikum am meisten verstehen muss. Im Einkaufsbeispiel könnte das bedeuten, den Batch-Approval-Pfad zu zeigen und die Ausnahmeregeln zu prüfen, anstatt jedes abgeschlossene Ticket zu durchlaufen. Wählen Sie, was den Leuten hilft, eine nützliche Entscheidung zu treffen. Behalten Sie das Sprint Goal im Blick, einschließlich wo das Ergebnis zu kurz greift; eine kürzere Demo sollte ein unangenehmes Ergebnis nicht verbergen.

Für jeden Punkt sollte das Team das Problem, das geänderte Verhalten und die Belege hinter seinen Behauptungen erklären können. Fragen Sie dann, welche Rückmeldung nützlich wäre. Prüfen Sie eine Annahme über einen Workflow? Wählen Sie zwischen zwei nächsten Schritten? Testen Sie, ob eine Einschränkung akzeptabel ist? Eine spezifische Frage gibt den Leuten einen Weg in die Diskussion, den „Irgendwelches Feedback?" selten bietet.

Die praktische Vorbereitung ist immer noch wichtig. Bestätigen Sie, was die Definition of Done erfüllt, was wo deployed ist und was tatsächlich demonstriert werden kann. Richten Sie repräsentative Daten ein und prüfen Sie den Pfad, den Sie zeigen wollen. Lassen Sie Zeit für Unterbrechungen. In Scrum ist die Demonstration nur ein Teil des Sprint Reviews, wo das Team und die Stakeholder das Ergebnis prüfen und herausfinden, was als Nächstes zu tun ist. Sie sollte diese Zusammenarbeit unterstützen, nicht das gesamte Event verbrauchen.

Wo Flow hilft

Die Demo-Notizen von Simyl Flow können für ein Business-, technisches oder gemischtes Publikum abgestimmt werden. Neben dem Vorschlagen demo-würdiger abgeschlossener Items verbinden die Notizen die Arbeit mit Business Value und liefern Gesprächspunkte, erwartete Stakeholder-Fragen und vorgeschlagene Antworten. Das Team hat einen Ausgangspunkt, um zu erklären, warum eine Änderung wichtig ist, und sich auf die Unterhaltung vorzubereiten, die sie auslösen könnte. Im Einkaufsbeispiel könnte das bedeuten, sich auf Fragen zu Ausnahmen vorzubereiten, mit Antworten, die gegen das tatsächliche Verhalten geprüft wurden.

Wenn die Agenda zusammengedrängt wird, enthalten die Notizen auch einen „Falls die Zeit knapp wird, betonen Sie:"-Brief, der Business-Value-Punkte aus den Items des Präsentierenden zusammenführt. Das Team entscheidet immer noch über Reihenfolge und Prioritäten, prüft, was bereit zur Demonstration ist, und verifiziert die Behauptungen. Flow hilft, die Erklärung fokussiert zu halten; das Team bleibt verantwortlich für das, was es sagt.

Vorbereitungszeit summiert sich über das Team. Als illustratives Beispiel: Wenn Flow vier Entwicklern jeweils fünfzehn Minuten vor einer Demo spart, gibt das eine Team-Stunde zurück. Bei angenommenen Vollkosten von 75 US-Dollar pro Stunde sind das 75 US-Dollar Kapazität, mehr als der monatliche Growth-Preis von 49 US-Dollar pro Team. Eine Demo kann den Monat unter diesen Annahmen abdecken, und Demo-Vorbereitung ist nur eine der Zeremonien, die Flow unterstützt. Das ist Zeit, die für andere Arbeit verfügbar ist, keine garantierte Ersparnis oder Bargeld, das aus der Lohnabrechnung entfernt wird. Vorbereitung zu überspringen hat auch Kosten: Es lässt alle im Meeting entwirren, was vorher hätte erklärt werden sollen.

Die Unterhaltung braucht danach auch einen Ort, wohin sie gehen kann. Flow kann Demo-Feedback in Retrospektiven-Karten und Aktionen verwandeln und dem Team helfen, Lernen in seine Verbesserungsarbeit zu tragen. Produkt-Feedback sollte auch die relevanten Product-Backlog-Entscheidungen informieren. Eine Anfrage nach einer fehlenden Lieferantenregel und ein wiederkehrendes Problem mit Demo-Umgebungen brauchen unterschiedliche Nachverfolgung, auch wenn beide aus derselben Review kamen. Vereinbaren Sie, wer jede Nachverfolgung vorantreibt und wann das Team prüft, was passiert ist.

Schauen Sie sich vor der nächsten Demo das erste Item an, das Sie zeigen wollen. Kann jemand außerhalb des Teams verstehen, wem es hilft, was sich geändert hat und was Sie noch lernen müssen? Wenn nicht, bereiten Sie weiter die Erklärung vor, nicht mehr Tickets hinzuzufügen. Geben Sie den Leuten genug zum Hinterfragen, nicht nur genug zum Applaudieren. Nutzen Sie dann, was Sie hören, um zu entscheiden, was als Nächstes passiert.