Soziale Experimente sind asozial; ein Beitrag über verantwortungsvolle Führung

Culture Hacks, Fail-Safe Experimente und Kulturen des Scheiterns sind Schlagworte die in den letzten Jahren im Kontext von sozialen Systemen und Organisationsberatung regelmäßig auftauchen, doch inzwischen vermehrt. Experten und andere Menschen die sich „langjährige Erfahrung“ auf die Fahnen schreiben plädieren für eine sogenannte „Experimentierkultur“.w-_edwards_deming

Sehr häufig beziehen sie sich dabei auf den PDCA-Zyklus von Shewart und Deming. Dabei ist das ein sehr großes Mißverständnis, sozusagen ein Haltungsfehler bei dem sich die beiden Analysten sicherlich im Grabe rumdrehen würde. Nun, was interessieren uns die Gedanken der beiden Wissenschaftler?

Naja! Gelebte Experimentierkultur lässt Menschen und Teams unmittelbar leiden, es fügt ihnen menschlichen Schaden hinzu. Es kostet Reputation und hat Auswirkungen in vielerlei Richtungen: menschlich, emotional, finanziell, organisatorisch und familiär.

Letztlich spiegelt das sich in Kosten wieder die die Organisation und Gesellschaft trägt. Hier geht es nicht um eine Kleinigkeit, sondern systemische Veränderungen die eine Auswirkung haben weil jemand lapidar gesagt hat: „komm wir probieren das mal aus“. Teamwechsel, verlorene Aufträge, verlorene Kundenbeziehungen, Jobverlust,…

Die beiden Wissenschaftler Deming und Shewart haben mit PDCA einen Zyklus formuliert und veröffentlicht mit dem Veränderungen und Produktentwicklung angegangen werden kann. Es heißt dabei:

1. Plan
2. Do
3. Check
4. Act

und nicht:
1. Plane
2. Experimentiere
3. Lass dich überraschen
4. Mach´ irgendwas

Die folgende Grafik liefert dazu weitere Details. Sie stammt aus den originalen Dokumenten von Shewart (Quelle: Deming Institut, www.deming.org) und wurde von mir übersetzt:

shewhartcycle

Im Grunde steckt dahinter die empirische Prozessteuerung („Inspect & Adapt“) die im Scrum Guide erwähnt wird, ja. Aber es geht nicht darum sich etwas zu überlegen, auszuführen und sich von den Ergebnissen überraschen zu lassen. Ganz im Gegenteil. Das was Deming in seinen Dokumenten und Vorgehensweisen ausführlich beschreibt zielt darauf ab Unterschiede im Sinne von Abweichungen zu erkennen und dann nachzuregulieren.

Bedeutet auf Projektkontext übertragen: Bereite dein Projekt vor, schätze die Aufwände, messe den Fortschritt – entspricht der Fortschritt nicht der Vorbereitung dann passe an.

velocitygrafik

 

Deming geht dabei noch weiter und unterscheidet die Ursachen für Abweichungen. Es gibt spezielle Ursachen da lohnt es sich überhaupt nicht nachzuregulieren wie beispielsweise ein Computerdefekt oder eine Reifenpanne. Das passiert halt einfach einmal im Leben. Eine Reifenpanneverhinderungsmaschine macht da einfach keinen Sinn. Aber die Analyse von Ursachen ist ein anderes Thema.

Hispanic, Caucasian mixed business woman from the back - looking at something over a white background

Wichtig ist der Unterschied den das Vorgehen im eigenen Denken macht. Stelle ich drei Mitarbeiter ein und lasse mich von der Wirkung überraschen ODER bereite ich das intelligent vor. Wen braucht das Thema? Wer passt menschlich rein? Wie alt sollte derjenige sein? Was sagt das Team? Was gibt es für zukünftige Projekte? Was brauchen wir dafür? Wie kann die Einarbeitung verlaufen? Fragen für die man Antworten finden darf.

Bei jeder Veränderung am System stellen sich diese Fragen und es dürfen die dazugehörigen Gespräche geführt werden. Ein System darf für sich selbst die passenden Antworten suchen. Das bedarf eines Moderationsprozess.

Damit wir vom selben ausgehen: an was für Fragestellungen denke ich:

  • Soll Torsten Meier Scrum Master im Team xy werden?
  • Sollen wir ein Angebot für das Projekt xy schreiben?
  • Brechen wir das Projekt xy ab?
  • Brauchen wir ein Arbeitszeitsystem?
  • Sollen wir die Arbeitszeit von 6 – 20 Uhr ermöglichen?
  • Wollen wir Teams ohne disziplinarischen Chef führen?
  • Möchten wir cross-funktionale Teams?
  • Wie lange sollen unsere Teams zusammenarbeiten?

All das sind typische Fragestellungen am System. Sie haben eine unmittelbare Auswirkung darauf, wie sich die Menschen innerhalb des Systems verhalten werden. Und: Es gibt eine direkte Verbindung zwischen der Qualität eines Systems und der Qualität des menschlichen Verhaltens darin.qualitaet Bedeutet auch: wenn Sie nicht zufrieden sind wie sich Menschen verhalten, dann stimmt die Qualität des Systems nicht. Nach Deming ist dann eine Anpassung erforderlich und zwar am System und nicht am Menschen. Aus der Fragestellung ob von 6 – 20 Uhr gearbeitet werden kann, ergeben sich beispielsweise eine Vielzahl an Fragen:

Brauchen wir eine Kernarbeitszeit? Wie gewährleisten wir die gesetzlichen Rahmenbedingungen? Wie sichern wir das die Überstunden im gesunden Rahmen bleiben? Was tun wir gegen Betrug? Wie sichern wir den Kundenkontakt? Müssen die Verträge angepasst werden?

Und das interessante ist: die wenigsten Menschen wären überhaupt beim Überlegen dieser Veränderung der Arbeitszeit auf die Fragen gekommen – diese ergeben sich nämlich wann? Richtig, wenn man beginnt mit einem ausgewählten Teilnehmerkreis darüber zu sprechen. Das nennen wir Vorbereitung oder Vorbereitungsprozess. Ein wichtiger Teil bei Änderungen am System.

Woher stammt der Denkfehler mit der Experimentiertkultur?

Es gibt da aus meiner Sicht mehrere Ursprünge die vermutlich unbedacht miteinander vermischt werden oder es wird versucht sogenannte „Best practices“ auf den Kontext der sozialen Systeme zu übertragen.

1. Lean Startup

In „agilen Kreisen“, also Bücher, Blogs, Vorträgen und Co. kursieren viele konstruktive Gedanken die sich darauf beziehen das ein Produkt im Sinne von Lean Startup und Minimum Viable Product sehr früh beim Kunden getestet werden soll. Es geht um Kundenfeedback und -resonanz, die Frage „Ist dass das, was der Kunde will?“

Da macht das Sinn, vor allem bei Software, weil man die ja beim Entstehen und Entwicklen sonst nicht sieht. Die Übertragung dessen auf Organisationssysteme ist jedoch fahrlässig – es sei denn man wünscht sich Überraschungen mit allen besagten Nebeneffekten, positiv und negativ.

2. Testdriven Development

In der Software-Entwicklung spricht man von testgetriebener Entwicklung. Man schreibt erst  einen Test und anschließend die Codezeile die den Test erfüllt. Im Grunde ist das Vorgehen übertragbar auf Organisationsentwicklung.

a) Definiere was du erwartest

b) Schalte um

c) Prüfe ob dein Test erfolgreich ist

Eine gute Sache, wenn richtig verstanden und in der Form angewandt. Fehlt Schritt a) oder c) oder beide ist das ein fahrlässiges Vorgehen und sorgt für Überraschungen.

3. Ungünstige Theorien und Modelle

Neben dem Lean Startup Gedanken gibt es jedoch auch Modelle die voller Mißverständnisse sind. „Best practices“-Ratgeber die Aussagen machen wie: in komplexen Systemen kannst du nicht wissen welche Ergebnisse sich zeigen, hier musst du ausprobieren („Probe, Sense, Respond“). Ein Beispiel liefert das Cynefin-Framework und die unterschiedlichen Interpretationen dessen.

Es geht an der Stelle nicht um das Modell, sondern um das Führen mit diesem Modell. Das ist eine Theorie die ich nicht weiter kaufen würde, weil du bekommst was du denkst. und wenn du Überraschungen provozierst bekommst du Überraschungen.

4. Ursache und Wirkung

Und zu allerletzt geht es auch um Verantwortung. Natürlich ist es leicht nach einem misslungenen Experiment zu sagen: „hat leider nicht funktioniert, das System hat anders reagiert als erwartet.“ – aber es ist auch verantwortungslos und ein Zeichen von schlechter Vorbereitung. Und es ist eine Opferhaltung.

Selbstverständlich gibt es Situationen in denen Überraschungen auftreten z.B. das erste Produkt-Review nach dem der Kunde sagt das ihm dies und jenes nicht gefällt, er es anders hätte usw. Dann ist es so und gilt es dies ernst zu nehmen. Es darf klar kommuniziert werden: „Haben wir verstanden, wir sind in den ersten Annäherungsphasen, nehmen wir so auf, wird abgestellt.“ Dann ist es jedoch kein Experiment, sondern der Ernst des Lebens. Da hängen Aufwände und Menschen an dem Projekt.

An jedem Projekt hängt ein vollständiges Team, mit Leidenschaft, Engagement und Menschen.

Schlechte Theorien und Modell gaukeln uns vor, es gäbe keinen Zusammenhang zwischen Ursache und Wirkung. Bestimmt ist das in Einzelfällen auch so oder es nicht möglich alle Informationen in absehbarer Zeit zu identifizieren, aber eben nicht grundsätzlich und es ist schon gar kein Grund deshalb auf eine umsichtige Vorbereitung zu verzichten.

Es gibt oft oder vermutlich immer (?) eine enge Kopplung zwischen Ursache und Wirkung, nämlich bei intelligenter, umsichtiger und sensibler Vorbereitung.

Im Gegensatz dazu ist die Streuung gross wenn ich mich miserabel vorbereite und „mal guck was so passiert“. Wie bei einem schriftlichen Test: gut vorbereitet, bedeutet üblicherweise auch ein gutes Ergebnis. Manchmal nicht, dann dachte man wäre gut vorbereitet und war im Irrtum. Auch das passiert.

 

Zum Abschluss ein Zitat:

Bilder:

William Edward Deming, https://upload.wikimedia.org/wikipedia/commons/7/73/W._Edwards_Deming.jpg

Ressourcenplanung à la Scrum

„Projektmanagement und Scrum. Das ist doch irgendwie das selbe. Du musst doch trotzdem deine Ressourcen planen.“

So oder so ähnlich fangen gute Gespräche Blogartikel an. Schauen wir uns das mal an – ist das denn so? Und falls nicht, wie ist es tatsächlich?

Die kurze Antwort ist ja, dass ich ungern von Ressourcen und Ressourcenplanung spreche, because… #agile. Diese Abneigung bezieht sich dabei auf den Begriff und die Semantik wie sie aus der Betriebswirtschaftslehre stammt:

„Eine Ressource kann ein materielles oder immaterielles Gut sein. Meist werden darunter BetriebsmittelGeld­mittel, BodenRohstoffeEnergie oder Personen und (Arbeits-)Zeit verstanden (…)“

https://de.wikipedia.org/wiki/Ressource

Diese Definition, die Semantik und der praktische Umgang damit ist aus meiner ganz eigenen Sicht so problematisch weil,…

a) …es dem Menschen nicht gerecht wird, denn Menschen sind keine Ressourcen die man in einem Team oder einem Projekt wie Betriebsmittel hinzufügt oder wegnimmt.

„Kannste machen, ist dann halt…“

Menschen bringen grundsätzlich eigene Kompetenzen, Stärken, Schwächen, Interessen, Eigenheiten, usw. mit und damit es in einem Team/Projekt harmoniert müssen Menschen zusammen passen.

b) …dabei Ressourcen häufig als „tot“ betrachtet werden, ohne Leben. Der Mensch, Projekte, Kunden und die Gegenwart sind jedoch komplex. Wer plant kann versuchen alle komplexen Fälle und Risiken mit zu integrieren, dann wird der Plan jedoch nicht mehr gut und passend sein.

c) Ressourcenplanung im Grunde nicht funktioniert

Das Thema ist auch in Büchern zum Thema Scrum und Agile nicht wirklich verankert. Aus dem Gedankenprotokoll glaube ich sogar, das sich auch Boris Gloger in der „Scrum-Bibel“ davon distanziert und eine gute Erklärung liefert.

Jetzt muss man Aufwände, Teamgröße und Co. ja dennoch in irgendeiner Form verwalten damit man herausbekommt ob:

  • neue Projekte umgesetzt werden können
  • die Teams ausreichend groß sind
  • genug Kapazität für neue Aufgaben vorhanden sind
  • (hier andere Gründe einfügen wieso Sie Ressourcenplanung nutzen)

Also… wie geht das in „Agile“

Die Grundlage bildet ein empirisches Vorgehen, vereinfacht gesagt ein Bezug auf gemachte Erfahrungen – diese werden gemessen. Wie? Am Besten nicht in Manntage oder andere Zeiteinheiten, sondern man nimmt eine andere Einheit zum Schätzen, also zum Beispiel Gummibärchen, Mohrenköpfe oder einfach Punkte – Storypoints. Alle Aufgaben werden dann geschätzt in diesen Punkten. Das macht das Team gemeinsam und plant schließlich den Sprint.

Handle so, daß du die Menschheit sowohl in deiner Person, als auch in der Person eines jeden anderen jederzeit zugleich als Zweck, niemals bloß als Mittel brauchest.

Immanuel Kant

Wie viele Storypoints schafft das Team im Sprint?

Dann läuft der Sprint und hinterher wird geschaut: Was hat das Team wirklich geschafft? Die Anzahl an geschafften Storypoints nennt man auch die Velocity (mehr dazu im Scrum Glossar).

velocitygrafik

 

 

Das interessante was sich an der Vorgehensweise ist das, was sich alles ablesen lässt:

a) hat das Team alle Aufgaben geschafft?

b) kamen neue Aufgaben dazu die vorher nicht geplant waren? (z.B. Bugs) – Falls ja, wie viele?

c) ist das Team unterfordert oder überfordert?

d) wie viele Aufgaben liegen noch im Product-Backlog?

e) wenn das Team mit der Geschwindigkeit (Velocity von „39“ Storypoints) weiterarbeitet wie lange hat es dann noch zu tun bis das Projekt abgeschlossen ist?

Unter Berücksichtigung einiger Randaspekte* lässt sich schließlich rechnen wie lange ein Team mit aktuellen Aufgaben beschäftigt sein wird:

velocitykalkulation

 

Beispiele für Randaspekte die dabei berücksichtigt werden sollten:

  • die Velocity für ein Team schwankt (je nach Urlaub, Krankheit, Abwesenheit von Teammitgliedern)
  • die abgegebenen Schätzungen werden mit jedem Sprint voraussichtlich besser und genauer
  • es kommen im Laufe der Zeit mit hoher Wahrscheinlichkeit neue Stories und Anforderungen in das Backlog
  • die Velocity ist nicht übertragbar weil a) individuell pro Team und b) eng gekoppelt mit der Schätzung des Teams

tl;dr

In agilen Teams wird typischerweise mit Schätzungen und dem Burndown Chart gearbeitet. Eine

klassische Ressourcenplanung ist nicht mehr notwendig, weil ohnehin zu ungenau.

Mit der Velocity erhält man pro Team eine empirische Kennziffer mit der sich die weiteren Sprints vorbereiten lassen. Üblicherweise werden 1-3 Sprints genauer geplant, alles darüber hinaus zunächst nur grob – weil in der Zukunft viele Änderungen warten.

Das Burndown-Chart hat zudem den Vorteil dass darauf aufbauen analysiert werden kann wie gut der aktuelle Arbeitsprozess läuft. Grundlage für die Verbesserungen in der Retrospektive.

…und wer mehr lesen möchte…

Die unterschätzte Wirkung von leichtgewichtiger Prozess-Visualisierung, Artikelserie:

Teil 1: Einleitung in die Prozessvisualisierung – Warum ist das Thema im komplexen Kontext besonders wichtig?

Teil 2: Wie wirkt sich ein aktuelles und sortiertes Board auf die Selbstorganisation im Team aus?

Teil 3: Wie Wie können Abweichungen im Prozess mit dem Burndown-Chart identifiziert werden?

Beobachtungen aus dem Walking Skeleton Game

Gestern fand in Baunatal bei Kassel der erste „Agile Building Day“ statt. 10 Teilnehmer(innen) bekamen von Matthias Seul und mir eine Einführung in Lego Serious Play und den Minimum Viable Product Ansatz. Im Vordergrund stand die Fragestellung:

„Wie können Großprojekte angegangen werden, damit Sie frühen Kundenwert schaffen und dynamisch auf Veränderungen reagieren können?“

headeragilebuildingday

Den Hauptteil füllte ein tiefer Einblick in die Arbeitsweise nach dem Walking Skeleton Ansatz von Alistair Cockburn. Es war eine kleine „Prämiere“ für das neu konzeptionierte Walking Skeleton Game. Die Beobachtungen dazu möchte ich teilen.

Was ist das Walking Skeleton Game?

Zunächst eine kurze Wiederholung: Das Walking Skeleton Game soll zeigen wann und wie dieses Vorgehensmuster seine Vorteile ausspielen kann.

„In order to reduce risks on projects like the above you need to figure out all the unknowns as early as possible.“

goo.gl/zty8sw

und dann los…

„Wir bauen ein Haus!“

„Was denn für ein Haus?“

„Ein normales Haus eben.“

„Achso, klar. Ein normales Haus. (???)“

Es sind ein paar simulierte Kniffe notwendig, damit klar wird welchen Unterschied das Vorgehensmodell in der Praxis macht. Also haben wird in der ersten Phase mit einem chaotischen Projekt begonnen und alles aus der Tasche gezaubert damit die Teilnehmer(innen) möglichst tief ins kalte Wasser geworfen werden. Das bedeutete zum Beispiel:

  • Starten ohne abgestimmtes Vorgehensmuster oder Vorbereitungen
  • ein detailverliebter Kunden der das große Ganze aus den Augen verliert
  • eine Timebox die sich dynamisch verlängert
  • ein Chef dem kurze Kundenzusagen wichtiger sind, als ein erfolgreiches Gesamtprojekt
  • regelmäßige Störungen und Ablenkungen der Teams
  • eine hohe Geräuschkullisse und unkontrollierte Teamveränderungen
  • indirektes Kundenfeedback über Dritte ohne die Möglichkeit für Rückfragen
  • plötzliche Reviewtermine

Und natürlich im Vordergrund: Anforderungsänderungen, Anforderungsänderungen und Anforderungsänderungen. Alle zwei bis drei Minuten.

Beide Teams wurden dabei durch detailgetreue Schilderungen dazu verleitet sich auf die Inneneinrichtung zu konzentrieren, statt auf das große Ganze. Somit wurden von Teams (natürlich) Vorannahmen getroffen die korrigiert werden mussten. Es gab keinen Garten, also musste das komplette Haus verschoben werden. Die Grundrisse der Räume stimmten nicht, also musste die Inneneinrichtung neu angeordnet werden. Es fehlten Fenster, also mussten Außenwände neu gebaut werden. Schlafzimmer wurden vergessen, also musste eine zweite Etage her… Änderung für Änderung wurde hinzugefügt und die Timebox von 20 Minuten schrittweise auf 45 Minuten ausgeweitet. Das Ziel der Simulation war für möglichst viele Umbauten zu sorgen.

Ergebnis der ersten Bauphasedebriefing

Team A hat das Projekt nach ungefähr 30 Minuten eigenständig abgebrochen und den Bau der zweiten Etage verweigert. „Ich kündige.“ – Die Simulation war in diesem Sinne sehr erfolgreich :)

teambwalkingskeletonTeam B war hartnäckig und baute zwar bis zum Ende und auch eine zweite Etage, Dach und Inneneinrichtung gebaut – war jedoch nicht sehr zufrieden mit dem eigenen Ergebnis („Pfusch am Bau“) und ebenfalls sichtlich demotiviert.

teama-walkingskeleton

Was wir simuliert hatten, war natürlich überspitzt und dennoch aus der Praxis für die Praxis.

Im Anschluss daran baten wir die Teams zur Abgabe einer subjektiven Bewertung des Projektes (1 – niedriger Wert, 10 -hoher Wert). Der Kunde und der Auftragnehmer stimmten mit ab und lieferten die Sicht „von außen“. Wir haben diese Werte schließlich mit dem zweiten Durchlauf verglichen. Dazu am Ende des Artikels mehr.

metrik

 

Dazwischen: Theorie erfahren und Standards vereinbaren

Im Anschluss an die erste Bauphase folgte ein Theorieblock über das Walking Skeleton Vorgehen und die Ankündigung einer zweiten Bauphase. Dazu wurden Standards mit den Teams vereinbart, die die Zusammenarbeit vereinfachen sollen.

miniDarüber hinaus wurde der böse Auftragnehmer in einen Scrum Master umgewandelt und ein Vorgehensmodell gewählt was an Scrum angelehnt ist. 3 Sprints mit Planung, Sprint, Review und Retrospektive.

Zweite Bauphase mit dem Walking Skeleton Ansatz und Vorbereitung der Teams

Der zweite Durchlauf beginnt mit einem Vorbereitungsdialog zwischen Kunde, Team und Scrum Master. Als derjenige der die Rolle des Kunden spielte, kann ich gut beschreiben, wie sich meine Haltung im Gegensatz zum ersten Durchlauf unmittelbar änderte.

Kunde: „Ich möchte ein Haus. Ein normales Haus.“

Scrum Master: „Was ist denn ein normales Haus?“

Kunde: „Naja, gute Frage. Mit Fenstern, Türen, ein Dach und ein Garten. Es sollte drei Zimmer haben, ein Bad, eine Küche und ein Wohnzimmer.“

Scrum Master: „Ah ok. Gibt es denn weitere besondere Eigenschaften die das Haus haben sollte?“

(Kunde grübelt…)

Trotz aller Simulation brauchte es 3-4 gekonnte Fragen des Scrum Masters um mich in den Denkprozess zu führen und mir wurde sehr schnell selbst klar: „Ich habe im Moment keine Ahnung wie das Haus aussehen kann oder soll.“

Es war ad hoc nicht für die Teams beschreibbar und in Anbetracht der ablaufenden Vorbereitungszeit auch klar: es ist in Worten wohl kaum möglich und braucht Skizzen oder direkt das lebendige Objekt :) Es blieb nur die Möglichkeit das offenzulegen was offensichtlich war: „Jetzt im Moment gibt es noch kein klares Bild.“

Rückblickend betrachtet hatte sich in diesen paar Minuten meine Haltung von „Ich führe als Kunde“ tatsächlich in „Ich bin auf Führung angewiesen“ geändert. Nun führte nicht ich als Kunde die Teams, sondern musste mich und alle Anforderungsänderungen in den Scrum Prozess eingliedern. Jeder Versuch dazu blieb erfolglos weil priorisiert wurde, neue Wünsche hinten angestellt werden mussten und der Scrum Master diese Änderungen nur noch im Review ermöglichte – was zeitlich begrenzt war. Soweit die eigene Beobachtungen.

und im Ergebnis?

Naja, ungelogen: die Teams arbeiteten ruhig und gelassen. Man konnte Absprachen hören die miteinander getroffen wurden und nach jedem 8 Minuten Sprint waren neue Ergebnisse sichtbar. Zwar ohne Inneneinrichtung, dafür jedoch modular veränderbar und Bezugsfertig. Jeder Raum als einzelnes Element.

teamaflow

teamahaus

Team A lieferte ein Haus was allen Änderungswünschen entsprach. Fenster wurden gegen Türen getauscht, eine zweite Etage ergänzt, Räume getauscht, eine Garage ergänzt, Fensterbänke eingefügt und sogar Teammitglieder zwischendurch ausgetauscht – was problemlos ging und von beiden Teams kaum wahrgenommen wurde.

Das Ergebnis von Team B konnte sich ebenfalls sehen lassen, allerdings wurde die dritte Etage nicht abgeschlossen. Diese Änderung war für das Team recht groß weil

a) nach dem zweiten Sprint von der modularen Bauweise abgewichen wurde und

b) festgestellt wurde das die Schnittstelle – in dem Fall die Treppe – für Probleme sorgte

teambhaus

 

Wie in einem realen Projekt eben: Es sind selten die Details und einzelnen Komponenten die Schwierigkeiten machen, sondern die Schnittstellen zwischen den Komponenten. Das ging daraus gut hervor.

Debriefing der zweiten Phase

Das Debriefing war locker und gelöst. Keine Kündigungswünsche :) Die Vorteile des Walking Skeleton Ansatz gepaart mit Scrum als Vorgehensmodell sind offenbar ebenfalls sichtbar geworden:

debriefing2

 

Gegenüberstellung

Auch nach diesem Durchlauf haben wir beide Teams gebeten ihre subjektive Meinung zum Projekt abzugeben. Diese Daten wurden aufbereitet und mit dem ersten Lauf vergleichbar in eine Tabelle übertragen.

walkingskeletonteamawalkingskeletonteamb

Was fällt daran und in der Gesamtbetrachtung auf?

  • Im Hinblick auf Aussehen, Stabilität, Erweiterbarkeit, Projektergebnis und Qualität der Zusammenarbeit hat der Scrum-Ansatz mit dem Walking-Skeleton Prinzip für einen Punktezuwachs und offenbar eine höhere Zufriedenheit gesorgt
  • Fremd- und Selbsteinschätzung weichen je nach Projektsituation voneinander ab – unabhängig von der Vorgehensweise
    • es fällt auf das die Abweichung beim ersten Durchlauf bei Team A auftritt und im zweiten Durchlauf bei Team B – das waren die beiden Projektsituationen in denen das Ergebnis den Kunden nicht vollständig überzeugte. These: höhere Abweichungen zwischen Team- und Kundenbewertung deuten auf Kundenunzufriedenheit hin?
  • Trotz das beim zweiten Durchlauf netto nur 24 Minuten gebaut wurden (3 Sprints x 8 Minuten) ist das Ergebnis besser als bei einer Bauzeit von 45 Minuten
  • Gesamt betrachtet (also mit Planung und Retrospektive) ist keiner der beiden Ansätze „schneller“, zumindest nicht nach drei Sprints, aber eben robuster gegenüber Anforderungswünschen und Umbauten
  • Die ersten Ergebnisse waren mit dem Walking Skeleton Ansatz bereits nach dem ersten Sprint (8 Minuten) sichtbar: es standen zwei Räume und ein weiterer war bereits begonnen. Im chaotischen Modus standen zu diesem Zeitpunkt nicht einmal die Hälfte der Außenwände, Innenwände fehlten, Fenster und Türen fehlten,..
standardraeume2

Ergebnis nach acht Minuten Bauzeit mit Walking Skeleton Ansatz

tl;dr

Insgesamt hat das Walking Skeleton Game gezeigt wie sehr sich die ausgewählte Organisationsform auf die Arbeitsqualität und die Ergebnisse auswirken. Das Endergebnis wird dadurch allerdings nicht automatisch besser, schneller oder erfolgreicher, sondern es hängt auch davon ab in wie weit Standards eingehalten werden und wie weitreichend die Änderungswünsche des Kunden tatsächlich sind. Fensterbänke waren beispielsweise ein kleineres Problem, aber die Aufstockung von 2 auf 3 Stockwerke stellte jedoch eine größere Herausforderung. Allerdings hatten beide Teams nach dem Walking Skeleton Ansatz ein Haus mit mindestens fünf Räumen – nach 24 Minuten. Auffällig war, das mit dieser Vorgehensweise auch der Zusammenhang zwischen Änderungswunsch und Umsetzungszeit direkt sichtbar wurde.

In Summe war die Zufriedenheit mit dem Scrum-Ansatz, gezielter Vorbereitungszeit und festen Review-Terminen höher und die Zusammenarbeit für den Kunden stressfreier. Er konnte am lebenden Modell planen, schieben, entwickeln und begrenzt ändern.

Die Vorteile des Walking Skeleton Ansatzes liegen am modularen Ansatz, der dem Kunden ermöglicht mit dem echten Modell zu „spielen“, Konstruktionsänderungen vorzunehmen und auf Augenhöhe mit dem Team über Machbarkeit von Umbauten zu sprechen. Auch die Qualität ist beim Walking Skeleton Ansatz eher gleichbleibend für jeden Raum – was bei der anderen Variante überhaupt nicht betrachtet wurde.

Die Aufgabenverteilung fiel dem Team im zweiten Durchlauf sichtlich einfacher und die Modularisierung ermöglichte nicht nur einen unkomplizierten Austausch von Teammitgliedern, sondern auch theoretisch einen Austausch der Räume von einem Projektteam ins andere. Darüber hinaus war die Optimierung der Arbeitsweise fest verankert.

 

Mit Scrum in den Burnout?

Campfire on shi shi beach in Olympic national park

Wenn moderne Ideen, Frameworks oder auch Produkte an Popularität gewinnen, dann weichen im Laufe der Zeit einige Interpretationen sehr schnell vom Ursprung ab. Leider. Dann kommt es zu kausalen Verbindungen und Irrtümern die nicht der Grundidee entsprechen.

Was schade ist, denn es wird dem Werkzeug an sich nicht gerecht. Gleichzeitig sind Missverständnisse oder Vorbehalte vorprogrammiert. Denken Sie an ein Hilfsmittel, an ein Werkzeug. Vielleicht an Ihr Auto oder ein Messer in der Küche.

Sie können mit dem Messer schneiden oder mit dem Auto von A nach B fahren. Viele Menschen tun das, gewinnen an Mobilität, können somit komfortabel an die Arbeit fahren, Freunde besuchen oder ein leckeres Essen zubereiten. Daneben kann man mit einem Messer auch andere verletzen oder sich in den Finger schneiden oder mit dem Auto in die Fußgängerzone fahren und Menschen verletzen. Das geht beides. Jetzt ist die Frage ob diese Werkzeuge per se schlecht sind oder Opfer destruktiver Anwendung werden?

Wieso das Ganze? Ich möchte mich mit diesem Beitrag auf einen recht schroffen Artikel beziehen der Scrum und agile Methoden für ein erhöhtes Burnout-Risiko verantwortlich macht. Nicht nur weil ich glaube, das es den Methoden nicht gerecht wird, sondern auch weil einige Irrtümer enthalten sind. Es geht um folgenden Artikel:

Ab in den Burnout, aber mit Methode! Was nach dem besten Ansatz aller Zeit in der Softwareentwicklung klingt, kann zu ganz schön vielen Problemen führen. Agile ist nämlich nicht nur gut für Projekte, sondern erhöht unter Umständen auch das Burnout-Risiko der beteiligten Mitarbeiter.

Agil ausgebrannt – Wie Arbeitsmethoden & -bedingungen in den Burnout führen

Ich werde dazu einzelne Passagen des Artikels herausziehen und kommentieren. Sie können daraus ein tieferes Verständnis zur Scrum-Methode entwickeln. Let´s go.

In der gegenwärtig zehnten Auflage der großen Anwender-Befragung von VersionOne liegt die pünktliche Auslieferung des Produkts in der Liste der beliebtesten Erfolgsmetriken vor der hohen Produktqualität in Führung. Und danach kommt gleich noch die Zufriedenheit des Kunden. Wie soll man das bloß unter einen Hut bekommen?

Die Wahrheit ist: Das geht nicht. Auch Agile kann entweder zu schnelleren Ergebnissen führen oder dazu, dass die Produktqualität steigt. Wer beides will, muss der Realität ins Auge blicken – oder lässt seine Entwickler ausbrennen.

Irrtum #1: Agile führt nicht zu schnellerem Ergebnis, sondern es liefert frühere Teilinkremente die potentiell ausgeliefert und vom Kunden beurteilt werden können. Es gibt zusätzliche Feedbackschleifen die vermeiden sollen, das lange Zeit etwas falsches entwickelt wird – was demotiviert. Schneller wird man nicht. Das Burnout-Risiko steigt damit nicht, im Gegenteil, es wird eher gesenkt, weil: frühe Wertschätzung gegenüber dem was ist, schnelle Anpassung und Korrektur von Fehlern.

Irrtum #2: „Ein Spagat aus Qualität, pünktliche Auslieferung und Kundenzufriedenheit geht nicht.“ Doch geht, nur im Scrum-Ansatz wird weder an Qualität, zeitlichen Terminen und Kundenzufriedenheit gespart, sondern am Inhalt. Der Spagat gelingt durch Maximierung des Geschäftswertes und Weglassen von unwichtigem.

Auf Ebene der täglichen Bewertung des Projekterfolgs steht die Velocity im Zentrum der Aufmerksamkeit: Ist das Team schnell genug? Arbeitet es das Product-Backlog mit einer gleichbleibend hohen Geschwindigkeit ab? Das ist offenbar der wichtigste Maßstab dafür, wie gut agil arbeitende Teams sind.

Irrtum #3: Die Velocity und das Burndown-Chart sind Indikatoren dafür ob das was sich das Team am Beginn des Sprintes vorgenommen hat bis zum Ende des Sprintes wirklich fertig wird. Es geht um eine Selbstüberprüfung der Realisierbarkeit und ob „Störungen“ vorliegen die daran hindern.

Abweichungen dafür sind Grund für Analysen in der Retrospektive. Es geht also nicht um Aspekte wie „schnell“ oder „gut“ ein Team ist, sondern darum ob der Prozess, den das Team nutzt, passt.

Addieren wir nun noch einen Mikromanager hinzu, haben wir beste Bedingungen für hohe Burnout-Quoten.

Irrtum #4: There is no Micromanager, because agile. :) Ein Scrum-Team arbeitet vollständig ohne Management. Es gibt die Rollen Scrum Master, Product Owner und Entwickler. Natürlich kann es innerhalb der Stakeholder die Situation des Micromanagements geben – dann ist es jedoch Aufgabe des Scrum-Masters/des Teams darüber zu sprechen, falls das in irgendeiner Weise zum Problem wird.

Die Velocity sollte also lieber nur zur langfristigen Beurteilung der Entwicklung der Teamleistung verwendet werden, nicht, um die Leistung des einzelnen Entwicklers täglich zu bewerten. Sonst droht ungesunder Stress; Angst vor negativen Konsequenzen nach schlechten Tagen tut niemandem gut. Wer dauerhaft in der Sorge arbeitet, dass er für einen Tag abgestraft werden könnte, an dem es ihm einfach nicht so gut ging, gerät schnell in den Burnout-Teufelskreis. Das könnte allerdings häufiger vorkommen als man annehmen würde, wenn Velocity doch der wichtigste Maßstab für die Bewertung agil umgesetzter Projekte ist.

Irrtum #5: Eine Vermischung zwischen persönlicher Velocity und Team-Velocity die es im Scrum-Framework in der Form nicht gibt. Eine Velocity bezieht sich immer auf das Team – nie auf einzelne Mitarbeiter.

Auch jenseits aller anti-agilen Polemik lassen sich einige Faktoren identifizieren, die fest zur agilen Arbeitsweise gehören und doch die Entstehung von Burnouts begünstigen. Lange To-Do-Listen und das Gefühl, nie alle anstehenden Aufgaben bewältigen zu können, gehören dazu.

Irrtum #6: Dem Gefühl, anstehende Aufgaben nicht bewältigen zu können wird doch mit konkreten User Stories die schriftlich formuliert werden, einem festen Ansprechpartner (dem Product Owner), Akzeptanzkriterien, gemeinsamen Schätzung im Team und einer Zusammarbeit als Team sehr stark entgegen gewirkt. Darüber hinaus hilft die Velocity des Teams dabei eine klare Aussage über die Realisierbarkeit und den zeitlichen Horizont abzuschätzen. Was vorher nur vage formuliert war, wird nun sichtbar und in Fakten betrachtbar.

Besonders problematisch ist das, wenn Entwickler zu wenig Einfluss darauf haben, was auf ihrer To-Do-Liste landet. Das gilt sowohl für den stetigen Nachschub, gegen den sie sich oft nicht wehren können, als auch für die Art der Aufgaben. Jeder Entwickler macht bestimmte Dinge lieber und auch, wenn wohl niemand im Berufsalltag nur seiner bevorzugten Tätigkeit nachgehen kann, muss auch das in kreativen Jobs wie dem des Entwicklers von Zeit zu Zeit möglich sein. Sonst sinkt die Motivation.

Irrtum #7: In Scrum werden keine Aufgaben zugewiesen (Push), sondern jeder nimmt sich per Pull-System ein der nächsten Aufgaben mit hoher Priorität. Daher gibt ein implementiertes Scrum-Backlog den Entwicklern wesentlich mehr Freiheitsgrad als zum Beispiel die Aufgabenverteilung via Chef-Position.

Gegen stetigen Aufgaben-Nachschub habe ich aber kein wirkliches Argument und kenne auch nicht wie das Scrum-Framework darauf reagiert. Rein persönlich finde ich ja nachwachsende Aufgaben ein sicheres Zeichen dafür, auch noch in ein paar Monaten gebraucht zu werden :)

Auf Teamebene existiert außerdem der sogenannte Scrum Fatigue. Der Begriff wird von Gavin Coughlan benutzt, um zu beschreiben, was passiert, wenn Scrum-Teams ihren Antrieb verlieren. Werden die Meetings immer unproduktiver, ist das Backlog unklar definiert, fehlte es an Erfolgserlebnissen, befindet sich das Scrum-Team auf dem Weg in die Krise und nimmt das Produkt gleich mit.

Irrtum #8: Damit genau das nicht passiert, gibt es doch die Retrospektiven – nach jedem Sprint.

Gute Leistungen dürfen beispielsweise nicht für selbstverständlich gehalten werden, sondern müssen erwähnt werden. Nur das hält die Motivation hoch und hilft Mitarbeitern dabei, ihre Erfolge wahrzunehmen.

Irrtum #9: Die Wissenschaft streitet darüber und keiner weiß, was wirklich motiviert (siehe Reinhard K. Sprenger). Was wir aber Wissen: was uns demotiviert und das kann in einem Framework in denen die Werte Mut und Offenheit eine große Rolle spielen, natürlich eingebracht werden.

Und ständig wechselnde Anforderungen, beispielsweise bei der Arbeit mit unentschlossenen Kunden, gehören ebenfalls zu den Faktoren, die das Ausbrennen von Mitarbeitern begünstigen.

Irrtum #10: Da stimme ich zu. Doch ist der kausale Zusammenhang an der Stelle verkehrt. Das liegt nicht am Scrum-Framework – im Gegenteil, das Framework gibt die Chance mit unentschlossenen Kunden und hohen Unsicherheiten konstruktiv umzugehen. Zugleich ist die kundennahe Entwicklung nicht in Scrum begründet, sondern daran das sich unsere Märkte heute stark verändert haben und besonders in der Software-Entwicklung häufig individuelle Kundenaufträge umgesetzt werden.

So oder so kann ein Job in der IT-Branche aber stressig werden – um bei Dauerstress den Burnout zu vermeiden, können allerdings persönliche Strategien heranzogen werden, die wir im dritten Teil dieser Artikelserie verraten.

Richtig und wertvoll! Burnout ist nämlich ein persönliches Thema und das ist Irrtum #11: Die Vermischung zwischen persönlicher und organisatorischer Ebene die sich vollständig durch diesen Artikel zieht.

Burnout entsteht beim Menschen und ist sozusagen „hausgemacht“ – das ist quasi ein persönliches „Problem“. Natürlich wirkt der Kontext und die Umwelt darauf ein, aber eben nur bedingt und daher ist es egal ob mit Scrum oder ohne Scrum gearbeitet wird. Das Risiko dafür gibt es in beiden Fälle, aber die Ursache ist oftmals eine ganz andere. Sie sind komplex.

Das ist auch der Grund weshalb es in jedem Beruf und jeder Branche eine fast gleich verteilte Prozentzahl an sogenannten „Burnout“-Betroffenen gibt.

Scrum an sich besitzt jedoch viele Artefakte damit sich eine hohe Mitarbeiterzufriedenheit einstellen kann und unsichtbares sichtbar wird. Doch ist es wie bei einem Messer… Sie können sich damit in den Finger schneiden oder Ihr Mittagessen zubereiten.

Mit Scrum in den Burnout? Ich weiß nicht.

Kompliziertheit in Software-Architektur reduzieren, Qualität steigern: Walking Skeleton Ansatz

staceyIn neuen Software-Projekten gibt es oftmals zwei große Unbekannte: das WAS? und das WIE? Meist ist gleichzeitig unklar was der Auftraggeber tatsächlich haben möchte und mit welcher Technologie es umgesetzt werden kann. Das kennen die meisten aus der Stacey-Matrix.

Damit Projekte mit dieser Ausgangssituation erfolgreich umgesetzt werden können, ist es erforderlich klärende Informationen zu bekommen.

„In order to reduce risks on projects like the above you need to figure out all the unknowns as early as possible.“

goo.gl/zty8sw

In der Praxis passieren an dieser Stelle jedoch mindestens zwei typische Fehler:

  1. Es wird sich nur darauf konzentriert die Unsicherheit in den Anforderungen abzubauen
  2. Es wird sich nur darauf konzentriert die Unsicherheit in der Technologie abzubauen

Situation 1 ist erkennbar an Anforderungsdokumenten mit mehr als 30 Seiten und Meetings, Meetings, Meetings. Situation 2 ist erkennbar wenn wochenlang an einer Software gearbeitet wird, aber noch kein echter Anwendungsfall gezeigt werden kann bzw. noch nicht entwickelt wurde oder an sehr euphorischen Techies :)

In beiden Fällen entstehen meist (theoretische) Luftschlösser – denn es wird am tatsächlichen Problem vorbei gearbeitet. Oftmals reine Verschwendung, denn beides muss zusammen erfolgen.

Ein Beispiel? Das ist vergleichbar mit dem Plan ein Haus zu bauen, aber keine Informationen über Materialien, gesetzliche Vorgaben und Handwerk zu haben. Oder ein Haus zu bauen, aber nicht zu wissen wer einzieht.

Erst wenn die technischen Rahmenbedingungen klar sind, kann geschaut werden, wie eine Anforderung integriert werden kann und umgekehrt. Das ist ein kreativer/komplexer Prozess bei dem wie im Reißverschlussverfahren unterschiedliche Parteien zusammen auf eine Bahn gelangen.

Trust me, I´m engineer

Johannes Hofmeister hat sich mit dem Thema des Software-Engineerings im Rahmen einer Studie wissenschaftlich befasst und dabei visualisiert was genau beim Software-Entwicklungsprozess passiert:

emprastudie

Kurz: Es findet beim Entwicklungsprozess ein Mapping zwischen dem Domänen und dem Code Modell statt. Das ist sozusagen die Kern-Aufgabe des Software-Engineerings. Ein guter Entwickler kann beides bzw. in einem guten Team sitzen ausreichende Menschen die beides können und gut zusammenarbeiten.

Ist eine von beiden Seiten nicht ausgeprägt, kann ein Projekt nie erfolgreich fertig gestellt werden. Ich habe das in der folgenden Grafik visualisiert (Erweiterung der Grafik von Johannes Hofmeister durch mich, also reine „Koglin-Adaption“).

walkingskeleton

In Software- und Produktentwicklungszyklen sollten also gleichzeitig auf der Anforderungs- und der Technologieebene Unsicherheiten im Gleichschritt reduziert werden.

anatomical overlays 1

Wie das geht, beschreibt der Walking Skeleton Ansatz:

„A Walking Skeleton is a tiny implementation of the system that performs a small end-to-end function. It need not use the final architecture, but it should link together the main architectural components. The architecture and the functionality can then evolve in parallel.“

http://goo.gl/A2xFNq, Alistair Cockburn

Mit diesem Ansatz wird die Parallelentwicklung zwischen Architektur und Funktion möglich. Das fördert die gesunde Balance zwischen Geschäfts- und Anwendungslogik. walkingskeletonslice

So genial, weil genau das die Fertigkeit ist, die ein (agiles) Team benötigt wenn es lernen möchte wie es von langfristigen Entwicklungsphase, die sich über mehrere Monate erstrecken, auf kurzfristige Auslieferungsphasen von zwei bis vier Wochen kommen kann. Damit der Kunde frühes Feedback geben und das Team das „Richtige“ liefern kann.

Und wie genau das umgesetzt werden kann, erfahrt ihr entweder durch eine Teilnahme am kommenden Agile Building Day. Dort werden wir das nämlich live simulieren und erleben. Oder ihr lest euch online etwas in das Thema ein.

Für diejenigen die das trainieren möchten, habe ich gemeinsam mit Matthias Seul gerade ein Konzept für das sogenannte „Walking Skeleton Game“ ausgearbeitet. Wir haben das die Woche bereits erfolgreich verprobt.

Eine Umstellung von langfristig laufende Projekten auf kurzfristige Iterationen mit früher Wertlieferung wie es in agilen Projekten üblich ist, wird häufig in ersten Momenten als schwierig oder unmöglich empfunden. Das Walking Skeleton Game soll zeigen wie es möglich wird.

Eine vollständige 17-seitige Anleitung wurde dazu abschließend in den letzten Tagen verschriftlicht und wird gerade gegen gelesen. Falls ihr daran interessiert seid, hinterlasst einfach eine kurze Mail unter mail@team-architekt.de und erfahrt alle Updates.  Die Simulation basiert auf der bekannten Scrum Lego City Simulation.

onepage

„Wir machen ja Scrum, aber…“ – wieso klemmt´s?

rugby scrum

Scrum kann in fünf Minuten erklärt werden. Der Prozess, die Rollen, Meetings, die Artefakte und was dafür notwendig ist damit es rund läuft allerdings nicht. Wieso?

Es handelt sich um ein ausgeklügeltes Framework das in sich zusammen kraftvoll wirken kann und es wird vor allem erst kraftvoll wenn die komplexe Komponente sich dabei mit ihren Potentialen entfalten kann.

Darüber hinaus ist es ein Unterschied:

  • Habe ich Wissen über etwas? oder
  • Kann ich Wissen auch gewinnbringend einsetzen? Besitzen alle anderen im Team das erforderliche Können?

Wer weiß wie ein Flugzeug fliegen kann, kann es noch nicht fliegen.

Der zweite Punkt ist ganz entscheidend wenn die Vorteile der agilen Vorgehensweise ausgespielt werden sollen:

  • Lieferung des größtmöglichen Geschäftswertes
  • Potientiell auslieferbares Produkt/Software alle <= 30 Tage
  • Schnelle Offenlegung von Problemen
  • Kontinuierliche Verbesserung des Prozesses

Unternehmer, Teamleiter und Geschäftsführer stehen dabei hin und wieder vor der Schätzung dieser Aufwände. Also der Frage welchen Impact das auf ihr Unternehmen hat und was tatsächlich „gelernt“ werden darf, damit sich die 3-400 % Performance-Steigerung zeigen die Jeff Sutherland verspricht.

The average Scrum team delivered a 35% improvement in velocity at Yahoo [1] where teams properly coached delivered 300-400% improvements. The best Scrum Master at MySpace peaked at 1680% of initial velocity after 20 weeks and averaged 450% increase in velocity over 10 Sprints. (Quelle: Scrum Metrics)

Daher liefert dieser Artikel eine Liste von Kompetenzen die ein Scrum kennen und erfolgreich anwenden darf, damit solche Performance-Steigerungen möglich sind. Es zeigt gleichzeitig vor welchen Herausforderungen ein Team steht das mit Scrum arbeiten möchte.

Erforderliche Kompetenzen für Scrum

  1. Erstellen eines lieferfähigen Produktes zum Sprintende
  2. Zyklische Meetings vereinbaren und regelmäßig durchführen
  3. Meetings ergebnisorientiert, zielgerichtet und zeitbegrenzt durchführen
    • Planning
    • Review
    • Daily Scrum
    • Retrospektive
  4. Pünktlich bei Meetings erscheinen
  5. Timeboxing berücksichtigen, kurz und präzise fassen
  6. Verständnisse für Pull-Systeme: Wie kann ein Aufgaben-Pull-System im Team implementiert werden?
  7. Product Backlog aufbauen
  8. Backlog priorisieren
  9. Kundenwert analysieren
  10. Backlog pflegen
  11. User Stories formulieren
  12. Nutzerrollen formulieren, Personas entwerfen
  13. User Stories schätzen
  14. User Stories zerlegen
  15. Akzeptanzkriterien formulieren
  16. Akzeptanztests schreiben
  17. Kontinuierliche Verbesserungen identifizieren
  18. Formulieren der Definition of done
  19. Einhalten der Definition of done
  20. Verbessern der Definitionen
  21. Velocity messen und überwachen
  22. Hindernisse identifizieren und lösen
  23. Release planen
  24. Testgetriebene Entwicklung
  25. Pair programming / Mob programming
  26. Refactoring und Clean Code
  27. Coding Dojos
  28. Code Reviews
  29. Testen
  30. Continuous Integration / Continuous Deployment einführen und umsetzen
  31. Collective Ownership einführen
  32. Als crossfunktionales Team zusammenarbeiten
  33. Produktinkremente nach dem Minimum Viable Product Ansatz umsetzen (Einfachheit anstreben)
  34. Mit dem Kunden kommunizieren
  35. Feedback vom Management mit einfließen lassen

Was wir Ihnen mit dieser Liste deutlich? Was davon kann ihr Team gebrauchen?

Sprechen Sie mich an. Ich analysiere gerne und kostenlos vor Ort welche Aspekte abgerundet werden dürfen, damit ihre Teams mit viel Spaß und Freude gute Software an ihre Kunden liefern.

Die primäre(n) Änderung(en) des neuen Scrum Guides (übersetzt ins Deutsche)

Vor ein paar Tagen (Juli 2016) haben Jeff Sutherland und Ken Schwaber eine aktualisierte Version des englischen Scrum-Guides veröffentlicht. (Was ist Scrum?)

Was ist der Scrum-Guide?

Der Scrum-Guide stellt einen Leitfaden für Scrum dar. In ihm sind auf 17 Seiten die Scrum-Rollen, -Meetings, -Artefakte sowie die gültigen Spielregen formuliert die dazu führen, das mit diesem Framework komplexe, innovative und kreative Projekte erfolgreich umgesetzt werden können.

Hier finden Sie die aktuelle und kostenlose Version des Scrum Guide in englisch (Juli 2016). Die deutsche Version ist noch nicht übersetzt. Was nicht weiter tragisch ist, denn die Anpassung ist minimal. Dennoch finden Sie die übersetzten Passagen in diesem Artikel.

Was wurde geändert?

Im Internet ist die Rede von einer wesentlichen Änderung. Ich sehe insgesamt zwei – ein kleiner markenrechtlicher Aspekt und eine inhaltliche Ergänzung:

scrumGuideTM

  • Der Scrum-Guide ist eine Trademark geworden
  • Die fünf Scrum-Werte wurden im Scrum-Guide hinzugefügt

Dieser Artikel soll sich auf die inhaltliche Ergänzung konzentrieren:

scrumValues

 

Wofür sind Werte wichtig?

Werte geben eine Orientierung – eine Richtung – ohne eine konkrete WAS?-Definition. Sie vermitteln was wichtig ist, ein Ideal. Die fünf Werte die jetzt im Scrum-Guide aufgenommen wurden, unterstützen beispielsweise…

…das schnelle offenlegen von Problemen – was sie lösbar macht…. oder steigern den Fokus in Meetings – nämlich auf das Sprint-Ziel.

Wie lautet die genaue Erweiterung im Scrum Guide?

Die Passagen die hinzugefügt wurden, sind folgende:

When the values of commitment, courage, focus, openness and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone. The Scrum Team members learn and explore those values as they work with the Scrum events, roles and artifacts.

Scrum Guide, Seite 4

Übersetzt:

Wenn die Werte Engagement, Mut, Fokus, Offenheit und Achtung vom Scrum Team verkörpert und gelebt werden, werden die Scrum Pfeiler der Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen für alle auf. Die Scrum Teammitglieder lernen und erkunden diese Werte während sie mit den Scrum Events, Rollen und Artefakten arbeiten.

weiter geht es im Scrum-Guide…

Successful use of Scrum depends on people becoming more proficient in living the se five values. People personally commit to achieving the goals of the Scrum Team. The Scrum Team members have courage to do the right thing and work on tough problems. Everyone focuses on the work of the Sprint and the goals of the Scrum Team. The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work. Scrum Team members respect each other to be capable, independent people.

Scrum Guide, Seite 4

Übersetzt:

Die erfolgreiche Nutzung von Scrum beruht darauf, dass Menschen kompetenter werden, diese fünf Werte zu leben.

Commitment

Die Menschen engagieren sich persönlich, die Ziele des Scrum Teams zu erreichen.

Mut

Die Scrum Teammitglieder haben den Mut das Richtige zu tun and an schwierigen Problemen zu arbeiten.

Fokus

Jeder fokussiert sich auf die Arbeit des Sprint und die Ziele des Scrum Teams.

Offenheit

Das Scrum Team und dessen Stakeholder verpflichten sich, über die Arbeit sowie über die Herausforderungen bei der Verrichtung der Arbeit, offen zu sein.

Respect

Scrum Teammitglieder achten sich gegenseitig als fähige, unabhängige Menschen.

(Was ein Sprint ist, was ein Scrum Master tut und was es mit Stakeholdern auf sich hat, erläutert Ihnen das Scrum Glossar)

Meine Empfehlung

Diskutieren Sie diese fünf Scrum-Werte doch bei der nächsten Retrospektive mit dem Team.
Bringen Sie die Werte in eine Hierarchie: Was ist dem Team besonders wichtig? Und diskutieren Sie im Anschluss wie diese Werte zukünftig in die Arbeit einfließen und den Projekterfolg steigern kann.
Diese Werte eignen sich ebenfalls für einen Team-Codex der von allen Beteiligten unterschrieben werden und als visuelle Erinnerung aufgehangen werden kann.
ScrumTeamCodex

5 interessante Gründe wieso agile Vorgehensweisen sich weiterhin in Deutschland durchsetzen werden

Der Beitrag 5 Crazy Reasons Why Agile does not Work In Germany ist sehr stimmig. Allerdings gibt es auch gute Gründe weshalb sich agile Vorgehensweisen weiterhin auch in Deutschland durchsetzen werden. Fünf der wichtigsten habe ich kurz zusammengestellt.

  1. Die Projektkomplexität wächst
    • Viele Bereiche des Lebens sind heute mit nützlichen Lösungen und Dienstleistungen abgedeckt. Die Anzahl der komplexen und innovativen (IT-) Projekte wird daher weiterhin zunehmen. Beispiele wie der Berliner Flughafen oder der langjährige Chaos-Report zeigen deutlich auf, das die Vorgehensweisen die dabei angewandt werden nicht gelingen. Wer frühen Wert liefern und Fehlinvestitionen vermeiden möchte, wird sich nach agilen Vorgehensweisen umsehen.
  2. Der Kunde kauft nicht regional – sondern er wählt aus großem Angebot aus
    • Bei einem wachsenden Angebot haben die Kunden mehr Möglichkeiten für a) ihr individuelles Produkt und b) einen guten Preis zu finden. Welche Umbrüche dadurch entstehen, zeigt beispielsweise der Automobilmarkt. Damit ein guter Preis zustande kommt, müssen die Produktionskosten gesenkt werden. Das gelingt besonders gut bei einer Optimierung der investierten Arbeitszeit und der angewandten Prozesse. Wachsen Prozesse lebendig mit und werden kontinuierlich verbessert, können die Preise gesenkt und Wettbewerbsvorteile erreicht werden.
  3. Wachsende Zahlen der persönlichen Überlastung
    • Die Zahlen von Menschen mit Überlastungsdiagnosen wie Burnout und Co. sind weiterhin stark wachsend. Umso wichtiger wird es zunehmender die Realisierbarkeit von Projekten tatsächlich zu prüfen und eine Abschätzung dazu einzuholen: „Geht das überhaupt?“. Daneben fördern gute Sozialbedingungen das natürliche Miteinander. Eine klare Abstimmung über das Ziel welches erreicht werden soll, fortlaufende Kommunikation, Erfolge und gemeinsame Lösung erhalten die Gesundheit. Es geht also um gesunde Rahmenbedingungen bei der eine hohe Selbstbeteiligung und eine hohe Selbststeuerung eine Rolle spielen. Scrum eignet sich hier perfekt.
  4. Aufgabenverteilung nach dem PUSH-Prinzip wird zunehmend an Bedeutung verlieren.
    • Bei wachsender Projektkomplexität und hoher Aufgabendynamik durch schnelle Entwicklung werden Führungskräfte zunehmend kennenlernen das es nicht wichtig ist, das irgendjemand eine Aufgabe in irgendeinem Zeitraum erledigt, sondern der/die passende Mitarbeiter/Mitarbeiterin verlässlich und hochwertig die Umsetzung durchführen kann. Aufgabe und Kompetenzen müssen zusammenpassen. Andernfalls ist das Risiko für schlechte Ergebnisse, lange Einarbeitungs- und Umsetzungszeiten zu hoch. Die beste Möglichkeit hierzu bietet das PULL-Prinzip: Jeder Mitarbeiter entscheidet selbst ob er sich eine Aufgabe mit den bestimmten Rahmenbedingungen zutraut.
  5. Rahmenbedingungen aus dem letzten Jahrhundert behindern heutige Wertschöpfung
    • Sehr viele moderne Werkzeuge der Personalführung (Pay for performance, Zielvereinbarungen, Compliance, Bonussysteme, Talentpools, Anreizsysteme) zielen darauf aus, das der Mitarbeiter mehr und schneller arbeitet. Doch das Denken lässt sich nicht steuern oder kontrollieren. „Seien Sie mal kreativ.“ ist wie „Bitte nicht so depressiv gucken.“ – es funktioniert nicht. Kreative, hochwertige und schnelle Lösungen entstehen in der Zusammenarbeit mit Spaß, Freude, Erfolg und klarer Kundenausrichtung. Doch dies wird oftmals durch moderne Werkzeuge, Steuerung und Kontrolle behindert. Daher wird es zunehmend wichtiger sein, sich nach Alternativen umzuschauen, wie beispielsweise eine agile Organisationsarchitektur wie ich sie in einem kürzlichen Vortrag skizziert habe.

Ohne Scrum Master ist alles doof – Fragile Agile

Produktentwicklung und Projektarbeit ohne Scrum Master kannste zwar machen – ist dann halt kacke. Doch… ehm. Wi… (hust)… wie…. WIESO?

Na die Kombination aus Product Owner und Entwicklungsteam – wo führt die denn hin?

In einem Teamsystem ohne Scrum Master fehlt eine wesentliche Komponente. Nämlich die menschliche Instanz für Prozess-Einhaltung, Fortschrittsanalyse, Prozess-Verbesserung und „Supporting Leadership“. Es fehlt der Wächter, der Treiber – jemand der (neutral) aus der Vogelperspektive auf das Projektvorhaben schaut und für das Team, Organisation und Kunden auf die Einhaltung der Scrum-Versprechen achtet:

  • Lieferung des größtmöglichen Geschäftswertes
  • Potientiell auslieferbares Produkt/Software alle <= 30 Tage
  • Schnelle Offenlegung von Problemen
  • Kontinuierliche Verbesserung des Prozesses

Die Versprechen gehen dann mit hoher Wahrscheinlichkeit verloren. Dann baut ein Team und baut und baut und baut und baut und baut und baut… irgendetwas. Oder auch nicht. Ist ja dann egal. Oder haben Sie als Geschäftsführer die Zeit für den reibungslosen Ablauf in allen Teams zu sorgen? Hat es mit einem Teamleiter geklappt? Schauen Sie mal in die Projektstatistiken.

„Wir sind fast fertig! Noch 2-3 kleine Änderungen“

Ohne Prozesswächter sind alle zwar irgendwie kreativ – doch erfolglos und gelangweilt. Dann wird auf Feierabend und Pause gehofft.

Klar, man kann auch 16.000 Stunden im Jahr absitzen. Doch die meisten resignieren irgendwann – spätestens nach einem halben Jahr. Die suchen sich dann einen anderen Job. Andere werden krank – Burnout, Boreout, oder was ganz anderes. Wieder andere Arbeiten gedanklich an eigenen Projekten. Machen sich selbständig. Not macht erfinderisch. Oder andere perfektionieren eben das was sie tun. Dann wird das Haus was der Kunde haben wollte, eben ein Hochhaus mit 77 Etage, Tiefgarage und Hubschrauberlandeplatz am Dach.

Who cares?

 

Building it

 

Wenn sich Ihr Unternehmen das leisten kann, ok. Wenn es den Mitarbeitern egal ist was sie tun, ok. Wenn es Ihren Kunden egal ist ob etwas geliefert wird, ok. OK!

Mein Anspruch ist da ja eher, das die Arbeit – die den Großteil des Lebens ausmacht auch Erfolg, Spaß und Wachstum bringen darf. Arbeit ist in meinem Modell mehr als Anwesenheitspflicht. Es geht darin auch um Kunden die Ihrem Unternehmen vertrauen – die dafür zahlen das Sie das beste aus einer Investition machen. Wer zahlt schon für ein Produkt den doppelten Preis, wenn er weiß das es durch einen Mangel an Strukturen, Orientierung und Führung verbrasst wird?

Ein Scrum Master pro Team sorgt also dafür, das 6-12 andere einen guten Job machen können. Er hilft ihnen schneller und besser zu werden.

Ein guter Scrum Master…

  • …vereint Scrum Werte, -Ansätze und Wertschöpfung
  • …hat ein Gespür für das Team
  • …hat den Fortschritt und den Prozess im Auge
  • unterstützt dabei, dass das Produkt geliefert wird
  • moderiert wertvolle Meetings
  • gibt Möglichkeiten für kontinuierliche Verbesserung

Erst mit dem Dreigespann aus Team + Product Owner + Scrum Master entsteht eine ausgeglichene Team-Architektur die für kontinuierlichen „Flow“ sorgt – nicht zu viel und nicht zu wenig.agileFusion

Flow eben. Das merken die Mitarbeiter, das merkt der Kunde. Haben Sie schon einen guten Scrum Master?

 

7 Erfolgsfaktoren für schnellen Change – hin zur agilen Organisation

agileOrganisation

Gestern Abend stellte ich in 45 Minuten einen schnellen Weg zur agilen Organisation vor. Ein Erfahrungsbericht eines unternehmensweiten Change-Prozesses: „Umschalten auf agile Organisation“

Ein Aspekte waren dabei die 7 Erfolgsfaktoren für schnellen Change – diese an dieser Stelle noch einmal kurz vorgestellt werden sollen:

7 Erfolgsfaktoren für schnellen Change

  1. Geschäftsführung/Management beteiligt sich aktiv an der Lösungsfindung und Kommunikation des Change
  2. Es gibt führende Beteiligte die das agile Mindset verstanden haben und im Tagesgeschäft einbringen
  3. Einwände werden integriert und Lösungen adaptiert
  4. Strategische stabile Ausrichtung auf den Kunden statt interner Aktionismus
  5. Mitarbeiter haben Zeit und Möglichkeit den Change zu verstehen: Sprache, Hintergründe und Ziele
  6. Möglichkeit der Beteiligung einräumen
  7. Empowerment statt Angst – Einladen zum Lernen und Entwickeln von Kompetenzen

Einblicke in ausgewählte Slides

Fearless Change Titelfolie Ausgangssituation des Change Prozesses, Unternehmensinformationen Ziele der Organisation CoRe Culture Model Entstandener Nutzen Klar getrennte Entscheidungsräume

Haben Sie Interesse daran die Vorzüge agiler Zusammenarbeit in Ihre Organisations-Architektur zu nutzen? Kontaktieren Sie mich gerne.