Selbst dieses wahrhaft erschreckende Beispiel wurde inzwischen getoppt. 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 – wie z.B. Scrum – 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.

Was ist eigentlich timeboxing?

• I – wie Information
• B – wie Beratung
• E – wie Entscheidung

Information – wird in der Regel von einem Teilnehmer mitgeteilt, die anderen hören zu. Nachfragen zum Verständnis sind erlaubt, Diskussionen sollten vermieden werden. Wenn sich Diskussionsbedarf abzeichnet sollte dies vertagt werden und in einen neuen Beratungspunkt münden. Im Protokoll kann die Information nochmals wiederholt und ggf. durch die Antworten auf die verständnisfragen ergänzt werden.

Beratung – hier darf diskutiert werden. Meinungen werden ausgetauscht, Meinungen verändern sich. Im Protokoll sollten die geäußerten Meinungen und Ansichten dokumentiert werden.

Entscheidung – der Diskussionsstand wird nochmals zusammengefasst und eine Entscheidung getroffen. Im Protokoll wird die Entscheidung und nichts anderes dokumentiert.

Was bringt diese Typisierung der Tagesordnungspunkte. Sie erhöht die Verbindlichkeit. Ohne die explizite Unterscheidung der Punkte gehen Information, Diskussion und Beratung leicht ineinander über. Im Protokoll stehen dann viele unterschiedliche Aspekte ohne dass klar ist, welche Punkte nur diskutiert und welche wirklich entschieden wurden. Manchmal beruft sich jeder auf einen anderen Halbsatz im Protokoll, irgendwie haben dann alle recht und alle machen weiter wie sie denken.

Lassen sich mit einer Typisierung alle Besprechungen effizient gestalten? Nein, nicht immer – das liegt daran, dass wir Menschen sind und auch im ernsten Business Alltag nach Austausch suchen. Bei der Vorbereitung von Terminen sollte man das immer im Hinterkopf behalten und auch in der Planung der Besprechung berücksichtigen (Zeitstruktur, Pausen, Smalltalk).

Es spricht übrigens nichts dagegen die Typisierung auch mit einem Augenzwinkern zu erweitern. Ich selbst hatte auch in wichtigen Besprechungen als ersten Tagesordnungspunkt schon Nachbesprechungen von Fußballspielen stehen.

Zu guter letzt ein Bild wie ein Protokoll einer derartigen Besprechung aussehen könnte und ein Word-Dokument als Protokollvorlage.

1. Auch wenn man Scrum macht, heißt das noch nicht, dass man keine normalen Besprechungen mehr benötigt. Spätestens dann wenn der Scrum-Master sich um die Beseitigung von impediments kümmert wird er auch Besprechungen mit team-fremden Teilnehmern benötigen.

• 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 Globus¹ 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.²

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.

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 / Update: Diese Woche flatterte mir eine Anfrage auf den Tisch. Für ein Scrum-Team wurde 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.

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.

8 Referenten werden zu wichtigen Themen rund um Scrum interviewt. Die Themenauswahl klingt spannend und ist an der Praxis orientiert:

- Skalierung von SCRUM für große Projekte
- Agiles Produktmanagement mit Scrum
- Agile Softwareentwicklung mit verteilten Teams
- Klassisches versus agiles Projektmanagement
- Agiles Projektmanagement mit ZCOPE
- Spannungsfeld Architektur und Agilität
- Agile Engineering Techniken in SCRUM
- Agilität und Kultur

Die Interviews stehen auf einer speziellen Plattform online zur Verfügung. Mittels dieser Plattform stellen die Teilnehmer Fragen an die Referenten, diese werden beantwortet und diskutiert. Interviews, Fragen und Antworten stehen danach weiter zur Verfügung. Ich halte das für eine sehr gute Idee. Mir fallen die wichtigsten Fragen meistens auf dem Heimweg von einer Konferenz ein, das kann bei dieser Scrum-Konferenz nicht mehr passieren.

Wie sieht der gemeinsame Kern agiler Vorgehensweisen aus?

• Es wird akzeptiert, dass zu Beginn nur ein Teil der Anforderungen definiert ist.
• Es besteht permanenter und enger Kontakt zu denen,
  die das Arbeitsergebnis geliefert bekommen.
• Es wird in wiederkehrenden Intervallen gearbeitet.
• Am Ende jeden Intervalls wird ein verwendbares Zwischenergebnis fertig gestellt.
• Jedes Arbeitsintervall wird ausgewertet.
  Es werden Konsequenzen für das nächste formuliert und auch gezogen.
• Die produktive Arbeit wird von einem Team geleistet, das selbstorganisiert arbeiten darf.

Aus der Formulierung der Merkmale wird schon deutlich, dass diese Arbeitsweise nicht nur für Software-Entwicklung sondern für viele verschiedene Projektarten möglich sein wird. Wie die Merkmale in der Praxis konkret umgesetzt werden (z.B. mittels Scrum) ist letztendlich egal. Genauer betrachtet lässt sich diese Arbeitsweise auch mit “klassischem Projektmanagement” zuzüglich ordentlichem Changemanagement, kooperativer Führung und transparenter Kommunikation verwirklichen. Agilität ist ohnehin eher als Geisteshaltung denn als Prozessbeschreibung zu verstehen.¹

Nehmen wir an, dass in einem Projekt wie oben beschrieben gearbeitet wird. Das Team arbeitet und liefert nach einer gewissen Zeit ein (hoffentlich) verwertbares Zwischenergebnis ab. Sollte im ersten Intervall nichts Brauchbares fertig werden, muss eben nach den Gründen gesucht werden um dann im zweiten Anlauf erfolgreicher zu sein. Egal ob im ersten oder zweiten Anlauf, das Team hat sehr früh ein Erfolgserlebnis. Konkrete (Erfolgs)-Erlebnisse und Erfahrungen beschleunigen die teaminternen Klärungsprozesse wie Rollenklärung oder die üblichen Machtkämpfe erheblich. Ein simples Beispiel: Ein Kollege bezeichnet sich selbst als Spezialist für ein bestimmtes Thema. Stimmt das? Können sich Team und Projekt wirklich darauf verlassen? Nach der Lieferung des ersten Zwischenergebnisses hat sich das bestätigt (oder eben nicht). Die Bestätigung der Fähigkeiten, der Verlässlichkeit, das Erproben der Zusammenarbeit, das Wachsen des aufkeimenden Vertrauen – all dies erfolgt schneller wenn mit greifbaren Zwischenschritten gearbeitet wird.² Im negativen Fall wird ebenfalls schneller klar, dass der Kollege vielleicht nur eine große Klappe hatte und er mit einer anderen Aufgabenstellung mehr für das Projekt tun kann. Wichtige Grundvoraussetzungen für eine erfolgreiche Teamentwicklung wie die Klärung der Fragen “Wer gehört dazu?” bzw. “Wie sieht die gemeinsame Aufgabe aus?” werden bei einer solchen Vorgehensweise quasi im Vorbeigehen erledigt.

Wer agil arbeitet, stellt gewissermaßen ganz nebenbei gute Rahmenbedingungen für eine konstruktive Teamentwicklung bereit.

Eine konstruktive Teamentwicklung innerhalb des Projektes ist m.E. DER Erfolgsfaktor für Projekte. Scrum stellt hierfür bessere Rahmenbedingungen als das Wasserfallmodell bereit. Dennoch gibt es keinen Königsweg. Auch in Wasserfall-Projekten lässt sich ein Teil des agilen Gedankenguts (siehe obige Merkmale) leben. Ein gutes Team schafft fast alles, eine zerstrittene Projektgruppe kann jedes Projekt scheitern lassen.

1. Insofern kann ich Stimmen, die Scrum als alten Wein in neuen Schläuchen bezeichnen durchaus verstehen.
2. Ein Meilenstein in einem Projektplan ist nicht zwingend ein greifbarer Zwischenschritt. Die Softwareentwicklung hat es hier relativ leicht. Hier entspricht dies einem lauffähigen Release. In anderen Projekten muss die Definition der Meilensteine genau bedacht werden.