Beyond Sprint 0: Eine Alternative zur Integration von Teams

Scrum ist die beliebteste Projektmanagementmethode der Welt, wobei über 72 % der Teams Scrum oder einen Scrum-Hybrid verwenden. Wenn Sie in der Webentwicklung arbeiten, stehen die Chancen gut, dass Sie Scrum in irgendeiner Form verwenden.

Ein aktueller Trend in Scrum ist der „Sprint 0“ oder sein künstlerischer Cousin der „Design Sprint“. Es wurde viel darüber geschrieben, ob dies echte Sprints sind (sie sind es nicht), aber weniger darüber, warum sie überhaupt existieren, warum sie so hartnäckig bleiben und welche Alternativen es gibt.

Ich persönlich liebe Scrum und bin immer auf der Suche nach Möglichkeiten, wie ich es schrittweise verbessern kann. In diesem Artikel möchte ich die Methoden teilen, die ich in meinen Arbeitsablauf integriert habe, und eine Methode, die ich beim Zusammenführen von UX/UI und Entwicklung sowie beim Erstellen stärkerer Projektvisionen hilfreich finde.

Ein paar kurze Definitionen, bevor wir anfangen:

• Sprint 0
  Die anfängliche Anstrengung eines Teams, die für Scrum-Projekte erforderlichen Leitdokumente zu erstellen: eine Vision, ein Produkt-Backlog und Schätzungen zur Produktfreigabe.
• Design-Sprint
  Die anfängliche Anstrengung eines Teams, ein Leitdesign für den Rest der Veröffentlichung zu erstellen.
  

Warum es Sprint 0 und den Design Sprint gibt

Es ist schön und gut zu sagen: „Sprint 0 ist kein echter Sprint, mach es nicht.“ Aber diese sprintartigen Anpassungen existieren aus einem bestimmten Grund. Viele Teams übernehmen sie, weil ihr Projekt einen unerfüllten Bedarf hat, der über den unmittelbaren Anwendungsbereich von Scrum hinausgeht. Meine Beobachtung ist, dass Sprint 0 und Design-Sprints am häufigsten verwendet werden, um die folgenden Situationen anzugehen:

1. Fehlen einer starken Leitvision;
2. Mangelnde Designintegration in den Entwicklungsworkflow.

Der Scrum-Prozess geht davon aus, dass eine klare Vision entwickelt und vom Product Owner kommuniziert wurde. Aber heben Sie die Hand, wenn Sie an Projekten gearbeitet haben, bei denen die Vision entweder schwach, falsch oder unsichtbar war. Ich auch! Sprint 0 ist ein Versuch des Entwicklungsteams, die Visionslücke zu schließen. Es ist nicht die schlechteste Idee, also wo ist das Problem? Aus agiler Sicht ist Sprint 0 nicht iterativ, nutzt nicht die Talente des gesamten Teams und liefert nebulöse Ergebnisse. Und bevor Sie darauf hinweisen: „Hey, das eigentliche Problem hier ist, dass Scrum-Teams nicht die Arbeit des Product Owners übernehmen sollten“, glaube ich tatsächlich, dass ein interdisziplinäres agiles Team eine der besten Umgebungen ist, um ein starkes, realistisches Team zu entwickeln Visionen und Ziele.

Ich schlage eine agilere Methode zur Visionsbildung vor, die ich erfolgreich in No-Handoff-Projekten eingesetzt habe. Ich werde beide Situationen untersuchen, in denen diese sprintähnlichen Anpassungen verwendet werden, und beschreiben, wie dieser alternative erste Sprint den agilen Workflow besser unterstützt.

Vision und der Prototyp-Sprint

In der ersten Situation, wo es an einer starken Vision mangelt, sind die Leitdokumentation oder Ideen zu schwach, um ein Scrum-Projekt wirklich zu beginnen. Für jeden Prozess (einschließlich Scrum) benötigen Sie eine Anleitung, bevor Sie die Reise beginnen. Agile eignet sich hervorragend, um den besten Weg zum Erreichen eines Ziels zu finden, aber die Entwicklung der anfänglichen Vision liegt nicht in ihrem Aufgabenbereich. Tatsächlich fehlt in Scrum insgesamt eine Beschreibung der erforderlichen Vision für den Beginn des Entwicklungsprozesses. Ob es nun wirklich Scrum ist oder nicht, Sprint 0 ist nur ein Web-Team an vorderster Front, das die Tools verwendet, die es hat, und versucht herauszufinden, was es tun muss, bevor es damit beginnt.

Der wirkliche Nachteil von Sprint 0 besteht darin, dass das Erstellen des Leitdokuments für das Projekt zu dem Zeitpunkt, an dem Sie über die wenigsten Informationen verfügen, für den folgenden Entwicklungsprozess von geringem Wert ist.

Leitende Projektvisionen, die nicht mit der iterativ entstehenden Realität übereinstimmen, müssen entweder den teuren Prozess eines weiteren Sprint 0 durchlaufen oder werden häufiger einfach ignoriert.

Eine bessere Alternative ist der Prototypen-Sprint: ein erster Sprint, der das gesamte Team einbezieht, während er tatsächlich den ersten Prototypen selbst erstellt.

Der Prototyp-Sprint-Vision-Prozess

Brainstorming-Ideen werden so schnell wie möglich in einen funktionierenden Prototyp mit geringer visueller Wiedergabetreue übersetzt. Der Prototyp ist in einem funktionalen Front-End-HTML- und CSS-Framework geschrieben, dh in der gemeinsamen Sprache des Teams. Nicht jeder kann ein Datenblatt oder eine Visionserklärung verstehen. Jeder kann eine Website verstehen und die Kommunikation ist einfacher und umfasst ein breiteres Spektrum an Disziplinen.

Am Ende des ersten Sprints ist der Prototyp bereit für erste Tests an mehreren Fronten, einschließlich allgemeiner Benutzerfreundlichkeit, Zugänglichkeit und mobiler Reaktionsfähigkeit. In meinen Teams ist dies ein gültiger und wichtiger erledigter Schritt. Der Prototypen-Sprint produziert auch ein erstes Product Backlog. Wenn Backlog-Elemente in zukünftigen Sprints abgeschlossen werden, gewinnt der Prototyp an Genauigkeit. Der Prototyp ist kein Wegwerfcode – er ist grundlegend.

In manchen Projekten wird während der Produktion des Prototyps eine schriftliche Vision generiert. Aber in vielen Projekten ist der Prototyp die Vision. Es spricht die gemeinsame Sprache des Teams und gerät natürlich nie aus dem Takt mit dem Produkt.

Beispiel

Das folgende Beispiel ist ein funktionierender Prototyp für eine E-Commerce-App, der anhand der groben Skizze in der ursprünglichen Ausschreibung fertiggestellt wurde. So rau es auch ist, es war maßgeblich daran beteiligt, die Energien des Teams in eine produktive Richtung zu lenken und viele potenzielle Ablenkungen und Fallstricke zu überspringen, um sich auf funktionale Kriterien zu konzentrieren.

Ein anfänglicher Prototyp führt oft zu Änderungen an den Anforderungen, die einfach nur beste Vermutungen sind, bis sie im Licht der Benutzererfahrung stehen. Eine der Erkenntnisse, die wir aus dem oben gezeigten Prototypen-Sprint gewonnen haben, ist beispielsweise, dass die Preise und der „Kaufen“-Button ursprünglich viel zu niedrig auf der Seite waren. Der ursprüngliche Wunsch war, sie unter den Produktinformationen und über den Empfehlungen zu platzieren, aber ein funktionaler Prototyp zeigte schnell, dass die Hierarchie nicht sehr funktional war.

Eine weitere Funktion, die ans Licht kam, war, dass die Galeriebilder ursprünglich groß sein und sich über die gesamte Breite der Seite erstrecken sollten. Anstatt den Stakeholdern hypothetische Gründe darzulegen, warum dies nicht funktionieren würde, konnte der Prototyp die Probleme in einer gemeinsamen Sprache demonstrieren, die das gesamte Team versteht. In einer Power-Session mit Stakeholdern haben wir diese Seite schnell in eine allgemein anerkannte Hierarchie umstrukturiert.

Da der Prototyp zugänglich und reaktionsschnell geboren wird, können wir sofort mit dem Testen auf mehreren Geräten und Technologien beginnen. Obwohl das Design (falls man das in diesem frühen Stadium überhaupt so nennen kann) absichtlich Low-Fidelity gehalten ist, war sofort ersichtlich, dass die Jahreswechsel-Meldungen auf dem Desktop auf Mobilgeräten zu groß waren und die Benutzerfreundlichkeit beeinträchtigten (links). Wir haben den Prototyp schnell aktualisiert, um einen kleineren Switcher im Header zu verwenden (rechts).

Während dieses Prototyp-Sprints traten schnell einige andere Probleme zu Tage:

• Nachdem der Kunde durch die funktionale Navigation geklickt hatte, stellte er sofort fest, dass er eine wichtige funktionale Komponente in seiner Spezifikation vermisst hatte: einen Blog. Dies wirkte sich auf die Schätzung und das Timing aus, aber wir konnten uns schnell anpassen.
• Für das UI-Team war offensichtlich, dass die Preisanzeige zu komplex und verwirrend war. Wir haben mit dem Kunden andere Möglichkeiten erkundet und konnten während des Prototypen-Sprints mehrere Lösungen schnell prototypisieren und anwendertesten.

Anstatt dass die Vision potenziell hinderlich ist oder schon bei Entwicklungsbeginn veraltet, werden in einem Prototypen-Sprint Vision und funktionale Kriterien gemeinsam entwickelt und unterstützen sich gegenseitig. Und da die Vision vom Team generiert wird, gibt es keine Übergabe an das Team, wodurch diese riskante Phase im Entwicklungsprozess praktisch vermieden wird.

Design und der Prototyp-Sprint

In der zweiten Situation – einer fehlenden Integration des Designs in die Entwicklung – wird häufig ein „Design-Sprint“ verwendet. Ich finde diese Richtung sogar noch kontraproduktiver als einen Sprint 0. Die Herausforderungen bei der Integration von Design in einen komplexen Entwicklungsprozess sind real, aber ein Design-Sprint ist ein kontraproduktiver Ansatz. Der Design-Sprint ist ein Pflaster für das Symptom – die Herausforderung, integrierte Teams aufzubauen –, geht aber nicht auf das zugrunde liegende Problem ein – die Herausforderung, die Bedürfnisse der Benutzer zu verstehen und zu erfüllen. Das Frontloading des Designs in einen Sprint vermeidet die Herausforderung der Integration, aber die Vorteile eines integrierten und inkrementellen Designprozesses und das Fenster, das sich öffnet, um Benutzer zu verstehen und zu erreichen, gehen vollständig verloren.

Der Prototypen-Sprint, den ich in No-Handoff-Projekten verwende, ist eine produktive und vollständig agile Alternative zum Design-Sprint. Es ist kollaborativ und führt UI/UX und Entwicklung von den frühesten Phasen des Projekts an zusammen. Selbst das erfahrenste Designteam kann von der Einbeziehung anderer Disziplinen profitieren, und vor allem stellt es sicher, dass sich Code- und Designziele nicht widersprechen.

Oftmals soll der Design Sprint auch die Vision konkretisieren. Dies ist ein verzweifelter Schritt, der auf einem vagen, aber aufschlussreichen Verständnis basiert, dass der Designprozess besser dafür geeignet ist, Visionen zu generieren als die Entwicklung. Eine vom Design generierte Vision ist jedoch ein schlechter Ersatz für eine echte, kollaborative, teamweite Anstrengung.

Die armen Designer müssen ohne die fachübergreifenden Informationen, die erforderlich sind, um diese Bemühungen wirklich wertvoll zu machen, ein Endprodukt erstellen, um die Entwicklung anzukurbeln. Obwohl ein Designer mit technischem Wissen und mehr Erfahrung eine bessere Chance hat, dies richtig zu machen, ist es immer noch sehr riskant. Da es am Ende der Phase kein potenziell lieferbares Produkt gibt, um es gegen die Vermutungen zu testen, geht es weiter in die Entwicklung. Wenn das Design nicht ins Schwarze getroffen hat oder wenn sich die Spezifikationen ändern, kann dies zu langen Verzögerungen führen, wenn es an das Designteam zurückgeht. Agilität ist im Kern ein Risikomanagementprozess, und wir können etwas Besseres tun, als unsere agilen Projekte mit einem von Natur aus riskanten Design-Sprint zu beginnen.

Der Prototyp-Sprint-Designprozess

Die wichtigste Änderung gegenüber einem traditionelleren Design-Sprint besteht darin, dass das Team während des Prototypen-Sprints direkt vom Papier zum Prototypen übergeht und die Verwendung von Sketch, InVision, Photoshop oder anderen digitalen Layoutprogrammen überspringt. Sie fungieren in dieser Phase als visuelle Krücke und scheinen sehr schnell Wert zu schaffen (weil gute Designer gut aussehende Dinge herstellen), aber der wahre Wert eines High-Fidelity-Mockups in diesem frühen Stadium ist sehr gering, während die potenzielle Gefahr, die es mit sich bringt – Hochzeitsbeteiligte zu den falschen Lösungen – ist hoch.

Diese Tools eignen sich am besten für High-Fidelity-Flat-Mockups, aber der erste Prototyp ist weder High-Fidelity noch Flat. Whiteboard und Bleistift und Papier lassen das Team Ideen schnell durcharbeiten, ohne an sie gebunden zu sein. Dann setzen Sie dieses Denken so schnell wie möglich in einen funktionsfähigen Prototyp um.

Jedes Teammitglied, einschließlich der Designer, sollte den Prototypen direkt in Lo-Fi-Phasen kennenlernen und bearbeiten können. Aber wenn das nicht möglich ist (oder es ein längerfristiges Ziel ist und Sie jetzt vorankommen müssen), dann ist ein paarweiser Ansatz, bei dem ein Designer und ein Entwickler Seite an Seite arbeiten, gut. Skizzen können vom Designer beschrieben und vom Entwickler gemeinsam interpretiert werden, wodurch ihr gemeinsames Verständnis für jeden Standpunkt erweitert wird.

Beispiel

Das folgende Beispiel zeigt unseren Prozess, der eine gründliche Analyse einer bestehenden Website direkt in einen funktionsfähigen Prototyp destilliert. Es ermöglichte die Auswertung der Ergebnisse des Berichts in einer nativen Webumgebung, eine ganz andere Erfahrung als die intellektuelle Analyse von Empfehlungen in einem gedruckten Dokument:

Außerdem ist der Funktionsprototyp im Gegensatz zum ausführlichen Analysedokument (so hilfreich es auch war) frei von Fachjargon und verwendet eine gemeinsame verbale und visuelle Sprache, die jeder verstehen kann. Es öffnet das Gespräch auf einer visuellen Anzeige für alle Teammitglieder und Disziplinen.

Unsere Hauptfrage beim Erstellen dieser Vorlage war, wie viele Designdetails enthalten sein sollten. Da wir auf ein reichhaltiges Dokument voller Analysen zurückgreifen konnten, hätten wir den Prototyp weiter entwickeln können. Aber im Hinterkopf behaltend, dass Bildmaterial schnell (und unbeabsichtigt) aus dem Bereich der Idee in den Bereich der Fakten wechseln kann, haben wir das Layout unverbindlich gehalten und das Dokument auf seine wesentlichen Elemente und seine Bedeutung reduziert.

Interne Tests haben uns auf den Weg zu einer stärker benutzerorientierten Lösung gebracht, indem wir viele potenzielle Probleme übersprungen haben, aber wir haben es bewusst vermieden, so früh im Prozess verfeinerte Designentscheidungen zu treffen. Es ist wichtig, alle Ideen und Vorschläge, einschließlich der des Kunden, ständig gegen bekannte Daten abzuwägen und sich daran zu erinnern, dass unser Wissenspool zu diesem Zeitpunkt kleiner ist als in jeder anderen Phase des Projekts.

Ein weiterer Grund, warum es wichtig ist, den anfänglichen Prototyp lo-fi zu halten und keine „Design“-Elemente einzubeziehen, ist, dass das Team-Buy-in durch irrelevante visuelle Elemente entgleisen kann, die unbeabsichtigte viszerale Reaktionen hervorrufen. Wir verzichten auf Farbe und verzichten sogar auf das Kundenlogo (stattdessen ein Leerzeichen oder ein hellgraues Kästchen als Platzhalter). Das Gespräch muss kontinuierlich an funktionalen Kriterien wie Inhaltshierarchie, Zugänglichkeit, Benutzerfreundlichkeit, Sprache und Bedeutung orientiert werden. Versichern Sie dem Team, dass die „lustigen Sachen“ kommen werden, aber nicht in diesem frühen Stadium.

Tatsächlich ist es ein wichtiges Ziel eines erfolgreichen Prototypen-Sprints, so wenig Designentscheidungen wie möglich im Voraus zu treffen. Erfolgreiches Design wird von der Benutzererfahrung gespeist, also lassen Sie Zeit für entstehendes Projektwissen, um die Benutzeroberfläche zu informieren.

Wann ist der Prototyp-Sprint abgeschlossen?

Der Sprint ist abgeschlossen, wenn der Prototyp und die begleitenden Artefakte vom gesamten Team (einschließlich des Kunden) genehmigt wurden und der Prototyp als bereit für erste Tests auf Benutzerfreundlichkeit und Barrierefreiheit gilt.

Ein früher funktionaler Prototyp erweckt die Projektvision durch Skalierung (Anzahl der Seiten, Umfang der Navigation und andere Hauptelemente der Benutzeroberfläche), zukünftige Komplexität (Platzhalterinhalt mit nützlichen Deskriptoren, möglicherweise einige frühe Funktionen codiert) und Identifizierung von Anforderungen (bestimmte benötigte Technologien) zum Leben , wo sie bereitgestellt werden, alle Abhängigkeiten). Entscheidungen bezüglich Tools, Arbeitsumgebung und Code-Stack werden mit dem Input des gesamten Teams getroffen.

Das Erreichen dieses erledigten Inkrements kann für ein erfahrenes Team mit einem reaktionsschnellen Kunden nur einen Tag dauern, dauert jedoch normalerweise etwa eine Woche und nicht mehr als zwei Wochen. Prototyp-Sprints sollten sich schnell bewegen, und das Überschreiten des zweiwöchigen Zeitrahmens kann ein Warnsignal sein. Es kann bedeuten, dass andere Probleme im Spiel sind.

Einige häufige Probleme, auf die Sie während eines Prototyp-Sprints achten sollten

Einige häufige Probleme, auf die Sie bei der Implementierung des Prototyp-Sprints achten sollten, sind:

• Umarmen Sie den Wert von Low-Fidelity und vermeiden Sie die Betonung der Optik. Seien Sie wachsam in Bezug auf diesen Punkt, da Teams, denen dieser Ansatz neu ist, möglicherweise Hilfe und Bestätigung benötigen, wenn sie über „Wo ist das Logo“ hinausgehen und sich auf tiefere Fragen zu Funktionalität und Hierarchie konzentrieren.
• Eine andere Facette des oben Gesagten: Achten Sie auch darauf, sich nicht an Ihre eigenen Design-/Layout-Ideen zu binden. Es ist hilfreich, sich bei Prototypen-Sprints daran zu erinnern, dass nichts Wertvolles generiert wird, und von den Endergebnissen losgelöst zu bleiben. Außerdem ist es ein weiterer Grund, die Prototypen minimal und ehrlich gesagt ziemlich hässlich zu halten. Es dient dem Zweck, die Benutzer getrennt zu halten.
• Eine frühzeitige Übernahme des Prozesses durch die Führung ist von entscheidender Bedeutung . Da das gesamte Team beteiligt ist, müssen Ihr Kunde, Ihr Chef und die Entwickler den Prozess mit ihrem Engagement, ihrer Kreativität und ihrer Zeit unterstützen und fördern. Sei kein einsamer Cheerleader, dein ganzes Team muss mit den Pompons schwenken!
• Schlechte Kommunikation ist die Achillesferse jeder Teamarbeit . Der Prototyp-Sprint löst keine hartnäckigen Kommunikationsprobleme, bringt sie aber früher zum Vorschein, da das gesamte Team fast sofort in einen kollaborativen Workflow eintaucht. Alle bereits bestehenden Kommunikationsprobleme werden früh und oft in einem Prototyp-Sprint auftauchen, während Sie auf einen Konsens und Ihr erstes fertiges Inkrement hinarbeiten. Nutzen Sie die Gelegenheit zur Verbesserung der Kommunikation und binden Sie das gesamte Team ein, um Lösungen zu finden.
• Wählen Sie das richtige Front-End-Framework . Wenn Sie noch keines haben, müssen Sie möglicherweise verschiedene Front-End-Frameworks ausprobieren, bevor Sie eines finden, das mit dem Workflow Ihres Teams funktioniert. Ich empfehle, sich mit minimalen Frameworks wie Fomantic oder Bulma zu beschäftigen und sich nicht mit Schnickschnack zu verzetteln. Das richtige Framework ist jedoch immer das, das für Ihr Team funktioniert.
• Das UI/UX-Team muss ein Komfortniveau mit und Zugriff auf das Front-End-Framework entwickeln . Idealerweise arbeiten sie direkt am Prototyp, wodurch unnötige Übergaben und die Notwendigkeit der Übersetzung von einem Medium in ein anderes (dh von der Skizze zum Prototyp) vermieden werden. Wenn Ihr Front-End-Team nicht mit CSS und HTML vertraut ist, funktioniert auch ein paarweiser Ansatz (mit einem Designer und einem Programmierer, die gemeinsam am Framework arbeiten) gut.
• Denken Sie zu guter Letzt daran, dass Sie als Team besser und schneller werden ! Das Ausführen eines produktiven Prototyp-Sprints ist eine Fähigkeit, die mit der Übung wächst.

Was passiert als nächstes

Das fertige Inkrement des ersten Sprints – der funktionale Low-Fidelity-Prototyp – bildet die Grundlage für alle folgenden Sprints. Mit einem funktionierenden Prototyp können Benutzertests auf Benutzerfreundlichkeit, Zugänglichkeit und Reaktionsfähigkeit sofort beginnen und sicherstellen, dass zukünftige Sprints von UX informiert werden.

Der Prototypen-Sprint ist ein guter Start für jeden Scrum-Prozess, aber in meinen Projekten besteht unser nächster Schritt darin, zu einem zweigleisigen Workflow überzugehen, bei dem UI/UX einen halben oder ganzen Sprint vor der Entwicklung arbeitet, um den Prototyp zu entdecken und visuell zu aktualisieren neue Erkenntnisse widerspiegeln.

Der Prototyp entwickelt sich organisch und wird immer raffinierter, gespeist aus UX-Forschung und realistischen Funktionsanforderungen. Diese Informationen, die während des Prototypen-Sprints nicht verfügbar waren, tauchen erst im Laufe des Projekts inkrementell auf. UI/UX und Entwicklung fließen durch den zweigleisigen agilen Prozess in die Arbeitsabläufe des jeweils anderen ein.

Es gibt keine Übergabe des Designs an die Entwicklung, die erstellt werden soll, oder eine entwickelte App, um das Design an die Oberfläche zu bringen. Stattdessen bindet der Prototyp-Sprint die gesamte Gruppe von Anfang an ein und bildet eine starke Grundlage für einen kollaborativen agilen Workflow während des gesamten Projekts.

Die Leitvision, die sich aus einem Prototyp-Sprint ergibt, wird nicht perfekt sein und sich wahrscheinlich ändern, wenn mehr gelernt wird, aber die Erkenntnis, dass wir zu Beginn weniger wissen als in jeder anderen Phase eines Projekts, ist das Herzstück des agilen Arbeitsablaufs. Wenn wir dieselbe Philosophie auf die Entstehung der Projektvision und des Designs durch einen Prototypen-Sprint anwenden, ist das Ergebnis ein umsetzbares fertiges Inkrement, wirklich nützliche Artefakte, gemeinsame Zustimmung und ein Muster von Teamarbeit und Zusammenarbeit, das während des gesamten Projekts aufrechterhalten werden kann .

Ein Hinweis zu Agentureinstellungen

Wenn Sie in einer Agentur arbeiten, denken Sie vielleicht, dass sich dieser Ansatz schwer verkaufen lässt. Leider hast du wahrscheinlich recht. Viele Agenturen sind von Natur aus nicht agil und streben aktiv nach einer vollständigen Projektübergabe, oft mit offizieller Abnahme und sorgfältig dokumentierten Auswirkungen auf spätere Änderungen. Sich für einen Prototyp-Sprint in einer nicht agilen Organisation einzusetzen, ist ein Fehlstart: Es liegt einfach nicht in ihrer DNA. Sobald eine Organisation agile und interdisziplinäre Teams einsetzt, kann sie leicht überlegen, ob der Prototyp-Sprint ohne Übergabe ihren Prozess verbessern wird.

Fazit

Sprint 0 und Design-Sprints adressieren echte Herausforderungen, mit denen viele Scrum-Teams konfrontiert sind: fehlende Vision, fehlendes integriertes Design oder beides. Sie sind verständliche und logische Antworten, aber sie bieten keinen hohen Wert oder tragen nicht zu starken agilen Teams bei.

Sie durch einen Prototyp-Sprint zu ersetzen, ist ein praktischer Weg, um die Nachteile von Sprint 0 zu beheben und Sprints zu entwerfen, während gleichzeitig die Grundlage für eine stärkere agile Zusammenarbeit in zukünftigen Sprints gelegt wird.

Ein Prototyp-Sprint nutzt die Talente des gesamten Teams, generiert die notwendige Vision, führt zum ersten fertigen Inkrement des Teams und vermeidet Projektübergaben. Durch diesen Prozess bauen die Teams eine gemeinsame Verantwortung für die Projektvision und eine stärkere Grundlage für die interdisziplinäre Zusammenarbeit im agilen Geist auf.

Weiterführende Literatur zu SmashingMag:

• Ein besserer Facilitator werden
• Anpassung von Agile für Teilzeitteams
• Die Bedeutung von Projekt-Retrospektiven
• Bringen Sie einen besseren Designprozess in Ihr Unternehmen