Projektarbeit in allen Facetten

Schlagwort: Scrum

Agilität ist nicht New-Work

Posted on by Dr. Eberhard Huber

Agil ist cool, modern, menschenfreundlich, new-workig, demokratisch, selbstorganisiert und rasend schnell. Derzeit wird vieles in einen Topf geworfen, das nichts miteinander zu tun hat. Agil bedeutet im Sinne des Wortes nur “beweglich. Der Kern des agilen Manifest sind vier einfache Prinzipien

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderung mehr als das Befolgen eines Plan

Genau genommen sind das lax formulierte Prinzipien, die einer beweglichen Arbeitsweise förderlich sind. Da steckt nichts von “New Work” oder Geschwindigkeit drin.

Es ist hilfreich sich zu vergegenwärtigen wie das agile Manifest entstand. Kluge Köpfe aus der Software-Entwicklung trafen sich um aus vielen Methoden vielleicht die beste oder eine gemeinsame zu finden. Das ist nicht gelungen, stattdessen wurde das agile Manifest als gemeinsame Wertebasis funktionierender Vorgehensweisen formuliert.

Hier wäre auch anzumerken, dass Scrum nicht “DIE agile Methode” ist, sondern nur eine von vielen, die damals diskutiert wurden. Scrum ist 6 Jahre älter als das agile Manifest.

Agil arbeiten bedeutet auf Veränderungen zu reagieren. Veränderungen können viele Ursachen haben. Ob die zu Beginn formulierten Anforderungen ungenau waren und im Laufe des Projektes präziser wurden bzw. bisher unbekannte Anforderungen hinzukommen ist völlig nebensächlich.

Die Kunst ist es, sich von ursprünglich Geplantem zu verabschieden und Neues zu beginnen. Wenn das gelingt, erhöht sich die Wahrscheinlichkeit, dass am Ende etwas Brauchbares rauskommt. Das ist eigentlich alles.

Geschwindigkeit ist eine andere Baustelle, die hängt mit der Qualität der Kooperation aller Beteiligten zusammen. Gute Kooperation zu entwickeln ist nicht immer einfach, aber mitnichten irgendeiner Methode vorbehalten. Dass manche Methoden mehr förderliche Elemente enthalten als andere ist unbestritten. Es ist jedoch ein Trugschluss, dass die Huldigung einer Methode automatisch zu gelungener Kooperation führt.

Hört mit dem Etikettenschwindel auf!

Posted on by Dr. Eberhard Huber

Auf die Gefahr hin zu provozieren oder den einen oder anderen zu verstimmen muss ich mir heute meinen Ärger um nicht zu sagen meine Frustration von der Seele schreiben. In einem Cartoon zum Thema Retrospektive klang es schon verhalten an, dass es unzählige “Scrum-but”-Implementierungen gibt. Das reicht von kleinen Abweichungen oder Missverständnissen bis hin zu groben Fehlern. Eine besonders destruktive Ausprägung ist mir schon mehrfach untergekommen.1

Eine “irgendwas” Implementierung, die sich Scrum nennt, verzichtet praktisch auf alles was Scrum ausmacht. Keine der Rollen ist besetzt, es gibt kein Backlog, daily scrum findet nicht statt. Das Einzige was es gibt sind “Sprints”. Dafür wird deren Ergebnis von außen vorgegeben. Sprints – das hört sich so schön schnell an, da kommt mehr dabei heraus – außerdem lassen sich Teams schneller takten, die Leute leisten mehr. Ein minimales agiles Zugeständnis gibt allerdings noch: Kundenvertreter wurden mit ins Team gesteckt. Das Mikromanagement wird durch Gruppendruck ersetzt. Die Arbeitsbelastung steigt und steigt. Gleichzeitig steigt die Angst aufzubegehren, weil der Druck von zwei Seiten kommt.

Mir schwillt der Kamm wenn ich so etwas erlebe. Sicher möchte ein Arbeitgeber, dass die Arbeitsergebnisse zählbar und gut sind. Wenn es aber nur noch um Taktung geht, die Mitarbeiter ausgepresst werden und jede Idee, die noch mehr Leistung verspricht, völlig einseitig aufgesetzt wird, hat der “Scrum-but”-Spaß ein Ende. Ja – ein gutes Team kann große Leistungen erbringen. Um diese zu erbringen benötigt es aber die eigenverantwortliche Freiheit selbst zu bestimmen was im nächsten Sprint erledigt werden soll. Organisationen, die derartige “Scrum-irgendwie” Ansätze verfolgen, handeln in meinen Augen unethisch. Die Dualität von Rechten und Pflichten, die Verantwortung für die Mitarbeiter wird ignoriert. Ich befürchte, dass der geschilderte Fall kein Einzelfall ist. Möglicherweise werden viele Änderungen, die unter den Flaggen “agil”, “Team”, “Verantwortung” usw. segeln, insgeheim nur vorgenommen um den Leistungsdruck erhöhen zu können.

Eine (ggf. höhere) Leistung, die aus echter Verantwortung der Mitarbeiter resultiert, ist nicht von heute auf morgen zu bekommen. Die Einführung neuer Arbeitsweisen wird in der Regel die scheinbare Leistung erst einmal verringern. Es ist vergleichbar mit einer Investition – auf die Rendite muss man ein wenig warten.

Warum schreibe ich das Ganze? Ich hinterfrage gerade selbstkritisch ob all die Lobeshymnen für die häufig genannten Ansätze nicht kontraproduktiv sind. Eine kurze Übung auf einem Scrum-Training, die eindrucksvoll demonstriert wie schnell und um welche Größenordnungen sich die Geschwindigkeit für eine bestimmte Aufgabe im Team erhöhen lässt ist das Eine. Den langen Weg diesen Effekt auch bei komplexen Aufgaben zu erzielen ist das Andere. Die Verheißung eines Hochleistungs-Teams erinnert mich ein wenig an die Renditeversprechen von Wertpapieren. Im Gegensatz zum reinen Finanzmarkt geht es in Projekten jedoch um reales Arbeiten – dazu gehört auch Anstrengung und zwar von ALLEN Seiten.

Hört mit dem Etikettenschwindel auf!

Auf die Gefahr hin zu provozieren oder den einen oder anderen zu verstimmen muss ich mir heute meinen Ärger um nicht zu sagen meine Frustration ...
Hört mit dem Etikettenschwindel auf!

wir sind fast fertig

Ich werde zwischenzeitlich immer wieder darauf angesprochen was ich von den Verzögerungen beim Bau des Berliner Flughafens halte. Einen weiteren Anstoß etwas darüber zu schreiben ...
wir sind fast fertig

Hybrides Projektmanagement ist keine Ausrede

Hybrides Projektmanagement ist in aller Munde. Der situativ passende Mix aus Methoden bzw. Elementen verschiedener Vorgehensweisen führt zum Erfolg. In einer Werbeanzeige las ich kürzlich, ...
Hybrides Projektmanagement ist keine Ausrede

#PM.Vorlesungen

Im Sommersemester 2019 halte ich an der Hochschule der Medien in Stuttgart zwei Vorlesungen über Projektmanagement: IT-Projektmanagement und „Agiles ProjektManagement“. Eine eindeutige Trennung zwischen den ...
#PM.Vorlesungen

Projekt oder »das nach vorn Geworfene«

Projekt [lateinisch proiectum »das nach vorn Geworfene«] das, -(e)s/-e, geplante oder bereits begonnene Unternehmung; (groß angelegtes) Vorhaben. Brockhaus, Projekt. http://brockhaus.de/ecs/enzy/article/projekt (aufgerufen am 2019-03-14) Dieses Zitat ...
Projekt oder »das nach vorn Geworfene«
  1. Die erste Fassung des Textes hatte ich 2012 geschrieben, die beschriebene “Scrum-Ausprägung” ist mir seitdem immer wieder aufs neue begegnet. [↩]
Dann nennt es bitte nicht Scrum

Dann nennt es bitte nicht Scrum

Posted on by Dr. Eberhard Huber
Die erste Fassung dieses Textes habe ich 2011 geschrieben. Möglicherweise war zu Beginn des Scrum-Hypes eine Menge Unkenntnis im Spiel, wenn es zu unvollständigen und manchmal abstrusen Scrum-Implementierungen kam. Zwischenzeitlich sollte das mit der Unkenntnis erledigt sein. Dennoch begegnen mir in letzer Zeit wieder vermehrt sehr seltsame Ideen mit der Aufschrift “Scrum”. Deshalb habe ich beschlossen dieses Text nach und nach zu ergänzen. Originaltext aus dem Jahre 2011 Kürzlich wurde ich unfreiwilliger Ohrenzeuge eines so genannten Scrum-Meetings. Warum nur Ohrenzeuge? Das Meeting fand telefonisch statt und ich habe das Telefonat unfreiwillig mitgehört. Einer der Teilnehmer fragte mich hinterher: “Wie funktioniert Scrum wirklich?” Im weiteren Gespräch, in dem ich Details über das gerade beendete “Scrum-Meeting” erfuhr, stellte sich dann heraus, dass womöglich keiner der Beteiligten wirklich wusste wie Scrum funktioniert. Um ehrlich zu sein mir standen nach dem Gespräch die wenigen verbliebenen Haare zu Berge. Es gibt Organisationen, die guten Gewissens sagen “Wir machen Scrum” und dennoch in der täglichen Praxis ein Musterbeispiel abgeben, wie man es nicht machen sollte. Einige der Punkte aus dem Gespräch möchte ich nachfolgend kurz skizzieren und kommentieren:
  • Es gibt kein Scrum-Meeting, es gibt das daily scrum. Das ist eine kurze, straff organisierte Zusammenkunft des Teams. Eine tägliche Telefonkonferenz von zwei Stunden ohne Moderation ist kein daily scrum.
  • Das daily scrum ist eine Zusammenkunft des Teams und keine Konferenz eines ständig wechselnden Personenkreises. Das Team sollte wissen wer dazugehört und nicht erst zu Beginn des Termins erfahren wer heute dabei ist. Wenn nicht einmal klar ist wer zum Team dazu gehört ist schon die Minimalbedingung erfolgreicher Teamarbeit nicht erfüllt.
  • Probleme werden im daily scrum nur öffentlich gemacht und angerissen. Sie werden notiert und außerhalb geklärt, gelöst oder einer Lösung zugeführt und nicht stundenlang im Meeting diskutiert. Wenn z.B. Schulungen notwendig sind werden diese organisiert und nicht im im daily scrum abgehalten. Das Notieren von Problemen und Hindernissen wie z.B. Schulungsbedarf und die Organisation von Abhilfen sind unter anderem Aufgaben des Scrum-Masters.
  • Eine tägliche Telefonkonferenz mit Zeitzonenverteilung rund um den Globus1 ist wenig effektiv weil immer einer halb im Bett ist. Hier wäre eine andere Einteilung des Teams oder eine Aufteilung in zwei kleinere Teams die bessere Lösung.
  • Qualitätskriterien werden als Abnahmekriterien für die User Stories formuliert und nicht als Meta-Use-Cases, deren Inhalt nichts mit den User Stories zu tun hat.
  • Ein Scrum Team muss kompetent sein, das heißt die Teammember sollten in Summe die für die Arbeit notwendigen Kenntnisse besitzen. Es macht wenig Sinn eine Gruppe von Cobol-Entwicklern auf ein PHP – Projekt anzusetzen und sie als PHP-Scrum-Team zu bezeichnen.2
In besagter Organisation gibt es weder einen Scrum-Master noch einen Product-Owner. Insofern ist es faszinierend, dass überhaupt das Wort Scrum in den Mund genommen wird. Epilog Scrum ist ein außergewöhnlicher Ansatz im wahrsten Sinne des Wortes, der dementsprechend außergewöhnliche Ernsthaftigkeit in der Umsetzung erfordert. Ein Etiketten-Schwindel hilft niemand. Dann lieber wie bisher weiter machen – und – nennt es bitte nicht Scrum. Nachtrag 1: Aus einer Projektanfrage, die mir auf den Tisch geflattert ist: Für ein Scrum-Team wird ein Projektleiter gesucht. Meine Rückfrage “Brauchen Sie einen Scrum-Master oder einen Product-Owner” stieß auf völliges Unverständnis. Scrum und die normale Projektleiter-Rolle passen nicht zusammen, zumindest nicht innerhalb des Aufgabenbereichs eines Teams. Nachtrag :2 Die Rollen in Scrum sind wichtig. Die Aufgaben des Scrum-Masters können nicht vom ohnehin vorhandenen Projektleiter nebenher mitgemacht werden.  
  1. Im konkreten Fall: Europa, USA Ost, USA West und Indien, d.h. einer schläft immer. [↩]
  2. So bizarr sich der Cobol – PHP Vergleich anhören mag ist er dennoch ein reales Beispiel mit dem ich mich schon auseinandersetzen musste. [↩]
(k)ein Projekt- sondern ein Scrum-Cartoon

(k)ein Projekt- sondern ein Scrum-Cartoon

Posted on by Dr. Eberhard Huber
Aus gegebenem Anlass heute ein bitterer Cartoon, der leider mehr als ein Körnchen Wahrheit enthält. Gelegentlich wird die Retrospektive missbraucht um effektiver Schuldige zu suchen. Über die Hintergründe des Cartoons gibt es hier noch mehr zu lesen: Hört mit dem Etikettenschwindel auf!
© pentaeder 2019 / 2020