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

Diese ist Teil 1 von X in einer Reihe, die wir fortan als eine Art Projekttagebuch hier veröffentlichen werden.

Scrum Master

„Der Scrum Master hat die Aufgabe, die Prozesse der Entwicklung und Planung durchzuführen und die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht, und fördert das Zu-Tage-Treten der bestehenden Verbesserungspotentiale. Er ist keinesfalls für die Kommunikation zwischen Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren. Er steht dem Team zur Seite, ist aber weder Product Owner noch Teil des Teams. Der Scrum Master sorgt mit allen Mitteln dafür, dass das Team produktiv ist, also die Arbeitsbedingungen stimmen und die Teammitglieder zufrieden sind.“

Quelle: Wikipedia

Ich bin also ein Scrum Master.

Wie konnte das nur passieren? ;c)

Als ich vor etwas über sechs Wochen in meinem aktuellen Projekt als Projektleiter ankam, wusste ich noch wenig über die Vorgänge und Arbeitsweisen, die mich hier erwarten würden.

Die Situation, die ich vorfand lässt sich in etwa so beschreiben:

Es gibt ein motiviertes und kompetentes Team von sechs Performern.

Diese sind innerhalb einer projektgetriebenen Matrixorganisation für den organisatorischen Aufbau einer Supporteinheit zuständig und unterstützen die angrenzenden Bereiche unter anderem durch Reviews ihrer Dokumente auf Berührungspunkte mit dem Betrieb.

Abgesehen davon gibt es derzeit aktuell ein Hauptprojekt und mindestens vier weitere Sekundärprojekte, in welchen die Performer Tätigkeiten übernehmen und welche durch mich gesteuert oder aktuell geplant werden.

Erste Gespräche mit meinem Auftraggeber ergaben, dass es derzeit kaum Transparenz bezüglich Arbeitslast, ad hoc Aufwendungen und zur Erreichung der Ergebnistypen gibt.

Gegen zusätzliche Aufgaben ‚aus der Linie’ (also vom Chef der Abteilung,) deren Projektrelevanz zumindest fragwürdig ist, kann man sich nicht wehren, da aufgrund eben dieser fehlenden Transparenz nicht veranschaulicht werden kann, welche Auswirkungen die Zusatzaufgaben auf die Zeitachse im Projektverlauf haben.

Das Hauptprojekt (Aufbau einer Europaweit einzigartigen Technologie) wird „top-down“ geplant. Es gibt wenig bis gar keine Abstimmung zwischen den ‚Planern’ und den verantwortlichen Projektleitern. Die Projektleiter können zwar Risiken, Probleme und Änderungen an der Zeitachse ‚nach oben’ kommunizieren; jedoch erfolgt hierauf in der Regel verschwindend geringe Resonanz.

Statusberichte werden nur auf Anforderung und bei Bedarf kommuniziert. Die Erstellung dieser Berichte wird als ‚notwendiges Übel’ hingenommen und Teamintern kaum zur eigenen Verortung benutzt. Innerhalb des Teams ist einem einzelnen Performer nicht klar, woran der Kollege gerade Arbeitet. Die Fäden darüber hielt bisher mein Auftraggeber in der Hand – der nun aber zunehmend mit Linientätigkeiten belastet wird und deshalb nicht mehr in der Lage ist das Team zu steuern.

Aufgrund dieser Tatsache wenden die Performer im ständigen Heldeneinsatz eine schwer zu beziffernde Anzahl an Stunden täglich zum Beseitigen von Problemen und dem Beschaffen von Informationen auf.

Ich fasse zusammen:

- Es gibt ein motiviertes Team, dessen Tun ständigen Änderungen (ad hoc vom Chef) unterworfen ist.

- Sowohl Team als auch Projektleitung verfügen nicht über den nötigen ‚Durchblick’ darüber

o ‚Wer’ gerade ‚Was’ zu tun hat.

o Welche Probleme es aktuell bei wem gibt.

o Wann welche Ergebnisse fällig oder fertig sind.

o Welche Abhängigkeiten in den Tätigkeiten der einzelnen Performer bestehen.

Zu diesem Zeitpunk war mir klar, dass eines der Hauptprobleme bei der Steuerung und dem erstellen von Statusberichten nicht etwa schlechte Arbeitsleistung war, sondern vielmehr das Fehlen entsprechend zielgerichteter Kommunikation.

Also habe ich ein Meeting anberaumt, welches Täglich von 13:30 Uhr bis 13:45 Uhr stattfindet. Die Teilnehmer hatten in Vorbereitung zu diesem Termin die in Scrum definierten Fragen vorzubereiten.

“Bist du gestern mit dem fertig geworden, was du dir vorgenommen hast?”

“Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten?”

“Gibt es ein Problem, das dich blockiert?”

Quelle: Wikipedia

Dieses Meeting war der erste Schritt zu meinem Ziel.

Hinderlich (aus meiner Sicht) war die Tatsache, dass ich die Projektschritte und Arbeitspakete inhaltlich nicht tief genug kannte, um auf die Antworten zu den Fragen entsprechend einzugehen.

Da es ja zu diesem Zeitpunkt noch kein Scrum-Board gab, auf dem wir Arbeitspakete hätten visualisieren können, war die Wahrnehmung der Teilnehmer doch eher abstrakt.

Zu diesem Zeitpunkt jedoch bereits ein erster Benefit:

Die Performer tauschten sich nun täglich nach dem Essen (Bei Kaffee und Süßigkeiten) darüber aus, wer gerade mit was zu kämpfen hat und bis wann welche Ergebnisse zu erwarten wären … und: (eigentlich nicht wirklich im Sinne von Scrum ;c) Ich habe einfach mal fleißig mitgekritzelt und bevor ich mich versah den Statusbericht für die laufende Woche aus den Gesprächen generiert.

to be continued…

(Wer Tippfehler findet, darf sie behalten - mein Lektor hat Urlaub ;c)

Pünktlich zum 1. Oktober war es soweit: Es fiel der Startschuss für die gemeinsamen Creative Scrum Aushänge – unsere Kooperation mit der TU-München geht damit in die nächste Phase.

Die Aushänge sind mit allen offiziellen Genehmigungen versehen und finden sich im Gebäude der Informatik-Fakultät an einigen exponierten Plätzen. Ganz gezielt geht es darum, interessierte Mitstreiter für das Thema Creative Scrum zu finden. Wir freuen uns auf die ersten Rückmeldungen.

Click on image for full screen view

Wenn man sich in der Scrum-Community heute so umhört, dann stellt man schnell fest, dass die meisten Personen aus der Ecke der Softwareentwicklung kommen. Also eher die Auftragnehmerseite. Die Auftraggeberseite ist jedoch zumeist so gut wie gar nicht vertreten. Doch warum ist das so? Sind agile Methoden für die Auftraggeber nicht attraktiv genug? Oder liegt es vielleicht eher daran, dass die betroffenen Entscheidungsträger noch nichts darüber gehört haben?

Unsere bisherige Erfahrung sagt uns, dass eher Letzteres der Fall ist, denn Scrum bietet dem Auftraggeber sehr wohl eine Reihe von Vorteilen (sie auch der letzte Artikel über „Scrum und Festpreisverträge”). Für alle, die keine Lust haben, diesen Artikel nachzulesen, seien die wichtigsten Punkte an dieser Stelle nochmal wiederholt:

• Dem Auftraggeber ist es erlaubt, bisher unbearbeitete Anforderungen durch Neue auszutauschen. Dadurch erspart man sich teure Change Requests (betrifft v.a. Festpreisverträge)
• Da Software bei Scrum iterativ entwickelt wird, ist es möglich, am Ende jeder Iteration steuernd auf das Projekt einzuwirken (üblich sind hier 4 Wochen). So kann man zu jeder Zeit die Kontrolle darüber behalten, wie sich das Produkt weiterentwickelt.
• Ein iterativ entwickeltes System kann natürlich auch leicht schrittweise ausgerollt werden. Ein Big-Bang ist nicht notwendig. Das verringert das damit verbundene Risiko erheblich, hat aber auch andere Vorteile, z.B. geringere Kosten für Mitarbeiterschulungen.
• Es ist möglich, ein Projekt vorzeitig abzubrechen und dennoch ein lauffähiges System zu bekommen. Dies kann z.B. bei Budgetkürzungen der Fall sein, aber auch, wenn der erreichte Entwicklungsstand gut genug ist. So kann man sogar erreichen, das gewünschte Produkt für weniger Geld als vorgesehen zu bekommen - wann gab es das schon mal?

Darüber hinaus fallen mir aber auch noch eine Reihe weiterer Vorteile ein:

• Man erhält sehr schnell lauffähige Software, auch wenn diese noch nicht den gesamten Funktionsumfang aufweist. Dieser wird jedoch Schritt für Schritt mit jeder Iteration steigen.
• Die Abnahme (und damit auch Bezahlung) kann somit immer anhand ausgelieferter Funktionalität erfolgen. Aufwendige Abnahmetests sind nicht mehr nötig.
• Es müssen bei Projektstart noch nicht alle Anforderungen an das Produkt bekannt sein. Stattdessen kann man sich Schritt für Schritt vorarbeiten und muss sich erst dann festlegen, wenn die Entwicklung an diesem Punkt angelangt ist.

Diese Liste erhebt natürlich keinen Anspruch auf Vollständigkeit und kann sicherlich noch erweitert werden (Vorschläge hierzu am besten einfach per Kommentar). Wenn also so viele Gründe dafür sprechen, warum fordern Auftraggeber heute dann Agilität nicht noch viel vehementer ein als bisher? Auch hierfür fällt mir einiges ein:

• Die bei Agilität übliche konstante Mitarbeit des Auftraggebers stellt an diesen höhere Anforderungen als bisher. Neben dem damit verbundenen höheren (Zeit-) Aufwand denke ich hier v.a. an Entscheidungskompetenzen, da vom Auftraggeber verlangt wird, verbindliche Entscheidungen in relativ kurzer Zeit zu treffen. Nicht jede Organisation kann das jedoch leisten.
• Die Entscheider haben keine IT-Kultur. Sie begreifen das Problem der Software-Entwicklung nicht. Gerade bei fachfremden Entscheidern scheint sich bis heute hartnäckig der Eindruck zu halten, dass Software einfach zu spezifizieren und trivial zu programmieren wäre, ohne größeres Risiko. Dass gerade bei Individualsoftware (um die es hier ja geht), in der überwiegenden Mehrheit der Fälle jedoch eher das genaue Gegenteil der Fall ist, scheint sich dagegen bisher noch nicht sehr weit rumgesprochen zu halten.
• Gerade bei größeren Unternehmen treten oft auch organisatorische Zwänge auf. Verträge mit auf Agilität ausgelegten Klauseln (wie im Artikel „Scrum und Festpreisverträge” vorgeschlagen) sind oft einfach nicht vorgesehen. Sie zu installieren, wäre jedoch für ein einzelnes Projekt ein zu aufwendiger Prozess, der ewig dauert, und dessen Ausgang ungewiss ist. Also lässt man es lieber.

Und schließlich natürlich noch der trivialste, aber meiner Meinung nach zugleich auch der wichtigste Grund:

• Scrum ist in vielen Unternehmen einfach noch unbekannt. Es sollte daher unsere Aufgabe sein, dies zu ändern und das Wort hinaus in die Welt zu tragen. Vielleicht schaffen wir es, dass Scrum mal in der Tagesschau kommt :-).

Andererseits: Vielleicht sind hier auch wir als Auftragnehmer mehr gefordert unseren Kunden „ein Angebot zu machen, das sie nicht ablehnen können”. Hier greife ich gerne die Idee meines Kollegen Olivier Guillet auf, der vorschlägt, Angebote auf zwei verschiedene Weisen zu kalkulieren und dem Kunden selbst die Entscheidung zu überlassen:

1. Agil, mit kürzerer Laufzeit, mit Flexibilität bei den Anforderungen, konstanter Mitarbeit des Kunden und einem auf Stundensätzen basierenden Vertrag, der aber im Normalfall zu einem geringeren Preis als bei Festpreisverträgen führt (auch wenn dieser Preis hier natürlich nicht garantiert werden kann)
2. Standard-Festpreis-Modell: Längere Laufzeit, geringere Involvierung des Kunden („Über-den-Zaun”-kompatibel), dafür mit einem garantierten Festpreis, aber teurer als Variante 1.

Und selbst wenn ein Kunde dann immer noch einen Standard-Festpreis-Vertrag verlangt, so kann man ihm die angesprochenen Modifikationen vorschlagen, um etwas Agilität in den Vertrag zu bringen. Die Chancen hierfür stehen nicht schlecht: Uns sind bereits erste Beispiele für Unternehmen bekannt, die speziell an Scrum angepasste Verträge eingeführt haben, und dies sogar aktiv von ihren Auftragnehmern einfordern. Da der erreichte Effizienzgewinn für sich spricht, ist es wohl nur noch eine Frage der Zeit, bis Agilität zum Standard wird.

Mir wäre es jedenfalls recht…

BFE

Über Tag eins des Creative Scrum Workshops wurde ja bereits weiter unten berichtet (Link), hier nun einige Einblicke in die Erlebnisse der Teilnehmer am zweiten Tag:

Nachdem die Anforderungen geklärt waren (Struktur), konnten wir 2 Sprints für die Erstellung der Broschüre durchlaufen lassen.

Im ersten Sprint wollten wir in Untergruppen Stichpunkte für jedes Thema sammeln, die Texte dazu verfassen und Korrektur lesen, so dass wir im zweiten Sprint die Texte optisch gestalten (Lay-out) und zusammensetzen konnten.

Aber während des Sprintdurchlaufs merkten wir, dass noch weitere Aufgaben (wie Zielgewichtung und Informationsbeschaffung) erledigt werden mussten, bevor wir mit dem Textschreiben beginnen konnten und auch dass das Textverfassen länger dauerte als ursprünglich angenommen.

So wurden dann im zweiten Sprint die Aufgaben des ersten Sprints beendet und Layout-Erstellung und Text-Zusammensetzen auf die nächste Woche verschoben.

Was haben wir in dem Scrum-Workshop gelernt?

Dass Scrum eine super Methode ist, um strukturiert und effizient in Teams zu arbeiten und sich diese auf verschiedenste Themen anwenden lässt. Zudem haben wir gemerkt, wie wichtig eine klare Arbeitsanweisung des „product owners” für eine zügige Aufgabenerledigung ist und dass eine vorherige Abschätzung des (Zeit-)aufwands für jede Aufgabe durchaus hilfreich sein kann.

Auch wenn wir mit der Broschüre nicht ganz fertig geworden sind - die Roh-Texte für unsere Broschüre sind erstellt worden!

Ein großes Dankeschön an Christof Stierlen und Alexander Maisch für die Bereitstellung von Ressourcen und die zielgerichtete Anleitung sowie an Florian Forster und Harry Wartig für die Verwendung der computergestützten „creative collaboration tools”.

Manuela Weber für das TEG-Team

Nur äußerst selten werden die Worte Kreativität und Softwareentwicklung in einem Atemzug genannt. Jahrzehntelang behauptete sich eine “ingenieursmäßige” Perspektive auf die Softwareentwicklung, getreu dem Motto: eine Software zu programmieren ist wie ein Haus bauen. Zunächst müssen exakte Pläne vorliegen, die dann von den Bauarbeiten “implementiert” werden und am Ende steht das Traumgebäude in seiner vollen Pracht vor dem stolzen Eigner. Eine kreative Ausgestaltung durch die Bauarbeiter, die womöglich nicht dem geplanten Vorgehen entsprechen, ist in diesem Model ungewünscht.Die Praxis hat nun aber gezeigt, dass die Entwicklung (nicht-trivialer) Softwaresysteme gemäß dem zugrunde liegenden, streng sequentiellen “Wasserfallmodell” allzu häufig scheitert. Nicht zuletzt diese negativen Erfahrungen führten schließlich zur Formulierung des “Agilen Manifests”, hinter dem sich nichts geringeres als ein Paradigmenwechsel verbirgt: Softwareentwicklung wird hier als empirischer, dynamischer Prozess verstanden, der hochgradig von den beteiligten Individuen geprägt wird.

In SCRUM zeigt sich die Fokussierung auf die Individuen in der Betonung der (gleichberechtigten) Teamarbeit. Auch die “Schutzfunktion” des SCRUM Masters für sein Team, das Führen eines Impediment-Logs, das Daily-Scrum-Meeting und die fest eingeplanten Reviewphasen sind Facetten, die auf die Wertschätzung der Teammitglieder sowie die Schaffung von Freiräumen für diese abzielt. Genau diese Freiräume bietet nun auch eine optimale Ausgangsbasis für Kreativität und Innovation, die durch zu detailverliebte Projektpläne und Arbeitsteilungsprozesse ansonsten wenig Chancen haben.

Diesem Gedanken folgend ging es im IF-/TEG-/TUM Creative-Scrum-Workshop vom 8./9.August unter anderem darum, zu erforschen, an welchen Stellen und in welchem Rahmen im SCRUM-Projektprozess die Kreativität der Teams aktiv unterstützt werden kann. Dazu wurde den Teilnehmern Zugänge zur IdeaStream-Plattform (www.ideastream.de) bereitgestellt. IdeaStream ist eine Anwendung mit der Teams über einen Browser kollaborativ (in Echtzeit) Kreativitätstechniken durchführen können. Die angebotenen Techniken reichen dabei vom “klassischen” Brainstorming über den Morphologischen Kasten bis hin zu Ideenbewertungstechniken. Den Teilnehmern wurde dabei nicht vorgegeben, an welchen Stellen sie die Anwendung einzusetzen haben, sondern sie konnten sich frei entscheiden, sie nach Bedarf zu verwenden.

Am Ende des Workshops hat sich gezeigt, dass die Nutzung eines Kreativitätsunterstützungstools in einem SCRUM-Prozess an mehreren Stellen sinnvoll sein kann:

- Beim Sprint-Planning: Zum Aufteilen der Backlog-Einträge in Tasks, zum Abwägen unterschiedlicher Implementierungsansätze

- evtl. auch zum Aufwandschätzen (Planing-Poker, wurde aber im Workshop noch konventionell abgehalten)

- Bei der Retrospektive: Zum Sammeln, Organisieren und Archivieren des Feedbacks. An dieser Stelle kann ein anonymisiertes Brainstorming den Teilnehmern angenehmer sein als ein “klassisches” Brainstorming.

- Fallweiser Einsatz, ggf. in Ad-Hoc-Gruppen, zur Bearbeitung der Tasks: Es war zu beobachen, dass die Teilnehmer auch während der Bearbeitung der Tasks von der Kreativitätsunterstützung Gebrauch gemacht haben. Dies geschah spontan und selbstorganisierend in Ad-Hoc-Gruppen mit unterschiedlichen, auch wechselnden Teilnehmerkreisen. Insbesondere die Ideenbewertungsfunktion war ein beliebtes Abstimmungsinstrument für die Gruppe.

In einer sich dem Workshop anschließenden Umfrage bescheinigten alle Teilnehmer, dass sich der Einsatz unterschiedlicher Kreativitätstechniken insgesamt positiv auf die Sitzungsergebnisse ausgewirkt hat. Auch wurde das gemeinsame, gleichzeitige Arbeiten an Ideen von der großen Mehrheit der Teilnehmer als positiv bewertet. Ein Wermutstropfen stellte allerdings der Zusatzaufwand dar, der mit der Kreativitätstechnikunterstützung einherging - was aber vornehmlich auf technische Probleme am ersten Workshoptag zurückzuführen ist.

Aus dem Workshopverlauf wurde darüber hinaus deutlich, dass auch eine sich im wesentlichen selbst abstimmende Gruppe einen erfahrenen Moderator benötigt, um effizient arbeiten zu können. Dieser Moderator wird auch bis auf weiteres nicht durch eine wie auch immer geartete Computeranwendung ersetzt werden können. Allerdings kann eine Kreativitätsunterstützungssoftware durch strukturelle Führung sowie Informationsbereitstellung den Moderationsaufwand erheblich verringern.

Florian Forster, TU München.

08.08.08, 08:08 Uhr Andere heiraten um diese Zeit, und auch wir starten in eine neue WeltWir haben bei der InterFace AG gemeinsam mit der Technischen Universität München und TEG – the entrepreneurial group eine Workshop vorbereitet, um zu erproben, wie wir die agile Vorgehensmethode SCRUM unterstützen können mit Hilfe von Creative Collaboration Tools.

Nachdem wir uns im Vorfeld viele Gedanken gemacht haben (siehe Post 1 und Post 2), geht es nun an die Umsetzung. Die Richtung ist klar:

Creative Scrum = Kreativitätstools + Scrum Methode

Pünktlich treffen sich die Teilnehmer bei InterFace in Unterhaching im Seminar-Stockwerk zur Begrüßungs- und Vorstellungsrunde.

Als erstes erhalten wir von Alexander Maisch, einem Scrum-Master der InterFace AG, eine gezielte Einführung in die Grundlagen und Vorgehensweisen von SCRUM. Die Rollen von Product Owner, Team und Scrum-Master werden erklärt und mit Praxisbeispielen untermauert.

Als nächstes stellt Florian Forster von der TU München die IdeaStream-Plattform vor, die dort für die Erprobung der Creative Collaboration Tool - Fragestellungen entwickelt und eingesetzt wird.

Nach der Mittagspause geht es an die praktische Anwendung. Die Laptops werden gezückt, die Ideen sammeln sich sehr rasch auf der elektronischen Plattform an. Auch das Sortieren und Bewerten der gefundenen Ideen geht mit jedem Durchgang schneller von der Hand.

Ganz typischen Fragestellungen werden behandelt: Wer sind die Stakeholder im gewählten Praxisprojekt ? Was sind ihre Interessen und Ziele ? Wie können wir diese Ziele unter einen Hut bringen und gemeinsam erreichen ?

Mit der Zeit machen alle Beteiligten wertvolle Erfahrungen, auch ganz praktische Probleme werden gelöst: Ja, das WLAN ist mit zweistelligen Teilnehmerzahlen anfangs etwas überfordert. Und auch das stimmt: eine Moderation ist in jeder Phase sehr wichtig, trotz oder vielleicht manchmal auch wegen der hoch motivierten Teilnehmer.

Aber am Ende des Tages haben wir den ersten Scrum-Sprint in dieser Konstellation geschafft, die Haupthindernisse sind aus dem Weg geräumt, erste Ergebnisse sind gefunden.

Mit entsprechend viel Schwung geht es am nächsten Tag weiter. Und nach den zwei folgenden Scrum-Sprints sind sich alle Beteiligten einig: Wir sind inhaltlich mit der Praxis-Problemstellung zu einem guten Ergebnis gekommen, Scrum als Vorgehensmethode hat dabei sehr geholfen, und der Einsatz der Creative Collaboration Tools war eine wirkliche Hilfe.

Jeder, der es miterlebt hat, war von der guten Stimmung, den Arbeitshilfsmitteln und den Ergebnissen sehr angetan. Wir haben gemeinsam die Überzeugung gewonnen: Ein Ausbau dieser Workshop-Art lohnt sich für alle Beteiligten. Wir verfolgen die Idee weiter.

CST