Diese Woche hatte ich ein interessantes Erlebnis. Ich hatte den Vorschlag im "Scrum of Scrums" gemacht, unternehmensweite DoDs einzuführen, welche auch die Bereiche der Organisation einschließen sollten, die aktuell immer wieder zu Problemen wegen mangelhafter Qualität führen. Dieser Schritt hätte auch zu einer "Definition of Ready" der POs führen können - was dem Unternehmen gut tun würde. Soweit kam es aber nicht. Nach einer relativ langen und äußerst lebhaften Diskussion stellte sich heruas, dass einige der insgesamt 8 Teams ihre DoD nicht kannten. Noch schlimmer: Sie wussten nicht einmal, was genau das ist. Natürlich habe ich direkt Gegenmaßnahmen ergriffen - trotzdem kann es vielleicht dem ein- oder anderen Leser helfen, wenn er versteht, wie es dazu kam.
Vor etwa einem halben Jahr begann ich ein Engagement bei einem Kunden. Damals gab es keine Definition of Done, auch andere Grundelemente von Scrum waren nicht vorhanden. Im Grunde wurde Wasserfall gemacht, man hatte es nur neu gelabelt. Ich führte zunächst ein "Scrum of ScrumMasters" ein und brachte als erstes Thema die DoD auf den Tisch. Wir beschlossen, diese einzuführen. Von unseren Anstrengungen scheinbar entkoppelt, fiel unmittelbar danach eine DoD als Weisheit des "Test-Teams" (ein weiteres Scrum-But) von oben herab und wurde als verpflichtend deklariert. Diese DoD war mit keinem Team abgesprochen und schoss meilenweit am Ziel vorbei. Meine Reaktion auf diese DoD war kurz: Ich bat meine Teams, diese Email zu löschen und wie geplant selbst eine DoD zu entwerfen und mit dem PO zu verhandeln. Dies setzte ich auch gegenüber dem Test-Team durch und coachte die übrigen ScrumMaster darin, eine DoD zu entwickeln, einzuführen sowie kontinuierlich zu verbessern. Die Kollegen vermeldeten kurz danach Erfolg. In der (ebenfalls neu eingeführten) Retrospektive wurden die DoDs überarbeitet und eingeführt, in den folgenden Reviews wurde jedem Team die Frage gestellt, ob die DoD auch bei allen fertigen Stories eingehalten wurde. Dies wurde meist bejaht.
Klingt doch soweit in Ordnung. Wie konnte es trotzdem zu solchen erheblichen Defiziten kommen?
Es stellte sich heraus, dass einer der Scrum Master Kollegen es versäumt hatte, seinen Teams zu erklären, was eine DoD ist und wofür man sie braucht. Stattdessen wurde eine DoD per Email an das Team geschickt ("das ist jetzt eure DoD") und natürlich sofort vom Team ignoriert und vergessen. In der Folge einigte man sich auf den "Daumen des Product Owners" als Definition of Done - hop oder top wie im alten Rom. Nur leider hatten dadurch weder das Team noch der PO auch nur den Hauch einer Ahnung, wie gut die Qualität der gelieferten Features war. Auch unterschied sich die Qualität von Story zu Story stark. Jetzt sind es genau diese beiden Teams, die in einer Flut von Bugs versinken. Der Scrum Master dieser Teams hat auf ganzer Linie versagt - und ist leider nicht mehr verfügbar, um ihn zu coachen (er hat sich anderen Herausforderungen gestellt).
Was haben wir aus diesen Fehlern gelernt? Wie lösen wir das Problem?
Zunächst habe ich den Teams erklärt, was eine DoD ist und wofür sie gut ist. Auch habe ich die Folgen der fehlenden DoD transparent gemacht. Anschließend tat ich das Gleiche mit den Product Ownern und stieß sofort auf Zustimmung und Verständnis. Zum Nachlesen habe ich diese Informationen auf einer kleinen Wikiseite dokumentiert. Die POs werden zusammen mit ihren Teams und dem in Kürze verfügbaren neuen Scrum Master sinnvolle DoDs definieren.
Als weitere Maßnahme werden sich die Scrum Master in Zukunft gegenseitig coachen. Neben dem "Scrum of ScrumMasters", wird es ein intensives Pairing geben. Immer zwei Scrum Master werden sich in wechselnden Paaren gegenseitig unterstützen und von einander lernen. So wird hoffentlich verhindert, dass uns erneut entgeht, wenn ein Kollege Hilfe braucht.
Einen erneuten Anlauf für unternehmensweite DoDs wird es wohl in den nächsten paar Sprints nicht geben...
Monday, August 22. 2011
Die Geschichte von Scrum aus Jeff's Perspektive
Es gibt viele Mythen und Geschichten darüber, wie genau Scrum eigentlich erfunden wurde. Jetzt ist mir ein Podcast in die Finger geraten, der Licht ins Dunkel bringt. Jeff erzählt darin, wie alles begonnen hat. Einige der bemerkenswerteren Punkte möchte ich hier herausgreifen.
Ich finde diese Einblicke spannend und hoffe, dass ihr euch auch daran erfreuen konntet. Ich werde mal sehen, ob ich von Ken eine ähnlich detaillierte Sicht finde. Sonst frage ich ihn, wenn ich ihn das nächste Mal sehe.
- Jeff war Kampfflieger in der AirForce - unter anderem auch in Vietnam. 11 Jahre seines Lebens hat er in diese Tätigkeiten investiert. Irgendwann hat er realisiert, dass seine Kameraden in diesem gefährlichen Beruf ihre Leben verlieren und er hat sich dazu entschieden, in die Privatwirtschaft zu wechseln. Ken war übrigens bei den Marines - aber dazu ein andermal mehr.
- Jeff wechselte in den Medizinbereich und hat dort auch seine Doktorarbeit zur Krebsforschung geschrieben ("Was bringt eine Zelle dazu, zu einer Krebszelle zu werden?").
- Ein Schlüsselerlebnis war damals, dass er mit einigen Leuten aus dem Krankenhaus einen Flugzeugträger im aktiven Dienst besichtigt hat. Jeder an Deck - auch der Rangniedrigste auf dem untersten Deck - konnte ihnen jederzeit sagen, was die Mission des Schiffes war. Die Leute im Krankenhaus konnten das nicht von sich behaupten - nicht einmal die Ärzte kannten die Mission.
- Die ersten tiefen Berührungen mit Projektmanagement gab es danach im Bankensektor. Von diesen wurde er angeworben, um ein eher technisches Problem zu lösen.
- Er musste feststellen, dass es
so many projects that were crashing and burning
gab - genau wie damals im militärischen Flugdienst mit seinen Kameraden. - Er begann diese Situation mit den Methoden, die er auch im Rahmen seiner Doktorarbeit genutzt hatte, zu analysieren. Das Ergebnis war erstaunlich: Die Projekte waren immer zu spät; Druck kam von oben; Todesmärsche wurden angeordnet; die Leute hatten einen Hang zum Burnout und definitiv keinen Spaß an der Arbeit; Je größer der Druck wurde, desto mehr Verspätung bekam das Projekt; auch Conways Law ("an organization's structure will reflect in the code") war offensichtlich
- In der Arbeit mit jungen Startups versuchte Jeff dann, Gegenmittel zu entwickeln. Das begann mit einer ausführlichen Recherche von 30 Jahren Harvard Business Review.
- Fündig wurden sie schließlich im Aufsatz New New Product Development Game von Nonaka und Takeuchi. Darin wurden sechs Erfolgsfaktoren der erfolgreichen Unternehmen genannt:
- Eingebaute Instabilität
- Selbstorganisierende Projektteams
- Überlappende Entwicklungsphasen
- Multilearning
- sanfte Kontrolle / Selbstkontrolle
- Organisationsweiter Lerntransfer
- Jeff übernahm diese Punkte als Basis und entwickelte sie mit Hilfe anderer Erfolgsgeschichten (zum Beispiel von Borland) weiter. Den Namen behielt er bei.
- Irgendwann während dieses Prozesses entschlossen sich Jeff und Ken - der zu diesem Zeitpunkt bereits ähnlich weit in seinen Überlegungen und Bemühungen gekommen war - zusammenzuarbeiten.
- Kurz danach gab es dann die OOPSLA - auf dem es quasi den offiziellen Kick-Off für Scrum gab.
Ich finde diese Einblicke spannend und hoffe, dass ihr euch auch daran erfreuen konntet. Ich werde mal sehen, ob ich von Ken eine ähnlich detaillierte Sicht finde. Sonst frage ich ihn, wenn ich ihn das nächste Mal sehe.
Sunday, August 14. 2011
Meinungen und Hintergründe zum ScrumGuide
Einige Punkte aus dem ScrumGuide 2011 werden in der Community heiß diskutiert. Während man die Art und Weise kritisieren kann, mit der einige Kollegen "um sich schlagen", so sind einige der Argumente durchaus diskussionswürdig.
Die meisten Diskussionspunkte führen deshalb zu erhitzten Gemütern, weil die Idee des ScrumGuides sich geändert hat. Während in der Vergangenheit versucht wurde, "ganz Scrum" zu beschreiben ist die neue Idee, ein "Regelbuch" herauszubringen, das auch nur dieses enthält: Die Regeln. Strategien, Best Practices und Hintergründe sind nicht Bestandteil dieser "Spielanleitung", sondern separate Dokumente - wenngleich auch sehr wichtig.
Sehen wir uns vor diesem Hintergrund die einzelnen Punkte etwas genauer an:
Es kann immer helfen, sich auch mit den Hintergründen einer Angelegenheit zu befassen, anstatt nur die eigenen Schlüsse zu ziehen. "Kommunikation über Dokumentation" sollte normalerweise auch bedeuten, dass ich zunächst den Verursacher meines schlechten Bauchgefühls befrage, bevor ich ein Dokument gegen ihn verfasse. Ken redet übrigens gerne über den ScrumGuide: Fragt ihn doch einfach, wenn ihr einen bestimmten Punkt diskutieren wollt.
- Die hinter Scrum stehenden Werte (Mut, Offenheit, Vertrauen, Fokus...) tauchen nicht im ScrumGuide auf
- Forecast ist "schwächer" als Commitment
- Das "Team" heißt jetzt "Development Team"
- Burndowns sind verschwunden
- Es gibt keine Releaseplanung mehr
Die meisten Diskussionspunkte führen deshalb zu erhitzten Gemütern, weil die Idee des ScrumGuides sich geändert hat. Während in der Vergangenheit versucht wurde, "ganz Scrum" zu beschreiben ist die neue Idee, ein "Regelbuch" herauszubringen, das auch nur dieses enthält: Die Regeln. Strategien, Best Practices und Hintergründe sind nicht Bestandteil dieser "Spielanleitung", sondern separate Dokumente - wenngleich auch sehr wichtig.
Sehen wir uns vor diesem Hintergrund die einzelnen Punkte etwas genauer an:
- Die hinter Scrum stehenden Werte fehlen. Sie sind das, worauf Scrum aufbaut und weshalb Scrum entwickelt wurde. Unbestreitbar sind sie das Wichtigste an Scrum überhaupt (zumindest für mich). Trotzdem stehen sie genau da: Hinter Scrum. Sie sind nicht Bestandteil des Regelwerkes, sondern der Grund dafür, dass bestimmte Regeln entwickelt wurden. Es ist zwar wünschenswert, aber nicht notwendig, dass jeder Anwender von Scrum versteht, warum bestimmte Regeln (z.B. Retrospektive oder Timeboxing) existieren - solange er sie befolgt. Meine Vision ist trotzdem, die Werte von Scrum in die Welt hinaus zu tragen (dazu brauche ich aber den ScrumGuide nicht).
- Forecast ist schwächer als Commitment. Auch hier kann es helfen, den Urheber zu fragen. "Commit" war in Scrum schon immer als "forecast" gemeint. Um es noch etwas mehr zu präzisieren: Schon immer hat das Team versprochen, fokussiert und mit Hochdruck auf das Sprintziel (bzw. die PBIs) hinzuarbeiten, bei gleichzeitiger Einhaltung der DoD. Schon immer galt bei der Auswahl der PBIs, dass das Team zwar glaubt diese zu schaffen, sich aber nicht sicher ist. Das wurde in der Vergangenheit aber von den "Druckaufbauern" und "Kontrollfreaks" missverstanden: Diese Fraktionen werteten auch den zweiten Teil als "Das Team hat versprochen, das Ziel zu erreichen". Das ist natürlich falsch und wird durch "forecast" richtig gestellt. Noch etwas: Wer es nötig hat, hier Druck aufzubauen, sollte sich fragen, ob er seinem Team vertraut ("trust" ist übrigens ein Grundwert von Scrum). Menschen denken unter Druck nicht schneller.
- Manch einer hat Angst, dass die Umfirmierung von "Team" zu "Development Team" dazu führt, dass einige der Teammitglieder sich angegriffen fühlen. Schließlich "entwickeln" Tester und UI-Experten ja nicht. Oder etwa doch? In meinen Augen ist "Entwicklung" nicht gleichbedeutend mit "Programmierung", sondern bezeichnet den Akt der Produkterstellung von der Idee bis zur Auslieferung. Wenn sich jetzt Teammitglieder darüber beschweren, wird eher ein schon länger existierendes Problem deutlich. Nachforschen kann hier nicht schaden.
- Kann man Scrum auch ohne Burndowns machen? Na klar! Die Dinger sind zwar einfach und oft hilfreich, aber eben nicht maßgeblich für Scrum. Ich kann meinen Fortschritt auch anders visualisieren. Zum Beispiel mit einem Taskboard. Oder mit Burnup-Charts. Oder wie es eben sonst nützlich und angebracht in meinem Team ist.
- Die fehlende Releaseplanung hat auch mich zunächst irritiert. Dann ist mir aber der folgende Leitsatz eingefallen: "Was braucht man, um mit Scrum beginnen zu können? - ein Ziel und ein Team!". Nicht in jedem Setting ist eine Releaseplanung sinnvoll. Außerdem ist eigentlich jeder Sprint ein Release ("potentially shippable product increment"), daher sollte man wohl eher von einer "Langfristplanung" sprechen. Diese sollte wiederum jeder PO haben - in dem Maße, in dem es für sein Team und sein Projekt/Produkt sinnvoll ist.
Es kann immer helfen, sich auch mit den Hintergründen einer Angelegenheit zu befassen, anstatt nur die eigenen Schlüsse zu ziehen. "Kommunikation über Dokumentation" sollte normalerweise auch bedeuten, dass ich zunächst den Verursacher meines schlechten Bauchgefühls befrage, bevor ich ein Dokument gegen ihn verfasse. Ken redet übrigens gerne über den ScrumGuide: Fragt ihn doch einfach, wenn ihr einen bestimmten Punkt diskutieren wollt.
Monday, August 1. 2011
Scrumguide 2011 erschienen
Letzte Woche (eigentlich vorletzte Woche, aber der Guide wurde nochmals korrigiert) ist der neue Scrumguide erschienen. Bemerkenswert: Jeff und Ken haben ihn gemeinsam geschrieben und unterzeichnet. Damit ist eine Brücke zwischen Scrumalliance und Scrum.org geschlagen. Allerdings ist dies bislang die einzige Verbindung zwischen den beiden Organisationen.
Inhaltlich möchte ich nur auf eine Änderung im aktuellen Scrumguide eingehen: Commitment gibt es jetzt nicht mehr. Es wurde umbenannt in Forecast. Warum ist das so?
Commitment war ursprünglich gemeint als "Das Team verspricht, alles in seiner Macht stehende zu tun, um das Ziel zu erreichen". Ausgelegt wurde "Commitment" aber meist als "das Team hat versprochen, das Ziel zu erreichen". Das klappt natürlich nicht - woher soll das Team vorher wissen, was es erreichen wird? Wissen können wir das nicht - nur vermuten. Alles was wir tun, ist eine Vorhersage abgeben, eine Schätzung also. Tut man das nicht und sieht Commitment als Versprechen an, so werden wieder Command and Control Strukturen eingeführt: Der PO kontrolliert dann (oft mit Hilfe des Scrum Masters), dass das Team sein Versprechen auch einhält. Das erzeugt unnötigen Druck, denn wie ihr ja wisst, denken Menschen unter Druck nicht schneller (De Marco).
Ich glaube fest daran, dass ein motiviertes Team sowieso alles in seiner Macht stehende tut, um das sich selbst gesetzte Ziel zu erreichen.
Inhaltlich möchte ich nur auf eine Änderung im aktuellen Scrumguide eingehen: Commitment gibt es jetzt nicht mehr. Es wurde umbenannt in Forecast. Warum ist das so?
Commitment war ursprünglich gemeint als "Das Team verspricht, alles in seiner Macht stehende zu tun, um das Ziel zu erreichen". Ausgelegt wurde "Commitment" aber meist als "das Team hat versprochen, das Ziel zu erreichen". Das klappt natürlich nicht - woher soll das Team vorher wissen, was es erreichen wird? Wissen können wir das nicht - nur vermuten. Alles was wir tun, ist eine Vorhersage abgeben, eine Schätzung also. Tut man das nicht und sieht Commitment als Versprechen an, so werden wieder Command and Control Strukturen eingeführt: Der PO kontrolliert dann (oft mit Hilfe des Scrum Masters), dass das Team sein Versprechen auch einhält. Das erzeugt unnötigen Druck, denn wie ihr ja wisst, denken Menschen unter Druck nicht schneller (De Marco).
Ich glaube fest daran, dass ein motiviertes Team sowieso alles in seiner Macht stehende tut, um das sich selbst gesetzte Ziel zu erreichen.
(Page 1 of 1, totaling 4 entries)