Geschrieben am

„Lass uns ein Meeting machen!“

conference-table-24030335

„Lass uns ein Meeting machen!“

Aus aktuellem Anlass unterbreche ich mal die Serie über die esoterischen Anforderungen und schiebe mal einen Rant über die Meeting-Unkultur im Bereich Requirements Management ein. Wie üblich, muss Paul für die Einleitung herhalten:

Product Owner Paul kommt kurz nach Sprintanfang gut gelaunt über den Flur. Seine Tasse mit heißem Kaffee duftet verführerisch. Gestern das Sprint Planning lief super. Er freut sich darauf, heute mal Dinge nacharbeiten zu können, die in den letzten paar Tagen wegen der Vorbereitungen auf das Sprint Planning liegen bleiben mussten.

Leider kommt er nicht weit.

Als er an Scrum Master Simons Büro vorbeikommt, kommt ihm ein hektischer Simon entgegen gesprungen:

„Wir haben ein Problem mit den Anforderungen. Wir wollten heute mit dem Top Prio Sprint Backlog Item anfangen. Aber wir haben da im Sprint Planning völlig was übersehen! Keine Ahnung, wie das passieren konnte! Aber so wie wir uns das gedacht haben, funktioniert das hinten und vorne nicht! Was sollen wir tun?“

„Ok, wir müssen das lösen. Lass uns ein Meeting machen!“

„Ok, wer lädt ein?“

„Du.“

„Ok. Wer soll alles mit dazu?“

„Weiß nicht. Am besten einfach alle. Jetzt gleich. Blocke uns 4 Stunden.“

Es kommt, wie es kommen muss: Von den 24 Personen sagen 20 Personen 4 Stunden lang so gut wie gar nichts. Die übrigen 4 Personen reden teilweise über technische Lösungen, prozessuale Lösungen, Umgehungen, die Schuldfrage und grundsätzliche Erwägungen, um nie mehr in eine solche Situation zu kommen. Das Fazit am Ende der 4 Stunden:

  • Mehrere Lösungsmöglichkeiten, keine Entscheidung für oder gegen eine davon.
  • Folglich keine vergebenen Arbeitsaufträge.
  • Keine Entscheidung über das weitere Vorgehen zur Lösungsfindung.
  • 24 × 4 h = 96 h vertane Zeit. Bei einem ungefähren internen Stundensatz von 50 € also ca. 5.000 €.

Was ist schief gelaufen?

„Lass uns ein Meeting machen!“ weiterlesen

Geschrieben am

Verwechslungsgefahr — Projektanforderungen vs. Produktanforderungen

projektplan_speicher

Achtung Verwechslungsgefahr!

In meinen Trainingsveranstaltungen kommt immer wieder die Frage auf, warum es denn nicht sinnvoll ist, Projektaspekte  wie bspw.

  • Meilensteine,
  • Kosten,
  • benötigte Mitarbeiter oder
  • Deadlines

gleich zu Anfang des Projekts mit in das Lastenheft des Produkts hineinzunehmen. Gerne sogar als Anforderungen kenntlich gemacht.

Das Argument ist, dass der Leser dann alles direkt an einer Stelle vorfindet und auch die Brisanz des Ganzen direkt anhand der genannten Zeitabläufe und Kostenrahmen einzuschätzen lernt.

Ich spreche mich da immer aus den folgenden Gründen vehement dagegen aus: Verwechslungsgefahr — Projektanforderungen vs. Produktanforderungen weiterlesen

Geschrieben am

Stakeholder — von guten und von pathologischen Vertretern ihrer Zunft

stakeholders

Stakeholder Management ist eine der spannendsten Disziplinen im Requirements Engineering. Wenn man es mal kurz und sarkastisch formulieren will, geht es um nichts anderes als herauszufinden, wen ich wie ernst nehmen muss von den zig Leuten, die mit mir (in meiner Rolle als Requirements Autor) reden wollen.

Bei vielen davon bin ich mir natürlich sicher, dass ich ihren Input in jedem Fall ernst nehmen muss. Bei anderen wiederum weiß ich, dass sie sich nur mit nett gemeinten Hinweisen an mich wenden.

Auch die umgekehrte Frage ist spannend: Welcher Stakeholder hat sich bei mir noch gar nicht gemeldet und ich muss aktiv auf ihn zugehen?

Wie für so vieles gibt es natürlich auch hier eine Norm, die uns bei der Suche nach den Stakeholdern weiterhilft, hier ist es die DIN ISO 100006, die folgendes dazu zu sagen hat:

Stakeholder eines Projektes sind alle Personen, die ein Interesse am Projekt haben oder von ihm in irgendeiner Weise betroffen sind.

Bin ich als Requirements Manager auf der Suche nach meinen Stakeholdern — also nach denjenigen Personen oder Parteien, denen ich Einfluss auf meine Spezifikationsdokumente geben möchte, dann wähle ich meist einen Ansatz nach diesen beiden Checklisten: Stakeholder — von guten und von pathologischen Vertretern ihrer Zunft weiterlesen