"Wir legen uns hin, wir zünden Lichter an, im Universum sind wir die einzigen." Es scheint, dass diese Zeile aus dem Lied der Splin-Gruppe sicher als Soundtrack der Einführung der Sprint Review-Praxis in Dodo Pizza erkannt werden kann.
Haftungsausschluss: In einem Artikel beschreibt Anton die erste Version eines brauchbaren Sprint-Reviews. Wir haben bereits eine fortgeschrittenere, aber darüber in der nächsten Serie.
Der erste Versuch, die Sprint-Review-Praxis bei Dodo Pizza zu starten, schlug kläglich fehl.
Vielleicht denken Sie, dass Praktiken der Scrum-Pizza-Kette im Allgemeinen nutzlos sind. Einer der Hauptvorteile von Dodo Pizza ist jedoch seltsamerweise ein eigenes IT-System, das alle Prozesse in 495 Pizzerien der Kette in 12 Ländern verwaltet.
Über 80 Entwickler und Analysten arbeiten heute an diesem System (und im Laufe der Zeit werden mehr als zweihundert hinzukommen). Als schnell wachsendes Startup streben wir nach maximaler Effizienz. Daher verwenden wir viele der Frameworks für „flexible Entwicklung“: Scrum, LeSS, extreme Programmierung.
Aber was ist das für ein Gedränge ohne Sprint-Review? Und du wirst recht haben.
Wie Sie wissen, gibt die Sprint-Überprüfung den Rhythmus für das Team vor und motiviert, die Arbeit bis zum Ende des Sprints abzuschließen. Noch wichtiger ist, dass es dabei hilft, ein wertvolles Produkt zu erstellen, das ein Unternehmen benötigt, und nicht nur Rückstandsaufgaben zu erledigen. Also schreiben sie auf jeden Fall in Bücher.
Aus irgendeinem Grund hat dieser Ansatz bei uns jedoch nicht funktioniert. Zum Beispiel haben wir bei einem der ersten Sprint-Reviews Dodo Pizza-Franchisenehmern aus Kasachstan ihre neue Website gezeigt - dodopizza.kz. Das Feedback war inspirierend: Die Partner sagten, dass die Website großartig aussieht und vor dem Hintergrund der Konkurrenz wie ein Meisterwerk erscheinen wird.
Als wir es herausbrachten, stellte sich heraus, dass viele Dinge darin fehlten. Das heißt, wir haben Zeit mit der Sprint-Überprüfung verbracht, aber tatsächlich kein nützliches Feedback von Partnern erhalten.
Im Allgemeinen haben wir solche Sprint-Bewertungen bald stillschweigend eingestellt.
Nach ein paar Monaten beschloss ich, es erneut zu versuchen. Zu diesem Zeitpunkt hatten wir bereits acht Teams, die im LeSS-Framework an demselben Rückstand arbeiteten. Wir haben versucht, alle Regeln von Large Scale Scrum zu befolgen, und das Fehlen einer Sprint-Überprüfung war einer der Verstöße.
Ich habe mich im Voraus darauf vorbereitet, dass zunächst alles schlecht sein wird und Sie mit der Trial-and-Error-Methode nach dem richtigen Format suchen müssen. Nach jeder Überprüfung bat ich die Teilnehmer, die Veranstaltung auf einer Skala von 1 bis 10 (Bottom - Omnische) zu bewerten. Anfangs waren die Ratings sehr niedrig, näher am "Boden". Wir gaben jedoch nicht auf, experimentierten und irgendwann in ein paar Monaten begannen sie, zum Ognisten zu wechseln.
Das haben wir geändert
Hausaufgaben machen
Wir haben festgestellt, dass Sie nicht weniger Zeit für die Vorbereitung als für den Sprint-Test selbst aufwenden müssen - oder sogar mehr. Die ganze Veranstaltung dauert zwei Stunden und ich mache mich für drei Stunden fertig. Schließlich ist es notwendig, Ziele mit den Teams zu koordinieren, mit Partnern, Managern der Verwaltungsgesellschaft, Mitarbeitern von Pizzerien und anderen Gästen zu vereinbaren, Gespräche zu buchen, ein Poster zu erstellen, Moderatoren zu finden, Anweisungen zu erteilen, einen Zeitplan zu erstellen und zu zeichnen, Flip-Chats aufzulegen, um Feedback zu sammeln usw. Ohne all das wird es einfach Chaos geben.
Nicht unvollendet anzeigen
Zuerst zeigten wir halbfertige Features. Wir haben jedoch erkannt, dass wir auf diese Weise Teams und vor allem Kunden täuschen. Einmal haben wir dem CEO eines Geoservice-Unternehmens gezeigt, das Kartendaten zwischenspeichert. Bei der nächsten Überprüfung wurde es dann erneut angezeigt - nur mit behobenen Fehlern. Als wir zum dritten Mal ankamen und denselben Dienst zeigten, aber bereits auf der Kampfwebsite, hatte der CEO eine logische Frage: "Was zum Teufel zeigen Sie zum dritten Mal dasselbe?"
Jetzt bei der Sprint-Überprüfung zeigen wir nur, was auf der Kampfseite veröffentlicht ist. Wenn etwas fast fertig ist - es gibt nur Fehler, die behoben, getestet und angeordnet werden müssen - werden wir nicht angezeigt.
Verhandlungen statt offener Raum
LeSS-Autoren empfehlen eine Sprint-Überprüfung in Form eines "Basars". Alle Teams müssen ihre Arbeit in einem großen Raum zeigen, und Interessierte können zu Stationen gehen, die sie interessieren. Wir haben es mehrmals versucht, es stellte sich heraus, laut und pingelig.
Laptop-Bildschirme sind klein, nichts ist auf ihnen sichtbar, Lärm von benachbarten Stationen erschwert die Konzentration und die ständige Bewegung der Menschen schafft Chaos. Daher versammeln sich jetzt im Konferenzraum alle nur am Anfang und am Ende. Die Hauptaktion findet in den Besprechungsräumen statt, in denen jedes Team seine Arbeit präsentiert. Dort, Ausrüstung, große Bildschirme, Sie können bequem sitzen, entfernte Teilnehmer sind verbunden und es gibt einen Ort zum Sammeln von Feedback.
Übergänge sind verboten!
Zunächst bewegten sich unsere Stakeholder frei zwischen den Teams. Aber es war nervig. Stellen Sie sich vor, Sie haben angefangen, etwas zu erzählen, und in zehn Minuten tritt eine neue Person der Gruppe bei und stellt Fragen zu dem, worüber Sie gerade gesprochen haben.
Fangen Sie an zu antworten - der Rest ist gelangweilt. Ignorieren - die Person ist verärgert. Deshalb haben wir beschlossen, die Bewegung zwischen Gruppen zu verbieten. Ich habe das Thema ausgewählt, das Sie interessiert - sitzen Sie bis zur nächsten Pause zwanzig Minuten im Besprechungsraum.
Liebe Gäste
Wir haben festgestellt, dass die Zusammensetzung der "Gäste" von großer Bedeutung ist. Nichts motiviert einen Entwickler so sehr wie das Erscheinen in einem Sprint Review CEO. Vor allem, wenn Sie ihm einen technischen Trick wie einen Dienst in einem Cube zeigen oder Auth auf .Net Core übertragen müssen. Wir müssen erklären, warum wir das tun. Fedor Ovchinnikov, CEO von Dodo Pizza, ist begeistert und weiß, wie man alle aufheitert und in drei Minuten den Horizont der Unternehmensentwicklung umreißt. Nun, wenn wir Kundenfunktionen zeigen, zum Beispiel einen Halbpizza-Konstrukteur in einer mobilen Anwendung, rufen wir jetzt in der Regel externe Gäste, Bekannte und Freunde von Facebook an.
Gelöschte Mitglieder
Es ist einfach, ein Meeting abzuhalten, wenn sich alles in einem Raum befindet. Aber wir haben viele entfernte Mitarbeiter in Syktyvkar, Nischni Nowgorod, Kasan und Goryachy Klyuch. Es ist auch wichtig, dass sie teilnehmen.
Zuerst beschwerten sich die "Fernarbeiter", dass sie schwerhörig seien und fast nichts gesehen hätten. Jetzt kümmern wir uns sowohl um sie als auch um Offline-Teilnehmer. Die Checkliste zur Vorbereitung der Sprintprüfung enthält Elemente, die uns daran erinnern, die Verbindung zu überprüfen und die Ausrüstung einzurichten. Wir senden auf Slack und in jüngerer Zeit haben wir die Veranstaltung auf unserem Youtube-Kanal Dodo Pizza gestreamt.
Feedback-Haftungsausschluss
Als sich herausstellte, dass alles gut war und es keine Möglichkeit gab, das Format zu verbessern, stellten wir uns die Frage: Machen wir keinen Müll? Eine Sprint-Überprüfung ist eine ziemlich teure Veranstaltung (wenn man sie zynisch betrachtet - in Bezug auf die Anzahl der Teilnehmer, ihre Gehälter und die aufgewendeten Stunden). Nutzen wir diese zwei Stunden so produktiv wie möglich? Aus diesem Grund haben wir uns entschlossen, das Sammeln von Feedback während der Sprint-Überprüfung vollständig abzulehnen.
Im Format eines solchen Ereignisses kann es nicht tiefgreifend und qualitativ durchgeführt werden (erinnern Sie sich an einen Fall mit Kasachstan). Darüber hinaus sammeln wir die meisten wichtigen und qualitativ hochwertigen Bewertungen während des Sprints und ziehen alle Interessierten an, von internen Kunden bis hin zu Benutzern. Sie werden überrascht sein, selbst der Scrum Guide sagt nicht, dass Feedback zur Sprint-Überprüfung gesammelt werden sollte: "Während der Sprint-Überprüfung , das Scrum-Team und die Stakeholder arbeiten zusammen, was im Sprint getan wurde. " Team und Stakeholder, keine Benutzer. Interagiere, sammle kein Feedback. Eine ganz andere Bedeutung.
Öffne die "Küche"
Nicht alle Stakeholder sind tief in den Entwicklungsprozess eingebunden. Aber jeder will wissen, was dort los ist. Aus diesen Gründen haben wir beschlossen, den Sprint-Test neu auszurichten.
Wir zeigen immer noch die geleistete Arbeit, aber zusätzlich erzählen die Teams die Geschichte hinter den neuen Funktionen. Was war der Zweck? Was ist während des Sprints passiert? Was hat uns abgelenkt oder daran gehindert, unser Ziel zu erreichen? Welche Maßnahmen haben wir ergriffen, um das Ziel zu retten? Es hilft: Dies macht den Managern zum Beispiel klar, warum das „Verstecken der E-Mail des Kunden mit einem Check-in-Stern“ eine sehr schwierige Aufgabe ist („eine halbe Stunde Arbeit eines Programmierers“, wie Manager dachten). Umgekehrt hilft ein solcher Dialog Entwicklern, in Bezug auf „Kunden“ und ihre Probleme zu denken und nicht in Bezug auf die spezifischen Lösungen, an denen sie arbeiten.
Dies ist vielleicht die Hauptsache, die wir in unserem Ansatz geändert haben. Fortschritte sind offensichtlich, aber wie immer gibt es noch etwas zu verbessern. Die Experimente dauern an.
Die Hauptsache, die wir verstanden haben, ist, dass wir uns nicht auf die in den Scrum-Handbüchern vorgeschlagenen Formate festlegen müssen. Sie müssen versuchen, Fehler zu machen und zu experimentieren. Es gibt keine universellen Lösungen - Sie müssen nach solchen suchen, die in Ihrer Situation funktionieren.
Deshalb möchte ich Sie am Ende warnen: Kopieren Sie unser Format nicht. Er arbeitet gut mit uns zusammen, weil er als Ergebnis vieler Experimente geboren wurde. Suchen Sie nach Ihrem Ansatz - und Sie werden Erfolg haben. Es wird sicherlich nicht schlimmer sein.