Ein gutes Sprint Review Meeting – wie sieht das aus? Die Essenz von 6 „Agilisten“ aus Kassel

Logo2017_rund transparant inverseVon den Kompetenzen, Erfahrungen und Wissen waren wir sicherlich durchgemischt an diesem abendlichen und 40. Treffen der „Agile Usergroup Kassel“. Dabei begaben sich Manager, Koordinatoren, Agile Coaches, Entwickler und Product Owner sich zu sechst in den DialoUserGroup_Logosg und es galt wieder einmal: „Wer auch immer kommt, es sind die richtigen Leute.“

Die übergreifende Zielsetzung des Abends war: Wie sieht ein wirklich gutes Sprint Review Meeting aus?

 

Die kurze Antwort: es ist (der richtige) Takt durch gute Moderation, Vorbereitung und Fokus von allen Beteiligten gemischt mit der Anpassung auf die Zielgruppe. Das bedeutet konkret: in dem einen Team ist es eine angenehme und ruhige Zusammenkunft von Angesicht zu Angesicht mit Keksen die nicht fehlen dürfen. In anderen Teams sind es 26-minütige Reviewmeetings mit Übersichtsslides für die Executives zum Anfang und Videoaufzeichnungen.

Im Detail:
Natürlich gibt der offizielle Scrum Guide einige Anhaltspunkte zu den Grundlagen des Meetings. Diese haben wir initial kennengelernt und uns anschließend komplexeren Fragestellungen im World Café Format gewidmet – ein Auszug daraus:
1. Runde
• Wie läuft ein typisches Review-Meeting ab?
• Welche Zielsetzung hat das Sprint-Review-Meeting?
• Wen lädt man dazu ein und wen möglicherweise nicht?

2. Runde
• Welche Bedürfnisse haben die unterschiedlichen Teilnehmer und Rollen?
• Wie organisiert man es? Wo findet es statt?
• Was tut man bei Störungen?

3. Runde
• Wie sammelt und priorisiert man das Feedback?
• Was, wenn Feedback persönlich genommen wird?
• Wie lässt sich der Wert des Sprint-Reviews steigern?
Die Teilnehmer haben ihre eigenen Visualisierungen dazu erstellt und ein Fotoprotokoll erhalten. Leider habe ich verpasst das Einverständnis der Teilnehmer zur Veröffentlichung einzuholen. Daher eine eigene Zusammenfassung in grafischer Form:

gutesSprintReviewDanke – wieder einmal an alle Teilnehmer und in diesem Fall ganz besonders an Matthias S. der die agile Usergroup Kassel in den letzten drei Jahren unheimlich bereichert hat und sich jetzt örtlich und beruflich verändert.

 

Ja, Schätzungen sind ein Fehler #noEstimates

Fotolia_165717344_SFür Agilisten sind Schätzungen ein elementarer Bestandteil im Scrum- und Projekt-Prozess. Geschätzt wird relativ, im Vergleich mit den anderen Aufgaben und ohne zeitliche Größe. Verwendet werden fiktive Größen wie Storypoints, Gummibären oder T-Shirtgrößen. Hauptsache keine Personentage, Stunden oder andere Zeiteinheiten. Es geht um das Erfassen von Komplexität oder einfacher: um eine Prognose der Aufwände. Doch macht das (noch) Sinn? Anders formuliert:

Was ist #noEstimates und was möchten die Verfechter uns sagen?

Ein bis zwei Jahre habe ich die #noEstimates-Bewegung oberflächlich beobachtet, versucht das Thema zu verstehen, mich an Diskussionen dazu beteiligt und Kurzvorträge angehört – mit ernüchterndem Ergebnis. Das alles hat leider nicht dazu beigetragen ein klares Bild davon zu bekommen was die Initiatoren für eine Aussage treffen wollen. Bis heute.

Geht es um Zeitschätzungen? Personentage? Aufwände? Komplexität? Relative Schätzungen? Ist eine Methode? Eine Vorgehensweise? Ein Appell? Roy „Woody“ Zuill der den Hashtag #noEstimates offenbar das erste Mal verwendet hat schreibt dazu auf einer Folie in einem Vortrag:

Estimates defined: An approximate calculation or judgement of the value, number, quantity, or extent of something.

In software development, estimates are often used to attempt to predict the future. (Roy „Woody“ Zuill)

Er bezieht sich auf jegliche Schätzungen, ganz generell und womöglich hat er Recht! Darüber hinaus ist #noEstimates vielleicht einfach nur eine Einladung. Es ist keine Methode, Vorgehensweise oder gar ein Prozess.

Was ist die #noEstimates Bewegung?

Unter dem Hashtag #noEstimates wurde der Anstoß dazu gegeben das Thema „Schätzungen“ in Software-Projekten zu reflektieren:

  • Brauchen wir Schätzungen?
  • Sind Schätzungen nützlich?
  • Sind Schätzungen schädlich?
  • Sind Schätzungen verschwenderisch?
  • Sind Schätzungen dysfunktional?

Es ist eine provokante Denk-Einladung darauf vollständig zu verzichten. Ist Planung eine selbsterfüllende Prophezeiung?

Vielleicht fällt es Ihnen genauso schwer wie mir, diesem Gedankengang zu folgen. Schätzprozesse in Form von Magic Estimation oder Planning Poker hatten für mich immer einen Wert. Allerdings möchte Roy „Woody“ Zuill möglicherweise genau darauf hinaus.

Øredev 2013 – Roy Woody Zuill – No Estimates: Let´s explore the possibilities from Øredev Conference on Vimeo.

Schätzungen gaukeln uns Sicherheit in Form von Informationen vor, was uns beim Treffen von Entscheidungen helfen kann.

Möglicherweise sind diese Informationen tatsächlich überflüssig? Überlegen Sie selbst! Aber wenn ich darüber nachdenke, dann hatten Schätzrunden mit Planning Poker und Co. für mich wirklich nur einmalig einen großen Wert. Nämlich das Kennenlernen als solches. Das überrascht mich selbst, aber es half beim initialen Gedankengang große Pakete in kleine Arbeitspakete zu bekommen. Das ist die Essenz! Nicht der Schätzwert, ob 8 oder 100 Storypoints, sondern es ist der Informationsgewinn über den Projektumfang, die einzelnen Arbeitspakete und das „Schneiden“ von Stories. Darüber hinaus vielleicht welche 3-5 Schritte in jedem Arbeitspaket enthalten sind.

Es geht nicht um Schätzungen als solches, sondern der Wert liegt im Erkunden des Gebiets – dem Projektgebiet…

projectScope

 

…und benötigen wir dazu Schätzungen? Oder können wir darauf verzichten und benötigen lediglich diese Frage:

Ist die Aufgabe klein genug, damit sie begonnen werden kann?

…und kann die Sicherheit über die nächsten Schritte möglicherweise mit einer anderen Frage qualitativ hochwertiger beantwortet werden?

Was sind die 2-5 Teilschritte einer Story/Aufgabe/Anforderung?

…und dann wieder…

Sind diese Teilschritte klein genug, damit damit begonnen werden kann?

Babysteps statt Elefantenschritten. Kleine Schritte im Rahmen des Projektgebiets. Demnach kann ich mich mit dieser These anschließen: Steht die Landkarte, sind Schätzungen überflüssig. Was es braucht sind die Arbeitspakete, die Stories, kleine Stories. Der Informationsgehalt der Frage: „Was sind die nächsten Teilschritte die getan werden müssen?“ ist viel höher als „Wie groß schätzt du das Thema?“.

#noEstimates und „Woody“ gehen jedoch noch weiter hinaus…

Wer bis hierhin gelesen hat, soll belohnt werden.

Was wäre wenn… wir Schätzungen und Planung durch den sicheren Glauben ersetzen das wir wunderbare Ergebnisse ernten?noEstimates

 

 

 

 

 

 

Vorschau

12 Alternativen zum Ausprobieren

Skin prick allergy test to find out kind of allergy

Klar kann ausprobieren und experimentieren spannend und interessant sein. Doch es gibt Bereiche dort sollte man lieber professionell oder gar sensibler vorgehen. Herzoperationen zum Beispiel! Was kann da schon schief gehen? Automatisiertes Fahren im Straßenverkehr. Was kann da schon schief gehen? Oder Zusammenarbeit mit Menschen. Was kann da schon schief gehen? Oder Wertschöpfung für Menschen. Was kann da schon schief gehen?

Hier sind also 17 Alternativen zum Ausprobieren – wie kann lernen und Wachstum effizient und risikoarm stattfinden:

1. Vorbereiten von zielgerichtetem Handeln im Diskurs oder eigenständig

Sich vor einer Unternehmung ausreichend Gedanken über das mögliche Ziel, Teilschritte, Kontext, ökonomische, ökologische und systemische Auswirkungen machen.zielgerichtetesHandeln

2. Reflektieren durch Retrospektiven

Konstruktiver Rückblick nach vorn mit geführten Retrospektiven

starfishRetro

3. Lesen eines Buches oder eines Artikel
4. Diskutieren eines Themas
leanCoffeeKlein
5. Teilnahme an einem Training oder einem Seminar
6. Besuchen einer Community of practice
communityOfPracticeKlein
7. Betrachten eines Videos oder Besuchen eines Webinars
8. Beobachten wie andere vorgehen
9. Unterstützen lassen durch Kollegen
10. Nutzen von Methoden (Design Thinking, Canvases und Co.)
11. Durchführen von Befragungen
12. Einholen von Beratung

20151022_agilemoderation-mentoring

 

Die Auflösung von 7 Irrtümern über „Experimente“

Es trendet, das „Experimentieren“ und die „Experimentierkultur“. Dabei bleibt die ganze Sache ein großes Mißverständnis, eine Verbandelung von Irrtümern und eine große Tilgung von Informationen. Das ist zumindest meine Theorie die ich bereits im Artikel „Soziale Experimente sind asozial“ näher beleuchtet habe.

Fotolia_4513898_XL

Der wesentliche Schaden der durch soziale Experimente entsteht ist in Zahlen nicht messbar

Die Resultate der Überzeugung man könne nur durch ausprobieren lernen und weiterkommen halte ich nach wie vor für sehr gefährlich. Wenn nicht sogar für eines der größten Hindernisse wenn es um Transformation, Veränderung und Wachstum geht.

Jegliche Appelle in der Richtung sind mehr als fahrlässig, unprofessionell und kostspielig. Sie erzeugen Drama, Leiden und Schulden. Dieser Schaden ist nicht in Zahlen messbar. Daher haben Experimente in sozialen Systemen nichts verloren oder anders gesagt:

Doch welche Irrtümer zum Experimentieren gibt es im einzelnen und wie lassen sie sich auflösen?

Irrtum #1 „Die komplette Geschichte der Wissenschaft beruht auf dem Ausprobieren“

Das ist falsch, weil besonders das wissenschaftliche Vorgehen auf einer sehr systematischen Vorgehensweisen beruht:

  1. Erfassen des Problems
  2. Analysieren der bekannten Erkennisse in vorhandener Literatur und Forschungsarbeiten
  3. Strukturieren der theoretischen Arbeit
  4. Daten sammeln
  5. Durchführen von empirischen Erhebungen (geführte Experimente)
  6. Auswertung der Ergebnisse

Irrtum #2 „In der Medizin ist das Ausprobieren ein erfolgreiches Vorgehen“

Sehr gerne wird das Beispiel gebracht das ein Arzt die Wirkung eines verschriebenes Medikaments vorher auch nicht kennt. Dieser Vergleicht tilgt sehr viele Informationen.

Kennen Sie den Entstehungsprozess bis ein Medikament für ein „Problem“ auf den Markt kommt?

An Medikamenten wird monate- oder jahrelang entwickelt, geforscht und sie benötigen vor der Markteinführung eine Prüfung auf Zulassung, Unbedenklichkeit und technische Qualität. Dazu sind Tests mit Zellkulturen und Tieren, danach mit Gesunden und schließlich Patienten erforderlich. Danch erfolgt eine Zulassung mit Studien und Ergebnisprüfung. Es folgt eine Markteinführung mit anschließender Nutzenbewertung, usw. usf.

Quelle: https://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwiyzP2_4JzVAhXIuRQKHdAiC1IQFggmMAA&url=https%3A%2F%2Fwww.vfa.de%2Fdownload%2Fkap6-markteintritt.pdf&usg=AFQjCNHEwbxqA0qUYrvxI3IDhiYtPmD6qA

Quelle: https://www.vfa.de/download/kap6-markteintritt.pdf

Der Arzt verordnet Ihnen anschließend das Medikament nicht auf den Verdacht heraus es „könnte helfen“ oder „es auszuprobieren“ sondern er stützt seine Entscheidung auf fundiertes Wissen, Erfahrungswerte, ein medizinisches Studium und eine ausführliche Anamnese, optionale Blutwerte und ihre Patientenakte. Er prüft mit Ihnen im Dialog gemeinsam möglicher Allergien oder sonstige Bedenken.

Schließlich erhalten Sie eine Beratung in der Apotheke und einen Beipackzettel bevor Sie das Medikament einnehmen und dann, ja dann, gibt es quasi eine zielgerichtete Einnahme nach der die Wirkung beobachtet wird und je nach Leiden und Medikament müssen Sie erneut beim Arzt vorstellig werden.

Irrtum #3 „Experimentieren ist ein fester Bestandteil von agiler Arbeit und genau deshalb sind diese Methoden so beliebt und nützlich“

Nein, die agilen Ansätze sind deshalb so erfolgreich und beliebt weil sie einen pragmatischen Spagat zwischen Theorie und Praxis schaffen, diesen mit Wertschöpfung und sozialer Akzeptanz verbinden. Agile Methoden beweisen oder widerlegen unmittelbar ob eine Theorie funktioniert. Dabei ist allen Beteiligten, einschließlich dem Management und den Kunden klar, welchen Preis ein misslungener Sprint haben kann. Es gibt sowohl Planung, Transparanz als auch Zustimmung für ein Vorhaben.

Die Grundlage der Vorgehensweise sind empirische Prozesse die auf der „Inspect & Adapt“-Philosophie zum Fortschritt und Wachstum führt. In erfolgreichen Projekten wird nicht ständig am Prozess experimentiert, sondern es wird beibehalten was gut funktioniert und auf der Basis wird weiterentwickelt.

asd

Der „Inspect & Adapt“ – Kreislauf von Scrum – bekannt als PDCA-Zyklus von Deming und Shewhart

Irrtum #4 „Nur durch Ausprobieren kann man Lernen!“

Ja, das ist richtig. Aber wenn ein Experiment nicht funktioniert, was haben Sie dann gelernt? Sie kennen dann maximal einen Weg wie es nicht funktioniert. Was ist das Wert?

Den Schaden haben sie und die Beteiligten obendrauf. Niederlagen sind uncool. Die haben ihren Preis und sie gehören dazu, klar. Aber dann noch suchen was sie daraus mitnehmen können? Was ist das für ein Quatsch?Kopf mit Schalter

Neulich hat jemand das Beispiel gebracht wie man Radfahren gelernt hat. Das war ein Ausprobieren, oder? Betrachten Sie sich das mal. Haben Sie sich wirklich das Rad gepackt und sich auf den Weg gemacht? Nein! Man hat einen sicheren Ort gesucht zum Anlernen. Nicht die Autobahn oder die Hauptverkehrsstraße, sondern dort wo ein Fall gut ausgeht. Die meisten bekamen wohl eine gute Einweisung, Stützräder und einen Helm. Gleichzeitig wurde man geführt um den möglichen Schaden so gering wie möglich zu halten. Dabei war es wichtig Fortschritte zu sammeln damit die Motivation nicht verloren geht. Wenn doch mal etwas schief ging, dann hat man ihnen aufgeholfen. Oder hat sie jemals jemand gefragt : „Warum bist du gestürzt? Was hast du aus dem Sturz gelernt? Schau ist das nicht toll zu wissen was nicht funktioniert?“ – Völliger Unfug, oder?

Sie können sich jede Niederlage schönreden, ja alles, klar. Doch fragen Sie sich lieber:

  • „Was kann ich mir mit dem erlangten Wissen leisten?“,
  • „Wie gut ist das Erlente?“,
  • „Wie kann ich die Ergebnisse meines Tuns steigern?“ und
  • „Wie kann ich qualtiatives Wissen erlangen das mir und meiner Umwelt etwas nützt?“.

Sehen Sie das? Das ist ein qualitativer Unterschied im Fokus.

zeitstrahlWarum Die Erkenntnis als solches das etwas nicht funktioniert hat ist praktisch ergebnislos. Es ist ein egoistisches Konstrukt das keinen weiteren Nutzen liefert. Lernen ohne Ergebnisbezug ist nutzlos. Theorie und Praxis gehören zusammen und sollten in Summe betrachtet bewertet werden. Theorie alleine ist nutzlos. Genauso ist Erfahrung alleine nutzlos.

Blindes Vertrauen in Erfahrung ebenso wie blindes Vertrauen in Theorie können fatale Auswirkungen haben. Darum sollte jeder auch nur einigermassen plausible Ansatz erprobt, das heisst zum Ausgangspunkt des P.D.C.A.-Regelkreises gemacht werden. Ist der Ansatz geeignet das Problem zu lösen, im kleinen Massstab ebenso wie im gesamten System? In diesem Sinne sollte ein Manager auch über die Qualitäten eines Forschers verfügen, ja diese sogar übertreffen.  Denn  seine  Fehlentscheide bringen nicht nur ein theoretisches Gebilde ins Wanken, sondern gefährden die Existenz von Kunden, Lieferanten, Mitarbeitern und Aktionären. (William Edward Deming)

shewhartcycleIrrtum #5 bis #7

Vergessen Sie die Irrtümer #5 bis #7. Betrachten Sie lieber was stattdessen funktioniert. zielgerichtetesHandeln

Sie haben hoffentlich einige Anregungen dazu bekommen. Die Lösung liegt im zielgerichteten und wohlüberlegtem Handeln. Ein Tun das die Gefahren und vorhandenen Ressourcen berücksichtigt. Eine Vorgehensweise die die Ökologie und Ökonomie berücksichtigt. Der systemische Blick.

Wenn Ihnen dieser kostenlose Artikel gefallen hat, freue ich mich über einen kleinen „Return meines Invests“ in Form eines Buchkauf oder eine Weiterempfehlung dieses Artikels in den sozialen Kanälen.

Mehr dazu finden Sie im eBook „New form of management“ oder „Agil Moderieren – Erfolgreiche Veranstaltungen gestalten. Dynamisch, simpel und strukturiert“

title_pageSmall

 

 

Nichts müssen müssen – das Modell der agilen Organisation

Baker Beach is a state and national public beach on the Pacific Ocean coast, on the San Francisco peninsula

Der Brückenschlag zur agilen Organisation – wie sieht er aus?

Vielleicht beginnen viele Geschichten aus der Organisationsveränderung genau so:

  • „Sie müssen sich von Command & Control verabschieden“
  • „Sie brauchen eine Vertrauenskultur“
  • „Für Veränderung brauchen Sie Antworten auf die Frage X, Y und Z…“

Vielleicht begann auch noch nie eine Veränderung in dieser Form?

Ich weiß es nicht. Worin ich mir sicher bin, ist das meine bisherigen Beratungskunden, Zuhörer und Menschen mit organisatorischen Schwierigkeiten mit sehr konkreten Fragestellungen auf mich zu kamen.

Noch nie kam einer oder eine und hat gesagt: „Du, ich möchte mehr Vertrauen zu meinen Mitarbeitern.“ oder „Ich hätte gerne eine Augenhöhen-Kultur.“

Nein, die hatten entweder Ziele oder eine handvoll Probleme. Die wollten etwas bewegen und nicht einfach verändern der Veränderung wegen. Es gab konkrete Projekte die ein Kunde gerne abgeschlossen haben wollte und irgendetwas hinderte die Beteiligte daran dieses Ziel zu erreichen. Um mal ein typisches Beispiel zu nennen.

Weitere Beispiele für solche Problemstellungen:

  • Unsere Transaktionskosten sind sehr hoch, wir brauchen viele Schleifen bis ein Kundenproblem tatsächlich gelöst wurde und oftmals bleiben solche Vorgänge an bestimmten Stellen liegen, weil sich keiner der Sache annehmen möchte. Wie können wir diese Vorgänge denn beschleunigen?
  • Wir haben Schwierigkeiten die Chef-Position in ein cross-funktionales Team zu integrieren. Was machen wir denn mit dem ehemaligen Teamlead der technisch sehr versiert ist?
  • Es gibt bei uns ein cross-funktionales Team, das macht Design-Sprints, aber die liefern nichts lauffähiges und wir wissen nicht wo es klemmt. Wie können wir die Ursache dafür finden?
  • Unser Unternehmen möchte gerne weiter wachsen, es hängt allerdings sehr viel Verantwortung an einer zentralen Stelle. Wie können wir die Verantwortung in die Teams verlagern ohne ausreichend Sicherheit zu haben dass das gut geht?
  • Als Mitarbeiter möchte ich gerne Freiheit haben um Aufgaben unabhängiger und schneller abzuschließen. Wie kann ich erreichen das wir gemeinsam im Team und im Flow arbeiten?

Das sind aus meiner Sicht ganz konkrete Problemstellungen und Indikationen zum Umschalten auf agile Teams und ein Modell der agilen Organisation. Doch wie sieht das überhaupt aus?

Der Brückenschlag zur agilen Organisation

Wissen Sie das es „DAS Modell der agilen Organisation“ noch gar nicht gibt? Also die Experten sind sich hierbei noch gar nicht einig. Was zeichnet eine agile Organisation denn eigentlich aus? Wie sieht die Architektur dazu aus? Welchen Prinzipien folgt sie?

Es gibt zwar viele Puzzleteile, allerdings noch keine Einigkeit, keinen gemeinsamen Nenner oder gar ein Copyright auf die agile Organisation (das ist Ihre Chance!). Allerdings gibt es viele Grundlagen wie zum Beispiel das Pfirsichmodell aus „Organisation für Komplexität“ (Niels Pfläging). Das bietet schon viel.

Auf der Basis habe ich ein erweitertes Modell erstellt, das aus meiner Sicht die Grundarchitektur gut beschreibt.

architekturAgilerOrganisationen

In dem Modell agieren Teams als „Blackbox“. Sie selbst bestimmen ihre Arbeitsweise und es spielt dabei keine Rolle nach welchem Vorgehensmodell sie agieren. Was es allerdings gibt sind sogenannte Minimalanforderungen an die Arbeitsweise. Die stellt das Management, die Geschäftsführung oder das Team selbst. Das können Prinzipien sein wie:

* Wir liefern alle 14 Tage in einem Review ein lauffähiges Produkt oder

* Alle 14 Tage zeigen wir dem Geschäftsführer was wir gemacht haben oder

* Wir arbeiten als Scrum-Team mit den Rollen „Scrum Master“, „Product Owner“ und „Teammitglieder“

Was hier festgegelegt wird, kann von Organisation zu Organisation unterschiedliche sein und ist sehr abhängig vom Kontext, den Beziehungen untereinander, der bisherigen Kultur, der Altersstruktur, den Projekten und und und….

Nichts müssen müssen

Eine weitere Eigenschaft in einer solchen Struktur ist die Flexibilität. Ich denke das mindestens fünf Dinge sehr schädlich für soziale Systeme sind:

  1. fehlende Konsequenzen für unsoziales Handeln (z. B. weil sich jemand nicht an Vereinbarungen hält)
  2. fehlender Freiraum das soziale System wechseln zu können (z. B. harmoniert weil die eigene Kompetenz nicht weiter gebraucht wird)
  3. Sozialer Zusammenhalt ohne konkrete Aufgabe oder Zweck (z. B. Projekt nutzlos)
  4. eine Vielzahl an Regeln die in der Summe nicht überschaubar sind
  5. keine Möglichkeit zur Verantwortungsübernahme

Aus diesem Grund verzichtet das vorgestellte Architekturmodell weitgehend auf formale Regeln. Je nach Team kann es dennoch sinnvoll sein, sich auf 5-10 Regeln zu einigen. Alles andere ist häufig nicht weiter überschaubar.

bridgedScrumDraft

Wichtig ist, das jedes Team seine eigene Aufgabe, seinen Zweck oder sein Ziel hat. Sei es ein bestimmter Service oder ein bestimmtes Produkt oder ein Modul sein an dem das Team arbeitet. Erst wenn das klar ist, kann Fokus und „Zug“ entstehen – Arbeitszug.

Damit eine ausreichende Beweglichkeit in den Teams besteht, hat jeder die Möglichkeit ein Team zu verlassen. Entweder dadurch das die Beteiligten oder die Geschäftsführung zustimmt. Das kann in jeder Organisation anders geregelt sein. Hauptsache ist, das eine Wechselmöglichkeit vorhanden ist.

Teammitglieder sollten allerdings auch aus einem Team rausgewählt werden können, beispielsweise wenn sie sich nicht an die gemeinsamen Vorgaben halten, den Durchsatz hindern oder den Eindruck erwecken das sie sehr unzufrieden sind. Erst diese Wahlmöglichkeiten sorgen langfristig für Zufriedenheit und die richtige Kompetenzmischung innerhalb eines Teams. Bei wechselnden Aufgaben, muss das Teamgefüge ebenso mit wachsen können.

kraefteAgilerTeams

Skalierung und Deskalierung

Natürlich gibt es viele kleine Details die bei der Architektur einer agilen Organisation berücksichtigt werden sollten. So kann beispielsweise vollständig auf Skalierung verzichtet werden, wenn Verantwortlichkeiten übergreifend definiert sind. Es braucht gar keine komplizierten Regelwerke oder Abläufe in Kreisen. Die Architektur agiler Teams kann auf Basis von Verantwortungsverteilung erfolgen: Wie viel Eigenverantwortung darf ein Team haben? Darf es eigenständig neue Teammitglieder einstellen? Kann ein Team selbst über Ein- und Ausgaben entscheiden? usw. usf.

In der Praxis gibt es eine Vielzahl solcher Fragen die grundlegend beantwortet sein sollten – für jede Organisation selbst – aber das ist ein anderes Thema… und erfordert einen eigenen Beitrag – oder sogar ein Buch? Lesen Sie mehr, wenn Sie möchten.

_smartPhoneVersion

 

Agilität braucht Management

MINOLTA DIGITAL CAMERA

»Agilität braucht keine Tools. Agilität braucht Haltung!« – Können Sie es noch hören, lesen und sehen? Fast jeder zweite Artikel über „Agilität“ bewegt sich auf diesem Niveau – und dann haben Sie noch nicht die die Social Media Diskussionen verfolgt:

»Vertrauen ist gut. Ja, ja. Aber es braucht auch Veränderung im Management.«

»Ja, wir brauchen Führung, kein Management, aber auch…«

 

Fabelhaft!

Wissen Sie welches Magazin dazu inzwischen mein persönlicher Liebling geworden ist? Das Manager Magazin.

Ich bin da ganz offen mit Ihnen. Die Autoren sind Meister der Appelle…

  • »Wer seine Mitarbeiter von Veränderung überzeugen will, muss ihre Ängste verstehen.«
  • »Führen Sie als Coach.«
  • »Mitarbeiter an die Macht.«
  • »Verordneter Wandel funktioniert nicht.«
  • »Auch in guten Zeiten unbequeme Fragen stellen.«
  • »Schaffen Sie eine Vertrauenskultur.«
  • »Stoppt den Agilitätswahn!«

Geniale Komplexitätsreduktion. »Werden Sie agil!«

Sehen Sie das? Mein neuster Liebling ist der letzte Artikel. Lesen Sie den! Agilität, Vertrauen, Haltung, Fehler, Experimente, Offenheit, Schnellboot, Tanker, Veränderung. Alles drin! Bingo!

»Wirkliche Agilität braucht mehr als nur die Ankündigung ihrer selbst – vor allem die radikale Bereitschaft von Menschen mit Führungsverantwortung selbst agil zu werden. Und Zeit sich auf einen Prozess einzulassen, statt sich hastig selbst den Agilitätsstempel aufzudrücken.«

Nein.

»Wahre Agile ist vor allem eins: Der Wunsch nach einer lebendigen, pulsierenden Zusammenarbeit, die uns zu Schnellbooten macht statt zu trägen Tankern. Ein mehr als berechtigter Wunsch. Wir alle wollen Dynamik statt Stillstand.«

Und nein.

Ich echauffiere mich, aber wenn das die Lösung ist, dann hätte ich gern das Problem zurück. Jeder der sich annähernd mit Agilität, Scrum oder Komplexität beschäftigt hat dem wird klar sein das man Dynamik nicht wollen kann. Oder doch, ja. Sie können das wollen. Ungefähr so wie sie sich Sonnenschein im Urlaub wünschen können. Was Sie bekommen, liegt aber außerhalb Ihrer Entscheidung. Komplexität ist keine Entscheidungsfrage. Sie ist. denkpyramide

Verstehen Sie das? Dynamik ist doch sowieso da. Es ist keine Frage der persönlichen Wunschvorstellung. Und wissen Sie noch etwas? Dynamik ist das zentrale Indiz dafür das Tools wie zum Beispiel 5-Jahrespläne, Jahresziele und »Pay per Target« heute einfach keine gute Idee mehr sind

Und wissen Sie noch etwas? Dynamik ist ein zentrales Problem das Manager heute haben. Es geht gar nicht um die Wahl nach Stillstand oder Dynamik. Es geht darum das die Werkzeuge unterkomplex sind und nur noch mit sehr sehr viel Anstrengung funktionieren. Ich verstehe doch auch nicht wieso man sich das alles antut. Klar dass das nervt.

»Ich denke schlichtweg das Manager heutzutage für einen Großteil der Fehler in Unternehmungen verantwortlich sind. Probleme wie Misserfolg, Konflikte, Unzufriedenheit, Verzögerungen, Projektabbrüche und Co. Deming sprach sogar von 94 %.«

5-Jahresplan trifft Realität

planKreislaufHaben Sie schon einmal erlebt wie ein Projektmanager reagiert, wenn Sie ihn fragen ob das ein oder andere Paket in der Reihenfolge verschoben oder verändert werden kann? Der fällt aus allen Wolken, argumentiert, packt sein gesamtes rhetorisches Geschick aus, trickst, dreht und wendet nur damit eine Anpassung verhindert wird. Der will seinen Bonus nicht verlieren! Oder das Ganttchart in Excel bloß nicht anpassen. Ich kann ihn verstehen. Haben Sie so einen Excelplan schon einmal angepasst? Puh.

»Gebt Managern die Arbeit und Arbeitern das Denken zurück.«

Was ich allerdings nicht verstehe ist, die Reduktion der Thematik auf 10, 11 oder 12 Begriffe. Das wird dem Thema nicht gerecht. Das wird Führung nicht gerecht. Agilität ist ein bisschen mehr. Da drin stecken rund 80 Jahre an Weiterentwicklung. Sehen Sie, die Betriebswirtschaftslehre ist vor 50 Jahren stehen geblieben – Lean, Scrum und Co. sind zu dieser Zeit erst warm geworden.

agileMapAber dieser Artikel soll kein alleiniges Plädoyer für die Zeitgeister der Geschichte bleiben. Nein, es geht um mehr. Ich finde grundlegend das diese flachen Annäherungen über Appelle, Ratschläge und Storytelling der ganzen Angelegenheit „Arbeit“ nicht gerecht wird. Wir schweben hier weit unter der Komplexitätsgrenze, unterhalb dem was möglich ist und somit wird das ganze weder organisatorischen Systemen noch den dazugehörigen Menschen gerecht. Manager sind doch keine kleinen Kinder, die vertragen was, die können was und die müssen sogar etwas (Achtung Appell!) – nämlich ihrer Verantwortung gerecht werden.

»Wenn einer die wesentlichen organisatorischen Rahmenbedingungen verändern kann, dann sind es Manager.«_smartPhoneVersion

Genau deshalb ist für diese Zielgruppe ein ausgefuchstes Verständnis für Systeme und Komplexität relevant. Aber auch für alle die gemeinsam mit Managern etwas bewegen wollen.

Ich lade Sie dazu ein und gebe Ihnen über diesen Artikel hinaus etwas an die Hand – ein komplettes Mikro-Buch zum Thema: New form of management – In sieben Stunden lesbar und verarbeitbar. Es hat vor allem eins: Informationsgehalt.

problemMitKomplexitaet

Wofür braucht es in einer agilen Organisation nun Management?

Bei all der Aufregung habe ich fast die Antwort auf die eingehende Frage vergessen. Wofür braucht es Management in einer agilen Organisation oder in einem agilen Team?

architekturAgilerOrganisationenNatürlich für genau die Aspekte die bei Scrum und agilen Teams fehlen:

  1. Sicherstellung des langfristigen Unternehmenserfolges
  2. Schaffen und Erhalten von nachhaltigen Organisationsstrukturen
  3. Fördern eines übergreifenden Informationsaustausches
  4. Einhalten von gesetzlichen Bestimmungen
  5. Erschaffen von neuen Produkt- oder Serviceteams
  6. Gewährleisten von einem Mindestmaß an Qualität in allen Ebenen (Recruiting, Kommunikation, Ergebnisse,…)

Punkte die ein Scrum-Team typischerweise nicht leisten kann oder nach den agilen Prinzipien oder dem Scrum-Guide gar nicht leisten soll.

Ich plädiere dafür, das wir Management brauchen. Allerdings in einer neuen Form, oder wie Deming es sagen würde:

»Es wäre besser, wenn alle als ein System zusammenarbeiten würden, mit dem Ziel, dass jeder gewinnt. Was wir brauchen ist Zusammenarbeit und den Übergang zu einem neuen Managementstil.«

…mehr lesen

3 Denkmodelle für lebendige Führung

»Experimentieren Sie!«, »Schaffen Sie eine Fehlerkultur!« und »Mut zum Wandel« – Appelle trenden und fluten die Managermagazine. 15 € für das Heft mit 100 Seiten. Gefüllt mit Interviews und Befragungen. Ein Kochrezept jagt das nächste:

  • »Auch wer dreimal scheitert, muss nicht aufgeben«
  • »Freiheit kann auch ungewohnt sein«
  • »Wandel zu verordnen funktioniert nicht«

Echt jetzt?

Es ist die Rede vom Mitreißen der Mitarbeiter, vom Versammeln hinter der Idee, Überzeugen, Vorbildfunktionen und all diesem Unsinn. Ich frage mich bloß: Ist das der Qualitätsanspruch von Managern und moderner Führung? Ist das alles?

Wenn Sie etwas genauer und verantwortungsvoller an das Thema herantreten möchten, lade ich Sie auf drei alternative Denkmodelle ein.

1. Umschalten auf Wertstrom

Mit der Wertstromansicht werden Zulieferer, Dienstleister und Kunden in die unternehmerischen Abläufe und Verbindungslinien integriert.

systemNetzDraft

Es entsteht eine Betrachtung der Organisation als Ganzes in dem alle einer Sache dienen und nicht statisch getrennt nach Abteilungen und Funktionisbereichen. Dabei werden die Resultate der einzelnen Arbeitsschritte hervorgehoben und gleichzeitig bleibt das Ziel das alle Funktionseinheiten gemeinsam anstreben im Blick. Das kann relativ einfach sein, hat aber eine sehr große Wirkung.wertstroemungssicht
Die Ergebnisse von Lieferanten und Mitarbeitern durchlaufen unterschiedliche Etappen der Veränderung. Am Schluss liegt ein neues Produkt vor. Es ist nicht mehr gleich wie am Anfang und landet beim Kunden.

Die Marktforschung ist in dieser Struktur fest verankert damit ausgewertet werden kann welche Verbesserungen in Zukunft für den Kunden nützlich sein können oder was ihn zum Kauf bewegen könnte. Die Rückmeldungen können zu Maßnahmen in allen Phasen der Produktentstehung führen. Somit entstehen ganz konkrete Optimierungsansätze.

2. Systeme verstehen und wiederbeleben

metaZiel7 Punkte können dabei helfen ein besseres Systemverständnis zu entwickeln:

  1. Ein System lebt durch ein gemeinsam bekanntes Meta-Ziel das Nutzen für den Kunden und alle Beteiligte schafft
  2. Alle sehen sich als Bestandteil des Systems
  3. Ein weiteres gemeinsame Ziel ist das Optimieren des Systems
  4. Das Fördern einer (bekannten) Komponentekann andere benachteiligen
  5. Die Beziehungen zwischen den Komponenten sind genauso wichtig wie die Komponenten selbst und sollten gepflegt werden
  6. Je größer ein System, desto mehr Zeit beanspruchen Entscheidungen, desto träger wird auf Veränderungen reagiert
  7. Ein gutes Systemverständnis zeichnet sich durch vernetztes Denken aus, es gibt immer mehr als eine Folgereaktion

3. Unternehmen von innen nach außen betrachten

Ein Manager kann nur 7 +/- 2 Informationen parallel im Fokus behalten kann. Ist er also mit den Tagesaufgaben, Auftragsbezogener Zeiterfassung, KPIs, Jour Fixes, Projektpläne und Budgetkontrolle beschäftigt, geht der Blick zum Kunden verloren. Das gilt übrigens auch für Sie und jeden anderen Menschen, nach sieben Informationen ist typischerweise Schluss.

vernebelung

Im Taylorismus war das aufgrund der einfachen Prozessschritte in Ordnung, die ließen sich übergeordnet skizzieren und aufteilen. Aber heute in
einer Zeit von Passung und guten Ideen braucht es zunehmend unternehmerische und denkende Mitarbeiter. Oder anderes gesagt: Managementtools wirken dabei wie künstlicher Nebel auf einer Autobahnfahrt – sie verstecken das tatsächliche Unternehmensziel, den Zweck von Arbeit.

Was stattdessen?

Die Alternative ist eine Betrachtungsweise, die sich extern orientiert. Die mit so wenig internen Hindernissen wie möglich aufgestellt ist, damit der Blick zum Kunden, Markt und Wettbewerb erhalten bleibt. Soweit so einfach. Das ist schon alles.

externeSicht

 

Neugierig auf mehr Qualität für Führung?

Mehr dazu können Sie im eBook „No more management“ nachlesen.

Ein Buch das gerade entsteht und durch Ihr Interesse oder Ihre Kaufunterstützung weiter wachsen kann.

title_pageSmall

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.