Agiles Projektmanagement mit Scrum fĂŒr Agenturen đŸ‡©đŸ‡Ș

Scrum, so ganz grundsĂ€tzlich, ist eine Methodik fĂŒr agiles Projektmanagement. Ich sage bewusst Projektmanagement und nicht Softwareentwicklungsprozess, da ich der Meinung bin, dass man nicht nur die Entwicklung von Software so managen kann. Deshalb, und da wir als Digitalagentur sehr integriert unsere Kunden betreuen, sind bei uns vor allem die Definitionen der Rollen etwas anders als bei einem reinen technischen Dienstleister.

Ich möchte mit dem Beitrag auch ĂŒberhaupt einmal die Basis fĂŒr Scrum legen, damit bei den bald folgenden Artikeln ĂŒber agile Planung und agile Kalkulation auch jeder mitkommt, der Scrum bisher noch nicht kannte.

Philosophie

Scrum versucht, das Management der KomplexitÀt zu strukturieren:

  • Zerlegung: Der Weg zur Lösung wird in einzelne gut ĂŒberprĂŒfbare Schritte zerlegt.
  • Transparenz: Der Fortschritt und die Hindernisse eines Projektes werden tĂ€glich und fĂŒr alle sichtbar festgehalten.
  • ÜberprĂŒfung: In regelmĂ€ĂŸigen AbstĂ€nden werden ProduktfunktionalitĂ€ten geliefert und beurteilt.
  • Anpassung: Die Anforderungen an das Produkt werden nicht ein und fĂŒr alle Mal festgelegt, sondern nach jeder Lieferung neu bewertet und bei Bedarf durch weitere Iteration angepasst.

Die Rahmenbedingungen

  • 1 Verantwortlicher auf Kundenseite, der das Feedback kanalisiert und fĂŒr das Projekt verantwortlich ist. Der sogenannte Product Owner.
  • 1 Account Manager, der wĂ€hrend dem Sprint das Projekt mit dem Kunden durchgeht und stĂ€ndiger Ansprechpartner ist. Normalerweise ist das der sogenannte Scrum Master. Da das bei den meisten Projekten bei uns aber nicht eine volle Stelle ausfĂŒllt und die Kunden ohnehin schon einen Account Manager haben, welcher auch Strategie und Community kennt, ĂŒbernimmt dieser bei uns diese Funktion. FĂŒr Einhaltung und Moderation des Scrum Prozesses bin dann ich als CTO dabei.
  • 1 festes Team auf dem Projekt.

Sprint

  • Ein Sprint ist eine einzelne Zeiteinheit, in der das Produkt entwickelt wird und fĂŒr die “vorausgeplant” wird.
  • Die Dauer eines Sprints kann individuell bestimmt werden. GĂ€ngig sind 1 oder 2 Wochen.
  • Die Dauer eines Sprints sollte immer gleich lang sein.
  • Zum Start jedes Sprints steht ein Jour Fix als Sprintplanung.
  • Nach jedem Sprint ist eine lauffĂ€hige Version der Software online.

User Story

  • Eine User Story (“AnwendererzĂ€hlung”) ist eine in Alltagssprache formulierte Anforderung.
  • Sie ist bewusst kurz gehalten und umfasst in der Regel nicht mehr als zwei SĂ€tze.
  • Der Autor der Story sollte der Kunde des Software-Projektes sein.
  • Die User Story ist die wichtigste Methode, um ein agiles Projekt zu steuern.

“Als <Rolle> möchte ich <Ziel/Wunsch>, um <Nutzen>

Beispiele:

Anwendung starten: Die Anwendung startet, indem sie das zuletzt bearbeitete Dokument des Anwenders öffnet, damit der Anwender Zeit spart.
Anwendung schließen: Wenn der Anwender die Anwendung beendet, erscheint eine Anfrage, ob das bearbeitete Dokument gespeichert werden soll, damit Änderungen nicht verloren gehen.
Anwendung starten: Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.

Beispiele und Definition von Wikipedia.

Produkt Backlog

Das Produkt Backlog ist eine priorisierte Liste, die alles enthÀlt, was in dem fertigen Produkt enthalten sein sollte.

  • Neue Anforderungen in Form von User Stories
  • Bugs
  • Technische und organisatorische Tasks

Alles was aufkommt, wird vom Team und vom Kunden erst mal ins Produkt Backlog eintragen und bei der nÀchsten Sprint-Planung geschÀtzt und priorisiert.

Hier ist ein fiktives Beispiel:

Sprintplanung und Sprint Backlog

In der Sprintplanung wird definiert, was im Sprint passiert. Der Kunde bestimmt, welche Items vom Produkt Backlog in den Sprint Backlog kommen. So wird die PrioritĂ€t jederzeit vom Kunden gesteuert.

  • Das Team schĂ€tzt den Aufwand der User Stories in Punkten (z.B.1 – 3)
  • BeschrĂ€nkung des Aufwands auf z.B. 10 Punkte pro Sprint. (AbhĂ€ngig von TeamgrĂ¶ĂŸe)
  • Bugs kosten keine Punkte sondern mĂŒssen selbstverstĂ€ndlich behoben werden und kommen immer in das Sprint Backlog.
  • Jederzeit optimierung, was am meisten Business-Value generiert.

Fazit und Vorteile

Wir können direkt morgen anfangen, denn ein komplexes Projekt wird nicht noch komplexer geplant.

(Mein Hauptargument)

Man weiß ja heute nicht genau, was morgen sein wird. Deshalb setzt man besser enge Korridore (Sprints) um kontinuierlich kleine PlĂ€ne “auf Sicht” zu schmieden. So entsteht garantierter Business-Value, da wir spĂ€testens nach 2 Wochen abgleichen, ob wir gerade den maximalen Wert fĂŒr den Kunden schaffen. So entstehen auch keine ĂŒbermĂ€ĂŸigen Korrekturschleifen am Ende, da alles direkt gefeedbackt wird. Ganz nebenbei bietet es eine leichtere EinschĂ€tzung des Entwicklungsprozesses und sorgt so fĂŒr Transparenz, auch bei Nichttechnikern. Und mitunter das wichtigste dabei ist: Es ist jederzeit eine lauffĂ€hige Version online.

Das geht ĂŒbrigens auch fĂŒr nicht-technische Projekte, wie z.B. Strategieentwicklung ziemlich gut.

Join the Conversation

3 Comments

  1. I’m not sure the place you’re getting your info, however
    great topic. I needs to spend a while finding out much more or figuring out more.
    Thank you for wonderful information I was in search of this information for my mission.

Leave a comment

Your email address will not be published. Required fields are marked *