Was bekommen Sie, wenn Sie eine IT-Abteilung, eine fehlerhafte Sprint-Überprüfung, Entschlossenheit und Pizza überqueren? Größe, das ist was.
Unser erster Versuch,
Sprint-Bewertungen bei Dodo Pizza einzuführen, schlug spektakulär fehl. Sie würden vielleicht denken, dass eine Pizzakette überhaupt keine Scrum-Praktiken benötigt. So seltsam es auch scheinen mag, einer der Hauptvorteile von
Dodo Pizza ist sein eigenes IT-System, das alle Arbeitsprozesse von 430 Pizzerien in 11 Ländern steuert.
Derzeit arbeiten mehr als 60 Programmierer und Analysten an unserem System, und wir planen, diese Zahl auf
mehr als 200 zu erhöhen. Wie bei jedem schnell wachsenden Start-up streben wir maximale Effizienz an. Daher verwenden wir häufig agile Frameworks, einschließlich Scrum, LeSS und extremer Programmierung. Aber wie setzt man Scrum ohne Sprint-Reviews ein? Das ist die Frage, die Sie sich stellen könnten - und zu der Sie Recht haben würden.
Wie wir wissen, legt ein Sprint-Review den Arbeitsrhythmus für ein Team fest und motiviert es, die Aufgabe bis zum Ende des Sprints zu beenden. Noch wichtiger ist, dass eine Sprint-Überprüfung dazu beiträgt, ein Produkt zu erstellen, das für das Unternehmen wertvoll ist und nicht nur Probleme aus dem Rückstand löst. Zumindest sagen das die Bücher.
Aber irgendwie hat dieser Ansatz bei uns nie funktioniert. Zum Beispiel haben wir bei einem unserer ersten Sprint-Reviews unseren kasachischen Franchisenehmern eine neue Website (dodopizza.kz) vorgestellt. Das Feedback war inspirierend, unsere Partner sagten uns, dass die Website großartig aussah und im Vergleich zu den Mitbewerbern praktisch ein Meisterwerk war. Aber nach dem Start stellte sich heraus, dass es ernsthaft fehlte. Wir hatten also Zeit für einen Sprint-Test verschwendet, aber kein nützliches Feedback erhalten.
Bald haben wir diese Sprint-Bewertungen ganz stillschweigend gestoppt.
Einige Monate vergingen und ich beschloss, es erneut zu versuchen. Zu diesem Zeitpunkt hatten wir acht Teams, die an einem Rückstand im
LeSS- Framework arbeiteten. Wir haben versucht, alle Large Scale Scrum-Regeln einzuhalten, und die Stornierung von Sprint-Überprüfungen war ein Verstoß.
Ich machte mich auf schlechte erste Ergebnisse gefasst - es war klar, dass wir durch Ausprobieren das richtige Format finden mussten. Nach jeder Überprüfung bat ich die Teilnehmer, sie auf einer Skala von 1 bis 10 zu bewerten. Anfangs waren unsere Noten sehr niedrig, aber wir gaben nicht auf und experimentierten weiter, sodass die Bewertungen in ein paar Monaten begannen Bewegen Sie sich zum oberen Teil der Skala.
Das haben wir anders gemacht.
Unsere Hausaufgaben machen
Es ist klar geworden, dass die Vorbereitung der Sprintprüfung nicht weniger Zeit erfordert als die Sprintprüfung selbst oder sogar mehr. Eine Überprüfung dauert zwei Stunden, und ich verbringe drei Stunden damit, mich darauf vorzubereiten. Es gibt Überprüfungsziele, die mit dem Team, den Partnern, den Managern der Muttergesellschaft, den Mitarbeitern und anderen Gästen besprochen und vereinbart werden müssen, Konferenzräume zum Buchen, ein Poster zum Erstellen, Moderatoren zum Finden und Unterweisen sowie einen Zeitplan zum Zusammenstellen , Feedback-Flipcharts zum Aufhängen usw. Und ohne all das entsteht Chaos.
Wenn es nicht fertig ist, zeigen Sie es nicht
Zuerst haben wir bei Sprint-Reviews halbfertige Features gezeigt. Dann kam uns der Gedanke, dass dies bedeutete, unsere Teams und, noch schlimmer, unsere Kunden zu betrügen. Wir haben dem CEO einmal einen Kartendienst gezeigt, der kartografische Daten zwischenspeichert. Bei der nächsten Überprüfung haben wir es erneut gezeigt, wobei Fehler behoben wurden. Als wir es ihm zum dritten Mal brachten und auf der Live-Website zeigten, hatte er eine sehr berechtigte Frage: Warum zum Teufel muss er sich immer wieder dasselbe ansehen? Bei Sprint-Reviews werden nur Funktionen angezeigt, die sich bereits auf einer Live-Site befinden. Wenn etwas fast erledigt ist und wir nur Fehler beheben, testen und ausrollen müssen, zeigen wir es einfach noch nicht.
Konferenzräume statt offener Räume
LeSS-Entwickler empfehlen, eine Sprint-Überprüfung als „Basar“ durchzuführen, bei der alle Teams ihre Arbeit in einem großen Raum demonstrieren und die Leute die Stationen besuchen, an denen sie interessiert sind. Wir haben das mehrmals versucht und es war viel Lärm und Verwirrung.
Laptop-Bildschirme sind klein und unbequem, man kann sich aufgrund des Lärms an anderen Stationen nicht gut konzentrieren und man bekommt Chaos, wenn Menschen ständig herumwandern. Jetzt versammeln wir uns alle nur zu Beginn und am Ende der Überprüfung in einem großen Konferenzraum. Die Hauptaktion findet in kleinen Konferenzräumen statt, in denen jedes Team seine Arbeit präsentiert. Es ist komfortabler, es gibt alle notwendigen Geräte, großen Bildschirme und Internetzugang für Remote-Teilnehmer, und Sie können in Ruhe Feedback einholen.
Wandern ist nicht erlaubt
Anfangs gingen die Stakeholder frei zwischen den Teams, aber es war ärgerlich. Stellen Sie sich vor, Sie machen Ihre Präsentation, haben zehn Minuten lang gesprochen, und dann kommt jemand und stellt Ihnen Fragen zu den Dingen, die Sie gerade behandelt haben.
Wenn Sie antworten, langweilen sich alle anderen. Wenn Sie dies nicht tun, kann diese Person es ablehnen. Deshalb haben wir beschlossen, das Wandern zwischen Gruppen nicht zuzulassen. Wenn Sie ein Thema ausgewählt haben, setzen Sie sich bitte in einen Konferenzraum und warten Sie 20 Minuten bis zur nächsten Pause.
Liebe Gäste
Wir haben festgestellt, dass die Gästeliste sehr wichtig ist. Nichts motiviert einen Entwickler mehr als ein Firmenchef, der eine Sprint-Überprüfung besucht, insbesondere wenn Sie ein technisches Ding zeigen, wie das Hosten eines Microservices in Kubernetes oder das Migrieren einer Auth-Komponente zu .Net Core. Dann musst du erklären, warum du das alles überhaupt gemacht hast.
Fyodor Ovchinnikov, der CEO von Dodo Pizza , kann das Publikum mit Energie aufladen, in drei Minuten die Stimmung heben und die breiten Perspektiven der Unternehmensentwicklung skizzieren, aber wenn er Front-End-Funktionen wie eine eigene Pizza-Funktion demonstriert In unserer mobilen App laden wir externe Gäste ein, hauptsächlich Bekannte und Freunde von Facebook.
Ein lustiger Moderator und eine Kappe
Es stellt sich heraus, dass der Moderator die Hälfte des Erfolgs eines interessanten und aufregenden Sprint-Reviews ausmacht. Viele Leute haben diese Rolle gespielt; Ich habe es zuerst mit Hilfe unserer Scrum-Meister versucht.
Dann wurde Sergey Gryazev, unser Produktbesitzer für mobile Apps, Moderator, und jetzt können wir uns solche Ereignisse ohne seine Witze nicht mehr vorstellen. Und kürzlich haben wir ein rituelles Artefakt erworben, die Speaker's Cap. Der Lautsprecher sollte eine Kappe aufsetzen. Es bedeutet nichts Besonderes, es ist nur ein Ritual, aber es macht alle munter.
Remote-Teilnehmer
Es ist einfach, eine Sprint-Überprüfung durchzuführen, wenn alle im selben Raum sitzen. Aber wir haben viele entfernte Mitarbeiter in Syktyvkar, Nischni Nowgorod, Kasan und Goryachy Klyuch, und es ist wichtig, dass auch sie beteiligt sind.
Zuerst beschwerten sie sich, dass sie praktisch nichts hören oder sehen konnten, aber wir haben gelernt, uns sowohl um sie als auch um unsere Offline-Teilnehmer zu kümmern. In der Checkliste zur Vorbereitung der Sprintprüfung finden Sie Hinweise, dass wir die Internetverbindung überprüfen und die Ausrüstung anpassen müssen. Wir veröffentlichen Event-Updates über Slack und haben kürzlich begonnen, unsere Meetings auf dem
Dodo Pizza Youtube-Kanal zu streamen.
Sammeln Sie kein Feedback
Als wir bereits anfingen zu glauben, dass alles in Ordnung sei und wir nichts anderes verbessern müssten, fragten wir uns, ob wir tatsächlich das Richtige tun. Eine Sprint-Überprüfung ist eine ziemlich teure Angelegenheit, wenn man die Anzahl der Teilnehmer, ihren Lohn und die aufgewendete Zeit berücksichtigt. Nutzen wir diese zwei Stunden mit maximaler Effizienz? Aus diesem Grund haben wir uns entschlossen, bei Sprint-Bewertungen überhaupt kein Feedback einzuholen. Unter solchen Bedingungen ist das Feedback niemals umfassend oder von guter Qualität (die Überprüfung der kasachischen Website ist ein typisches Beispiel). Außerdem sammeln wir während des Sprints selbst viele aussagekräftige und nützliche Rückmeldungen, die alle Interessenten, von internen Kunden bis zu Benutzern, befragen.
Sie wären überrascht, aber selbst im Scrum Guide gibt es kein Wort darüber, wie Sie bei einem Sprint-Review Feedback einholen können. "Während der Sprint-Überprüfung arbeiten das Scrum-Team und die Stakeholder zusammen, was im Sprint getan wurde." Das Scrum-Team und die Stakeholder, keine Benutzer. Und sie arbeiten zusammen und sammeln kein Feedback. Darum geht es überhaupt nicht.
Willkommen auf der Backstage
Nicht alle Stakeholder nehmen aktiv am Entwicklungsprozess teil, aber alle möchten darüber informiert werden, was dort vor sich geht. Und das ist jetzt unser Ziel für die Sprintprüfung. Wir zeigen immer noch, was wir getan haben, aber außerdem sprechen unsere Teams über die Entstehung neuer Funktionen. Was war unser Ziel? Was war während des Sprints los? Was hat uns abgelenkt oder behindert? Welche Maßnahmen haben wir ergriffen, um unser Ziel zu erreichen? Und es hilft; Auf diese Weise können Manager beispielsweise verstehen, warum das Verbergen der E-Mail-Adresse eines Kunden in einer Quittung mit Sternchen überhaupt keine triviale Aufgabe ist und nicht nur eine „halbe Stunde Programmierung“, wie sie zuvor dachten. Und ein solcher Dialog hilft unseren Softwareentwicklern, über die Probleme der Kunden nachzudenken und sich nicht von der Lösung mitreißen zu lassen, an der sie arbeiten.
Dies sind die wichtigsten Dinge, die wir in unserem Ansatz für Sprint-Reviews geändert haben. Es gibt definitiv Fortschritte, aber es gibt auch noch Raum für Verbesserungen, also setzen wir unsere Experimente fort.
Vor allem eines haben wir verstanden: Sie müssen nicht zu sehr über die Empfehlungen des Scrum Guide nachdenken. Sie sollten durch Versuch und Irrtum gehen. Es gibt keine universellen Lösungen; Sie sollten nach denen suchen, die für Sie arbeiten.
Abschließend möchte ich Sie nur warnen. Kopieren Sie nicht unser Format. Es funktioniert für uns, da es aus Experimenten geboren wurde. Suchen Sie nach Ihrem eigenen Ansatz und Sie werden Erfolg haben. Was ist das Schlimmste, was passieren kann?