Hinderniswörter

Picture of a rock on a road

Sam Laing und Karen Greaves von Growing Agile haben vor kurzem ein paar praktische Tipps zu Impediments, also Hindernissen, auf Youtube zusammengestellt: Wie erkennt man sie? Wie kann das Team sie zusammen anpacken?

Schöner Tipp daraus: macht Euch eine Liste von Hinderniswörtern und fragt genauer nach, wenn Ihr sie öfters oder von mehreren hört. Nicht nur der Scrum Master ist dabei gefordert – jeder hat seinen blinden Fleck, oder besser: sein taubes Ohr.

Hier Sams und Karens Liste, mit den deutschen Entsprechungen:

ENDE
guessIch glaube / Wir glauben, ...
waitingIch warte / Wir warten ...
wishIch wĂŒnschte, ...
hopefullyHoffentlich...
tryIch versuche / Wir versuchen, ...
not available... nicht verfĂŒgbar / erreichbar.
busy... beschÀftigt / ausgelastet damit, ...
still... (immer) noch ...
expectedIch hatte erwartet / Wir hatten erwartet, ...
thoughtIch dachte / Wir dachten, ...

Denkt man ĂŒber die Wörter nach, dann erkennt man Alarmsignale fĂŒr viele klassische, blockierende Fehlentwicklungen:

  • Multitasking;
  • versĂ€umte Kommunikation;
  • fehlende Hilfsmittel;
  • PAL-Felder;
  • SelbstgefĂ€lligkeit.

Mir fallen noch weitere Hinderniswörter ein:

ENDE
not reallyeigentlich nicht / kein
who?wer?
should havehÀtte ... sollen
had promisedhatte versprochen, ...
stabilize... stabilisieren
officiallyoffiziell
pro formapro forma
finally / at lastendlich
temporaryvorĂŒbergehend
workaroundZwischenlösung

Das reicht schon fast fĂŒr ein veritables Impediment Bingo.
Welche Hinderniswörter kennt Ihr noch?

Heute kauf ich mir ein Zertifikat

A stack of certificates

Formulierungen wie „zertifizierter Scrum Master“, und „Certified Scrum Master (CSM), alternativ Professional Scrum Master (PSM) I“ tauchen immer öfter in Projekt- oder Stellenbeschreibungen auf, manchmal sogar unter der Rubrik must have. Das ist einerseits verstĂ€ndlich, weil jede/r sich einfach „Scrum Master“ nennen kann. Andererseits scheint wenig bekannt, was man sich unter „zertifiziert“ konkret vorstellen darf.

Um es einfach auszudrĂŒcken und es im entsprechenden Selbstversuch zu demonstrieren:

Ein zertifizierter Scrum Master ist jemand, der einen Multiple-Choice-Test bestanden hat. Je nach Geschmacksrichtung (Scrum Alliance: CSM; Scrum.org: PSM) ist ein vorheriger Anderthalb-Tages-EinfĂŒhrungskurs in Scrum zur Zeit dabei optional (Scrum.org) oder zwingend (Scrum Alliance).

CSM versus PSM I

Die beiden Varianten der Multiple-Choice-Tests schenken sich wenig, veranschlagte Zeit (60 Minuten), TestgebĂŒhr (100$, aber s.u.) und geistiger Anspruch (s.u.) sind bei beiden Unternehmen, pardon: Organisationen, deckungsgleich. Allerdings unterscheidet sich der Umfang spĂŒrbar:  35 Fragen fĂŒr den CSM-Titel, 80 fĂŒr den PSM I. Ebenso die fĂŒrs Bestehen nötige Quote richtiger Antworten: 69% fĂŒr den CSM-Titel, 85% fĂŒr den PSM I.

Zeitdruck und Quotendruck sind fĂŒr den PSM in spe also merklich höher – man darf wĂ€hlen: billiger und stressiger oder teurer und lockerer. Den CSM-Test kenne ich bereits, da ich einigen angehenden CSMs dabei ĂŒber die Schulter geschaut habe (nein, ich habe nicht beim Schummeln geholfen, sondern blieb ganz still). In eine kleine Auswahl der PSM-I-Testfragen kann man gratis hineinschnuppern, was sich dann Scrum Open Assessment nennt.

Ihr könnt es mir hoffentlich nachsehen, dass ich fĂŒr dieses Posting keinen „Certified Scrum Trainer“ (CST) der Scrum Alliance mit rund 1.400 € KursgebĂŒhr beglĂŒcken möchte, nur um anschließend 35 Fragen fĂŒr das CSM-Zertifikat beantworten zu dĂŒrfen. Das erste mal „Scrum Master“ war ich vor gut einem Dutzend Jahren, einen obligatorischen EinfĂŒhrungskurs vor einem Test ist mir dieses Posting daher nicht wert. Ich spare mir also den CSM-Kurs und wĂ€hle den PSM-I-Testparcour.

PlĂ€diere ich etwa gegen CSM- oder PSM-EinfĂŒhrungskurse generell? Ganz und gar nicht, in fokussierter AtmosphĂ€re mit einem guten Trainer die Grundlagen von Scrum kennen zu lernen ist eine gute Idee.

Die Multiple-Choice-Tests

NĂŒchtern und illusionslos gesprochen, prĂŒfen die Multiple-Choice-Tests bei beiden Organisationen im Wesentlichen folgende Dinge:

  1. ob man den offiziellen Scrum Guide (bei der Scrum Alliance bereits subtil relativiert durch Core Scrum) im Kopf prÀsent hat, inklusive feiner Details
    (wie etwa das „potentially“ in „potentially releasable“)
  2. ob man vor dem Klicken konzentriert die Fragen und alle Antworten bis zum Ende liest und dabei auch Verneinungen nicht ĂŒbersieht
    (etwa in „Which two (2) things does the Development Team not do during the first Sprint?“)

Beide Tests sind auf braves Auswendiglernen und minimales Transferwissen angelegt, oder, um es anders auszudrĂŒcken: sie sind Tests auf der Shu-Ebene, mit einer Prise Ha. Wo ein Scrum Master mit etwas echter Erfahrung agil antworten und sagen wĂŒrde „Lass uns das Team fragen“ sollte man im Test lieber nicht ins GrĂŒbeln geraten, sondern brav die Lehrbuch-Antwort herleiten und geben.

Maximal 3-4 Fragen erfordern echtes Übertragen von Wissen auf hypothetische Situationen. Daher wĂ€re es leider fĂŒr die MissionZertifizierung“ riskant, die eher simplen Fragen gedanklich mit (s)einer schwierigen UnternehmensrealitĂ€t verknĂŒpfen und entsprechend beantworten zu wollen. Merke: mit den Radiobuttons eines Multiple-Choice-Tests kannst Du nachtrĂ€glich nicht diskutieren. Was nicht bedeutet, dass sich hinter den Kulissen nach Kritik nichts Ă€ndert. Vergleiche zum Beispiel folgende zwei Fassungen einer Frage (von Scrum.org).

FrĂŒher:

Scrum Master is a management position?
A) True
B) False

Aktuell:

Scrum Master is a „management“ position?
A) True
B) False

Unterschied bemerkt? Wie hÀtte er Deine Antwort jeweils beeinflusst?

„Richtig“ ist ĂŒbrigens A). Zur Erinnerung: mit den Radiobuttons eines Multiple-Choice-Tests kannst Du nachtrĂ€glich nicht diskutieren.

„Und? Wie war’s?“

Scrum.org sagt:

Results for: Rolf F. Katzenberger
Title: PSM I
Score: 75 out of 80 points
Percentage: 94%
Duration: 00:30:59
Date started: Fri 5th Apr 2013 6:18am
Date finished: Fri 5th Apr 2013 6:49am

Feedback:
Congratulations! You have demonstrated a fundamental understanding of the roles, rules, artifacts, and time-boxes that bind together the Scrum framework. This qualifies for certification as a Professional Scrum Master I.

Passabel. Leider liefert Scrum.org unter Feedback nichts zu den aus seiner Sicht falschen Antworten; ich kann Euch also nicht berichten, wo ich geschlampt habe oder den Scrum Guide nochmal hÀtte durchlesen sollen. Apropos durchlesen: der Unterschied zwischen fundamental und profound ist klar?

Nach einer Investition von einer halben Stunde und umgerechnet 77 € darf ich mich jetzt also „Professional Scrum Master I“ nennen und ein hĂŒbsches Logo auf meiner Webseite zeigen.

Mindestens haltbar bis…

FĂŒr den CSM-Titel gilt:

There is not currently a continuing education requirement for the CSM certification.
In order to renew your certification and membership, you can use the green „Renew Membership“ button on your dashboard. It is $100 for two years.

Bei mittlerweile geschĂ€tzten 60.000 CSMs weltweit generiert dieser kleine grĂŒne Button also potentiell 3 Millionen $ Einnahmen pro Jahr. Ich gestehe unumwunden, dass ich die Scrum Alliance um dieses GeschĂ€ftsmodell beneide und tröste mich damit, dass ich wenigstens kein Tropfen in seinem revenue stream bin.

Der PSM-I-Titel hĂ€lt momentan lebenslĂ€nglich, ohne weitere Kosten. Sobald diese Geschmacksvariante dank Preisvorteil und MHD zahlenmĂ€ĂŸig mit dem CSM etwa gleich gezogen hat, rechne ich allerdings mit einer spontanen Erleuchtung seitens Scrum.org, dass nur ein obligatorischer EinfĂŒhrungskurs mit einer jĂ€hrlichen gebĂŒhrenpflichtigen Auffrischung auf Dauer den hohen QualitĂ€tsstandard beim PSM I garantieren könne. Derzeit existieren bereits an die 7.500 PSM-I-TiteltrĂ€ger weltweit, das VerhĂ€ltnis zu CSMs liegt also noch bei rund 1:8.

Mein Fazit

Wissen ist nicht gleich Können.

Liebe Personaler, CSM und PSM gehören nicht in Projekt- und Stellenausschreibungen. Achtet statt dessen genau darauf, welche Skills und Erfahrungen durch Entwicklungsarbeit und Berufserfahrung belegt sind. Wer eine Zertifizierung als must have in einer Ausschreibung fĂŒr Scrum Master auflistet, aber keine nachgewiesene Erfahrung verlangt, wird gerade von den erfahrenen Scrum Mastern nicht ernst genommen, die er gerne an Bord holen möchte.

Liebe angehende Scrum Master, ich kenne einige deutsche CSTs persönlich und empfehle deren CSM-Kurse oft und gerne. Aber nicht wegen des Zertifikats.

Liebe Scrum Alliance und Scrum.org, nie hĂ€tte ich mir vor 12 Jahren trĂ€umen lassen, kĂŒnftig so etwas erfrischend offen GeschĂ€ftstĂŒchtiges zu lesen wie heute Morgen von Sabine Canditt (CSM, CSP, CSC, CST), zum Thema Scrum Guide (Scrum.org) versus Core Scrum (Scrum Alliance):

scrum.org und die Scrum Alliance sind zwei unterschiedliche Organisationen mit unterschiedlichen Zertifizierungsprogrammen. Um voneinander unabhÀngig sein zu können, brauchen beide Organisationen eine Referenz, die der Zertifizierung zu Grunde liegt, und die sie selbst beeinflussen können.

Das trifft es wohl recht genau: Man benötigt zwei Definitionen von Scrum, damit zwei Organisationen zwei Arten von Zertifikaten verkaufen können.

Update 2014-09-24: Scrum Alliance, scrum.org und Scrum Inc. haben heute bekannt gegeben, dass sie sich wieder auf den Scrum Guide als gemeinsame Definition von Scrum geeinigt haben. Der Scrum Guide wird ab sofort unter scrumguides.org verfĂŒgbar sein.

Wissenstransfer mit Shu-Ha-Ri-Sprints

Agile Teams leben in der Grauzone: Skills und Aufgaben sind keine Frage von Schwarz oder Weiß, ich oder Du.

Wenn die Testerin zum „Bottleneck“ wird, weil Entwickler nicht wissen (wollen), wie man ein Testskript anwirft: schlecht fĂŒrs Ziel. Wenn der Product Owner (PO) keinen Sinn darin sieht, von Anfang an mit der Testerin an brauchbaren Akzeptanzkriterien zu feilen: schlecht fĂŒrs Ziel. Wenn die Testerin zwar programmieren könnte, aber sich strĂ€ubt, auch mal Unittests zu erweitern: schlecht fĂŒrs Ziel.

Der Scrum Guide sagt:

UnabhĂ€ngig von der verrichteten Arbeit werden die Mitglieder des Entwicklungs-Teams als Entwickler bezeichnet. Scrum sieht keine anderen Titel fĂŒr die Mitglieder eines Entwicklungs-Teams vor; es gibt keine Ausnahme von dieser Regel

Das bedeutet fĂŒr das interdisziplinĂ€re Team eben nicht, dass jeder wirklich alles und noch dazu gleich gut können muss. Es bedeutet, dass jeder zu jedem Zeitpunkt Meister, Geselle und Azubi zugleich ist, nur eben auf unterschiedlichen Gebieten – und immer wieder von neuem.

Agiles Teamwork lebt von dieser Grauzone. Davon, dass nicht danach gefragt wird, wer fĂŒr das Erreichen des Ziels verantwortlich ist, weil die Antwort ohnehin klar ist: das gesamte Team.

Wann immer das Schwarz-oder-Weiß-Spiel („Was soll ich denn noch alles können?“, „Das ist nicht mein Job!“, …) gespielt wird, um letztlich gar nichts außerhalb der eigenen Expertise kennen lernen zu mĂŒssen: schlecht fĂŒrs Ziel. Eine meiner wichtigsten Fragen an jedes Team ist deshalb: wie spielt Ihr denn statt dessen das Meister-Geselle-Azubi-Spiel, so dass es funktioniert?

Shu-Ha-Ri-Sprints: lernen, verstehen, vermitteln

Ein interessanter Weg neben z.B. Workshops, Schulungen und Communities of Practice (CoPs): das Team erklÀrt jeden Sprint zu einem Shu-, Ha- oder Ri-Sprint, rotierend.

  • WĂ€hrend eines Shu-Sprints (von 柈 shu, befolgen) betrachtet sich jedes Teammitglied als „Azubi“ und wĂ€hlt ein Wissensgebiet, zu dem es einen im Team allseits anerkannten Meister um die Zusammenarbeit bei einem entsprechenden Task bittet. Bist Du selbst der einzige Meister, dann befolgst Du Deine eigenen Lessons Learned oder die Literatur, die Du fĂŒr maßgeblich hĂ€ltst, fĂŒr diesen Sprint ĂŒbergenau und achtest darauf, wo Du vielleicht schlampig oder ĂŒberheblich geworden bist.
    (Wieder) lernen durch Achtsamkeit ist das Ziel.
  • In einem Ha-Sprint (von ç Ž ha, sich lösen) betrachtet sich jedes Teammitglied als „Geselle“, reflektiert und notiert bei jedem Task, welche Praktiken, Techniken und Konventionen des Teams den Prinzipien des agilen Manifests gerecht werden und welche nicht.
    Die Zusammenarbeit besser verstehen durch Achtsamkeit ist das Ziel.
  • In einem Ri-Sprint (von 雱 ri, transzendieren) betrachtet sich jedes Teammitglied als „Meister“ und ĂŒberlĂ€sst gezielt die Hauptarbeit an einem Task, fĂŒr den es selbst am besten geeignet wĂ€re, einem „Azubi“. Es gelten keine kurzfristigen Kosten-, Geschwindigkeits- oder FehlertrĂ€chtigkeits-Ausreden.
    Respekt, Mut und Offenheit durch aufmerksames Coachen zu leben ist das Ziel.

In jeder Sprint-Retrospektive sammelt das Team die Erfahrungen des Einzelnen damit. Und es wird nach meiner Erfahrung einiges zusammengetragen, was zu wichtigen Erkenntnissen fĂŒhrt. Ein Wissenstransfer findet ganz nebenbei statt, beim Arbeiten (Tasks), nicht statt dessen (Workshop, Schulung).

Warum wird der gesamte Sprint unter ein entsprechendes Motto gestellt? Warum darf sich nicht jeder in jedem Sprint frei zwischen Shu, Ha und Ri entscheiden?

Die strikte Regel bietet mehrere Vorteile:

  • die Rotation des gesamten Teams zwischen den dreien verringert Statusgehabe und macht klar, dass a) jeder ein respektabler Fachmensch auf seinem Gebiet ist und b) es zum Status des „Meisters“ gehört, zu coachen;
  • die Retrospektiven zerfasern nicht und fokussieren, in Rotation, jeweils auf Shu, Ha oder Ri;
  • kein Teammitglied kann ewig Azubi bleiben;
  • da es keinen Meister ohne Azubi (und umgekehrt) gibt, findet in Shu- und Ri-Sprints laufend ein intensiver Rollenwechsel statt; und
  • da sich niemand in einem Ha-Sprint als Meister oder Azubi definieren (lassen) muss, schĂ€rft jeder dritte Sprint den gleichberechtigten Blick aller darauf, ob wirklich schon, noch oder wieder agil gearbeitet wird.

Welche Wege habt Ihr gefunden, Euer Meister-Geselle-Azubi-Spiel zu spielen?

Hier stinkt’s! Platz 10: FĂŒr immer Azubi

Ja, tatsĂ€chlich: ich bin großartig. Schwierige Momente und Missionen löse ich lĂ€ssig und unaufgeregt. Unfassbar sicher ist mein Auftreten.

WĂ€hrend das Team noch rĂ€tselt, wĂ€hrend die FĂŒhrungsriege mich mit flehenden Augen ansieht, sind mir die Lösungen schon in der Sekunde klar, in der das erste Wort ĂŒber ein mögliches Problem fĂ€llt. Sagte ich gerade „Problem“? Ich meinte natĂŒrlich: Petitesse.

Mein Dauerzustand entspannter Unterforderung weicht nur fĂŒr einen flĂŒchtigen Augenblick, wenn ich die Verzweifelnden (wie ĂŒblich) mit einer fabelhaften, den Tag rettenden Geste aufrichte und in meinen Bann ziehe.

Und dann klingelt der Wecker. Ich wache auf, und das echte Leben beginnt.

Jammerschade – spĂ€testens nach der PubertĂ€t hat Hollywood wohl ausgedient und Platz gemacht fĂŒr den Klassiker „Übung macht den Meister“. Das hat man verstanden und verinnerlicht.

Oder etwa nicht?

Symptome: wie es zu mĂŒffeln beginnt

Meistens zeigt die Verinnerlichung Wirkung. Gelegentlich aber durchschauen und beherrschen wir alles, was jemals erdacht und erfunden wurde, aus dem Stegreif. Gerade bei simplen Dingen wie Scrum, Extreme Programming oder Kanban ist völlig offensichtlich, welch grobe Schnitzer sich die jeweiligen Erfinder geleistet haben und aus unerfindlichen GrĂŒnden zu korrigieren weigern. Selbst wenn sie dazu alles Nötige von uns erfahren könnten, wĂŒrden sie uns auch nur einmal um geistigen Beistand bitten:

  • Mit Post-Its, Karteikarten und Stiften arbeiten? Unprofessionell! Wozu gibt’s Software?!“
  • 19 Seiten Scrum Guide einhalten? Funktioniert bei uns nicht! Jedenfalls nicht, bevor wir das tayloren und customizen (wie die anderen 500-Seiten-Methodiken vorher auch).“
  • Jeden Tag eine Viertelstunde Standup-Meeting, fĂŒr alle? Nur wegen Statusreporting? Wir reden sowieso den ganzen Tag miteinander…“
  • Anderthalb Stunden retrospektive Nabelschau, therapeutisches Miteinander-Reden? Alle 2 Wochen? Wozu haben wir unser betriebliches Vorschlagswesen?!“
  • Wir machen ab sofort Scrum! Aber mit dreimonatigen Sprints, nur einmal Standup Meeting pro Woche, eindeutigen Arbeitspaketverantwortlichen und fixer Releasecontainerbeplanung 4 Monate vorab – eben einfach professionelles Scrum, mit allem, was naives Scrum bisher strĂ€flich vernachlĂ€ssigt!“

Klingt vertraut? Selber schon so etwas gedacht und gesagt? UnerklĂ€rlich, weshalb „nach unserer Umstellung auf AgilitĂ€t“ mehr und mehr so lĂ€uft wie frĂŒher – nur noch schlimmer?

Ursachen fĂŒr mĂŒffelnde AgilitĂ€t, Platz 10: FĂŒr immer Azubi

Wie in einem Metier die Stationen bis zum „Richtig gut“ aussehen, dazu gibt es einige Modelle. Die BrĂŒder Stuart und Hubert Dreyfus beschreiben 5 Stufen (schön erlĂ€utert bei Werner Stangl):

  1. AnfÀnger (Novice)
  2. Fortgeschrittener AnfÀnger (Advanced Beginner)
  3. kompetent Handelnder (Competence)
  4. Erfahrener (Proficiency)
  5. Experte (Expertise)

Etwas gröber, dafĂŒr noch eingĂ€ngiger, lauten die seit dem Mittelalter klassischen Stufen:

  1. Lehrling
  2. Geselle
  3. Meister

Wie lange braucht man zum Experten und Meister? Als Faustregel kann man mit rund 10.000 Stunden intensiver BeschĂ€ftigung rechnen. Beruflich gesehen sind das umgerechnet knapp 62 Arbeitsmonate, etwas ĂŒber 5 Jahre also. Jahre, bis man agiles Arbeiten wirklich verinnerlicht hat? Das kann man einsehen und respektieren – muss man aber nicht.

FĂŒr manche kratzt es arg am beruflichen Ego, zusammen mit oder gar – Himmel! – von anderen etwas lernen zu mĂŒssen. Mag sein, dass sogar Leonardo etwas laufend ĂŒben musste. um es zu verstehen und zu beherrschen. Aber doch nicht ich!

Shortcut Impossible

Das BedĂŒrfnis, ohne MĂŒhe simple Rezepte mit klaren Erfolgsaussichten nachzukochen und dafĂŒr umgehend belohnt zu werden, hat keine Chance auf ErfĂŒllung. Weder durch Bienenfleiß beim BĂŒcherkonsum, noch mittels Durchdenkdelegation an Berater, noch durch munteres Mischen von Methodenmoden.

Wer seine Einsteiger-Stadien nicht liebt, lebt und letztlich hinter sich lĂ€sst, bleibt eben ewiger Azubi, unzufrieden mit jeder Methode, dabei aber von wenig Selbstzweifel geplagt. Klare und banale Ursache – doch von vielen so wenig beachtet wie die Fensterscheibe von der Fliege.

Wieso kommt man trotzdem derartig mĂŒffelnd durch’s agile Leben?

Aus demselben Grund, aus dem auch mittelmĂ€ĂŸige Handwerker,  mittelmĂ€ĂŸige Softwareentwickler, mittelmĂ€ĂŸige Unternehmen durchkommen: Weil es zum Leben reicht – und nicht das Leben kostet. Wer damit kein Problem hat, hat damit schon die Lösung. FĂŒr alle anderen hier ein Vorschlag.

Lösungsmöglichkeit

Lerne, das Paradox zu lieben: wer nicht als ewiger Einsteiger gelten will, muss immer wieder einer werden. Je neugieriger, desto besser. Was heißt das, konkret?

ZurĂŒck ins Mittelalter. Oder in den fernen Osten.

Egal, wie gut Du bist: Lehrling, Geselle und Meister bleibst Du immer. Nur das Thema und Dein Stadium wechseln. Gut, wenn Du die typischen BedĂŒrfnisse jeder Stufe immer vor Augen hast und sie bei anderen wie bei Dir selbst respektierst:

  • als agiler Lehrling hoffst Du auf einfache Regeln, Rollen und Artefakte, die den Erfolg garantieren. Du bist verunsichert, wenn Du Dich mustergĂŒltig an alle Regeln gehalten, aber Deine Aufgabe trotzdem nicht erfolgreich zu ende gebracht hast. Du brauchst Ermutigung dafĂŒr, dass Du immer mehr Dinge immer öfter richtig machst.
  • als agiler Geselle lernst Du immer besser, Deine Werkzeuge passend zur Situation zu wĂ€hlen, anhand von Prinzipien. Du bist verunsichert, wenn Du keine Idee hast, wie Du eine Aufgabe bewĂ€ltigen sollst – und wenn offenbar auch niemand sonst aus der ganzen Community eine solche Idee hat. Du brauchst Ermutigung dafĂŒr, dass Du keinen offenkundigen Unsinn bis zum bitteren Ende durchexerzierst, sondern Verantwortung ĂŒbernimmst. Gelegentlich auch mal ohne Erfolg.
  • als agiler Meister bist Du Dir nicht mehr bewusst, nach Prinzipien zu handeln. Deine Handlungen fließen direkt aus Deinen Wertvorstellungen und Deiner Erfahrung.  Du brauchst konstruktive, harte Kritik, wenn Du langsamer Fortschritte machst als Dir möglich wĂ€re. Du brauchst auch Lehrlinge, die in naher Zukunft einmal besser sein werden als Du je warst.

Es lohnt sich, dem eigenen Ego so lange diesen lebenslangen, auf den verschiedensten Gebieten wiederkehrenden Zyklus vor Augen zu fĂŒhren, bis es zu murren aufhört und ihn genießen kann.

Zu altbacken fĂŒr Dich?  Gut, dann beschreibe ich es vielleicht einmal so:

Was Du ab heute tun könntest

Fange an:

  • Wem wirst Du heute etwas weiter geben und ĂŒberlassen?
  • Welche Alternativen wirst Du heute nĂ€her betrachten?
  • Was wirst Du heute aufmerksam ĂŒben?

enprovia Scrum Day 2012

This week, I had the pleasure to discuss Caveats and traps to avoid in agile development and Success factors for medium to large size Scrum projects at the enprovia Scrum Day 2012 in Bratislava, Slovakia (please find my presentations attached at the end of this post).

A great opportunity to chat with practitioners from all sectors (legal, financial, software shops, and many more). Agile clearly has a substantial market share here, so we were able to focus on detailed, tricky questions.

In preparation of my talks, I took the chance to flip through my oldest agile-related notebooks again, reviewing my personal lessons learned from 12 years of work in that field. The Top 10 of traps I had encountered proved to be almost exclusively related to organizational and psychological issues, but even the „techies“ in the audience didn’t resent that. During an afternoon talk, I summarized three central success factors for large Scrum projects.

Lots of interesting discussions at a superbly staged event – thanks again to enprovia for starting this in Slovakia!

The slides, for downloading: Caveats and traps to avoid in agile development, Success factors for medium to large size scrum projects

Pragmatic Teams

Was fĂŒr Leute möchte man im Team haben?

Was macht ein gutes Team aus?

Es ist pragmatisch. Es hĂ€lt sich an ein paar einfache, zeitlos gĂŒltige GrundsĂ€tze:

Richtig ist, was funktioniert

Relevant ist, was in der Praxis einen spĂŒrbaren Unterschied macht. Richtig ist, was heute mit Blick auf das Ganze funktioniert. Erkenne, was bereits gut genug ist und lasse es gut sein. Es entscheidet die Teambilanz, nicht Dein Einzelerfolg.

Immer in medias res

Komm ohne Umschweife zur Sache. Denk nicht nur ĂŒber den ersten Schritt nach, tu ihn. Sorge dafĂŒr, dass Du immer mutig die Richtung Ă€ndern kannst. Hole Dir von Anfang an offenes, ehrliches Feedback, von Mensch und Maschine. Erspare Dir und dem Team unnötiges Drama und schlampiges Heldentum, es gibt genĂŒgend echte BewĂ€hrungsproben fĂŒr Deine Talente und die der anderen im Team.

Du bist nie allein

Respektiere jedes Teammitglied und respektiere das Team. Das Team ist nicht anonym, und Du bist es auch nicht. Der Kunde ist Teil des Teams, seine Erwartungen stehen aber ĂŒber Deinen. Nur ein intaktes Team gibt Energie.

Nur die Teambilanz entscheidet, und Du trĂ€gst Verantwortung dafĂŒr: was um Dich herum kaputt geht, kaputt ist oder kaputt bleibt, wird frĂŒher oder spĂ€ter Dein persönliches Problem.

Liebe und lerne Dein Metier

Hab‘ Freude daran, dass Du in jeder Minute Lehrling, Geselle, und Meister in einem bist. Es ist keine Frage des Alters oder des Status‘, sondern der Neugier, der praktischen Übung und der Erfahrung. Deinen Wert bestimmst Du jeden Tag selbst mit.

Als Lehrling ĂŒbe die Grundlagen sorgfĂ€ltig ein, lerne die Hilfsmittel kennen und befolge die Regeln. Sei klug in der Wahl Deiner Meister. Als Geselle finde Lösungen und Alternativen. Vergiss nicht, dass Du immer auch Lehrling bist. Sei klug in der Wahl Deiner Freiheiten. Als Meister, sei eine Quelle der Inspiration. Vergiss nicht, dass Du immer auch Geselle und Lehrling bist. Sei klug in der Wahl Deiner Grenzen.