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.
Sunday, July 24. 2011
Wozu braucht Scrum das Management?
Scrum definiert drei Rollen: Das Entwicklungs-Team, den Product Owner und den Scrum Master. Alle drei sind in gewissem Sinne Management-Rollen: Das Team managt sich selbst, der PO managt das Produkt und der Scrum Master den Prozess. Wofür aber brauchen wir das "reguläre" Management?
Die Antwort ist einfach: Wir brauchen sie dafür, dass sie das tun, was ihre hoheitlichen Aufgaben sind. Die Entwicklung von Visionen, Zielen und Strategien. Die Gestaltung der Organisation. Und natürlich die Definition und das aktive Leben der Grundwerte im Unternehmen, insbesondere Mut, Vertrauen und Transparenz.
Bei einer Scrum-Einführung gibt es drei Hauptformen:
Achja: Nehmen Sie die Verzehnfachung nicht zu wörtlich. Es sind die absoluten Ausnahmeimplementierungen, die das erreichen.
Die Antwort ist einfach: Wir brauchen sie dafür, dass sie das tun, was ihre hoheitlichen Aufgaben sind. Die Entwicklung von Visionen, Zielen und Strategien. Die Gestaltung der Organisation. Und natürlich die Definition und das aktive Leben der Grundwerte im Unternehmen, insbesondere Mut, Vertrauen und Transparenz.
Bei einer Scrum-Einführung gibt es drei Hauptformen:
- U-Boot-Scrum (Submarine Scrum)
- Scrum von unten (Bottom-up Scrum) und
- Scrum von oben (Top-Down Scrum)
Achja: Nehmen Sie die Verzehnfachung nicht zu wörtlich. Es sind die absoluten Ausnahmeimplementierungen, die das erreichen.
Thursday, July 21. 2011
Warum Scrum Murks ist
Relativ häufig trifft man als Coach in deutschen Unternehmen früher oder später auf ein Team, das mit einer gewissen Häme darauf hinweist, dass "Scrum" rückwärts gelesen "Murcs" ergibt. Das passiert jedoch nicht in allen Teams. Woran liegt das?
Meine Theorie ist, dass die Teams dadurch zu erkennen geben, dass in "ihrer" Scrum-Implementierung etwas nicht stimmt. In allen Fällen, die ich bislang gesehen habe, haben folgende Punkte zugetroffen:
Der "Murcs"-Hinweis war demnach ein Hilferuf des Teams an mich, den Scrum Master / Coach. Da wundert es nicht, dass ich den Spruch nicht mehr höre, wenn die Probleme angegangen werden und die Lethargie das Team verlässt.
Motivierte Teams Murcsen nicht! - oder wie Alex Armstrong es ausgedrückt hat: "Well, if they are doing Scrum backwards, what do they expect?"
Meine Theorie ist, dass die Teams dadurch zu erkennen geben, dass in "ihrer" Scrum-Implementierung etwas nicht stimmt. In allen Fällen, die ich bislang gesehen habe, haben folgende Punkte zugetroffen:
- Das Unternehmen verwendete schon seit einer Weile einen Prozess, den es Scrum nannte. Der Zauber des Neuen, Aufregenden war verflogen.
- Das Unternehmen machte kein Scrum, sondern "ScrumBut", hatte also wesentliche Bestandteile von Scrum verändert.
- Schwerwiegende Impediments schwelten schon seit langem und wurden nicht gelöst. Meist aufgrund mangelnder Unterstützung durch die Mächtigen.
- Die Teammitglieder waren entsprechend frustriert
Der "Murcs"-Hinweis war demnach ein Hilferuf des Teams an mich, den Scrum Master / Coach. Da wundert es nicht, dass ich den Spruch nicht mehr höre, wenn die Probleme angegangen werden und die Lethargie das Team verlässt.
Motivierte Teams Murcsen nicht! - oder wie Alex Armstrong es ausgedrückt hat: "Well, if they are doing Scrum backwards, what do they expect?"
Thursday, July 14. 2011
Warum E-Mail-Kommunikation das Werk des Teufels ist
Gelesen hat das wohl mittlerweile jeder Agilist: Face-to-Face soll man kommunizieren und nicht schriftlich oder per Mail. Aber warum eigentlich? In den letzten Tagen habe ich ein sehr interessantes Beispiel dazu erlebt:
Was ist bis hierher passiert? Die Sachebene war nicht das Thema, der Konflikt kam von der Beziehungsebene. Der angemailte Kollege hatte schon die erste Mail als Angriff aufgefasst. Statt den Konflikt auszutragen, wollte er ihn umgehen - daher die abwehrende Haltung. Meine E-Mail wurde dann als "runter zitieren" empfunden, was das Gefühl des Angriffs noch weiter verstärkt hat. Wieder wurde versucht, die Angelegenheit nicht selbst zu lösen, sondern zu delegieren ("Regel das mit meinem ScrumMaster"). Der Ansatz meines Teammitglieds eine persönliche Klärung herbeizuführen wurde ebenfalls als (massiver) Angriff erlebt: Ein groß gewachsener Mann, der den Türrahmen füllt und auch nach einer klaren Aufforderung ("Hau ab!") nicht weicht, sondern sagt: "Nein, ich will das jetzt klären!". Keine Fluchtmöglichkeit. In die Ecke gedrängt.
Umgekehrt hat mein Teammitglied das Verhalten des Kollegen als höchst unprofessionell und irrational erlebt. Er fühlte sich beleidigt und missverstanden - schließlich wollte er ihm nur die Hand reichen und die Angelegenheit aus der Welt schaffen. Ein Musterbeispiel von einem Konflikt.
Wie ging es weiter?
Was habe ich daraus gelernt?
- Ein Teammitglied von mir war in einer Besprechung mit dem Abstimmungsverfahren unzufrieden. Da die Besprechung schön timegeboxt war, konnte er sein Anliegen auch nicht mehr vorbringen.
- Mit seinem Anliegen kam er zu mir, seinem ScrumMaster. Meine Antwort war: "Geh hoch und kläre das selbst mit der Person."
- Mein Teammember schrieb daraufhin eine E-Mail an den Kollegen, in der sinngemäß stand: "Ich bin unzufrieden mit der Art und Weise, wie das gelaufen ist und komme gleich hoch, um das mit dir zu klären." Diese Mail war nur an den Kollegen adressiert.
- Die Antwort des Kollegen kam prompt per Mail: Es gebe nichts zu klären, man könne im nächsten Meeting darüber reden. Diese E-Mail war allerdings nicht nur an den Kollegen, sondern an sämtliche Scrum-Teams adressiert. So um die 70 Leute durften also mitlesen.
- Der Kollege war sauer und wollte zurückmailen. Davon konnte ich ihn abhalten. Stattdessen habe ich - entgegen meiner sonstigen Vorgehensweise - an ihn geschrieben (ein Fehler, ich hätte direkt hochgehen sollen!): "Es ist unnötig, eine Email an alle zu schreiben, wenn die Angelegenheit nur zwei Leute betrifft. Komm doch kurz runter, dann können wir das diskutieren."
- Auch hier kam prompt die Antwort. Adressiert an sein Scrum-Team (immerhin...): "Es gibt nichts zu klären, regel das mit meinem ScrumMaster." - was zum Henker hat der damit zu tun?
- Hier habe ich endgültig begriffen, dass E-Mails ein Fehler sind und uns nicht helfen. Im Dialog mit meinem Teammitglied haben wir entschieden, dass er hoch geht und ein Gespräch versucht. Das hat er dann auch sofort gemacht.
- Ein paar Minuten später kam er wieder zurück - sauer und frustriert. Er wurde wohl als "Quertreiber" beschimpft und mit "hau ab" aus dem Büro geworfen. Auch mehrere Versuche der Gesprächsaufnahme haben hier nicht funktioniert.
- Wir einigten uns darauf, die Angelegenheit zu überschlafen.
Was ist bis hierher passiert? Die Sachebene war nicht das Thema, der Konflikt kam von der Beziehungsebene. Der angemailte Kollege hatte schon die erste Mail als Angriff aufgefasst. Statt den Konflikt auszutragen, wollte er ihn umgehen - daher die abwehrende Haltung. Meine E-Mail wurde dann als "runter zitieren" empfunden, was das Gefühl des Angriffs noch weiter verstärkt hat. Wieder wurde versucht, die Angelegenheit nicht selbst zu lösen, sondern zu delegieren ("Regel das mit meinem ScrumMaster"). Der Ansatz meines Teammitglieds eine persönliche Klärung herbeizuführen wurde ebenfalls als (massiver) Angriff erlebt: Ein groß gewachsener Mann, der den Türrahmen füllt und auch nach einer klaren Aufforderung ("Hau ab!") nicht weicht, sondern sagt: "Nein, ich will das jetzt klären!". Keine Fluchtmöglichkeit. In die Ecke gedrängt.
Umgekehrt hat mein Teammitglied das Verhalten des Kollegen als höchst unprofessionell und irrational erlebt. Er fühlte sich beleidigt und missverstanden - schließlich wollte er ihm nur die Hand reichen und die Angelegenheit aus der Welt schaffen. Ein Musterbeispiel von einem Konflikt.
Wie ging es weiter?
- Zunächst habe ich mit dem ScrumMaster des Kollegen gesprochen. Dieser hatte bereits mit dem Kollegen geredet und wusste daher über die Gefühlswelt dort Bescheid.
- Wir beschlossen, den Druck vom Kollegen zu nehmen und von uns aus keine weiteren Versuche der Klärung zu unternehmen. Gleichzeitig sollte der ScrumMaster mit dem Kollegen sprechen, ihn auf das gegenseitige Erleben der Situation hinweisen und betonen, dass alle involvierten Personen ihn sehr hoch schätzen. Auch unser Wunsch zur emotionalen Klärung des Vorfalls sollte betont werden.
- Dieses Gespräch fand statt und hatte zum Ergebnis, dass der Kollege sich selbst entschloss, von sich aus das Gespräch zu suchen.
- Leider erfolgte das Gespräch nicht. Die Überwindung war wohl zu groß für den Kollegen. Erst ein "Anschubsen" über den ScrumMaster führte dazu, dass das Klärungsgespräch (unter 4 Augen) wirklich statt fand.
- Die Kollegen entschuldigten sich und bereinigten die Situation. Aus Sicht der Konfliktparteien ist das Problem damit gelöst.
Was habe ich daraus gelernt?
- Jede noch so gut gemeinte E-Mail ist ein Fehler, wenn es um die Beziehungsebene geht
- Ich selbst sollte immer auf meine eigenen Ratschläge hören - auch wenn zur selben Zeit noch drei andere Leute etwas von mir wollen
- ScrumMaster sind wichtig - gerade weil sie das Vertrauen ihrer Teammitglieder genießen und dadurch auch die Beziehungsebene gut ansprechen können
Monday, July 11. 2011
Das Scrumorakel-Logo
Heute wurde ich gefragt, wofür das Scrumorakel-Logo steht. Das wird wohl öfters passieren - hier ist die Antwort:
Angefangen hat alles mit dem Portal designenlassen.de. Dort kann man ein Preisgeld ausloben, sein Projekt beschreiben und sich Vorschläge für Logos, Designs, usw. machen lassen. Auf dieser Plattform habe ich mein Logo in Auftrag gegeben und innerhalb von einer Woche ca. 90 Vorschläge erhalten. Gewonnen hat dabei der Vorschlag von Michel Lapka von ML Design: Er hat es geschafft, die beiden Scrum-Kreise (Symbolisch für die Iteration und das Daily Scrum) stilistisch zu integrieren. Gleichzeitig ist es ihm gelungen, diese Scrum-Kreise so anzuordnen, dass mit etwas Phantasie ein "S" erkennbar ist. Begrenzt wird dieses "S" durch ein "O" - einen runden Kreis um das Ganze. Das Orakel "umfasst" also die Gesamtheit von Scrum. Gleichzeitig sind die Formen einfach, ansprechend und einprägsam. Der Metallic-Look und die klaren Linien machen das Ganze in gewisser Weise "edel". Auch wenn ein Orakel als solches nicht seriös ist, so ist es das Logo für sich genommen durchaus.
Ich gebe zu, dass diese Interpretationen dem normalen Betrachter nicht sofort eingängig sein werden. Er wird vermutlich nichtmal auf die Idee kommen, dass das Logo eng mit Scrum und dem Orakel verwoben ist. Ist aber so.
Die Idee mit den verschiedenen Metallen für die verschiedenen Fragen kam mir, da einem Orakel in der Antike Opfergaben dargebracht wurden. Je größer die Opfergabe, desto schwierigere Fragen konnten gestellt werden. Für ein paar "Silbermünzen" gab es also weniger, als für pures "Gold". Daran habe ich mich angelehnt. Allerdings bemühe ich mich, nicht so verschwommen und in Trance zu antworten, wie es die Pythia (das Orakel im alten Griechenland) tat. Trotzdem bleibt natürlich die Pflicht für den Fragesteller, meine Antwort in den Kontext des jeweiligen Problemfalls einzuordnen und zu bewerten.
Angefangen hat alles mit dem Portal designenlassen.de. Dort kann man ein Preisgeld ausloben, sein Projekt beschreiben und sich Vorschläge für Logos, Designs, usw. machen lassen. Auf dieser Plattform habe ich mein Logo in Auftrag gegeben und innerhalb von einer Woche ca. 90 Vorschläge erhalten. Gewonnen hat dabei der Vorschlag von Michel Lapka von ML Design: Er hat es geschafft, die beiden Scrum-Kreise (Symbolisch für die Iteration und das Daily Scrum) stilistisch zu integrieren. Gleichzeitig ist es ihm gelungen, diese Scrum-Kreise so anzuordnen, dass mit etwas Phantasie ein "S" erkennbar ist. Begrenzt wird dieses "S" durch ein "O" - einen runden Kreis um das Ganze. Das Orakel "umfasst" also die Gesamtheit von Scrum. Gleichzeitig sind die Formen einfach, ansprechend und einprägsam. Der Metallic-Look und die klaren Linien machen das Ganze in gewisser Weise "edel". Auch wenn ein Orakel als solches nicht seriös ist, so ist es das Logo für sich genommen durchaus.
Ich gebe zu, dass diese Interpretationen dem normalen Betrachter nicht sofort eingängig sein werden. Er wird vermutlich nichtmal auf die Idee kommen, dass das Logo eng mit Scrum und dem Orakel verwoben ist. Ist aber so.
Die Idee mit den verschiedenen Metallen für die verschiedenen Fragen kam mir, da einem Orakel in der Antike Opfergaben dargebracht wurden. Je größer die Opfergabe, desto schwierigere Fragen konnten gestellt werden. Für ein paar "Silbermünzen" gab es also weniger, als für pures "Gold". Daran habe ich mich angelehnt. Allerdings bemühe ich mich, nicht so verschwommen und in Trance zu antworten, wie es die Pythia (das Orakel im alten Griechenland) tat. Trotzdem bleibt natürlich die Pflicht für den Fragesteller, meine Antwort in den Kontext des jeweiligen Problemfalls einzuordnen und zu bewerten.
Friday, July 8. 2011
Scrum in der Politik?
Wir wissen, dass Scrum in der Softwareentwicklung funktioniert. Kein Wunder - dafür wurde es entwickelt. Wir wissen außerdem, dass es als Instrument zur Organisationsentwicklung eingesetzt werden kann. Elemente daraus können auch für die Hardwareentwicklung und andere Situationen des betrieblichen Alltags genutzt werden. Scrum hinterlässt auch im privaten Umfeld seine Spuren: Wer die Prinzipien verinnerlicht hat, betreibt ständig "Inspect & Adapt", sorgt für Transparenz und fokussiert sich immer auf das Wichtigste. Bei dem ein- oder anderen hängt vielleicht sogar ein Backlog an der Wand...
Was ist mit der Politik? Auch dort müssen Themenfelder ausgewählt, "User Stories" (Gesetze, Eingaben, Petitionen, ...) mit dem höchsten Wert entwickelt und jedes "Release" (zur Wahl) fertige "Produkte" geliefert werden. Transparenz, Offenheit und Mut sind leider kaum erkennbar. Unsere aktuelle Regierung hat nichtmal "Fokus" zu bieten. Ein zielloses rumgeschubst-werden durch die "Stakeholder" ist an der Tagesordnung. "Inspect & Adapt" findet praktisch nicht statt - die gleichen Fehler werden immer wieder gemacht. Klingt eigentlich, wie die meisten Projekte, in denen ich unterstütze.
Wie könnte Scrum in der Politik aussehen?
Zunächst einmal stellen die Abgeordneten oder Parteimitglieder die Teams dar. Sie müssen schuften. Sehr gut: Endlich ein paar Pigs in der Politik
Die Minister und Parteivorstände könnte man als Product Owner betrachten. Sie geben die Richtung vor und entscheiden letztendlich, was auf die Tagesordnung kommt. Die Parteiprogramme (und Koalitionsverträge) könnte man als "Product Backlog" betrachten. Hier steht alles drin, was die POs erreichen wollen. Gestaltet werden sollten diese durch die Stakeholder - also uns, die Wähler. Da wir nur "fertige Produkte" ausliefern dürfen, sollte es für jedes Team eine "Definition of Done" geben. Neben den rechtlichen Aspekten könnte man dort z.B. auch einen Punkt "Wählermeinung abfragen" einbringen. Mit den heutigen modernen Kommunikationsinstrumenten sollte das zu vertretbaren Kosten umsetzbar sein. Natürlich muss dazu die Visibilität quer durch die Republik sehr hoch sein. Der Acceptance-Test ist dann die Abstimmung im Parlament (oder auf dem Parteitag). Lediglich den ScrumMaster vermisse ich noch. Wer sorgt für die Prozesseinhaltung? Wer moderiert und fokussiert die Beteiligten? Ich fürchte, dafür gibt es noch keine Entsprechung in der aktuellen Politik - bitter nötig wäre sie aber. Endlich einer, der weder Macht- noch inhaltliche Interessen verfolgt, sondern nur die Gesamtproduktivität und das persönliche Wohlergehen der Beteiligten im Sinn hat. Hach, wäre das schön!
In den alten, verkrusteten Parteien scheint mir ein so radikaler Ansatz nicht umsetzbar. Selbst die Grünen sind schon korrumpiert. Was bleibt, sind die Piraten (trotz des marketingtechnisch verheerenden Namens). Ich denke, ich sollte mal mit denen reden: Steuerbordbatterien klar, hart anbrassen, drei Strich nach Lee abfallen - diese Breitseite könnte etwas verändern.
Was ist mit der Politik? Auch dort müssen Themenfelder ausgewählt, "User Stories" (Gesetze, Eingaben, Petitionen, ...) mit dem höchsten Wert entwickelt und jedes "Release" (zur Wahl) fertige "Produkte" geliefert werden. Transparenz, Offenheit und Mut sind leider kaum erkennbar. Unsere aktuelle Regierung hat nichtmal "Fokus" zu bieten. Ein zielloses rumgeschubst-werden durch die "Stakeholder" ist an der Tagesordnung. "Inspect & Adapt" findet praktisch nicht statt - die gleichen Fehler werden immer wieder gemacht. Klingt eigentlich, wie die meisten Projekte, in denen ich unterstütze.
Wie könnte Scrum in der Politik aussehen?
Zunächst einmal stellen die Abgeordneten oder Parteimitglieder die Teams dar. Sie müssen schuften. Sehr gut: Endlich ein paar Pigs in der Politik
Die Minister und Parteivorstände könnte man als Product Owner betrachten. Sie geben die Richtung vor und entscheiden letztendlich, was auf die Tagesordnung kommt. Die Parteiprogramme (und Koalitionsverträge) könnte man als "Product Backlog" betrachten. Hier steht alles drin, was die POs erreichen wollen. Gestaltet werden sollten diese durch die Stakeholder - also uns, die Wähler. Da wir nur "fertige Produkte" ausliefern dürfen, sollte es für jedes Team eine "Definition of Done" geben. Neben den rechtlichen Aspekten könnte man dort z.B. auch einen Punkt "Wählermeinung abfragen" einbringen. Mit den heutigen modernen Kommunikationsinstrumenten sollte das zu vertretbaren Kosten umsetzbar sein. Natürlich muss dazu die Visibilität quer durch die Republik sehr hoch sein. Der Acceptance-Test ist dann die Abstimmung im Parlament (oder auf dem Parteitag). Lediglich den ScrumMaster vermisse ich noch. Wer sorgt für die Prozesseinhaltung? Wer moderiert und fokussiert die Beteiligten? Ich fürchte, dafür gibt es noch keine Entsprechung in der aktuellen Politik - bitter nötig wäre sie aber. Endlich einer, der weder Macht- noch inhaltliche Interessen verfolgt, sondern nur die Gesamtproduktivität und das persönliche Wohlergehen der Beteiligten im Sinn hat. Hach, wäre das schön!
In den alten, verkrusteten Parteien scheint mir ein so radikaler Ansatz nicht umsetzbar. Selbst die Grünen sind schon korrumpiert. Was bleibt, sind die Piraten (trotz des marketingtechnisch verheerenden Namens). Ich denke, ich sollte mal mit denen reden: Steuerbordbatterien klar, hart anbrassen, drei Strich nach Lee abfallen - diese Breitseite könnte etwas verändern.
Monday, July 4. 2011
Der Weg der Scrum.org
Gerade komme ich vom 2. ScrumTisch Stuttgart zurück. Ken Schwaber war auch da und hat uns ein paar interessante Einblicke in die aktuellen Entwicklungen der Scrum.org gewährt. Der ScrumGuide wird beispielsweise überarbeitet: Einige Missverständnisse werden ausgeräumt, einigen Fehlentwicklungen wird vorgebeugt. Zum Beispiel wird endlich die Sektion "Artefakte" korrigiert - bislang steht dort das Burndown Chart als Artefakt, jedoch nicht das Product Increment. Aus meiner Sicht der größte Fehler im ScrumGuide.
Auch arbeitet Ken an einem neuen Buch. Bislang habe ich nur die Einleitung lesen können, diese klingt aber vielversprechend. Ich berichte mehr, wenn ich das ganze Werk kenne (was voraus setzt, dass es fertig ist).
Auch arbeitet Ken an einem neuen Buch. Bislang habe ich nur die Einleitung lesen können, diese klingt aber vielversprechend. Ich berichte mehr, wenn ich das ganze Werk kenne (was voraus setzt, dass es fertig ist).
« previous page
(Page 5 of 6, totaling 55 entries)
next page »