Ohne zeitintensive Vorplanung und mit kleinem Budget

Das Budget begrenzt nicht Ihre Möglichkeiten

Kennen Sie diesen Konflikt? Es gibt eine Produktvision, die zahlreiche Anforderungen erfüllen soll, allerdings ist das Projektbudget begrenzt. Aufgrund des zu kleinem Budget können vorerst nicht alle gewünschten Anforderungen umgesetzt werden. Deshalb muss sinnvoll priorisiert werden. Falls Sie sich nun fragen, ob eine agile Entwicklung in diesem Fall überhaupt möglich sei. Ja, gerade hier kann sich eine agile Entwicklung anbieten. Weshalb das so ist? Lesen Sie selbst.

Herausforderungen

  • Begrenztes und pausiertes Budget
    (Teil sofort, Teil im Jahr darauf)
  • Schwankende Verfügbarkeit der Ansprechpartner
  • Deutlich mehr Anforderungen als Budget

Wie läuft eine agile Entwicklung nach Scrum ab?

Im folgenden Abschnitt möchten wir Ihnen einen kurzen Einblick in den Scrum-Prozess geben. Schauen Sie sich auch gerne das weiter unten verlinkte Video an. In diesem Video wird der Scrum Prozess sehr gut erklärt.

Eine Besonderheit im Scrum ist eine iterative und inkrementelle Vorgehensweise. Das Projekt wird in kurze Zyklen (Sprints) aufgeteilt. Am Anfang eines jeden Zyklus wird die Arbeit, die in diesem Zyklus umgesetzt werden soll, geplant. Nach Ablauf des gemeinsam festgelegten Zeitraums für den Zyklus (höchstens 4 Wochen), werden die Ergebnisse präsentiert und besprochen. Hier bekommen die Entwickler direktes Feedback zu den umgesetzten Anforderungen. Es findet also ein ständiger Lesson Learned Prozess im Projekt statt. Danach wiederholt sich der Ablauf. Es werden neue Anforderungen geplant und für den neuen Zyklus (Sprint) freigegeben. Da die Anforderungen erst hier endgültig definiert und priorisiert werden, können neu erworbene Erkenntnisse und jüngste Entwicklungen jederzeit in die Planung mit einfließen.

Durch die (Neu-)Priorisierung der Anforderungen wird immer das Wichtigste zuerst bearbeitet.

Grundsätzlich wird bei der Umsetzung nach dem Prinzip des MVP (Minimum Viable Product) vorgegangen. Also das minimale Produkt oder die minimale Dienstleistung, die für den Kunden von Wert ist. So wird gewährleistet, dass schnell funktionsfähige Arbeitspakete ausgeliefert werden können und nicht zu lange in eine falsche Richtung entwickelt wird. Verfeinerungen oder Bonusfeatures sind natürlich jederzeit möglich. Je nachdem wie diese Priorisiert werden.

In diesem Video wird die Vorgehensweise nach Scrum sehr gut veranschaulicht:

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Vorteile einer agilen Entwicklung:

 

  • Voller Einblick
    Scrum ist gekennzeichnet durch eine offene Kommunikation und hohe Transparenz. Der PO hat ständigen Einblick in die Entwicklung und kann mitsprechen, indem er dem Dev-Team Feedback zu den vorgestellten Arbeitsergebnissen gibt. Sollte sich etwas in eine Richtung entwickeln, die er nicht als sinnvoll erachtet, kann also noch rechtzeitig entgegen gesteuert werden.

  • Änderungen erwünscht
    Beim agilen Ansatz wird weniger Zeit für eine detaillierte Planung vor dem Projektstart aufgewendet, da während des Projektes fortwährend weiter geplant wird. Daher können die Erkenntnisse nach jedem Sprint (= Teilung des Projekts in kurze Zyklen) in die weitere Planung einfließen. Ihre Software ist somit immer dem aktuellen Stand angepasst (bezüglich Technik, Anforderungen, Unternehmensstruktur etc.)

 

  • Echtes Enduser-Feedback und “Lessons Learned”-Prozess
    Nach jedem Review-Meeting (= Vorstellung und Abnahme der umgesetzten Arbeitspakete) gewinnt der Product Owner (PO= hat die Produkt-Vision und gibt die Aufgaben bzw. die Richtung vor) neue Erkenntnisse und kann damit weiterplanen und neu priorisieren. Durch diese direkte Rückmeldung vom Anwender (=der PO vertritt auch die Interessen der Stakeholder) können gute Ergebnisse erzielt werden und das Produkt kommt dem sehr nahe was wirklich gebraucht wird.

 

  • Dev-Team entwickelt permanent “das Wichtigste zuerst”
    Der Scrum-Prozess sieht eine fortlaufende (Neu-)Priorisierung der Aufgaben vor. Die Entwickler bearbeiten die Aufgabenpakete in der vom PO festgelegten Reihenfolge. So wird immer das Wichtigste zuerst entwickelt. Sollte das Budget knapp werden, wurden dann bereits die wichtigsten Teile zuerst umgesetzt und müssen nicht hinten runterfallen.

 

  •  Lauffähige Produktiv-Version
    Ein weiterer Vorteil ist, dass zum Ende eines jeden Sprints eine lauffähige Produktiv-Version an den Enduser ausgeliefert wird. Deshalb ist es möglich die Entwicklung nach einer gewissen Anzahl von Sprints erstmal zu stoppen und mit der Software zu arbeiten. Zu einem späteren Zeitpunkt können dann die noch offenen Anforderungen neu priorisiert und die Software weiterentwickelt werden. Ein Entwicklungsstopp wäre beispielsweise notwendig, wenn das Budget aufgebraucht wurde oder wenn der PO eine Zeit lang nicht mehr erreichbar ist.

Scrum in Stichpunkten

  • Arbeiten in Zyklen / Iterationen (Sprints, z.B. 14 Tage, 21 Tage oder 28 Tage)
  • Anforderungen werden als sog. Userstories gepflegt.
    • Anforderung aus Benutzersicht in der Form:
      Als ROLLE möchte ich FUNKTION um NUTZEN
    • Ggfs. Beschreibung, um die Anforderung genauer zu formulieren
    • Akzeptanzkriterien, die erfüllt werden müssen
    • Wenn alle Akzeptanzkriterien demonstriert werden können, gilt die Userstory als abgenommen, scheitert (mind.) ein Akzeptanzkriterium, gilt sie als nicht abgenommen
    • Auslegung, wie ein Akzeptanzkriterium erfüllt wird, liegt beim Entwickler.
    • Hat man bestimmte Vorstellungen, müssen sie als Akzeptanzkriterium beschrieben werden. Die Entwicklung erfolgt möglichst eng an den Wortlaut der Akzeptanzkriterien
      • Das steigert die Effizienz
      • Das sorgt für Klarheit, da es die Product Owner erzieht, klare Akzeptanzkriterien zu formulieren
  • Meetings in jeder Iteration:
    • Anfang vom Sprint: Planning 1
      • Neupriorisierung der Reihenfolge der Userstories
      • Vorstellen der Userstories für den nächsten Sprint
      • Abschätzung der Komplexität der Userstories
      • Freigegebene Userstory darf nicht mehr verändert werden (von niemanden)
    • Nach dem Planning 1: Planning 2
      • Das Entwicklerteam unter sich 
      • Im Planning 2 geht es darum wie die Anforderungen umgesetzt werden. Die Entwickler besprechen im Planning 2 technische Details für die Umsetzung und committen sich zu den geplanten Userstories, das bedeutet sie geben ihr Commitment (Zusage) die Userstories im Sprint umzusetzen.
    • Während dem Sprint: Backlog Refinement
      • Es werden neue User Storys, Features und Epics in das Backlog aufgenommen
      • Diese werden dann zusammengefasst oder verfeinert.
      • Es werden Akzeptanzkriterien erarbeitet, die Aufwände abgeschätzt, und evtl. Abhängigkeiten festgestellt.
      • Ein gut vorbereitetes und „refintes“ Backlog ist die Voraussetzung/Grundlage für ein effizientes Planning und trägt zu einem insgesamt effizienteren Scrum-Projekt bei.
      • Neupriorisierung der Reihenfolge der Userstories
    • Ende vom Sprint: Review Meeting
      • Der Entwickler demonstriert dem Product Owner jedes Akzeptanzkriterium.
      • Die fertigen Stories werden vom PO abgenommen, also auf “done” gestellt.
  • Rollen im Scrum-Prozess:
    • Product Owner ⇒ hat die Produkt-Vision
      • Definiert die Anforderungen und Reihenfolge für die Umsetzung.
      • Wird meist vom Kunden übernommen
      • vertritt die Interessen der Stakeholder
    • Stakeholder
      • haben ein (wirtschaftliches) interesse am Produkt
    • Agile Coach (=Scrum Master)
      • sorgt für die Einhaltung der Prozesse sowie die Effizienz des Teams
    • Dev Team (= Entwicklerteam)
      • entwickeln gemeinsam am Projekt, d.h. sie setzen die User Stories im Backlog um
      • eruieren gemeinsam die technischen Umsetzungsmöglichkeiten und helfen sich gegenseitig bei Schwierigkeiten

Fazit

Generell ist eine agile Entwicklung auch mit einem kleinen Projektbudget möglich. Eine Software ist quasi nie fertig entwickelt. Es wird immer Anforderungen geben, die noch umgesetzt werden können. Meist zwingen die Rahmenbedingungen wie ein Zeit- oder Budget-Limit zum Aufhören. Durch die kleinen in sich geschlossenen Arbeitspakete sind Entwicklungspausen in Scrum gut möglich. Natürlich unter der Berücksichtigung, dass das Budget für die Entwicklung der ersten grundlegenden Funktionen der Software sichergestellt ist, sodass mit der Software gearbeitet werden kann. Hierbei ist es wichtig, dass die Anforderungen mit dem höchsten Wert zuerst in der Software abgebildet werden. Dies wird im Scrum Prozess gut berücksichtigt. Wenn der Scrum-Prozess richtig eingehalten wird, werden die Anforderungen immer wieder neu priorisiert und damit immer das Wichtigste zuerst entwickelt.

Haben auch Sie eine Produkt-Vision in Ihrem Kopf? Wir würden uns freuen sie zu hören. Sprechen Sie uns gerne ganz unverbindlich an.