Seit einem halben Jahr darf ich bei Manage&More mitmachen, einer Aktivität von unternehmerTUM. Ich übe mich dort in der Rolle eines Mentors und habe einen Mentee. Bis vor kurzem wusste ich gar nicht, was ein Mentee ist, mittlerweile bin ich selber ein Mentee und zwar in Sachen Wikipedia. Das ist aber eine andere Geschichte.

Mein Mentee heißt Michael, er passt also auch vom Namen gut zur Überschrift. Michael ist ein sympathischer und authentischer Typ, früher hätte man gesagt, “einer mit dem man Pferde stehlen gehen kann”. Alle 4 - 6 Wochen treffen wir uns und sprechen über ein vorher vereinbartes Thema. Mal berichtet der eine und der andere spiegelt und fragt nach und mal machen wir das anders herum. So lernen wir voneinander einiges. Zum letzten Treffen hat Michael mir eine E-Mail gesendet: “Lass uns doch mal über Motivation sprechen!?” Das Thema hat mich angesprochen. Denke ich doch oft selbst genug darüber nach, wie meine Motivationslage so ist und warum ich für manche Themen gar nicht zu motivieren bin. Vorbereitet hab ich mich auf das Treffen zu erstmal mal, in dem ich - wie fast immer - den Begriff in Wikepedia gesucht habe. Da stand einiges zu Motivation drin. Ich habe es ausgedruckt, es waren 13 Seiten - und in der Tat war kaum etwas Falsches oder wirklich Unwichtiges dabei.

Michael wollte über Motivation mit mir sprechen, weil ihm in einem Feedback-Gespräch zurück gemeldet wurde, dass er ab und zu in Besprechungen seine Unlust zu gewissen Themen nicht verbergen könne und durch dieses “Fehlverhalten” die anderen Teilnehmer der Besprechung demotivieren würde. Und wie alle anständigen Menschen hat er zuerst die Schuld bei sich selbst gesucht. Aber Heucheln ist nun mal gar nicht so sein Ding.

Die spannende Frage war: Was soll man machen, wenn man in einer Besprechung an einem Thema mitwirken muss, das einem völlig unsinnig erscheint, man aber aus irgendwelchen Sachzwängen dabei sein muss. Ich glaube, das passiert uns allen hin und wieder - und wahrscheinlich in größeren Organisation noch häufiger als in kleinen.

Soll man dann heucheln, das Desinteresse verbergen und einfach aufs Tempo drücken, damit die grausame Besprechung schnell zu Ende geht und man sich dann ganz schnell wieder seinen wichtigen und geliebten Aufgaben widmen kann? Oder soll man den anderen Beteiligten ehrlich sagen, das man das Thema für nicht relevant hält, die eigene Beteiligung deswegen eh nicht zielführend wäre und dann die Besprechung mit einem freundlichen “Das könnt Ihr ohne mich ja eh viel besser, ruft mich an, wenn ihr das Thema durch habt!” verlassen?

Eine andere Idee: Man könnte sich auch das ungeliebte Thema zu eigen machen und sich die Frage stellen, welche Bedingungen denn erfüllt sein müssten, damit man es selber auch für sinnvoll erachten kann? Dann würde man sicher gute Argumente finden, die man trefflich einsetzen könnte oder die aber den eigenen Standpunkt verändern würden.

Wenn man aber wirklich der Meinung ist, dass das Thema absoluter Blödsinn ist, dann müsste man doch die Zivilcourage aufbringen, dies zu formulieren und einen innovativen Verbesserungsvorschlag zu machen - auch wenn man vor der Macht von entpersonalisierten und sich verselbstständigten Systemen resigniert hat und keine Chance sieht, etwas positiv zu wenden.

Wie man sieht, das Problem ist nicht einfach. Ich glaube, dass Heucheln und “Gute Miene zum bösen Spiel machen” die schlechteste Empfehlung ist.

mehr »

3 von X

Wie kaum anders zu erwarten beendeten wir den Sprint weit vor der Zeit;

Zum einen konnten die Performer den vom Product Owner (und mir) angenommenen Arbeitsaufwand stark “unterbieten”, zum anderen wurden Arbeitspakete, welche zu diesem Zeitpunk noch nicht relevant waren, oder starke Abhängigkeiten zu nachfolgenden Aktivitäten hatten einfach ‘hinten angestellt’ oder gänzlich verworfen.

Alles in allem machte es dem Team großen Spaß, in dieser Tiefe in die Planung involviert zu sein..

Nun fehlte eigentlich nur noch das ‘Big Picture’, bezüglich dem eigentlichen Ziel unserer Arbeit.

Ich habe bereits angesprochen, dass ein Product Backlog, wie wir es aus der Softwareentwicklung kennen für dieses Projekt wohl nicht besonders viel Sinn machen würde.. aber gänzlich ‘weglassen’ konnten wir dieses Artefakt auf keinen Fall: schließlich hatten wir das hehere Ziel, uns (auch argumentatorisch) gegen Einflüsse von Außen aufzustellen.

Also, bei insgesamt vier Projektaufträgen zum gegenwärtigen Zeitpunkt sollte das PBL wohl Aufgaben aus dem gesamten Programm enthalten; auch mussten wir Linien- und ad hoc Aufwendungen berücksichtigen, um mit der Methode Erfolg zu haben…

Mein Ansatz war ein simpler, der hauptsächlich von gesundem Menschenverstand getrieben wurde:

Wir würden die Vision und das Mission Statement des Auftraggebers sowie die direkten Projektziele zu einem Dokument zusammenfassen, welches dann entsprechend der auftretenden Änderungen iterativ überplant, und dessen Inhalte laufend neu priorisiert werden sollte.

Die Erstellung stellte sich anfänglich etwas kompliziert dar, aber nach dem Wechsel auf eine etwas abstraktere (Meta-)Ebene konnten wir schließlich ein ganz brauchbares PBL erstellen. Auch hier zeigte sich erneut, dass eine entsprechend verständliche Vision und das daraus abgeleitete Mission Statement wahre Wunder im Bezug auf Transparenz und Motivation bewirken können.

Heute geht es mit wehenden Fahnen in Sprint 2.

Die Performer akzeptieren die Methode, trotz Statschwierigkeiten mittlerweile voll umfänglich - nun geht es noch um das notwendige Maß an “Management Attention” - wenn auch noch ‘der Chef’ die Methode und das Vorgehen als wertvoll versteht, sind wir einen großen Schritt weiter - bis dahin kämpfe ich noch mit der “Insellösung” - ich transportiere die Ergebnisse und Abhängigkeiten aus SCRUM in Richtung des großen, tosenden Wasserfalls, gegen den wir anschwimmen..

Unser Fortschritt wird von mir in ein GANTT- Diagramm übersetzt, anhand dessen unser Team die Performance im Gesamtprojekt berichtet.

Wir werden sehen, wo weiteres “Optimierungspotenzial” auftritt, sobald es die ersten Wechselwirkungen zwischen Linie, Gesamtprojekt und unserer kleinen aber feinen SCRUM Gemeinde gibt.

We’ll see..

In den letzten beiden Artikeln zum Thema „Agiles Schätzen und Planen“ wurden bereits vorgestellt, wie es möglich ist, einen Sprint so zu planen, daß man sich möglichst immer die optimale Menge an User Stories vornimmt (nicht zu viel, aber auch nicht zu wenig).

Diese Planung wird alleine durch das Team durchgeführt (plus den Scrum Master). Eine Einflussnahme von aussen ist nicht vorgesehen, nicht einmal durch den Product Owner.

Das Team soll sich nämlich die zu erledigende Arbeit für den Sprint möglichst selbst auswählen, muss sich diesem „Sprint-Ziel“ dann aber auch verschreiben und darf auch nur noch in Ausnahmefällen davon abrücken. Auf diese Weise soll sich das Team stärker mit den Zielen identifizieren als wenn sie diese von aussen zugewiesen bekämen. Übrigens ein Ansatz, der tatsächlich funktioniert, wie unsere Erfahrungen hier eindeutig zeigen.

Natürlich möchte man aber auch dem Product Owner einen (berechtigten) Einfluss auf die Sprint-Ziele zugestehen. Wie löst man nun diese scheinbare Konfliktsituation?

Eigentlich ganz einfach:

Der Product Owner nimmt mit an der Sprintplanung teil.

Eigentlich ist dies sowieso notwendig, da nur der Product Owner dem Team den Sinn und Zweck einzelner Einträge des Product Backlogs erklären kann. Ein gutes Verständnis der Einträge ist aber wiederum unabdingbare Voraussetzung für eine gute Schätzung.

Kommt man nun gegen Ende der Planung an den Punkt, an dem das Team sich die Einträge für den neuen Sprint aussucht, so geschieht dies ja anhand der Einträge des Product Backlogs (das ja nach Geschäftswert sortiert ist). Die Sortierung aktuell zu halten gehört mit zu den wichtigsten Aufgaben des Product Owners.

Hat das Team die Liste der Features fertig erstellt, so wird sie noch einmal dem Product Owner vorgelegt, um sein Einverständnis zu erhalten. Normalerweise wird man es auch erhalten. Sollte dies aber wieder Erwarten nicht der Fall sein, so bleiben ihm noch drei Möglichkeiten der Einflussnahme:

• Er sortiert die Einträge des Product Backlog neu. Dies sollte eigentlich nur in Ausnahmefällen notwendig sein, zumindest wenn er es mit seiner Aufgabe genau nimmt, und das Product Backlog konstant aktuell hält,
• Er reduziert den Umfang eines Eintrags, um ihn so doch noch mit in den aktuellen Sprint aufnehmen zu können
• Er splittet den Eintrag auf. Der erste (dringendere) Teil wird sofort realisiert, der Rest auf einen späteren Sprint verschoben.

Somit wird die Kontrolle darüber, was in einem Sprint realisiert wird, zu gleichen Teilen auf Team und Product Owner verteilt:

Auf das Team, weil es alleine entscheidet, wieviele Story Points im Sprint umgesetzt werden können, und zudem noch die Einträge des Product Backlogs mit Story Points beschätzt.

Und auf den Product Owner, da er dem Team eine verbindliche Reihenfolge vorgibt, in der die Einträge des Product Backlogs realisiert werden müssen, und dieses bis zum Ende der Sprintplanung noch ändern kann.

Spielen alle Beteiligten ehrlich und aufrichtig zusammen, so schafft man so eine fast optimale Auslastung des Teams.

Darüber hinaus behält man auch immer den „Business Case“ (man verzeihe mir dieses Wort) im Auge, da der Product Owner, der ja derjenige mit der „Vision“ ist, immer dafür sorgt, die richtigen Anforderungen zur richtigen Zeit zu realisieren.

Die Sprintplanung ist also nun komplett, es kann also losgehen mit der Realisierung :). Bis zu Beginn des nächsten Sprints die nächste Planung ansteht…

BFI

Das ist doch schön zu sehen, wenn meine eigenen Ideen, die Rolle des ProductOwners zu visualisieren auch von “großen Geistern” geteilt werden: Jeff Sutherland schreibt dazu auf seinem Blog “World’s Best Product Owner: Evil Genius Steve Job“.

Kurz, aber mal wieder ein Lebenszeichen …

Stolz präsentieren wir etwas ganz besonderes: Jetzt ist es da, das nach unseren Recherchen erste und einzige “Scrum-Plakat” weltweit. Exklusiv wird es in IF-Blog zum kostenfreien Runterladen angeboten. Es war ein hartes Stück Arbeit für unser Team, aber jetzt ist die erste Version unseres Scrum-Plakates freigegeben.

Der Weg dahin:

Unser “Technology Scout” Alexander Maisch (genannt Axel) hat mir vor knapp einem Jahr berichtet, das er auf seiner Suche nach einem Scrum-Plakat nicht fündig wurde. Der Schluss war einfach: dann machen wir doch selber eines. Dann haben sich die Jungs und Mädels von InterFace, von der TUM und TEG so richtig ins Zeug gelegt. Wie für alles, was Hand und Fuss hat, haben wir neun Monate gebraucht. Und jetzt haben wir es gemeinsam geschafft, die erste Freigabe-Stufe ist erreicht.

Hier ist es, unser ultimatives Scrum-Plakat - zum freien Download. Auf Deutsch und Englisch

Und natürlich wird es kontinuierlich weiter entwickelt und jeder ist herzlich eingeladen, bei der Weiterentwicklung mitzuwirken. Und natürlich werden wir die weiterenwickelten Versionen dann auch wieder zum Runterladen freigeben!

RMD

Bei uns im Unternehmen sind viele junge Kollegen von “Scrum” als Methode der SW-Entwicklung begeistert. Deswegen haben wir ein internes Team gegründet und ein zentrales Projekt “Scrum” aufgesetzt. Wir nutzen “Scrum” in zahlreichen Projekten, IF-Blog hat eine eigene Kategorie Scrum und wir kooperieren intensiv in Sachen Scrum mit Universitäten.

Nicht zuletzt haben wir auch ein wunderschönes Scrum-Plakat geschaffen (wir hoffen, es ist das erste und einzige weltweit), welches natürlich “scrum-mäßig” weiter entwickelt wird. Dieses Plakat gibt es auf Deutsch und Englisch, wir werden es bald in IF-Blog zum “down-load” anbieten, zu Weihnachten gibt es dann ein großes Papierexemplar für unsere Kunden.

Unseren Scrum-Kollegen sage ich immer: “Toll, was Ihr da macht!” und füge hinzu: “Genauso haben wir vor 25 Jahren unseren HIT entwickelt!” Dann sehe ich grosse Augen und ernte ungläubiges Staunen. Aber in der Tat, da gibt es doch viele Parallelen.

HIT war unser erstes Erfolgsprodukt. Er wurde mit einem einzigartigen Team in unglaublichem Tempo entwickelt. Über das Team und seine Menschen werde ich hier noch öfters schreiben.

Ich habe das Pflichtenheft zur “Schreibmaschine” HIT geschrieben. Dank an Lars (Schmiedeberg), dass er es so viele Jahre persönlich aufbewahrt hat. In vielen Punkten ist Hit genauso geworden, wie ich es damals beschrieben habe, in einigen ganz anders. Und manche geplante “Features” sind auch in der aktuellen Version nicht vorhanden und werden wohl auch nie realisiert werden, obwohl sie ganz nett waren.

So bin ich gleich am Anfang zum “product owner” für HIT geworden und bis heute geblieben. Übrigens: der “product owner” unseres CLOUs war und blieb viele Jahre der Friedrich (Lehn). Natürlich ist eine zeilen- und spaltenorientierte Schreibmaschine auf UNIX im Markt nicht mehr relevant. Aber CLOU/HIT war ein wertvolles System mit mehreren Millionen Anwendern in Europa. Als Marktführer im Bereich Produktionstext lief er auf allen Unix-Systemen und später auch auf Windows. Und noch heute verrichtet der CLOU bei Behörden und Industrie wie ein alter Arbeitsgaul brav und nutzbringend seinen Dienst.

Tagsüber waren der Wolf (Geldmacher) und ich Berater, am Abend waren wir in der Firma. Wolf war unser Architekt, der technische Chef, der Helfer in allen Lebenslagen, der jedem mit Rat und Tat beistand. So wie unser Team technisch immer besser und mündiger wurde, übernahm Wolf immer mehr eine Rolle, die man heute als “Scrum Master” bezeichnen würde. Wir hatten also einen Feierabend-Product-Owner und einen Feierabend-Scrum-Master. Das hat aber ausgereicht, man konnte am Abend die wichtigen Dinge sehr effizient besprechen und schnell entscheiden. Die Besprechungen waren so ganz natürlich kürzer und effizienter.

Es gab bei uns goldene Regeln: Eine war, dass am Ende eines jeden Arbeitstages (!) die aktuelle Version mit Ausnahme von bekannten und nicht das Funktionieren prinzipiell störende Fehler laufen musste! Später bei XP  (=Extreme Programming), einem Vorläufer (?) von Scrum, hieß das dann “Continuous Integration”. Das war eine heiße Anforderung und hat zu zahlreichen Schichten bis spät nach Mitternacht  geführt (oder ins Morgengrauen - es war aber kein “Grauen”). Wir waren jung, der Idealismus groß, den Kollegen wurde jede Stunde bezahlt und vom Betriebsverfassungsgesetz und verwandten Gesetzen wussten wir auch nichts.

Wir hatten ein klares Rollenspiel. Wolf als “Scrum Master” vertrat die Interessen des Teams, er hielt konsequent allen Unbill vom Team fern und ließ niemanden von außen reinreden. Ich habe es ein paar Mal versucht und bekam immer eins auf die Nase. Auch das konnte (und kann) der Wolf ganz besonders: Nein zu sagen, ohne klein zu machen oder zu verletzen.

Bestimmen und Entscheiden durfte ich nur, wenn es um die Oberfläche bzw. um die Funktionalität des Systems ging. Ich hatte die Vision, die ich rückwirkend gesehen ziemlich rigoros durchzog und war Herr der Ressourcen. Und da gab es Konflikte. Gut kann ich mich noch erinnern, wie ich die Krise bekam, weil der Wolf schon 1985 (glaube ich) einen MX 500 mit 8 Prozessoren forderte (der Listenpreis lag deutlich über 300.000,- DM - das waren ungefähr 10 Mannjahre brutto zu Selbstkosten), den er ganz dringend für das HIT/CLOU-Team brauchte, und wie er dann die Krise bekam, als ich dieses System partout nicht kaufen wollte. Wir haben uns schnell geeinigt, haben das System gekauft (mit Forschungsrabatt hat es dann “nur” noch 200.000,- DM gekostet). Es war eine riskante aber richtige und vor allem schnelle Entscheidung.

Solche Entscheidungen wurden bei uns übrigens immer übers Wochenende getroffen, auch das ist ein sehr gutes Verfahren. Man bespricht das Problem Freitag Abend und entscheidet am Montag Früh, am besten kurz am Telefon.

Wir mussten damals wahnsinnig schnell sein. Unser Vertriebsstil war nämlich auch “scrum-mäßig”. HIT war am Beginn seiner Entwicklung nur ein rudimentäres System. Aber wir hatten bei vielen Kunden hohes Interesse geweckt. Und oft war die Ansage unserer potentiellen Kunden: Wir nehmen euer System, wenn Ihr uns noch diese oder jene Funktion einbaut, z.B. eine Suchfunktion, einen Trenner, eine Schnittstelle zu diesem oder jenen Drucker … Oder wenn Ihr eine Programmierschnittstelle anbietet oder Portierung auf ein weiteres Betriebssystem durchführt. Und das musste immer ganz flott gehen. Am Ende einer Woche wurde die Funktion dem Kunden versprochen, am Ende der nächsten Woche wurde sie ihm zumindest in der Grundfunktion vorgeführt und zum Ausprobieren (oft zum Echteinsatz) geliefert. So könnte man sagen, dass wir Sprints im Wochenrhytmus hatten, das bei einem doch sehr mächtigen System. Es war ein heißer Tanz - der über Jahre hinweg ging.

Wir waren immer so ziemlich die ersten, auch beim standardmäßigen Einsatz von Werkzeugen wie sccs oder lint. Auch das ist “scrum”! Ohne sauberes Arbeiten und Disziplin geht es nicht. Für Kaizen-Insider: Die 5 S sind auch bei Scrum die Grundlage des Erfolges.

Aber Dank der genialen und belastbaren Architektur, die sich Wolf und seine Mitstreiter (und ein wenig auch ich) ausgedacht hatten (und dank UNIX und seiner für damalige Zeiten revolutionärer Entwicklungswerkzeuge) und natürlich vor allem Dank eines Teams von jungen Mitarbeitern, die für ihr Produkt durchs Feuer gingen, haben wir es immer geschafft.

Das war schon Scrum !!!!

Heute könnte ich meinen jungen Kollegen sagen: “Scrum ist doch auch nur alter Wein in neuen Schläuchen!” Mache ich aber anders: Ich sage: “Scrum ist deshalb so gut, weil es eben ein wirklich guter alter Wein ist!”

Wahrscheinlich liegt hierin wohl ein Grund für den zunehmenden Erfolg von Scrum - vieles, was sich in der täglichen Praxis der Softwareentwicklung als hilfreich erwiesen hat, wurde durch Scrum aufgenommen und als offizielles Vorgehen akzeptabel gemacht.

In einer der nächsten Fortsetzungen berichte ich, wie wir mit Peter Öfelein, unserem Partner für PM bei der Siemens AG, die Versionsplanung auch ganz “scrum-mäßig” gemacht haben.

RMD

2 von X…

Bisher treffen sich unsere Helden einmal täglich um 13:30 Uhr in einem kurzen (15min), knackigen Meeting namens „Boxenstop“.
Der Scrum Master moderiert und nimmt Probleme auf, um deren Beseitigung er sich für das Team kümmert. (nebenbei schreibt er noch immer fleißig mit, damit er seinen Statusbericht voll bekommt *g*)

Zusätzlich dazu gibt es jeden Morgen ein 30 Minuten Meeting zwischen dem Auftraggeber (den wir später noch als Product Owner kennenlernen werden) und mir.

Durch diese Meetings konnte ich Transparenz und Kommunikation erzeugen – und das Vertrauen in mich als ‚Problem-aus-der-Welt-schaffer’ festigen.
Hauptsächlich kümmerte ich mich zu diesem Zeitpunkt wohl um noch nicht beantwortete eMails, ausstehende Termine zur Klärung von diesem und jenem.. Kleinkram eigentlich, der aber bei den Performern Mehraufwendungen erzeugt hat.

In meinen Besprechungen mit dem Auftraggeber habe ich wiederholt interesse an agilmen Projektmanagement erzeugen können – sowie Informationen aus dem Team und die aktuelle Auslastung an Ihn kommuniziert – so dass er besser in der Lage war Zurufe seitens seines Chefs entsprechend fundiert zu würdigen.

Auch kamen wir in diesen Meetings überein, dass wir uns gegen Arbeitslast ‚von Außen’ entsprechend zügig aufstellen müssen – ein Verfahren zur Bewertung und Einplanung der Zurufaktionen musste her. Wir beschlossen, das Team von störenden Einflüssen abzuschotten..

Spätestens jetzt war selbst mir klar, dass es eine Antwort auf unser(e) Problem(e) gibt.
Aber würde ich Scrum (oder auch nur einige Artefakte) in der vorliegenden Situation etablieren können?

- Wir sind umgeben (und als Team Bestandteil) von klassischen PM Methoden… die meisten davon „Top-Down“ von einer Hauptprojektleitung induziert, welche sogar bis auf Vorgangsebene die Planung vorgibt.
- Es gibt einige Artefakte, die in der Softwareentwicklung einen definitiven Zweck erfüllen.. aber wie sieht zum Beispiel das Product Backlog für ein Organisations-Projekt aus?
- Ein Team von sechs Menschen, die in diversen Projekten mitwirken über ein Scrum Board zu steuern (wichtig: sich selbst steuern zu lassen) und dieses Vorgehen auch noch ‚nach Oben’ hin zu rechtfertigen würde.. schwierig sein.
- Scrum hin oder her, es muss eine Brücke geschlagen werden zwischen agilen Methoden und klassischen Status Reports - meine Aufgabenstellung umfasst nicht nur ergebnisorientierte Projektsteuerung, sondern eben auch transparente Status Berichte ‘nach Oben’
- Die Performer haben keine Erfahrung mit Scrum.

Nach meinen Berichten über agiles Projektmanagement und insbesondere Scrum war mein Auftraggeber von dieser Idee überzeugt. Also einigten wir uns auf einen Versuch.

Und wie das Leben so spielt, kam am gleichen Tag ein Sekundärprojekt auf den Plan in welchem wir eine Ausschreibung vorbereiten sollten.

Also kurzum die Planung mit dem Auftraggeber durchgesprochen, Arbeitspakete erstellt und ab zum Schreibwarenladen. Paketpapier, Post-Its, Moderationskarten, Stifte, Posterkleber und Malerkrepp. Eigentlich kann es jetzt losgehen.

Also alle eingeladen zu einem Termin – zwei Bahnen Paketpapier an die Wand geklebt (und das sogar einigermaßen Waagerecht – ich bin ja so stolz!), mit bunten Karten beschriftet und in Spalten abgeteilt.. Fertig war das Scrum Board (welches fortan auf den Fluren vor meinem Büro für einige Verwunderung sorgen sollte – zumindest die war bereits auf meiner Seite)

(Anmerkung: Dem Scrum interessierten Leser ist bereits in meinem letzten Absatz aufgefallen, dass _ich_ die Arbeitspakete aufgeplant habe.. aber dazu gleich mehr.)

Also findet der Termin statt – zwei Stunden Kick Off für das Sekundärprojekt unter meiner Moderation. Mit gleichzeitiger Vorstellung des Scrum-Boards. Und der Methode. In zwei Stunden? Yeah right. Natürlich gab es so viele Fragen zum weiteren Vorgehen, dass wir den Termin glatt um eine Stunde überzogen haben – und selbst im Anschluss daran war der eigentliche Zweck von buntem Papier an der Wand noch nicht wirklich geklärt.

Jeder legt noch schnell ein Ei… erm – oder nimmt sich ein Kärtchen, klebt sein Namenskürzel als Post-It darauf und eigentlich ist ja jetzt alles klar, oder?
Dann sehen wir uns morgen Mittag wieder zum Boxenstop.

…

Ich rechne es dem Team sehr hoch an, dass sie mich zu diesem Zeitpunkt nicht einfach ‚plattgemacht haben’.. Gründe und Möglichkeiten dafür gäbe es genug.

Am nächsten Tag habe ich herausgefunden was das Problem war.
Die Performer standen bei Kaffee und Schokolade in meinem Büro und konnten mir glaubhaft versichern, dass Sie ja alles mögliche Versucht haben, aber die Aufgabenstellung habe einem kritischen Hinterfragen nicht standgehalten und so wurden die Aufwendungen zumindest dahingehend gering gehalten, dass die Arbeit bis zur weiteren Klärung eingestellt wurde.

Keine User-Story der Welt konnte die Aufgaben so umfassend erklären wie es die Performer untereinander im anschließenden Termin mit wenigen Worten konnten. Zur kurzen Erklärung möchte ich anfügen, dass die User Story im damaligen Fall eher eine Beschreibung des Ergebnistyps war.

Zu meiner Ehrenrettung muss ich sagen, dass ich zu diesem Zeitpunkt eventuell noch nicht einmal daran gedacht hatte, Scrum vollumfänglich einzusetzen – ich wollte lediglich einige Artefakte etablieren, welche die Steuerung leichter machen sollten.

Lessons Learned:
- Die Planung erfolgt im Team. Aus dem Team für das Team. Nur so ist sichergestellt, dass die Arbeitspakete inhaltlich verstanden werden.
- Scrum einzuführen ist entweder ein langsamer, aufbauender Prozess oder
- Ein schneller Prozess mit genügend Zeitinvestment für Vorbereitungen und Erklärungen.
- Kein Scrum Artefakt ist so gut, wie die Summe aus allen - gepaart mit der durchgängigen Anwendung.

Also blieb mir keine andere Wahl.. dem Papier an meiner Wand zufolge würden wir Scrum als Methode einführen. All the way, or no way at all.

To be continued…

Wie bereits im letzten Artikel erwähnt ist eine saubere Planung ein wesentlicher Garant für einen erfolgreichen Sprint. Mit den vorgestellten Methoden sollte man relativ einfach einen Umfang an Story Points errechnen können, den man in einem Sprint leisten kann.

Damit dies funktioniert, müssen natürlich zuerst alle Einträge des Product Backlogs beschätzt werden, um für jeden Eintrag einen Aufwand zu erhalten, mit dem man dann weiter planen kann.

Es gibt viele Möglichkeiten, Arbeitspakete zu schätzen.

Die einfachste Methode ist dabei ganz einfach, eine User Story dem Team zur Diskussion zu stellen und so lange zu warten, bis sich auf eine Zahl geeinigt haben. Dies wird in Fällen auch tatsächlich so gehandhabt, hat allerdings einen gravierenden Nachteil:

Im Laufe der Zeit hat sich nämlich gezeigt, daß die Diskussion üblicherweise so abläuft, daß ein Teammitglied, welches die Story gut versteht (oder zumindes denkt, dies zu tun) mit einer schnellen Schätzung rausplatzt. Dies führt dann jedoch dazu, daß andere Teammitglieder, die sich ihrer Sache nicht ganz so sicher sind, in ihrer Schätzung beeinflusst werden könnten (und wenn es nur unterbewusst ist).

In der Fachsprache nennt man dies „Anchoring“. Man sollte es wenn möglich vermeiden.

Eine einfache Methode, die dies tut, und die bei Scrum immer gerne eingesetzt wird, ist „Planning Poker“.

Sie besticht vor allem dadurch, daß sie leicht zu erlernen und relativ schnell in der Durchführung ist, dabei aber trotzdem genügend genaue Ergebnisse liefert.

Sie funktioniert wie folgt:

Zu Beginn erhält jeder Teilnehmer einen Satz Pokerkarten (ideal ist es übrigens, wenn das ganze Team teilnimmt). Ein Satz besteht aus 13 Karten mit den aufgedruckten Werten 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ?, [Kaffetasse] .

Wenn nun eine neue User Story beschätzt werden soll, so wird nun wie bisher so lange im Team diskutiert, bis alle soweit verstanden haben, worum es geht. In der Diskussion sind übrigens ausschliesslich sachbezogene Beiträge erlaubt. Statements mit vorauseilenden Wertungen („das ist ja einfach“) sind strikt verboten und werden mit einem nicht zu geringen Beitrag in die Kaffekasse bestraft :).

Nach Abschluss der Diskussion geht es dann an die Schätzung: Jeder Teilnehmer nimmt dann aus seinem Kartensatz diejenige Karte, von der er meint, daß sie dem Aufwand der zu schätzenden User Story (in Story Points) entspricht, und legt sie verdeckt (!) vor sich auf den Tisch.

Erst wenn auch der Letzte seine Karte Schätzung abgegeben hat werden alle Karten gleichzeitig umgedreht.

Auf diese Weise stellt man sicher, dass sich jeder seine eigenen Gedanken machen muss, und sich nicht an einem seiner Kollegen orientieren kann.

Ihnen ist vielleicht schon aufgefallen, daß die auf den Karten aufgedruckten Zahlen nicht ganz linear sind, sondern vor allem bei den höheren Zahlen größere Lücken aufweisen. Dies geschieht ganz bewusst: Auf diese Weise soll verhindert werden, daß größere Arbeitspakete mit einem falschen Sinn für Genauigkeit beschätzt werden. Je höher, je ungenauer. Aus diesem Grund ist es übrigens auch nicht erlaubt, mehr als eine Karte für eine Schätzung auszuwählen. 40+20 = 60 ist somit also nicht erlaubt. Man muss sich schon für einen Wert entscheiden.

Möchte man genauere Schätzungen erhalten, so sollte man die Story noch weiter aufteilen, und dann die einzelnen Teile beschätzen.

Der Kartensatz enthält übrigens 3 Jokerkarten: „0“, „?“ und „[Kaffeetasse]“.

• „0“ bedeutet „dieses Feature ist bereits implementiert oder nur eine Sache von wenigen Minuten.
• „?“ heisst: „Ich habe nicht mal ansatzweise eine Ahnung, worum es hier eigentlich geht“
• Kaffeetasse: „Mir langt’s erstmal. Machen wir eine kurze Pause.“

Nun decken alle „Mitspieler“ ihre Karten auf und vergleichen ihre Schätzungen. Weichen zwei der Werte stark voneinander ab, so wird dieser Umstand nochmal diskutiert und anschließend die Schätzung wiederholt. Dies geschieht so lange, bis alle Beteiligten in etwa denselben Wert schätzen.

Ob man nun den Mittelwert aller Karten nimmt, den höchsten und niedrigsten Wert ausser Acht läßt und den verbleibenden Rest mittelt, den Wert der mittleren Karte nimmt oder eine andere Metrik verwendet um auf den abschließenden Schätzwert zu kommen ist dabei jedem Team selbst überlassen. Im Laufe der Zeit wird man hier sicherlich etwas finden, womit alle Beteiligten einverstanden sind.

Nun sind wir mit der Schätzung dieses Features fertig. Diesen Vorgang müssen wir jetzt auch noch mit allen anderen Einträgen des Product Backlog machen, die für den aktuellen Sprint in Frage kommen.

Zusammen mit der im letzten Artikel vorgestellten Abschätzung des maximal in diesem Sprint zu leistenden Arbeitsumfangs ist es nun auch möglich, die zu realisierenden Features auszuwählen: Man beginnt am oberen Ende der Liste (die ja nach Geschäftswert sortiert ist) und übernimmt die entsprechende Anzahl an Einträgen ins „Sprint Backlog“. So nennt man die für die Realisierung in einem Sprint ausgewählten User Stories.

Einmal erstellt, soll das Sprint Backlog übrigens nur noch in absoluten Ausnahmefällen geändert werden, etwa wenn sich abzeichnet, daß man sich zu viel oder zu wenig vorgenommen hat.

Das Sprint Backlog wird ausschliesslich durch das Team erstellt. Der Product Owner darf keinen direkten Einfluss darauf nehmen.

Er verfügt aber über mehrere indirekte Möglichkeiten der Einflussnahme. Welche dies sind ?

Diese Frage wird im nächsten Artikel beantwortet….

BFI

In unseren Erfahrungen mit Scrum hat sich in der Vergangenheit immer wieder gezeigt, dass eine sorgfältige Sprint-Planung mit das Wichtigste Artefakt in Scrum ist. Sie entscheidet darüber, ob der anschließende Iterationszyklus das gewünschte Ergebnis liefert, oder aber in einem kompletten Chaos endet. Letzeres soll natürlich vermieden werden, wenn es irgendwie geht. Doch wie stellt man das am besten an?

Als Beispiel für eine funktionierende Sprintplanung möchte ich hier die Methode vorstellen, die Henrik Kniberg in seinem sehr empfehlenswerten Buch „Scrum and XP from the trenches“ gibt.

Grundlage für eine erfolgreiche Sprint-Planung ist ein einigermaßen sauber geführtes Product Backlog. Mit „einigermaßen sauber” meine ich hier:

• Es sollte existieren,
• auf dem aktuellen Stand sein, und
• die einzelnen Einträge sollten nach Geschäftswert priorisiert sein.

Ideal wäre außerdem noch, wenn es zu jedem Eintrag noch ein definiertes Abnahmekriterium gäbe („How to demo”), da sich so im Vorfeld bereits einige Missverständnisse ausräumen lassen (etwa über den Umfang des Eintrags). Dies alles liegt natürlich in der Verantwortlichkeit des Product Owners. Es ist daher unbedingt erforderlich, dass dieser seine Aufgabe auch ernst nimmt!

Sind diese Voraussetzungen erfüllt, so kann die eigentliche Planung beginnen. Hierfür sollte man sich genügend Zeit nehmen. Mein Vorschlag ist, sich pro Woche, die der anschließende Sprint dauert, in etwa 1 Stunde Zeit zu nehmen. Bei einem 4-wöchigen Zyklus wären das also 4 Stunden. Hört sich zwar lange an (das ganze Team einen halben Tag in Beschlag zu nehmen), ist aber jede investierte Minute wert!

Am Ende sollte man folgendes erreicht haben:

• Man hat ein Ziel für den Sprint festgelegt,
• ein Sprint Backlog erstellt,
• Termine für Sprint Review und das tägliche Statusmeeting ausgemacht, sowie
• eine Liste der Teammitglieder samt ihrer Verfügbarkeit.

Zuerst sollte man sich Gedanken darüber machen, welche Einträge aus dem Product Backlog man für den neuen Sprint übernimmt. Da diese Einträge nach Geschäftswert priorisiert sind ist dieser Schritt zunächst einmal relativ leicht:

Man beginnt am oberen Ende der Liste und übernimmt einfach so viele Einträge, wie man meint innerhalb einer Iteration realisieren zu können. Wieviele Einträge dies sind? Dazu schätzt man den Aufwand der ausgewählten Einträge und gleicht den ermittelten Wert dann mit den Erfahrungswerten aus vorangegangenen Iterationszyklen ab. Diese Technik wird „yesterday’s weather” genannt.

Natürlich steht ein solcher Erfahrungswert nicht immer zur Verfügung. Sollte dies der Fall sein, so kann man auch eine einfache Art der Ressourcenkalkulation verwenden. Basis hierfür bildet die Zahl der verfügbaren Manntage im Sprint. Bei einem 4-wöchigen Sprint in einem Team von 5 Leuten könnte eine solche Planung dann etwa wie folgt aussehen:

• Adam: 20 Manntage
• Bertram: 18 Manntage (hat 2 Urlaubstage genommen)
• Cäsar: 20 Manntage
• Dora: 10 Manntage (steht nur zu 50% zur Verfügung)
• Egbert: 20 Manntage

Insgesamt stehen für den Sprint also 88 Manntage zur Verfügung. Kann man nun also in diesem Sprint also nun Einträge im Wert von 88 Story Points realisieren? Nein, da die Einheit für Story Points aus „idealen Manntagen” besteht. Ein solcher idealer Manntag ist ein Tag, an dem eine Person die ganze Zeit über produktiv arbeitet, ohne jegliche Art von Pausen, Störungen oder Krankheit. Dies kommt in der Realität natürlich nicht allzu häufig vor. Der tatsächliche Wert wird daher etwas unter diesem Idealwert liegen. Diesen Unterschied zwischen idealem und realem Wert nennt man auch den „Fokusfaktor”.

Die Anzahl der in einem Sprint erreichbaren Story Points ist also [Zahl der Manntage] x [Fokusfaktor]. Den Fokusfaktor kann man z.B. aus vorangegangenen Sprints berechnen (über die Formel: Fokusfaktor = [realisierte Story Points] / [ Gesamtzahl Manntage]). Besser noch ist es natürlich, einen Mittelwert über mehrere Sprints zu verwenden.

Angenommen, im letzten Sprint wurden bei 90 zur Verfügung stehenden Manntagen Stories im Wert von 60 Story Points realisiert, so errechnet sich daraus ein Fokusfaktor von 60/90 = 0,66.

Für den neuen Sprint würde das dann bedeuten, dass wir damit planen können, insgesamt Einträge in der Höhe von 88 * 0,66 = 58 Story Points umzusetzen.

Was aber, wenn noch kein solcher Fokusfaktor existiert? Hier könnte man versuchen, ins Unternehmen zu schauen und ein Team zum Vorbild zu nehmen, das unter vergleichbaren Umständen arbeitet, oder aber (falls auch das nicht möglich ist) einfach einen Faktor zu schätzen. Dies hört sich im ersten Moment zwar etwas unprofessionell an, ist aber vertretbar, da dieser Fall eh nur im ersten Sprint eines neuen Projekts auftreten kann. Bereits ab dem zweiten Sprint kann man wieder echte Daten verwenden. In der Literatur (Link einfügen: „Scrum and XP from the trenches”) findet sich hier ein Wert von ~0,7, was auch in etwa unseren Erfahrungen entspricht. Falls Sie sich also keinen Wert selbst ausdenken wollen, so können Sie gerne diesen verwenden.

Der Fokusfaktor eignet sich übrigens nicht nur zum Planen eines neuen Sprints. Da er ja die Differenz zwischen idealen und tatsächlichen Manntagen darstellt, beinhaltet er somit auch alle Umweltfaktoren. Dies kann auch als Druckmittel bei Verhandlungen mit dem Product Owner dienen, wenn es etwa darum geht, Probleme zu beseitigen, die das Team in seiner täglichen Arbeit behindern. Man denke hier nur an eine im Hochsommer ausfallende Klimaanlage oder an häufig auftretende Netzwerkprobleme. Beides würde sich in einer Verringerung des Fokusfaktors niederschlagen, und somit einen direkten negativen Einfluss auf den Projekterfolg haben. Eine Beseitigung dieser Probleme hätte jedoch wieder eine Erhöhung des Fokusfaktors zur Folge, und damit auch eine Erhöhung der realisierbaren Story Points innerhalb eines Sprints.

Am Ende dieses Abschnitts wissen wir nun also, wie viele Story Points wir in diesem Sprint realisieren können. Um nun jedoch zu einer tatsächlichen Liste von Funktionen zu kommen, müssen zuerst noch alle in Frage kommenden Einträge des Product Backlogs beschätzt werden. Die Methode, die wir in solchen Fällen immer einsetzen, nennt sich „Planning Poker”. Wie diese genau funktioniert, darüber mehr im nächsten Artikel.

BFE

Zwei unserer hervorragenden Creative-Scrum-Mitstreiter von TEG (the entrepreneurial group) machen gerade ein Semester lang das Silicon Valley unsicher. Aktuelle Eindrücke erscheinen unter: http://tilstory.wordpress.com/

Hier ein erster Vorgeschmack für alle, die wie wir die Kalifornische Wintersonne lieben!

CS