Wie letztens versprochen, geht es weiter in unserer Scrum-Runde mit den im Framework beschriebenen Meetings. Jetzt denkt so mancher bestimmt: “Diese sogenannten Meetings produzieren doch nur Overhead, wir verschwenden jetzt schon viel zu viel Zeit in diesen endlosen, nichtsbringenden Runden!“. Ich kann es ihm nicht verübeln. Doch das Schöne ist:  In Scrum gibt es nur wenige davon, und auch diese sind zeitlich begrenzt und streng fokussiert! Also, lasst uns einen Blick darauf werfen, ich verspreche Euch, es lohnt sich.

Weiter lesen »

Seit Juli arbeite ich für ein neues Team. Dort gibt es bereits einiges, was nach Scrum organisiert ist. Für das Potential “nach oben” habe ich mir überlegt, dem Team in Form von “Merkblättern” Unterstützung für die Rollen und Meetings zu geben, die es im Scrum-Framework gibt.

Das erste Merkblatt habe ich für die Rolle Product Owner erstellt. Diese Rolle ist eine der schwierigsten, da es sich sowohl um eine Art fachliche Führungsrolle im Projekt handelt, bei der sicherlich gute technische Kenntnisse enorm helfen, als auch um einen Kommunikator in alle Richtungen.

Und wo ich das Merkblatt schon mal erstellt habe, möchte ich Euch gern daran teilhaben lassen: Scrum-Rolle-Product-Owner zum Download.

Wenn ihr dazu Fragen oder Kritik loswerden wollt, ich würde mich freuen, davon zu hören. Lasst mich auch wissen, wie ihr das Merkblatt einsetzen konntet, wie die Reaktionen Eures Teams darauf waren und was auf dem Merkblatt noch fehlt oder gar falsch bzw. missverständlich ist.

Vermutlich werde ich als nächstes die Rolle ScrumMaster erstellen und dann die wichtigsten Meetings. Alles wird dann auch wieder hier erscheinen. Wenn alle Merkblätter beisammen sind, dann werde ich eine feste Seite dazu hinterlegen, so das ihr mit einem Link alles erwischen (und weiterempfehlen) könnt.

Viel Spaß beim Ausprobieren!

Ich habe heute meine JIRA-Plugins aktualisiert und bin nun in den Genuss der Umbenennung (*) von Greenhopper zum neuen JIRA Agile seit Version 6.3 gekommen.

Dabei finde ich eines erstaunlich, und zwar die auf der Atlassian-Seite nachzulesende Aussage “JIRA Agile makes sprint and epic information first class citizens.” Das klingt erstmal nach ein wenig Marketing-Bling-Bling, ist aber erstaunlich, weil es die bisher zweistufige Hierarchie von Vorgang und Unteraufgabe praktisch in eine dreistufige erweitert. Zwar ist das bisher in keiner Navigation visualisiert, aber man kann es sich schon gut vorstellen.

Der Einschränkung auf die beiden Stufen konnte man bisher mit Komponenten begegnen, die wie Tags funktionieren: Eine zeitlose Zuordnung zwischen Tickets und einem Label. Ein Ticket kann man dabei auch mehreren Komponenten zuordnen. Dadurch ergibt sich eine n:m-Beziehung. Ein Epic (dt. Epos, pl. Epen) ist im Gegensatz zur Komponente nicht horizontal, sondern vertikal über den Vorgängen organisiert. Dadurch lassen sich verschiedene User Stories zu einem etwas größeren Feature zusammenfassen, z.B. “Nutzerverwaltung” oder “Batch-Modus”. Man muss natürlich aufpassen, einen Epic nicht zu stark zur Komponente werden zu lassen (zum Beispiel mit einer Bezeichnung wie “Frontend”). Sonst ergeben sich Epic-Tickets, die ewig und drei Tage offen bleiben (und das versaut bekanntlich die schönen JIRA-Statistiken zur Durchlaufzeit :-)).

Was ich weiterhin bei JIRA Agile vermisse ist eine echte Integration in die “Standard-Struktur” der Vorgänge: Schätzungen im Planning Board (wir machen das auf Stunden-Basis) werden nicht in die geschätzte Zeit eingetragen, und ein in JIRA Agile angelegter Sprint ist  etwas anderes als eine Lösungs-Version. Wenn man also ein Scrum-Projekt mit JIRA Agile’s Planungshilfe organisiert, ist man wie bisher dazu verdammt, auch nur dieses Board für die tägliche Arbeit im Sprint zu verwenden. Die Burndown-Charts im Projekt zum Beispiel lassen sich nur auf einer “echten” Lösungsversion anwenden und bleiben dann leer. Trägt man dagegen eine Schätzung als Zeit am Ticket ein und organisiert die Tickets in Lösungsversionen, versteht wiederum das Agile Board nichts davon. Dann liegen alle Tickets ungeschätzt und ungeplant in einem riesigen Backlog. Nach wie vor gibt es also getrennte Welten. Schade, denn eine enge Integration war genau das Feature, worauf ich mich gefreut hatte (und dem Marketing-Bling-Bling eigentlich entnommen hatte).

Immerhin, es gibt einen Lichtblick im Dunkel der Nacht: Das Planning Board zeigt links neben dem Epic-Filter auch eine Liste der Lösungsversionen an, auf die man auch Tickets aus dem Backlog ziehen und ablegen kann. Vielleicht ergibt sich ja zumindest bei der zeitlichen Planung in den nächsten Releases eine gewisse Konvergenz.

Es ist ein zentrales Merkmal der Scrum-Philosophie, dass das Produkt in kleinen, überschaubaren Iterationen – den Sprints – verbessert wird. So kann der parallel stattfindende Erkenntnis–Prozess immer wieder zur Neuausrichtung der Entwicklung genutzt werden. So geht weniger Zeit für endlose Spezifikation oder die Implementation unnötiger Features verloren. Doch wie können die Erkenntnisse des jetzigen Sprint konkret im nächsten Sprint genutzt werden, wenn diese nahtlos aneinander gereiht sind? Dieser Übergang hat mich schon immer gedanklich beschäftigt. Daher hier ein Review meiner Erfahrung damit.

Weiter lesen »

Ich weiß nicht genau, ob Euch es genau so geht. Aber ich finde es schwierig, einem Kunden oder Auftraggeber eine saubere Priorisierung abzuringen.

Zunächst gilt: Alles ist immer wichtig, auf Prio A, super-wichtig (A+) und auch mal super-super-wichtig (A++). Nach A+5 gehen einem die Plusse in der Magnetkiste aus. Oder aber es ist dringend. Und dadurch auch ganz wichtig. Und nicht zu vergessen: Dieses Feature hier, das ist zwar eigentlich Nice-to-have, aber ein gewisser Benutzer, der braucht das unbedingt. Das muss also sofort gemacht werden, am besten gestern. Ist aber an sich nicht ganz so wichtig.

Wenn man solche Sätze hört, da bekommt man schon mal kurz Ausschlag, 180er Puls oder gleich beides zusammen. Das ist weder strukturiert noch motivierend oder zielführend. Womöglich denkt der Auftraggeber noch, durch diesen Druck wäre das Projekt schneller fertig. Weit gefehlt, diese Bauernschläue kann er sich gleich an den Nagel hängen.

Jetzt könnte jemand sagen: Haha, das kann dir ja mit Scrum nicht passieren, denn dort ist ja das Backlog einfach eine geordnete Liste. Der PO kann ja nicht zwei Einträge gleichzeitig nach ganz oben schieben. Aber was passiert denn, wenn die Priorisierung der Liste einfach glatt verweigert wird? Dann konzipiert man meist doch alle Use Cases fertig. Oder man priorisiert die Liste nach bestem Wissen und Gewissen und erntet als Dank noch die nette Antwort: Den wichtigen Use Case hier unten, den wollen Sie wohl nicht umsetzen? Ich hatte doch gesagt, der ist wichtig. Hören Sie mir überhaupt zu (Denkblase: Sie geistesumnebelter Projektwurm!?)?

Jetzt könnte man den guten alten Trick anwenden und sagen: Natürlich, lieber Kunde, die sind ALLE GANZ WICHTIG! Und wir machen ALLES, wie immer SOFORT und beginnen GLEICHZEITIG AN ALLEN PUNKTEN. Dann schaut der Kunde sicherlich zufrieden, und wenn er die Bauernschläue-Plus gebucht hat, dann guckt er im zweiten Blick etwas verunsichert. Nach 3 Wochen meldet man dann ERSTE KLEINE ZEITLICHE PROBLEME und verschleppt das Projekt wie üblich. Die Laune ist dann wieder auf dem Nullpunkt, der Kunde etwas darunter und man selbst hat noch etwas Halsschmerzen vom ständigen Kopfschütteln. Nicht zu vergessen: Der Kunde hat das Backlog wahrscheinlich auch so groß gemacht, damit er in der Zwischenzeit für dämliche Fragen nicht erreichbar sein muss (erst Messe, dann Urlaub), die Entwickler haben ja erstmal zu tun.

Eigentlich geht es nicht anders, man muss in solchen Situationen eskalieren. Vor dem Projekt. Am besten gleich bei Weigerung zur Priorisierung. Dann müsste man gleich sagen: Wir weigern uns, diese Anforderungen umzusetzen, wenn Sie nicht in der Lage sind, mit uns zu kooperieren und Ihre Pflicht im Projekt zu erfüllen. Das wäre das ehrlichste und zielführendste, was man tun könnte. Und das Schonendste für das Budget den Kunden. Aber vermutlich eskaliert dann der eigene Chef einen auf eine andere Umlaufbahn. Ein trauriges Dilemma.

Wenn man Scrum näher studiert, wird deutlich, dass es mehr als drei Rollen darin gibt. Zwar beschreibt das Scrum-Framework explizit die Tätigkeiten und Verantwortlichkeiten von ScrumMaster, Product Owner (PO) und dem Team. Doch befinden sich alle drei in einem eingebetteten Ökosystem von weiteren Rollen, dem Management, den Stakeholdern und Benutzern. In der herkömmlichen Scrum-Literatur, die es für 20-40 Euro in jedem Buchladen tonnenweise zu kaufen gibt, wird kaum auf deren Rechte und Pflichten eingegangen. Ich habe jedoch festgestellt, dass es ohne die Einhaltung der Pflichten und die Unterstützung dieser Menschen kein erfolgreiches Projekt oder Produkt mit Scrum geben kann.

Weiter lesen »

Scrum und Kanban sind keine Gegensätze. Beide agilen Projektmanagement-Methoden lassen sich eigentlich wunderbar kombinieren. Allerdings nicht immer und überall. Letzte Woche kam mir eine Idee, das täglich Standup, was bisher nach Scrum verlief, etwas zu Kanban-isieren. Wie das geht, möchte ich Euch kurz vorstellen.

Weiter lesen »