Archiv der Kategorie: Agile

Agile Missverständnisse: Den Sprint abnehmen

Veröffentlicht am von
3

Alles wurde fertig entwickelt, und mit etwas abendlicher Arbeit und ein paar Kompromissen bei der Qualität konnte man tatsächlich alles liefern, was im Sprint enthalten war. Im Review stellt man die entwickelten Features vor, die Entwickler zeigen die Storys, an denen sie gearbeitet haben. Es werden die Akzeptanzkriterien durchgegangen und am Ende jeder Story wird gefragt, ob das so in Ordnung ist. Dann nimmt der Product Owner die Story ab, und damit ist bestätigt, dass sie umgesetzt wurde. Das Ganze wird formal dokumentiert – im Ticketing oder im Wiki – und am Ende gibt es ein Protokoll der Veranstaltung.

Das ist praktisch für das Team: Diese Stories sind fertig, bis auf Bugfixes und neue Features wird man von ihnen wenig hören. Endlich etwas geschafft.

Weiterlesen →

4 Tipps für besseres Feedback in Sprint Reviews

Veröffentlicht am von
5

Als Scrum Master habe ich schon an sehr vielen Sprint Reviews teilgenommen und mir dabei oft die Frage gestellt: „Wie bekomme ich mehr und brauchbareres Feedback im Review?“

In diesem Blogpost möchte ich meine Erfahrung teilen und zeigen, wie nützliches Feedback gefördert werden kann. Außerdem werde ich meine Fehler nennen, die dazu führten, dass kein brauchbares Feedback gegeben wurde.
Weiterlesen →

Agile Missverständnisse: Sprintabbruch durch das Team

Veröffentlicht am von
3

Es haben sich grundlegende Rahmenbedingungen geändert. Das Team stellt überraschend fest, dass das Sprintziel bei näherer Ansicht nicht mehr zu erreichen ist. Drei Tage vor Ende des Sprints ist deutlich sichtbar, dass der Forecast nicht annähernd erreicht werden kann.

Für das Team ist die Sache klar: Unter diesen Bedingungen kann man nicht mehr die Verantwortung für den Sprint übernehmen. Ähnlich sieht es der Scrum Master – so ist es nicht möglich, den Sprint weiterzuführen, er muss abgebrochen werden. Also trifft man sich in der Mitte des Sprints in einer spontan einberufenen Retro und bricht den Sprint offiziell ab, weil es ja nicht anders geht.

Weiterlesen →

Agile Missverständnisse: Druck & Stress

Veröffentlicht am von
4

Der Scrum Master muss das Team schützen! Deadlines erzeugen zu viel Druck für das Team! Und Überstunden darf es nicht geben!

Schaut man sich die Diskussionen in agilen Unternehmen an, entsteht schnell der Eindruck, dass die Entwickler-Teams sehr zart besaitet sind und es ihnen an Kraft und Resilienz fehlt, auch mit den kleinsten Störungen umzugehen.

Weiterlesen →

Agile Missverständnisse: Akzeptanzkriterien und andere Details

Veröffentlicht am von
4

„Das stand nicht in den Akzeptanzkriterien, das musste ich nicht machen.“ „Es stand doch in den Akzeptanzkriterien, dass der Styleguide gilt. Und der sagt ganz klar auf Seite 12, dass Buttons linksbündig floaten müssen.“ „So kann ich nicht anfangen, da fehlen ja noch alle Details.“ „Da versucht das Product Management uns mal wieder zu erklären, wie Technik geht.“

Akzeptanzkriterien und andere Details

Wir alle kennen die Schmerzen, wenn es um die Formulierung von User-Storys geht. Je nach Unternehmen, Abteilung und Person ist alles möglich: Zwischen Akzeptanzkriterien, die aus einem einzigen Wort bestehen, und seitenlangen Dokumenten mit hunderten Querverweisen, von denen ohnehin niemand davon ausgeht, dass sie wirklich gelesen oder geprüft werden können, ist alles denkbar.

Weiterlesen →

Warum du das Spotify Modell nicht kopieren solltest

Veröffentlicht am von
3

Ich schätze Klaus Leopold, Kanban Pionier und Special Guest unseres Product Owner Camp 2017, sehr. Daher habe ich auch den Newsletter von LEANability abonniert. In der neuesten Ausgabe gab es ein kleines Video-Interview mit Cliff Hazel, Coach Chapter Lead bei Spotify. Dort wurde auch die Frage beantwortet, ob Unternehmen das Spotify Organisations-Modell (Chapters, Guilds etc.) für sich kopieren anwenden sollten oder nicht.

Weiterlesen →

Agile Missverständnisse: DoR & DoD als Vertrag

Veröffentlicht am von
7

Mit der Definition of Ready vereinbart das Team mit dem Product Owner, woran man eine gute User-Story erkennt. Analog dazu die Definition of Done: Woran macht man fest, dass eine Story erledigt ist? Eigentlich praktische Werkzeuge, hat man doch endlich mal eine Größe, an der man die Eignung einer Story für die Entwicklung oder Produktion erkennen kann.

DoR & DoD als Vertrag

In der Praxis schlägt diese Orientierung jedoch oft über diese Intention hinaus. Die erste Definition of Ready wurde beschrieben als der Moment, an dem das Team sagt „Ah, ich habe es verstanden.“

Weiterlesen →

Vom „Geheimbund der transparenten Gehälter“ zu einem neuen Gehaltsworkflow

Veröffentlicht am von
3

Bereits 2015 reifte in den Köpfen einiger Kollegen die Idee von „transparenten Gehältern“. Doch es gab Widerstände unter dem Rest der Crew. Also bedienten wir uns eines „Kultur-Hacks“: In einer Bierlaune gründeten wir den „Geheimbund der transparenten Gehälter“. Alle Mitglieder, die durch Unterschrift auf die „Magna Carta“ aufgenommen wurden, verpflichten sich, innerhalb des Geheimbundes ihre Gehälter offen zu legen, nach außen jedoch absolutes Stillschweigen zu bewahren.

Der Geheimbund der transparenten Gehälter

Diese Geschichte spielte sich im Wiki unserer Firma ab. Jeder sah was da gespielt wird, die Gehälter-Seite war aber nur den Mitgliedern zugänglich. Wir hatten angeregte Diskussionen, mit reger Beteiligung.

Weiterlesen →

10 Dinge, die Entwickler an (JIRA-)Tickets schätzen

Veröffentlicht am von
6

Im letzten Monat habe ich auf dem PO-Camp darüber gesprochen, welche Bestandteile und Prinzipien aus Entwickler-Sicht für gute (JIRA-)Tickets erforderlich sind. Die gesammelten Anforderungen basieren auf der einen Seite auf kurzen Interviews mit Entwickler-Kollegen, die ich im Rahmen unserer Slacktime durchgeführt habe („Was machen für Dich gute JIRA-Tickets aus?“). Zum anderen fließen aber auch meine persönliche Erfahrung als Entwickler und Team-Mitglied, das relativ viel mit dem Kunden kommuniziert, mit ein.

Herausgekommen sind 10 Punkte, die sich auf das Format, den Inhalt und die Rahmenbedingungen, unter denen das Team mit den Tickets arbeitet, beziehen. Weiterlesen →

Kanban Anti-Pattern: der Kanban-Modus

Veröffentlicht am von
10

Die Situation kommt vielleicht bekannt vor: Das Scrum-Team rückt einer Deadline näher, der Scope ist noch immer groß und die Projektbeteiligten machen sich Sorgen, ob denn die Deadline zum geplanten Release gehalten werden kann. In so einer Situation gibt es verschiedene Herangehensweisen, um erfolgreich zu sein.

Ich war Scrum Master eines Teams, das sich entschlossen hat, in dieser heißen Phase in den sogenannten Kanban-Modus zu wechseln. In diesem Blogpost möchte ich beschreiben, was sich das Team davon erhofft hat, was wir dabei gelernt haben und ob wir damit die Deadline halten konnten.
Weiterlesen →