Hier sind ein paar persönliche Erfahrungen aus 4 der 5 Stoneman Mountainbike-Touren (es gibt auch Varianten für Road und Hike). Sie sind Momentaufnahmen und subjektive Einschätzungen. Vielleicht sind sie für den einen oder die andere nützlich.

Die Mointainbike-Stoneman-Touren sind Rundkurse mit 120 bis 180 km bei 3.700 bis 4.700 Höhenmetern. Offizieller Finisher kann man werden, wenn man die jeweilige Tour in 3 Tagen (Bronze). 2 Tagen (Silber) oder einem Tag (Gold) gefahren ist. Dabei geht es nicht um Wettkampf, sondern das Naturerlebnis – mit einer selbst gesetzten sportlichen Challenge.

Wir sind mit unserer Gruppe in unterschiedlicher Besetzung die Mountainbike-Stoneman Miriquidi (Erzgebirge), Taurista (Salzburger Land), Arduenna (Ardennen/Belgien) und Dolomiti (Dolomiten/Tirol) gefahren. Glaciara (Schweiz) soll konditionell und technisch am Anspruchsvollsten sein. Daher haben wir uns den für den Schluss aufgehoben.

Wir waren Anfang 40 bis Mitte 50 und wir kommen aus dem norddeutschen Flachland rund um Hamburg. Mit Mountainbiken in den Bergen hatten wir vor unserem ersten Stoneman überhaupt keine Erfahrung.

Den Stoneman Miriquidi sind wir zuerst gefahren. Damals sind wir vermutlich 1.000 km Mountainbike pro Jahr gefahren. Inzwischen fahren wir ca. 2.500 km Mountainbike/Jahr.

Wir sind Arduenna in Silber (2 Tage) gefahren, alle anderen in Bronze (3 Tage). Arduenna in Silber hat sich ungefähr so anstrengend angefühlt wie Dolomiti Bronze. Für den Einstieg würde ich mit Arduenna oder Miriquidi in 3 Tagen beginnen.

Der Artikel beginnt mit meinen subjektiven Tipps. Danach folgen Reiseberichte der verschiedenen Touren.

Training

• Die Höhenmeter sind beim Stoneman wichtiger als die Entfernungs-Kilometer. Daher sollte man beim Training möglichst viele Höhenmeter sammeln. Mit dem Bergauf-Fahren verbringt man beim Stoneman die meiste Zeit. Wenn man schneller werden will (z.B. für Silber), sollte man trainieren, schneller bergauf fahren.
• 15×100 Höhenmeter in Hamburg zu fahren, ist viel leichter als 3×500 Höhenmeter im Erzgebirge zu fahren. 3×500 Höhenmeter zu fahren ist viel leichter als 1×1.500 Höhenmeter zu fahren. Die Ursache sind die fehlenden Erholungspausen.
• Bei über 2.000 Meter merkten wir die dünne Höhenluft. Das betraf vor allem Dolomiti, wo es relativ viel in dieser Höhe unterwegs ist. Da wäre es schlau gewesen, dass wir uns erstmal 2 Tage akklimatisieren, bevor wir mit der Tour beginnen.

Unterkunft

• Bei Taurista und Dolomiti kann man gut zentral wohnen, bei Miriquidi und Arduenna eher nicht (die Gebiete sind sehr hügelig und bei zentralem Hotel müsste man noch ordentlich Höhenmeter zusätzlich fahren).

• In der Gruppe waren auch Wanderer dabei. Die haben Tagestouren gemacht und haben bei wechselnden Unterkünften unser Gepäck transportiert. 
• Wenn wir mehrere Unterkünfte brauchten, sind wir nie mit den offiziellen Logispartnern ausgekommen – viele schieden aus, weil die keine 10 Einzelzimmer frei hatten. Mit kleineren Gruppen sollte das eher gehen.
• Wenn man bei offiziellen Logispartnern übernachtet, kann man gegen Aufpreis einen Gepäcktransport buchen.

Die Touren

• Die Touren sind konditionell anspruchsvoll, aber nicht sehr technisch (von ein paar wenigen Abschnitten abgesehen).
• Für uns war der geringe Single-Trail-Anteil überraschend (um die 10%). Man fährt auf allen Touren sehr viel auf Feld- und Forstwegen bergauf. Arduenna hat den größten Single-Trail-Anteil, auch bergauf. Das macht mehr Spaß, ist aber auch anstrengender.
• Bei Dolomiti hat die Bronze-Variante mehr KM und mehr Höhenmeter (wir hatten 5.000 statt 4.000 auf der Uhr) als Silber oder Gold – weil man einen Gipfel hochfahren muss, zu dem man bei Silber oder Bronze über die Demut Passage kommt.
• Bei Dolomiti gibt es die Demut Passage, die Stellen mit akuter Absturzgefahr enthält. Man kann die Demut Passage auch umfahren. Dann ist die zweite Etappe aber ganz anders. Wenn man in der Gruppe fährt und ein Teil mit und die andere ohne Demut Passage führt, sieht man sich am zweiten Tag nur zum Frühstück und Abendessen.
• Ich habe mit Höhenangst zu kämpfen und habe mich daher nicht an dem Demut Passage getraut. Tipp: In der dritten Etappe gibt es auch ein paar steilere Abhänge, an denen man vorbei muss. Wenn man sich unsicher ist, könnte man mit der dritten Etappe starten. Wenn einem dort mulmig wurde, ist Demut vermutlich zu schwierig – am Ende natürlich Spekulation, weil ich die Demut Passage nie selbst gesehen habe.
• Während der Touren begegnet man relativ selten anderen Menschen. Dolomiti ist eine Ausnahme. Da fahren fast überall viele Mountainbiker rum – die allermeisten mit eBikes.
• Es besteht auf jeder Tour die Gefahr, dass man stürzt (bin beim ersten Miriquidi-Versuch auch in der Notaufnahme gelandet). Am Besten fährt man mind. zu zweit oder stellt sicher, dass man irgendwie Hilfe holen kann – das ist insbesondere im echten Gebirge (Taurista, Dolomiti) nicht immer so einfach, weil es dort nicht überall Handy-Empfang gibt.
• Die Touren sind ausgeschildert. Die Stoneman-Symbole sehen aber so ähnlich aus, wie sonst verwendete Fahrrad-Weg-Symbole. Genau hinsehen! Dolomiti ist nur rudimentär ausgeschildert (jedenfalls in der Bronze-Variante), die anderen sehr gut.
• Insbesondere bei Miriquidi muss man bei Abfahrten plötzlich abbiegen – da sind dann immer Teile der Gruppe dran vorbei gefahren.
• Wir haben immer die von Stoneman bereitgestellten GPX-Daten in Komoot zur Navigation verwendet. Eine Handy-Akkuladung reicht nicht aus, um den ganzen Tag zu navigieren. Entweder man tauscht irgendwann den Navigator oder hat eine Powerbank dabei.
• Es ist nützlich, die Karte aus dem Starterpaket auch dabei zu haben. Die hilft wenig für die Navigation, hilft aber, um z.B. abzuschätzen, wann die nächste Verpflegungsmöglichkeit kommt. Die liegen teilweise weit auseinander. Wenn man sich fragt, ob man bei dieser Gelegenheit was Trinken und Essen sollte oder auf die nächste Möglichkeit wartet: Macht es jetzt! Wir sind da ein paar mal reingefallen und mussten dann stundenlang mit knurrendem Magen fahren.

Checkpoints

• Als wir das erste Mal Miriquidi gefahren sind, hat nur einer das Startpaket gekauft – wir hatten zum Einstieg auch mit 4 Tagen geplant. Nachdem wir in der Gruppe gesehen haben, wir motivierend es ist, seine Tourkarte an den Checkpoints zu stempeln, haben wir danach immer die Starterpakete gekauft – außerdem nutzen wir ja die Infrastruktur und dann ist es nur fair, dafür auch etwas zu bezahlen.
• Es gibt den einen oder anderen Checkpoint, der nicht super-sichtbar ist. Tipp: Bevor man irgendwo runter fährt, sollte man prüfen, ob oben nicht doch ein Checkpoint ist. Bei Taurista gibt es gleich auf der ersten Etappe einen Checkpoint, der links um die Ecke liegt, an dem man ganz leicht vorbei fährt. Bei Arduenna gab es mind. einen Checkpoint, an dem wir fast vorbei gefahren wären.
• Bei Dolomiti knipst man seine Karter mit einem einfachen Locher. Der hat an jeder Station eine andere Form (Kreis, Quadrat, Stern etc.). Bei den anderen Tourcen gibt es aufwendigere Systeme, die an der passenden Stelle lochen.

Ausrüstung

• Crosscountry-Fully passt meiner Meinung nach am Besten für die Touren. Hardtail funktioniert auch (auf den Single-Trail-Abfahrten ist das dann etwas anspruchsvoller) und einige von uns sind auch Enduro gefahren – das funktioniert auch, ist aber unnötig.
• Vereinzelt sind Gruppenmitglieder mit eBikes gefahren. Wenn man die ganze Zeit mit Unterstützung fährt, schafft man die Bronze-Etappen mit großem Akku vielleicht knapp, mit Light eMtB gar nicht. Da braucht man zwischendurch längere Pausen zum Laden (nach Rückfrage war das in vielen Restaurants/Bistros möglich). Am Besten bringt man auch als eBike-Fahrer eine gewisse Grundfitness mit, damit man auch mit leeren Akku handlungsfähig bleibt.
• Die meisten aus der Gruppe fahren Flat Pedals, einer Click-Pedale. Bei Taurista und Dolomiti hat man teilweise sehr steile Schiebepassagen auf unebenen Grund. Daher sollten Click-Schuhe möglichst auch Profil haben.
• Kopftuch (ist im offiziellen Startpaket enthalten) hilft gegen Schweiß in den Augen, gegen Druckstellen durch den Helm und dagegen, dass man bei spärlichem Haarwuchs einen Sonnenbrand durch die Lüftungsschlitze des Helms bekommt.
• Ersatzschlauch, Werkzeug und Pumpe sind unbedingt notwendig. Wir hatten fast immer einen Platten. Es gibt inzwischen gute, kleine elektrische Pumpen. CO2-Kartuschen sind zwar mülltechnisch blöd, aber für den schnellen Reifenwechsel praktisch. Ich fahre inzwischen tubeless und hatte seitdem bei keiner Tour Reifenprobleme.

Gesundheit

• Sonnencreme nicht vergessen und großzügig verwenden – eigentlich eine Selbstverständlichkeit, wurde aber in unserer Gruppe auch immer mal wieder nicht beherzigt. Es gab fast immer Sonnenbrände. Insbesondere bei Taurista und Dolomiti gibt es Passagen oberhalb der Baumgrenze, bei denen es keinen Schatten gibt.
• Man sitzt lange im Sattel. Gesäßcreme macht es deutlich angenehmer und hilft gegen Scheuerstellen.
• Autan oder ähnliches gegen Mücken war bei den Stoneman-Touren eher nicht notwendig. Als wir nach dem Stoneman Dolomiti noch auf eigene Faust im unwegsameren Gelände unterwegs waren, wäre es aber sinnvoll gewesen.
• Einige der Touren liegen in Risikogebieten für durch Zeckenbiss übertragene FSME. Dagegen kann man sich impfen lassen. Ich habe das getan. Für die eigentlichen Stoneman-Touren ist es meiner Meinung nicht unbedingt notwendig. Die Wege sind zu breit, dass man nur selten Pflanzenkontakt hat. Tatsächlich gab es bei unseren Stoneman-Touren keinen einzigen Zeckenbiss. Weil ich aber ständig bei uns in der Gegend Zecken aufsammle, war die Impfung für mich trotzdem sinnvoll.

Verpflegung

• Man verliert viel Flüssigkeit (meine Sportuhr schätzte 5 bis 10 Liter pro Tag). Daher sollte man seine Wasservorräte an JEDER sich bietenden Gelegenheit auffüllen – es kann dann nämlich auch immer wieder passieren, dass es über Stunden keine Möglichkeit mehr gibt. Trinkrucksack oder mehrere große Flaschen sind notwendig.
• Kann bitte jemand einen Powerriegel entwickeln, der nicht klebrig süß ist? Die habe ich in brütender Hitze irgendwann nicht mehr runter gekriegt. Sport-Gels funktionierten für mich etwas basser – die sind auch eklig süß, aber man muss immerhin nicht kauen.

Gruppe

• Auf jeder Tour sind einige, wenn nicht alle, Gruppenmitglieder an ihre Leistungsgrenze gekommen. Das hat zu unvollständiger Kommunikation, Missverständnissen und Konflikten geführt. Mit Aussprache und abendlichen Bier konnten diese aber wieder beigelegt werden.
• Dabei spielen auch die unterschiedlichen Präferenzen eine Rolle. Der eine braucht 1h auf dem Bike, um richtig warm zu werden, andere düsen gleich los. Der eine präferiert viele kurze Pausen und das bringt Andere aus dem Tritt. Der eine frühstückt und braucht erst wieder Abends etwas richtiges zu essen. Andere bekommen Magenkrämpfe, wenn sie zwischendurch nicht zu Mittag essen. Eine lange Mittagspause führt bei anderen dazu, dass sie soweit runterkühlen, dass sie Schwierigkeiten haben, danach wieder neu zu starten. Der eine fährt gerne, schnell und ausdauernd bergauf, während andere häufiger mal schieben müssen. Der eine brettert die Abfahrten ohne Bremsen runter und der andere geht eher auf Nummer sicher. All das kann zu Konflikten führen und auch dazu, dass die Gruppe sich deutlich langsamer fortbewegt als der Einzelne es würde.

Stoneman Miriquidi 2019: 4 Tage

2019 haben wir völlig ahnungslos den ersten Miriquidi (Erzgebirge) geplant. Uns war bewusst, dass wir nicht besonders gut trainiert waren und haben daher mit 4 Tagen geplant. Dass wir offiziell Finisher werden, war uns nicht wichtig – und so richtig durchschaut hatten wir das ganze System nicht.

Wir waren 4 Mountainbiker und 2 Wanderer.

Anreise und Unterkunft

Wir sind mit 2 Autos aus Hamburg angereist (ca. 7h Fahrt). Wir wollten es uns leicht machen und haben eine Jugendherberge in der Mitte des Rundkurses gebucht in Neudorf. Die Idee, dass wir von der Jugendherberge mit den Bikes jeweils zum nächsten Punkt des Rundkurses fahren, hat sich relativ schnell zerschlagen: Die ganze Gegend ist so hügelig, dass das viele KM und Höhenmeter zusätzlich bedeutet hätte. Also haben wir uns von den Wanderern jeweils mit dem Auto bringen und abholen lassen. Mit Fahrt und Auf-/Abladen der Bikes haben wir dadurch pro Tag 1,5-2h Zeit verloren. 

Dafür sind wir in den Genuss der Gaststub Bimmelbahn gekommen, die wirklich sehr gutes Essen in urigem Ambiente hatten.

Die Tour

Auf der Tour haben wir dann gemerkt, wie anders es ist, mehrere hundert Höhenmeter am Stück zu erklimmen im Gegensatz zu den maximal 100 Höhenmeter, die wir im Hamburger Umland hinkriegen. Nachdem wir uns mit den daraus resultierenden Anstrengungen und Schmerzen arrangiert hatten, konnten wir die erklommenen Gipfel als Belohnung durchaus wertschätzen.

Nur einer aus der Gruppe hatte das offizielle Starterpaket gekauft. Es war aber deutlich spürbar, wieviel Motivation ihm das Abstempeln auf den Gipfeln gebracht hat. Bei den folgenden Touren haben daher alle die Starterpakete gekauft.

Am Ende von Tag 2 haben wir dann erlebt, wie lang die Auto-Fahrzeiten in dem Gebiet sein können. Wir Biker waren mit einem der Autos zu unserem Startpunkt gefahren und wollten uns dann Abends vom anderen Auto abholen lassen. Die Wanderer waren aber in die andere Richtung gefahren und es hätte 2h gedauert. Ein Taxi zurück zu unserem Auto am Startpunkt war nicht zu kriegen und auch keine Info, wann wieder Taxen verfügbar sein würden. Dann hat uns ein Einheimischer angesprochen, wo wir hin wollten. Wir haben ihm geschildert, wo unser Auto steht und er meinte, das „wäre doch gleich um die Ecke“ (tatsächlich machte die Tour da einen Schlenker). Er wies uns den Weg und wir sind los. Was er uns nicht gesagt hatte, war, dass wir erst sehr lang abwärts und dann extrem lange und extrem steil bergauf müssen (und dann ist es auch egal, dass die Strecke nur 7 km lang ist). Letztlich hat sich die Gruppe bei einbrechender Dunkelheit auf eine Bank gesetzt und der Biker mit dem eBike hat das Auto geholt.

Tatsächlich hätten wir die Tour mit unserem mäßigen Trainingszustand auch in 3 Tagen geschafft (mit etwas mehr Quälerei). Kurz nachdem wir am dritten Tag mit dem Gedanken gespielt hatten, die Tour am selben Tag noch zu Ende zu fahren, habe ich mich bergab überschlagen und bin mit dem Oberschenkel auf eine Wurzel geknallt. Sattel und Lenker verbogen, wahnsinnige Schmerzen und blau-schwarz anschwellender Oberschenkel machten den 3-Tages-Plan zunichte. Wir haben mich und mein Bike mit vereinten Kräften den Hang runter geschafft. Unten hatten wir Glück: Wir haben einen Forstarbeiter mit Fahrzeug getroffen, der mich und Bike zum nächsten Arzt gefahren hat. Dieser mich per Krankenwagen in die nächste Klinik verfrachten lassen. Dort habe ich den Abend dann wartend mit diversen anderen gestürzten Bikern verbracht und wurde schließlich mit der Diagnose Prellung wieder entlassen – nach einer sehr seltsamen Krankenhaus-Erfahrung, aber das ist eine andere Geschichte. Mit der Prellung hatte ich dann noch 3 Monate zu kämpfen. Der Rest der Gruppe ist den Stoneman dann am 4. Tag zu Ende gefahren.

Stoneman Miriquidi 2022: Bronze (3 Tage)

2022 haben wir es dann richtig in 3 Tagen versucht. Diesmal bestand die Gruppe aus 6 Bikern und 3 Wanderern.

Anreise und Unterkunft

Wir sind wieder 7h lang mit PKWs angereist und wir hatten 3 Hotels auf dem Rundkurs gebucht. Das war wegen der Größe der Gruppe nicht-trivial, weil viele der Logis-Partner nur wenige Zimmer hatten und wir im selben Hotel nächtigen wollten. Die Wanderer haben ein Auto mit dem Gepäck von Hotel zu Hotel gefahren.

Die Tour

Diesmal hatten alle Starterpakete und wir haben die Tour in drei Tagen geschafft. Nicht alle waren top-trainiert, so dass wir die drei Tage als Gruppe auch gebraucht haben und erst Abends im jeweiligen Hotel angekommen sind. Es hat uns außerdem genützt, dass wir die Tour schon mal gefahren waren. Wir konnten uns noch an Teile der Strecke erinnern und wussten, worauf zu achten ist.

Mit dem Starterpaket bekommt man bei jedem Stoneman  eine Stempelkarte. Auf den Gipfeln stehen an den Checkpoints passende Stempelstationen, die das passende Loch stanzen.

Die Wege zu den Gipfeln waren gut ausgeschildert.

Man muss aber schon genau hinsehen; es gibt in der Gegend auch sehr viele Hinweisschilder für andere Fahrradrouten und das generelle Fahrradsymbol ist dem Stoneman-Symbole ähnlich.

Außerdem muss man mehrfach auf schnellen Abfahrten links oder rechts vom Forstweg in den Wald abbiegen. Bei der hohen Geschwindigkeit haben nicht immer alle Gruppenmitglieder die Hinweisschilder gesehen und sind an der Abzweigung vorbeigerauscht. Und dann hilft es auch nicht, wenn die Fahrer dahinter sich die Seele aus dem Leib schreiben: das hört man nicht mehr. Und da es nicht überall Handyempfang gab, haben wir teilweise sehr lange (in einem Fall über 1 Stunde) gebraucht, um die Gruppe wieder zusammenzukriegen. Idealerweise navigieren alle parallel mit Komoot oder man sieht sich vor einer Abfahrt gemeinsam auf Komoot die Streckenführung an.

Die Hinweistafeln der Checkpoints waren meist gut sichtbar.

Es gab in meiner Erinnerung nur eine Tafel (die dargestellte), wo man ein wenig aufpassen muss, weil man nicht auf das Schild zufährt, sondern es plötzlich im Rücken hat, nachdem man an einem Turm vorbeifährt. Also: Bevor es wieder bergab geht, prüfen, ob da nicht eine Stempelstation ist.

Die Tour bin ich mit eBike gefahren. Die anderen in der Gruppe sind Bio-Bikes gefahren und steckte ich immer im Zwiespalt: fahre ich ohne Motorunterstützung und bin wegen des Bike-Gewichts der langsamste oder fahre ich mit Motorunterstützung und damit immer der Gruppe weg. Ich habe mich soweit möglich für Variante 1 entschieden und war am Ende über 90% der Strecke ohne Motorunterstzung gefahren. Und dafür war mir das Bike-Gewicht zu hoch und ich habe für die folgenden Touren auf Bio-Bike umgesattelt.

Als wir die  Tour gefahren sind, gab es vielfältige Forstarbeiten, so dass es viele Umleitungen auf der Strecke gab. Das hat dazu geführt, dass wir am Ende merklich mehr KM und Höhenmeter absolviert hatten, als vorgesehen waren. Dafür waren die Umleitungen relativ gut ausgeschildert.

Und sonst?

Man fährt auf der Tour durch das Trailcenter Rabenberg (kein Lift) und kommt am Trailpark Klinovec (mit Lift) vorbei. Da könnte man noch den einen oder anderen Tag nach dem Stoneman verbringen, wenn man schon mal da ist.

Stoneman Taurista 2023: Bronze (3 Tage)

2023 haben wir dann mit 3 Bikern und 3 Wanderern den Taurista (Salzburger) Land in Angriff genommen. 

Anreise und Übernachtung

Wir sind mit dem Auto-Nachtzug von Hamburg nach Innsbruck gefahren und den Rest der Strecke mit dem Auto. Zu der Zeit waren noch alten ÖBB-Nachtzüge unterwegs und wir hatten zu spät gebucht, um noch Schlafwagenabteile zu bekommen. Also sind wir im Liegewagen gereist. Bei unserem Alter und vielfach Größen von über 180cm waren die kurzen, harten Liegen eine sehr unangenehme Erfahrung.

Für die Übernachten vor Or konnten wir gut ein zentrales Hotel in Radstadt nehmen, weil die Ein- und Ausstiege der Tour alle auf demselben Höhenniveau liegen. Und wenn man 1.500 Höhenmeter gefahren ist, spielt es danach auch keine Rolle mehr, dass man nochmal 15km flaches Gelände zum Hotel fahren muss. Wir sind im Hotel Stegerbräu untergekommen, mit dem wir sehr zufrieden waren. Wir haben dort die Starterpakete und Tipps für die Tour bekommen, es gab einen Fahrradkeller, sehr gutes Essen und einen Saunabereich. Außerdem war es verhältnismäßig preisgünstig. Beim Abendessen im Hotel haben wir Zirbenschnaps entdeckt.

Die Tour

Wir hatten mit dem Gedanken gespielt, ob wir die Tour in 2 Tagen schaffen können und haben das mit dem Hotelwirt diskutiert. Sein Tipp war: Wenn wir bis spätestens 14h wieder auf Höhe des Hotels wären, dann könnten wir weiterfahren und würden es in 2 Tagen schaffen. Challenge accepted dachten wir uns… Um 18:30h waren wir wieder auf Höhe unseres Hotels. Wir hatten deutlich unterschätzt, um wieviel anstrengender die Anstiege im Vergleich zum Miriquidi sind. Also haben wir uns damit abgefunden, dass wir doch drei Tage brauchen würden. 

Die Hinweisschilder waren diesmal rot und alles war gut ausgeschildert.

Im Gegensatz zum Miriquidi gibt es viel weniger Gipfel und das bedeutet, wenige irre lange und teilweise extrem steile Anstiege. Und hier haben wir so richtig gemerkt, um wieviel anstrengender das ist. Es gibt beim Taurista in der zweiten Etappe eine längere Bergauf-Strecke, auf der man das Bike schieben und teilweise tragen muss. Und später gibt es eine Gipfel-Passage, wo man auch viel schieben und tragen muss. Dafür gab es dort die spektakulärste Aussicht mit Gebirgssee und Schneefeldern.

An den Checkpoints waren die Stempelstationen gut sichtbar und mit Hinweisen zur nächsten Etappe versehen.

In der zweiten Etappe kommt man einer 1km langen Schiebepassage vorbei.

Hier sollte man der Empfehlung unbedingt folgen. Der Weg ist sehr steil und voller Wurzeln. Und der Kilometer zieht sich sehr lang hin. Es ist schon anstrengend genug, sein Bike da hochzuschieben bzw. zu tragen.

Auf der Etappe Oberhütte-Johannesfall gab es eine Überraschung für uns. Wir hatten Oberhütte mit letzter Kraft in sengender Hitze erreicht, uns an der Hütte gestärkt und auf eine Abfahrt gefreut. Stattdessen führten die Hinweisschilder noch weiter bergauf. Wir mussten über einen Bergpass, der so steil und felsig war, dass wir die Bikes den größten Teil des 200 Höhenmeter-Anstiegs schieben und sogar tragen mussten. Außerdem kühlte es ab und der Himmel zog sich zu. Ich war so kaputt, dass ich mir dachte: “Wenn es jetzt noch anfängt zu regnen, rufe ich die Bergrettung.” Tat es aber nicht und so war meine Ausrede fürs Aufgeben unbrauchbar und wir haben es irgendwie zuende gebracht.

Und wenn man die Anstrengung mal außen vor lässt, hatten wir dort das beste Panorama mit Bergsee und Schneefeldern.

Am Ende waren wir glücklich und erschöpft, als wir die Tour absolviert hatten. Die Berge sind hier schon deutlich höher als beim Miriquidi.

Hier haben wir gelernt, dass es bei gleichen Höhenmetern viel anstrengender ist, wenige lange Anstiege zu fahren als viele kürzere. Außerdem waren viele der Anstiege deutlich steiler als beim Miriquidi. Und nicht zuletzt fährt man beim Taurista mehr oberhalb der Baumgrenze in dünnerer Luft. Und wenn man dann noch im Hochsommer bei wolkenlosem Himmel in der Sonne brutzelt, belastet das den Körper deutlich zusätzlich.

Ich habe mich bei den langen Anstiegen immer bei den Gedanken erwischt, einfach aufzugeben. Aber irgendwie ging es dann doch immer – zur Not geschoben und auf allen Vieren. Dass Gefühl, es geschafft zu haben, hat die Anstrengung rückblickend dann doch gelohnt.

Und sonst?

Nach der Tour haben wir das Hotel nochmal gewechselt und waren zu zweit 2 Tage im Bikepark Leogang. Der ist riesig und beeindruckend, für Anfänger aber eher nicht geeignet. Selbst die blauen (einfachen) Flow-Lines sind z.T. extrem steil und verlangen einem Einiges ab. Wir haben mehrfach gesehen, wie gestürzte Fahrer mit Quads abtransportiert wurden und sind auch beide jeweils einmal gestürzt – allerdings ohne größere Verletzungen. Crosscountry-Bikes kommen schnell an ihre Grenzen. Enduro oder Downhill passt besser.

Immerhin: Der Einstieg in die einzelnen Strecken des Bikeparks haben einen ganz guten Eindruck vermittelt, was auf einen zukommt.

Das hier haben wir z.B. ausgelassen (so wie viele der anderen Strecken auch):

Wir hatten trotzdem zwei Tage lang viel Spaß. Zu dem riesigen Pumptrack sind wir gar nicht mehr gekommen.

Stoneman Arduenna 2024: Silber (2 Tage)

Dann hat mich der sportliche Ehrgeiz gepackt. Bei den Bronze-Touren hatten wir immer auch Einzeletappen dabei, die bzgl. KM und Höhenmetern den Silber-Etappen ähnelten : Geht es vielleicht doch in 2 Tagen? Der Arduenna in Belgien schien sich dafür zu eignen: relativ wenige Höhenmeter und keine so langen Anstiege (in den Ardennen gibt es ja keine hohen Berge). Hier konnte ich nur einen Mit-Biker überreden, mitzumachen. 

Anreise und Übernachtung

Wir sind mit dem Auto aus Hamburg angereist und haben ein Hotel am Startpunkt und eines auf der Mitte gebucht. Und haben nur minimal notwendiges Gepäck im Rucksack dabei gehabt. Es war erstaunlich schwierig, passende Hotels zu finden. Daher mussten wir beim Hotel auf der Strecke auch auf eines ausweichen, das kein offzieller Logis-Partner war. 

Die Tour

Arduenna lässt sich super-flowing fahren und man ist fast ausschließlich im Wald unterwegs mit einem relativ großen Singletrail-Anteil. Letzterer hat dazu geführt, dass es doch anstrengender wurde, als ich gedacht hatte: Viele Anstiege lassen sich nicht in einem gleichmäßigen Trott wie auf einem Feldweg fahren. Man muss immer wieder über Wurzeln drüber und um die Kurve. 

Diesmal waren die Hinweisschilder gelb-braun. Wieder war alles gut ausgeschildert.

Echte Berge gibt es in den Ardennen nicht (jedenfalls im Vergleich zu Taurista). Die Checkpoints mit den Stempelstationen kann man daher leichter übersehen und versehentlich dran vorbeifahren. Das ist uns zweimal auch fast passiert, obwohl die Hinweisschilder groß genug waren.

Aber man fährt nicht immer direkt drauf zu und sie liegen eher an der Seite des Weges.

Eine grandiose Fehleinschätzung ist uns am ersten Tag unterlaufen. Wir haben am späten vormittag an einer Stempelstation in einem Ort und auf dem Hinweisschild stand, dass es bis zu nächsten Station (ca. 30km entfernt) keine Verpflegungsmöglichkeit mehr gäbe. 

Uns schien es zu früh zum Essen und so sind wir weitergefahren. Bei der nächsten Verpflegungsmöglichkeit kamen wir erst nachmittags an und wir fuhren auf dem Zahnfleisch. Man sollte die Empfehlungen wirklich ernster nehmen, als wir das getan haben.

Der zweite Tag begann für mich mit jeder Menge Schwerzen und die ersten zwei Stunden der Etappe habe ich überlegt, aufzugeben. Irgendwann habe ich den inneren Schweinehund aber besiegt und konnte nachmittags dann auch meinen Partner dazu bringen, weiter zu fahren – da war der am Ende seine Motivation.

Der höchste Punkt der Tour ist das hohe Venn (ein Hochmoor) mit 694 Metern Höhe. Die Belgier wollten aber wohl gerne einen 700er-Hügel haben und haben da noch ein paar Meter draufgesetzt. Das haben wir natürlich auch mitgenommen.

Mittags des zweiten Tages fing es dann noch an, in Strömen zu regnen. Wir hatten natürlich Regenjacken und -hosen dabei, waren nach ein paar Stunden aber trotzdem nass bis auf den Knochen. Die letzten Anstiege mussten wir gegen die Strömung die Hügel hoch.

Schließlich sind wir nass, dreckig und leicht unterkühlt nach zwei Tagen am Ziel angekommen.

In Summe sind wir 180km bei 4.000 Höhenmetern gefahren (offiziell 176km bei 3.900 Höhenmetern).

Und sonst?

Es wäre vermutlich ganz cool gewesen, noch einen Tag länger zu bleiben, um das belgische Bier zu genießen. Ich habe dann meinen Partner mit dem Auto nach Köln zum Bahnhof gefahren und ihn gegen meine Familie eingetauscht, die von Hamburg mit dem Zug angereist kam und wir haben dann noch einen Urlaub in der Eifel angehängt: Tolle Wandergegend mit erstaunlich wenig Mountainbike-Touren.

Stoneman Dolomiti 2025: Bronze (3 Tage) 

2025 haben wir uns dann den Ur-Stoneman in den Dolomiten in Süd-Tirol vorgenommen. Wir waren 4 Biker und 2 Wanderer. 

Anreise und Übernachtung

Leider gab es jetzt keinen Autozug von Hamburg nach Innsbruck mehr (die Erneuerung der ÖBB-Nachtzüge hat wohl dazu geführt, dass sie zu lang wurden, um noch Auto-Waggons anzuhängen) . Ein Teil der Gruppe ist mit Auto inkl. der Bikes angereist, der andere Teil mit dem Zug (ICE HH->München, Railjet München->Brixen, Bus als Schienenersatzverkehr Brixen->Bruneck, Regionalbahn Bruneck->Innichen, Bus Innichen->Sexten). Auto- und Bahnfahrt haben ca. gleichlang gedauert: 14h.

Ähnlich wie beim Taurista kann man hier zentral nächtigen – in Sexten oder Innichen. Wir haben das in Sexten im Hotel Waldheim gemacht. Im Gegensatz zu vielen anderen Hotels, die ich geprüft hatte, hatte die noch einigermaßen akzeptable Preise. Vor Ort waren wir dann begeistert von dem tollen Service, dem guten Essen im Rahmen der Halbpension und Sauna+Whirlpool.

Die Tour

Die Berge waren hier nochmal ein gutes Stück höher als beim Taurista – wir waren ständig über 2.000 Meter unterwegs.

Die Beschilderung ist deutlich rudimentärer als bei den anderen Stoneman-Touren. Auf den Gipfeln erwartet einen eine Stele mit einer Zange zum Lochen der Karte und es gibt keine weiteren Hinweise auf die nächste Etappe. Man wählt selbst, wo man das Loch setzt. Die Zangen machen auf jedem Kipfel eine andere Form (Kreis, Quadrat, Stern etc.)

Es gibt auf der Strecke keine Hinweisschilder, sondern nur auf Boden oder Baumstümpfe gesprühte Stoneman-Symbole in grün. Das Symbol ist jeweils so gedreht, dass die Spitze in Fahrtrichtung zeigt. Es sind aber lange nicht soviele Symbole vorhanden wie bei den anderen Stonemans. Da mein teilweise dieselbe Strecke hoch und runter fährt, ist auch nicht immer klar, ob man dem Symbol nach rechts oder links folgen sollte. Ohne Komoot-Navigation hätten wir mehrfach nicht den richtigen Weg gefunden.

Die schlechtere Beschilderung des Dolomiti liegt wohl daran, dass die Stoneman-Organisatoren keine Genehmigung bekommen haben, Schilder aufzustellen.

Die erste Etappe führte uns zum Strickberg (2.540 Meter hoch). Mit der zentralen Unterkunft fährt man im Grunde einmal den Strickberg rauf und den gleichen Weg wieder hinunter. Wir haben zuerst die Auffahrt zum Berg verpasst und waren danach gleich wieder auf der Komoot-Strecke. Daher haben wir unser Versehen erst relativ spät bemerkt und durften mit 200 Höhenmetern extra wieder zurück. Irgendwann um die Höhe von 2.000 Metern habe ich gemerkt, dass mein Puls explodiert und mir übel wurde. Rückblickend war die ungewohnte Höhenluft vermutlich ein wesentlicher Aspekt dabei. (Vermutlich wären 1-2 Tage Akklimatisierung vor der Tour sinnvoll, wenn man wie wir aus dem flachen Land kommt.) Mit viel Schieben und Kampf habe ich es aber doch bis zum Gipfel geschafft (Tag 2 ging etwas besser; am dritten Tag hatte ich mich wohl an die Höhenluft gewöhnt und es lief wieder wie gewohnt). Das letzte Stück hatte ich beim Schieben Begleitung von dem Gruppenmitglied mit Light eMTB. Trotz Range-Extenders reichte der Akku nicht ganz bis zum Gipfel. Alles in allem sind wir am ersten Tag knapp 70km mit 1.800 Höhenmetern gefahren.

An Tag 2 haben wir die Demut Passage ausgelassen. Ich wegen Höhenangst, der Rest der Gruppe wegen Gewittergefahr. Also war das Ziel der Leckfeldsattel mit 2.380 Metern. Von dort ging es zurück nach Sexten und das Auslassen der Demut Passage wurde am dritten Tag “bestraft”: Wir mussten zum Passo Silvella hochradeln. Wenn man die Demut Passage mitnimmt, kommt man da mit deutlich weniger Höhenmetern hin. Die dritte Etappe ist so die anspruchsvollste: Wir sind 57km und 2.100 Höhenmeter gefahren. Dafür gibt es ab Passo Silvella einen langen sehr coolen Trail auf ca. 2.300 Metern Höhe auf dem Bergrücken. 

​​

Dort gab es ein paar wenige Stellen, die ich bzgl. Höhenangst zumindest respekteinflößend fand. Vielleicht ein guter Test für die Demut Passage? Mit der dritten Etappe starten und wenn einem mulmig wird, die Demut Passage nicht fahren. Ist aber spekulativ. Ich habe die Demut Passage ja nie Live gesehen. 

Das Panorama ist nochmal beeindruckender als beim Taurista. Wir empfanden die Tour aber als anstrengender: weniger Gipfel, noch längere, noch steilere Anstiege.

Wenn man die Kilometer und Höhenmeter der ersten und dritten Etappe ansieht, hätten wir die Tour auch in Silber fahren können. Dann kann man allerdings de Demut Passage nicht umfahren bzw. kassiert nochmal über 1.000 Höhenmeter oben drauf.

In Summe sind wir 155km und 5.000 Höhenmeter gefahren im Gegensatz zu den offiziellen 120km bei 4.000 Höhenmetern.

Und sonst?

In Sexten liegt der Stoneman Info Point mit Shop. Dort kann man Starterpakete abholen und die Tour fertig melden (was bei den meisten Logispartnern nicht direkt möglich ist). Dafür haben wir dort den Gründer der Stonemans Roland Stauder getroffen und sehr nett mit ihm geplaudert. 

Außerdem gibt es in der Sextener-Gegend ein großes Trailnetz und viele Seilbahnen, wenn man das Trailnetz erkunden will, ohne ständig bergauf zu fahren. Wir sind nach der Tour noch den Erla-Trail gefahren, zu dem wir “nur” 720 Höhenmeter absolvieren mussten.

Mit den Jahren ist mir dann immer klarer geworden, was der Ausspruch wirklich bedeutet und wie hart das sein kann. Denn damit Following wirklich ein Leadership-Skill ist, reicht ein resigniertes Folgen nicht aus. Man muss es aus voller Überzeugung tun. Nur dann kann man andere animieren, das auch zu tun.

Und der harte Teil beginnt dort, wo man selbst andere Vorstellungen hat als jemand anderes, der gerade Führung übernimmt – und wenn wir ehrlich sind, haben wir das oft. Sich dann dieser Richtung anzuschließen und sie mit ganzem Herzen zu vertreten, ist nicht immer einfach.

Betrachten wir als Beispiel die Lockerung der Corona-Maßnahmen in Deutschland (ich weiß, dass Diskussionen zu diesem Thema ein heißes Eisen sind, aber Dinge mutig anzusprechen ist halt auch ein Leadership-Skill

Viele finden, dass Beschränkungen zu früh und zu radikal gelockert werden. Mir ist selbst auch schon mulmig geworden bei einigen Lockerungen. Und ich habe auch keine durchdachte Strategie zu den Lockerungen gehört. Viel davon scheint das Ergebnis von politischem Hickhack zu sein.

Eine interessante Frage ist also, wie man dieser Lockerungsrichtung aus vollem Herzen folgen kann. Dazu hilft mir, mir vorzustellen, dass die Politik eine sehr schlaue, sehr durchdachte Strategie verfolgt, die in der Kommunikation bei mir nicht richtig angekommen ist. Mit dieser Frage habe ich für mich folgende Strategie (re)konstruiert: „Wir haben eine relativ entspannte Situation bzgl. Ansteckungszahlen und der Sommer spielt uns vermutlich auch in die Karten (mind. dadurch, dass nicht gleichzeitig noch eine Grippewelle über uns drüber rollt). Diese entspannte Situation nutzen wir, um mit möglichst vielen Lockerungen zu experimentieren. So finden wir bis zum Herbst heraus, welche Maßnahmen wirklich notwendig sind, um die Ausbreitung einzudämmen. Wenn dann im Herbst/Winter die Fallzahlen wieder ansteigen sollten, brauchen wir keinen zweiten Lockdown, sondern können sehr gezielt agieren und dadurch den gesellschaftlichen und wirtschaftlichen Schaden minimieren.“

Mit dieser Sichtweise kann ich der Richtung aus vollem Herzen folgen und mit meinen eigenen Ängsten und Bedenken besser umgehen. Ich habe dann auch weniger Angst vor neuen Ausbrüchen. Tatsächlich sind die sogar zu erwarten. Wir haben mit dem „Lockdown“ ein ganzes Bündel an Maßnahmen installiert, um die Kurve abzuflachen – mit Erfolg. Allerdings haben die Maßnahmen wahrscheinlich sehr unterschiedliche Wirksamkeit. Die Erfahrungen mit den Lockerungen der letzten Wochen deuten darauf hin, dass viele Maßnahmen geringen Effekt haben und weniger sehr großen. Anfänglich wussten wir aber nicht, welche Maßnahme in welche Kategorie gehört. Im Rahmen der laufenden Experimente werden vermutlich auch Maßnahmen zurückgefahren, die einen großen Effekt hatten – steigende Infektionszahlen wären die Folge. Wir würden dabei aber auch lernen, dass diese Maßnahme offensichtlich sehr wirksam war.

Skurrilerweise spielt es dafür keine Rolle, ob die Politiker wirklich die oben genannte Strategie verfolgen. Dadurch, dass ich mich so verhalte, wie ich sie wahrnehme, trage ich dazu bei, dass die umgesetzten Maßnahmen das bestmögliche Ergebnis generieren. So nutze ich die Lockerungen sehr bewusst so, dass ich im Falle einer Infektion einigermaßen sicher sagen kann, woher ich sie habe und wen ich selbst infiziert haben könnte.

Kann man sich Selbstorganisation jetzt noch leisten?

Ich habe mehrfach gehört, dass jetzt Krisenstäbe das Heft in die Hand genommen hätten und man sich Selbstorganisation zur Zeit nicht leisten könne. Bei solchen Aussagen frage ich mich, ob es ein Missverständnis darüber gibt, welches Problem Selbstorganisation löst. Selbstorganisation ist ein wirkungsvoller Mechanismus, um komplexe Probleme im Team zu lösen. Das ist nichts, was man sich „leistet“. Es ist etwas, was effizient und effektiv ist, um eine bestimmte Problemklasse zu lösen.

Es geht keineswegs darum, dass es alle bequem und komfortabel haben und jeder überall mitreden und mitbestimmen darf.

Die Frage darf nicht sein, ob wir uns Selbstorganisation leisten können. Die Frage muss sein, welche der anstehenden Probleme am Besten durch selbstorganisierte Teams gelöst werden können.

Krisenstäbe und Krisenmanager

Krisenstäbe und Manager bewerten eine bestehende Krisensituation und entscheiden dann darüber, wie mit der Situation umzugehen ist. Jedem einigermaßen Krisenmanager ist dabei vollkommen klar, dass die Situation dynamisch ist und daher kontinuierlich neu bewertet werden muss. Jeder Krisenmanager hat Inspect&Adapt und damit einen Teil des agilen Mindsets im Blut.

Neben Inspect&Adapt gibt es weitere Aspekte, die für Agilität charakteristisch sind: 

• Kundenfokus: Wir wollen kundenrelevante Probleme lösen und sind dazu im engen Austausch mit den Kunden.
• Anspruchsvolle Lösungen: Die Lösungen, die wir schaffen, sind nicht trivial und brauchen unterschiedliche Fähigkeiten. Diese Fähigkeiten finden sich nicht in einer einzigen Person und daher brauchen wir ein Team.
• Arbeit in selbstorganisierten Teams: Die Probleme und die dazu passenden Lösungen lassen sich nicht vorab klar planen. Wir müssen uns über Inspect&Adapt nähern und das können in dem gegebenen Kontext aus Kundenfokus, Lösungskomplexität und dafür notwendiger Fähigkeiten selbstorganisierte Teams am Besten.
• Nachhaltigkeit: 

Für den Kontext von Krisenmanagement treffen die genannten Punkte selten zu. In der aktuellen Krisen haben viele Unternehmen deutliche Umsatzeinbußen. 

Kundenfokus: Der Job des Krisenmanagers besteht nicht darin, neue Kunden zu finden. Der Job besteht darin, die Kosten soweit zu drücken, dass das Unternehmen im existierenden Markt möglichst lange überleben kann.

Anspruchsvolle Lösungen: Die dafür notwendigen Lösungsstrategien können aufwändig sein, sie sind aber meist nicht anspruchsvoll: Kurzarbeit anmelden, Kredite beantragen, mit Vermietern und Banken verhandeln. Das alles braucht einzelne Experten, aber nicht immer interdisziplinär arbeitende Gruppen. Und wenn eine interdisziplinäre Gruppe arbeitet, wird diese meist zentral gelenkt.

Selbstorganisierte Teams: Diese beiden Punkte zusammen führen dazu, dass selbstorganisierte Teams für frühe Krisenarbeit nicht so zwingend sind wie für die Entwicklung innovativer Produkte.

Sowohl als auch

Nur Krisenarbeit zu machen, ist aber keine nachhaltige Geschäftsstrategie. Durch den starken Fokus nach innen, können Krisenmanager in erster Linie Kosten senken. Wenn das Geschäft als solches funktioniert und sich um Unternehmen schlicht zuviel Overhead angesammelt hat, reicht das sogar. Wenn es Probleme im Geschäft gibt (wie jetzt bei vielen Unternehmen in der Corona-Zeit), können Krisenmanager durch Kostensenkungen Zeit erkaufen. Durch ihren starken Fokus nach Innen und die oben beschriebene Arbeitsweise, sind sie aber nicht die optimale Antwort auf die Frage, wie man das Geschäfts wieder ans Laufen kriegt oder neue Geschäftsfelder erschließt.

Das können agile Teams besser. Die Stärke agiler Teams liegt in der kontinuierlichen Markt-Interaktion und dem (er-)finden kreativer Lösungen für Kundenprobleme.

In der aktuellen Situation braucht man als beides: sowohl Krisenmanager wie auch agile Teams. Eine Herausforderung besteht dabei sicher darin, dass Krisenmanager für ihren Jobanteil “strikt kosten sparen” sehr genau wissen müssen, was genau los ist. Sie müssen die Situation unter Kontrolle bringen und behalten. Das passt dann aber nicht mehr zur Arbeit agiler Teams, die nach neuen Lösungen suchen, wie das Geschäft neu gestaltet werden kann. Das strikt zu kontrollieren, verhindert Kreativität.

Und jetzt?

Konzeptionell ist vielen klar, dass unterschiedliche Problemstellungen unterschiedliche Vorgehensweisen brauchen – die entsprechenden Modelle a la Cynefin und Stacey kennen viele. In der Praxis tun sich viele Unternehmen aber sehr schwer damit, diese Diversität im Vorgehen auszuhalten, geschweige denn konstruktiv zu nutzen. Stattdessen bekämpfen sich die Vertreter der jeweiligen Lager. Und darin liegt im Moment auch eine große Chance zur “Versöhnung”: Vielleicht wird gerade klar, dass man seine Energie nicht in den Kampf zwischen den Lagern verschwenden sollte, sondern daran, gemeinsam die Krise zu meistern. Dabei können Unternehmen lernen, wie die unterschiedlichen Vorgehensweisen je Problemstellung angemessen verwendet werden können.

Enger Austausch zwischen Krisenmanagern und agilen Teams und regelmäßige Reflektionen darüber, was getan und was damit erreicht wurde, führt zu Unternehmenslernen. Und damit können Unternehmen tatsächlich gestärkt auch aus der Krise hervorgehen. Diese Reflektionen durchzuführen, ist in der aktuellen Situation eine große Herausforderung. “Sollen wir wirklich die 2 Stunden für eine Retrospektive investieren oder nicht doch besser an den nächsten Krisenaufgaben arbeiten?” Das braucht Leadership – jemand muss um Blick behalten, dass klassische Krisenarbeit, agile Lösungsfindung und gegenseitiges Lernen im jeweils angemessenen Maße stattfinden.

P.S.: Diskussionsbedarf zu dem Thema? Gerne bei mir melden: stefan.roock@it-agile.de oder Tel. 0172/429 76 17

P.S:: Vielen Dank an Yves Stalgies für wertvolles Feedback zu einer frühen Version dieses Blogbeitrags.

Um die COVID-19-Pandemie zu bekämpfen, haben viele Regierungen die Handlungsspielräume der Bevölkerung massiv eingeschränkt. Ist damit Selbstorganisation abgeschafft? Funktioniert Selbstorganisation nur bei Schönwetter und versagt, wenn es hart auf hart kommt?

Selbstorganisation bei Tieren

Beginnen wir mit dem Konzept der Selbstorganisation. Ein plastisches Beispiel für Selbstorganisation findet sich bei Fisch/ und Vogelschwärmen: Es gibt niemanden, der Ansagen für alle macht. Stattdessen sorgt ein einfacher Regelsatz dafür, dass der ganze Schwarm sinnvoll funktioniert (siehe https://de.m.wikipedia.org/wiki/Schwarmverhalten):

1. Bewege dich in Richtung des Mittelpunkts derer, die du in deinem Umfeld siehst (Kohäsion).
2. Bewege dich weg, sobald dir jemand zu nahe kommt (Separation).
3. Bewege dich in etwa in dieselbe Richtung wie deine Nachbarn (Alignment).

Zugvögel bilden V-Formationen, die durch die o.g. Regel nicht entsteht. Dazu sind andere Regeln notwendig:

1. Nutze den Auftrieb, den der Flügelschlag eines vor dir fliegenden Vogels verursacht.
2. Nimm dabei eine Position ein, von der aus du ungestört nach vorn blicken kannst.

Mit diesen Regeln entsteht die Formation, auch wenn die Vögel unkoordiniert starten.

Dadurch, dass die Individuen sich an die einfachen Regeln der Selbstorganisation halten, entstehen im Schwarm komplexe Verhaltensmuster. Dazu ist es nicht mal notwendig, dass die einzelnen Individuen das entstehende Muster als eigenes Ziel haben.

Selbstorganisation in der Gesellschaft

Unsere Gesellschaft inkl. des Wirtschaftssystems ist selbstorganisiert. Dabei organisiert sich jede Gesellschaft selbst – auch in Diktaturen. Der Unterschied besteht in der Enge bzw. Weite und der Verlässlichkeit des vorgegebenen Rahmens.

Die Gesetze definieren in den Rahmen, in dem sich Selbstorganisation entfaltet. Die Gesellschaft als solches verfolgt mit der Selbstorganisation kein gemeinsames Ziel – man kann argumentieren, dass die Aufgabe des Wirtschaftssystems die Vermehrung des Wohlstands der Gesellschaft ist. Allerdings ist das sicher kein Ziel, dass von allen Unternehmen aktiv verfolgt wird. Wie beim Schwarmverhalten der Vögel ist es auch nicht unbedingt notwendig, dass die einzelnen handelnden Akteure dieses Ziel verfolgen.

Und trotz dieser ganzen Ähnlichkeiten existieren relevante Unterschiede zwischen Menschen und Fischen oder Vögeln. Nach allem, was wir über Vögel und Fische wissen, können wir davon ausgehen, dass wir bewusstere Entscheidungen treffen, über die Vergangenheit reflektieren und Pläne für die Zukunft machen können. Daher können wir Menschen uns mit unschärferen Regeln als die Vögel selbst organisieren. Und daher funktioniert unsere Selbstorganisation auch meistens dann noch, wenn Einzelne sich nicht an die Regeln halten. Die anderen können darüber nachdenken, was die Abweichungen bedeuten und sinnvolle Schlussfolgerungen für ihr eigenes Handeln ableiten.

Beschränkung der Selbstorganisation in der aktuellen Krise

In der aktuelle Pandemie versuchen die Regierungen, die Gesellschaften auf ein gemeinsames Ziel einzuschwören: „Flatten the curve“. Das Ziel besteht darin, die Kurve der Infektionen soweit abzuflachen, dass die Gesundheitssysteme nicht kollabieren. Im Großen und Ganzen scheint dieses Ziel auch akzeptiert zu werden. Um dieses Ziel zu erreichen, haben die Regierungen Maßnahmen definiert, die je Land unterschiedlich, in Europa aber doch sehr ähnlich sind. Diese Maßnahmen bringen erhebliche Einschränkungen der Handlungsfreiheit der Einzelnen mit sich. Dass sie trotzdem im Wesentlichen akzeptiert und befolgt werden, dürfte mit der Akzeptanz der höheren Ziels „flatten the curve“ zusammenhängen.

Die beschlossenen Maßnahmen der Regierungen bestehen aus klaren, strikten Vorgaben. Diese Vorgaben definieren vor allem, was man alles nicht mehr tun darf. Sie unterscheiden sich damit von den Regelsätzen, die z.B. Schwarmverhalten erzeugen. Die Vorgaben sind nicht besonders gut dafür geeignet, neue und überraschende Handlungsmuster zu erzeugen. Und das ist vermutlich auch nicht beabsichtigt. Es geht im Moment nicht darum, innovative Lösungen für ein komplexes Problem zu finden. Es geht darum, durch einheitliches Handeln (oder besser Nicht-Handeln) eine Katastrophe für das Gesundheitssystem zu vermeiden.

Selbstorganisation existiert trotzdem

Allerdings ist damit Selbstorganisation keineswegs abgeschafft. Die Menschen und Unternehmen passen sich selbstständig im Rahmen der Vorgaben an. Restaurants mussten schließen und bieten Lieferdienste an. Unternehmen, die zur Zeit wenig zu tun haben, leihen Mitarbeiter an Unternehmen aus, die zur Zeit Personalengpässe haben. Die Menschen finden alternative Wege, um in Kontakt zu bleiben; meine achtjährige Tochter macht beispielsweise wöchentlich eine Videokonferenz mit ihren Freundinnen.

Warum nicht mehr Selbstorganisation in der Bevölkerung?

Selbstorganisation kann schneller bessere Lösungen für anspruchsvolle Probleme liefern als Fremdbestimmung. Dafür sind allerdings Voraussetzungen notwendig, die sich im Moment nicht vollständig herstellen lassen. Das erste Problem ist die fehlende Transparenz.

Aus den o.g. Beispielen für Schwarmverhalten lässt sich gut erkennen, dass die einzelnen Akteure ihr Umfeld kontinuierlich wahrnehmen müssen. So können sich die Verhaltensweisen der einzelnen Akteure gegenseitig so beeinflussen, dass am Ende des Gesamtergebnis entsteht.

Und genau an der Transparenz hapert es bei der COVID-19-Pandemie ganz erheblich. Bei vielen Infizierten treten keine oder kaum Symptome auf und trotzdem können sie andere Personen infizieren. Eine Regel wie „meide Kontakt zu Infizierten und isoliere dich selbst, wenn du infizierst bist“ funktioniert also leider nicht.

Stattdessen kennen wir nur die Anzahl der infizierten Personen (und das auch nur ungefähr) und viel schlimmer: Da Infizierte nicht sofort Symptome entwickeln, hinken die Statistiken 10-14 Tage hinterher. Man kann also nicht am Montag ein neues Verhalten ausprobieren, Dienstag morgen die Änderung der Infektionsrate ansehen und dann ggfs. etwas Anderes ausprobieren. Die Feedback-Zyklen sind zu lang, um die Gesellschaft selbstorganisiert das passende Verhalten herauszufinden zu lassen.

Das zweite Problem ist die Interpretation der Daten. Wenn Fallzahlen steigen oder sinken, kann das sehr unterschiedliche Ursachen haben (und z.B. mit der Menge der verfügbaren Tests oder geänderten Arbeitsweisen der Labore zusammenhängen). Wir Nicht-Experten können also nicht mal besonders gute Schlussfolgerungen aus den Daten ziehen. Selbst wenn es die Verzögerung bei den Fallzahlen nicht gäbe, wären viele der selbstorganisierten Entscheidungen vermutlich nicht besonders schlau.

Selbstorganisation zur Bekämpfung der Pandemie

Es gibt bereits viele selbstorganisierte Initiativen, um mit der Pandemie umzugehen. Die Entwicklung von Medikamenten und Impfstoffen findet in Unternehmen und Forschungsinstituten statt – ohne Command&Control durch die Regierung.

Und wenn wir es schaffen würden, mehr Transparenz und kürzere Feedback-Zyklen zu schaffen, kann die Gesellschaft selbstorganisierter dazu beitragen das passende Verhalten zu (er)finden. Die verschiedenen diskutieren Apps (z.B. zum Kontakt-Tracking) könnten dazu einen Beitrag leisten.

Und in Unternehmen?

Die Frage nach dem richtigen Maß an Selbstorganisation stellt sich auch in vielen Unternehmen. Im Moment ist die Zeit der Krisenstäbe und Krisenmanager. Aber bedeutet das, dass Selbstorganisation in den Unternehmen gescheitert ist? Dazu werde ich in den nächsten Tagen einen eigenen Blogpost veröffentlichen.

Commitment ist also nach wie vor ein wichtiger Bestandteil von Scrum, aber irgendwie anders als früher. Wie ist das jetzt wirklich gemeint? Das kann alles sehr verwirrend sein. Und es wird nicht einfacher dadurch, dass es keine gute deutsche Übersetzung für „Commitment“ gibt. Einige versuchen es mit „Verpflichtung“.

„Verpflichtung“ geht meiner Meinung nach genau in die falsche Richtung (siehe unten), aber dennoch kann uns diese Übersetzung nützen. Denn wenn wir „Verpflichtung“ zurück ins Englische transferieren, ist „Obligation“ eine valide Übersetzung.

Und „Obligation“ findet sich auch im Responsibility Process(tm) von Christopher Avery. Dieser definiert fünf Stufen, die wir durchlaufen, bevor wir vollständig in Verantwortung handeln. Zunächst ignorieren oder leugnen wir ein Problem mitunter (Denial). Danach geben wir jemand anderem die Schuld (Lay Blame), dann den Umständen (Justify) und uns selbst (Shame). Danach kommen wir in Handlung. Zunächst, weil wir uns verpflichtet fühlen (Obligation). Im Gegensatz zu den anderen Stufen sind wir jetzt handlungsfähig, wir nutzen unser kreatives Potenzial aber noch nicht aus. Das tun wir erst, wenn wir uns die Situation zu eigen machen und vollständig in Verantwortung gehen (Responsibility).

Das, was Scrum mit Commitment meint, ist Responsibility: Das Team nimmt die Aufgabe voll und ganz in Verantwortung; nicht weil es jemand von ihnen erwartet, sondern weil sie die Aufgabe gestalten wollen.

Das häufig als dysfunktional wahrgenommene rituelle Commitment auf den Sprint entspringt eher Obligation: einem Gefühl, sich verpflichten zu müssen.

Mit Commitment ist also nichts verkehrt, wenn es im Sinne von Responsibility stattfindet und es ist mit Commitment alles verkehrt, wenn das Team bei Obligation hängen bleibt.

Motto: Think. Create. Learn.

„Think. Create. Learn.“: das war das Motto der InnoDays. Think und Create habe ich überall gesehen und gespürt. Das Lernen waren meiner Meinung nach etwas unterbelichtet. Sicherlich wurde viel auf technischer Ebene gelernt, auch bzgl. Machbarkeit (z.B. 3D-Druck von Gutscheinen). Und die Teams haben auch quantitativ etwas über den Markt gelernt. So hatten viele Teams Zahlen, Daten, Fakten über den Markt und bestimmte Nutzergruppen in ihrer Abschlusspräsentation. Mir fehlte noch das qualitative Lernen über den Markt – welche Probleme und Bedürfnisse haben real existierende Menschen (und nicht irgendein Durchschnitt) wirklich?

Fazit

Für mein Gesamt-Fazit zu den Otto InnoDays wiederhole ich das, was ich bereits ganz am Anfang geschrieben habe:

Im Vergleich mit ähnlichen Veranstaltungen in anderen Firmen waren die Otto InnoDays 2016 auf jeden Fall ganz vorne mit dabei. Und wenn ich dann bedenke, dass Otto ein Konzern mit über 4.000 Mitarbeitern und kein eBusiness-Unternehmen mit nur 200 Mitarbeitern ist, ziehe ich meinen Hut. Von den Otto InnoDays 2016 können sich viele vermeintlich agilere Unternehmen eine große Scheibe abschneiden.

Ich habe an einigen Stellen deutlich etwas zu mäkeln gehabt (Einbindung von Endkunden, Vernetzung von Ideen), aber das ist im Vergleich zu anderen Unternehmen Jammern auf hohem Niveau. Ich hoffe, dass meine Mäkeleien dazu führen, dass die Otto InnoDays 2017 noch cooler werden als die Otto InnoDays 2016. Und dann lasse ich mich gerne wieder dazu einladen.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

InnoDays als dauerhafter Arbeitsmodus

Die Ergebnisse der Otto InnoDays waren größtenteils geeignet, um die Wertschöpfung zu erhöhen. Das zeigt sich auch darin, dass von den sieben Gewinnern fünf für die finale Umsetzung ausgewählt wurden (und nicht nur, wie zunächst vereinbart, nur eines).

These: Wenn man Entwicklungsteams ausreichend kundennah aufstellt, braucht man keine übergeordneten Roadmap-Planungsprozesse mehr. Man kann InnoDays zum regulären Arbeitsmodus machen.

Siehe dazu auch Agile Fluency Modell, 3 Sterne.

Einbindung von Endkunden

Die Ergebnisse der InnoDays hätten noch besser sein können, wenn es eine noch größere Kundennähe gegeben hätte. Das hat sich vor allem dort gezeigt, wo man nicht den Service für existierende Kundengruppen verbessern, sondern neue Kundengruppen („die jungen Leute“) ansprechen wollte.

These: Die Teams sollten direkten und intensiven Kontakt zur anvisierten Zielgruppe haben. Personen der Zielgruppe können temporär oder dauerhaft Teammitglieder sein.

Das ist übrigens keine „neumodische utopische Idee“, sondern ein alter (leider in Vergessenheit geratener) Hut: siehe Participatory Design.

Vernetzung von Ideen

Jede initiale Idee hat wertvolle und vollkommen bescheuerte Anteile. Die wertvollen Anteile müssen herausgearbeitet und die bescheuerten Anteile entfernt werden. Das geht am Effektivsten, wenn Ideen durch mehrere Gehirne gehen. Das einsame Genie ist ein Mythos (siehe Keith Sawyer: „Group Genius“).

These: Ideen müssen durch mehrere Gehirne gehen und miteinander vernetzt werden. Ein frühzeitiges Aussortieren „schlechter“ Ideen ist genauso kontraproduktiv wie ein frühzeitiges Commitment auf „gute“ Ideen.

Man kann hier das Design Thinking-Prinzip „Defer Judgement“ wiedererkennen.

Fazit

Die Otto InnoDays 2016 waren eine coole Veranstaltung. Die Ergebnisse sind wertvoll für Otto. Das Otto uns als Beobachter zuließ, kann uns als Community helfen, noch besser zu werden.

Das Erreichte ist noch nicht das Ende der Fahnenstange. Vielleicht helfen meine Thesen, um aus coolen InnoDays großartige InnoDays zu machen.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

Zuerst wurden die Ideen durch Abstimmung mit den Füßen gefiltert. Bei der Abschluss-Präsentation wurden die Sieger herausgefiltert. Diese gingen in einen Roadmap-Planungsprozess, in dem erneut gefiltert wurde.

Filter 1: Abstimmung mit den Füßen

Zuerst wurden Ideen gesammelt und veröffentlicht. Über diese Ideen wurde dann mit den Füßen abgestimmt: die Ideen, die zu wenig Mitstreiter fanden, wurden nicht durchgeführt (blaue Seite in dem Bild). Am Ende wurden in Summe 18 Projekte ausgewählt und durchgeführt.

Filter 2: Sieger kühren

Die Ergebnisse der ausgewählten 18 Projekte wurden im Plenum vorgestellt und vom Publikum sowie einer Jury in verschiedenen Kategorien bewertet. So blieben in Summe 7 Projekte übrig.

Filter 3: Strategie-Match prüfen

In einer außerplanmäßigen Roadmap-Planungsrunde wurden die verbliebenen 7 Projekte hinsichtlich ihrer „Passung“ zur Otto-Strategie geprüft. Es gab die Zusage, dass ein Projekt umgesetzt wird, falls eins zur Otto-Strategie passt. Letztlich wurden 5 der 7 Projekte zur Umsetzung ausgewählt.

Mehrstufiges Filtern

Der beschriebene Ansatz mit mehrfachem Filtern entspricht dem Stand der Kunst für solche Veranstaltungen, mit einer Besonderheit: bei den meisten Hackathons steht am Ende eine Betonmauer, durch die kein einziges Projekt durchkommt.

Vernetzen statt filtern

Allerdings ist der Ansatz des mehrstufigen Filterns aus meiner Sicht noch nicht optimal. Radikale Ideen sind in ihrer ersten Fassung fast immer Mist.

Dazu kommt mir gerade der Tweet von @_Mea_Culpa zu Pass:

Es gibt wahrscheinlich nichts auf der Welt, dass sich so gekonnt als Schwierigkeit tarnt, wie eine Chance.

Um das Potenzial in ersten Ideen herauszuschälen und zu entwickeln,  müssen die Ideen durch verschiedene Köpfe wandern, dort verändert und mit anderen Ideen kombiniert werden. Dann können wirklich großartige Dinge entstehen. Das Ganze hat übrigens Keith Sawyer sehr ausführlich mit vielen Praxisbeispielen in seinem Buch „Group Genius: The Creative Power of Collaboration“ beschrieben.

Der große Filter-Ansatz verhindert diesen Prozess und tendiert daher dazu, mittelmäßige Ideen Realität werden zu lassen. Das ist schon mal nicht so schlecht, weil immerhin die schlechten Ideen ausgesiebt werden. Es geht aber viel besser: Diverge & Merge ist leistungsfähiger als Diverge & Filter.

Fazit

Natürlich muss man sich irgendwann mal entscheiden, in was man investiert und was man im Moment bleiben lässt. Bei den Otto InnoDays wurden Ideen schrittweise ausgefiltert, so dass am Ende nur eine übrig blieb. Damit wird das Ziel der Reduktion von Optionen effektiv erreicht.

Der Ansatz zollt aber der besonderen Charakteristik von Innovation nicht den notwendigen Respekt. Fast jede radikale Idee ist in ihrer Rohform unbrauchbar. Ideen müssen durch verschiedene Köpfe gehen und mehrfach verändert und von anderen Ideen inspiriert werden. Neben dem Filtern sollte also auch das Vernetzen von Ideen im Prozess verankert werden.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

Projekte nach Innovationsaspekt

Häufig wird bei Innovationen unterschieden zwischen Kundenbedürfnissen, Business-Modell und Technologie (das Modell taucht in so vielen Varianten im Internet auf, das ich nicht sagen kann, woher es ursprünglich kommt). Dazwischen gibt es Schnittmengen. So könnte man eine innovative Technologie benutzen, um ein neues Kundenbedürfnis zu decken oder ein existierendes Kundenbedürfnis auf eine aus Kundensicht völlig neue Art und Weise. Oder man deckt ein existierendes Kundenbedürfnis aus Kundensicht wie bisher und nutzt eine neue Technologie „lediglich“, um das Produkt oder den Service preisgünstiger anbieten zu können. Oder man bleibt im Grunde bei seiner Lösung, hinterlegt sie aber mit einem anderen Business-Modell (man könnte z.B. von einem Abo-Modell auf Werbefinanzierung umsteigen).

Ich habe die 18 Projekte der Otto InnoDays grob in dieses Mengendiagramm abgebildet:

Meine Zuordnung der Projekte zu den einzelnen Innovationsaspekten kann man im Detail sicher diskutieren, am Schwerpunkt dürfte das aber nicht viel ändern: Die meisten Projekte näherten sich über angenommene oder tatsächliche Kundenbedürfnisse und versuchten diese über Erweiterungen der Plattform mit den existierenden Technologien anders oder besser zu befriedigen.

Bei Hackathons in anderen Firmen habe ich mitunter ein gänzlich anderes Bild gesehen, nämlich eines mit dem Schwerpunkt bei Technologie. Wenn man nichts weiter unternimmt, ist das auch ein ganz natürlicher Effekt: Die meisten Entwickler sind Technologie-fokussiert und haben eine ganze Menge cooler neuer Technologien gesehen, die sie gerne mal ausprobieren würden. Das ist nicht per se schlecht. Wenn man allerdings nach unternehmensrelevanter Innovation sucht, ist das meist zu wenig.

Daher finde ich es eine wirklich respektable Leistung der Otto InnoDays 2016, dass die Projekte einen so starken Fokus auf Kundenprobleme hatten.

Neue Produkte, neue Märkte?

Eine weitere häufig benutzte Klassifikation für Innovationen ist die Ansoff Matrix. Auf der X-Achse unterscheidet sie zwischen existierendem und neuem Produkt und auf der Y-Achse zwischen existierendem und neuem Markt (aus Anbietersicht). So erhält man vier Felder: existierendes Produkt im existierenden Markt, neues Produkt im existierenden Markt, existierendes Produkt im neuen Markt, neues Produkt im neuen Markt.

Wenn man neue Features zu einem existierenden Produkt entwickelt, bleibt man in der Regel im existierenden Markt. Diese Art der Innovation ist die Gebräuchlichste. Und auch, wenn es vielleicht erstmal etwas langweilig klingt. Diese Art der Innovation ist essenziell wichtig, um die eigene Marktposition halten und ausbauen zu können. Ansoff spricht von Markt-Penetration.

Man kann auch für den existierenden Markt ein neues Produkt entwickeln. Als Apple Anfing nach dem ersten iPod noch den iPod Mini und den iPod Shuffle zu entwickeln, hat Apple neue Produkte für seinen existierenden Markt der Musik-Player entwickelt. Ansoff spricht hier schlicht von Produktentwicklung.

Man kann auch ein existierendes Produkt in einem neuen Markt platzieren. Das bedeutet häufig einfach, dass man ein existierendes Produkt in neuen Regionen anbietet. Das hat mobile.de getan, als sie die Plattform auch in Italien und Frankreich anboten. Ansoff nennt das Marktentwicklung.

Und nicht zuletzt kann man ein neues Produkt für einen neuen Markt entwickeln. Das klingt am coolsten, ist aber auch am schwierigsten. Apple hat das mit dem iPhone und Tesla mit dem Tesla Roadster und später dem Model S gemacht. Ansoff spricht von Diversifikation.

Ich habe die 18 Projekte der Otto InnoDays grob den vier Quadranten zugeordnet:

Auch hier kann man sicherlich im Detail über die Zuordnung streiten. Aber auch hier gibt es einen klaren Schwerpunkt, nämlich die Verbesserung des existierenden Produktes für den existierenden Markt.

Disruptive Innovation?

Gewünscht waren „disruptive Innovationen“ und „out of the box“-Denken. Meiner Einschätzung nach, ist das allenfalls in Ansätzen gelungen. Ich finde das auch nicht so verwunderlich, weil die genialen disruptiven Ideen nicht einfach so vom Himmel fallen (siehe dazu den nächsten Blogpost in dieser Serie). Es ist ein komplexer chaotischer Prozess dafür notwendig, der i.d.R. länger dauert als die paar Tage, die für die InnoDays zur Verfügung standen.

Wenn man sich die Projekte der InnoDays ansieht, stellt man fest, die meisten sehr gut in die Otto-Strategie passen und die Umsetzung tatsächlich Mehrwert aus Kundensicht schaffen kann.

Da könnte man sich doch glatt die Frage stellen: Braucht man eigentlich den existierenden Roadmap-Prozess, Portfolio-Management etc.? Würde der Otto-Shop wirklich Schaden nehmen, wenn die InnoDays-Arbeitsweise die Standard-Arbeitsweise wäre, die Teams also selbst entscheiden, welche Features / Produkte sie entwickeln?

Das sowas möglich ist, zeigt Valve mit seiner Art der Entwicklung. Und es würde nicht bedeuten, dass die Leute, die sich jetzt um Produktmanagement kümmern, arbeitslos würden. Sie würden vermutlich gleichberechtigte Teammitglieder werden.

Wenn man da angekommen ist, ist das meiner Meinung nach tatsächlich ganz großes agiles Kino (3 Sterne nach dem Agile Fluency Modell).

Tatsächliche Kundenbedürfnisse?

Die Ideen, die in den einzelnen Projekten verfolgt wurden, erschienen mir auf den ersten Blick plausibel. Beim zweiten Hinsehen war ich mir bei einigen Ideen nicht mehr so sicher. Dass eine personalisierte Suche ein großes Potenzial hat, glaube ich sofort.

Es gab aber eine Reihe von Projekten, an denen ich doch zweifle: Anscheinend hätte Otto gerne einen größeren Marktanteil bei den jungen Käufern. Darauf sind ein paar Teams angesprungen. So entwickelte ein Projekt eine Sprachsteuerung, weil die jungen Leute so ihr Handy benutzen. Andere entwickelten einen Telegram-Chatbot, vom dem man sich beraten lassen kann – die jungen Leute chatten ja viel. Das mögen Produktzugänge sein, die bei der jungen Zielgruppe gut ankommen. Aber würden sie deshalb von Zalando zu Otto wechseln? Kann ich mir nicht vorstellen.

Ich vermute, dass Otto hier vor einer Herausforderung steht: Otto ist im eCommerce sehr stark darin, einzelne Features testweise einzubauen und aus dem Nutzungsverhalten zu lernen (A/B-Testing). Das funktioniert super für Markt-Penetration.

Es ist aber wenig hilfreich, wenn eine neue Zielgruppe adressiert werden soll (die nutzt die Plattform bisher ja kaum oder gar nicht). Da muss man den Kontakt zur Zielgruppe anders herstellen – meiner Meinung nach durch intensiven persönlichen Kontakt der Teams mit der Zielgruppe. Meine Empfehlung aus dem letzten Blogpost war, bei den nächsten InnoDays Endkunden zu integrieren. Mit diesem Blogpost kann ich meine Empfehlung konkretisieren: Es sollten die Endkunden sein, die man mit den Innovationen auch erreichen will.

Wie nah man Kunden bei der Entwicklung sein kann, zeigt sehr schön das Nordstrom Innovation Lab Video).

Fazit

Viele Teams haben den Zugang über die Kundenbedürfnisse gesucht. Das ist eine super Leistung. Direkter Kundenkontakt der Teams könnte helfen, die Bedürfnisse noch während der InnoDays mit wenig Aufwand zu validieren.

Die meisten entstandenen Innovationen waren nicht disruptiv. Sie können aber den Weg weisen, wie insgesamt der Produktmanagement-Prozess deutlich vereinfacht und agilisiert werden kann.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

Im Bereich eCommerce sind in den letzten Jahren beachtliche Erfolge erzielt worden: Skaliertes Scrum mit mit einer auf Verticals basierenden System-Architektur stellt die technische Basis bereit, auf der Business Agility (um mal ein Buzz-Word zu benutzen) möglich wird.

Die InnoDays 2016 waren ein weiterer Schritt in Richtung einer auf agilen Werten beruhenden Unternehmenskultur. Bei den InnoDays habe ich erlebt, wo diese Schritte bereits mutig gegangen werden, aber auch wo alte Strukturen immer wieder hervorbrechen.

Silos

In einigen Teams waren klassische Silo-Strukturen deutlich erkennbar. In einer Ecke saßen die Programmierer in einer anderen die Tester und ganz zentral der „Projektleiter“, der die Idee eingebracht hat.

Das zeigte sich auch, als ein Team einen geplanten Interviewtermin absagte, weil der Interviewer nicht da war. In einem agilen Team hätte ich erwartet, dass jemand anderes aus dem Team das Interview durchgeführt hätte.

Ich habe aber auch ganze andere Teams erlebt, in denen wirklich gemeinsam auf Augenhöhe gearbeitet wurde. Die Verwendung von Mob-Programming in einigen Teams war ein gutes Zeichen für diese Art der kooperativen Arbeit.

Ränge

In einigen Teams soll es mehrere Mitglieder aus der Profession „Projektmanager“ gegeben haben, die im Team um die Richtung gestritten haben.

In einem agilen Teams kann es natürlich auch Streit geben. Der Umgang ist allerdings anders als in der traditionellen Welt. In der agilen Welt wird der Konflikt möglichst weit geklärt. Wenn dann noch unterschiedliche Meinungen übrig sind, definiert das Team Experimente, um mehr über das Thema zu lernen und später eine gute Entscheidung treffen zu können.

Hier scheint die „klassische“ Kultur noch durch und zeigt, dass die agilen Werte und Prinzipien noch nicht durchgängig von allen gelebt werden.

Technik vor Nutzen

Es gab für die Teams die Möglichkeit, vor der Präsentation ihre Prototypen einigen potenziellen Nutzern vorzustellen und Feedback zu erhalten. Von dieser Möglichkeit haben nur wenige Teams Gebrauch gemacht. Der Grund war wohl Zeitmangel. Man wollte lieber weiter an der Entwicklung arbeiten als zu dem entwickelten Feedback einzuholen.

Das könnte ein Indiz dafür sein, dass einige Teams sich lieber mit der Technik als mit Kunden beschäftigen. Es könnte aber auch einfach bedeuten, dass die Zeit, die für die Entwicklung zur Verfügung stand doch etwas knapp bemessen war.

Und was ist mit Endkunden?

Das, was meiner Meinung nach den nächsten großen Schritt in die richtige Richtung bringen kann, ist der direkte Kontakt mit Endkunden. Bei den InnoDays 2016 war immerhin die Fachseite eingeladen. Auch wenn diese sich sehr gut mit dem Markt auskennen, sollte man die Fachseite nicht mit den Kunden verwechseln.

Nur im direkten Kundenkontakt können wirklich neue Bedürfnisse identifiziert und Lösungen schnell gegen diese Bedürfnisse validiert werden.

Einige Projekte haben sich daran versucht, junge Menschen auf die Otto-Plattform zu kriegen (z.B. durch Sprachsteuerung und Chat-Roboter). Allerdings frage ich mich, auf welcher Basis das passiert ist. Otto macht sehr oft A/B-Tests für neue Features auf der Plattform. Das nützt aber wenig, wenn die mit dem Feature adressierte Zielgruppe noch gar nicht auf der Plattform unterwegs ist. Dann muss man den direkten Kontakten zu echten Menschen aus der Zielgruppe suchen.

Wenn bei den InnoDays 2016 Endkunden ganz oder teilweise dabei wären, dann könnte das der ganzen Veranstaltung nochmal deutlich mehr Schub verleihen und die Lösungen noch besser machen.

Fazit

Ich habe eine insgesamt umgängliche, offene, engagierte Atmosphäre bei den InnoDays 2016 gespürt. Da hat Otto definitiv große Schritte in die richtige Richtung unternommen. Natürlich sind mehr als 100 Leute keine homogene Masse. Daher verwundert es nicht weiter, dass in einigen Teams bereits stärkere Anzeichen einer agilen Kultur zu sehen waren als in anderen.

Die stärkere Integration von Endkunden hat meiner Meinung nach sehr großes Potenzial – nicht nur bei den Otto InnoDays, sondern bei den meisten Hackathons, die ich gesehen habe.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

Das Ziel der Otto InnoDays war, innovative Ideen zu generieren. Sabrina Hauptman dazu: „Wir wollen Freiräume schaffen und zum Anders-Denken anregen; Out-of-the-box-Denken.“

Rahmenbedingungen

Es gibt eine Mission für eCommerce bei Otto:

Mit unseren OTTO Experten finden wir innovative Ideen, die dem Kunden einen relevanten Nutzen verschaffen.

Dafür entdecken wir Unbekanntes, untersuchen komplexe Probleme und lernen aus Nutzerfeedback.

Wir erschaffen gemeinsam Innovationen für die OTTO E-Commerce Plattform.

Es wurden drei Challenges definiert, die im Rahmen dieser Mission Fokuspunkte setzen sollten:

1. Otto ist da, wo Du bist.
2. Voller Datendrang
3. Reduce to the max

Für jede Challenge sollte es später einen eigenen Challenge-Sieger geben. Tatsächlich haben sie viele Projekte an den Challenges orientiert. So sind Mission und Challenges ein gutes Beispiel dafür, wie Alignment hergestellt werden kann, wenn das Was und Warum klar ist. Dann richten sich selbstorganisierte Systeme automatisch daran aus.

Überblick über den Ablauf

Die Otto InnoDays 2016 verliefen insgesamt über zwei Wochen. Die achttägige Ideenphase sollte inspirieren, Ideen hervorbringen und Ideen für die Umsetzungsphase selektieren. In der dann folgenden dreitägigen Umsetzungsphase wurden die selektierten Ideen von Teams so umgesetzt, dass sie am Ende der Woche präsentiert und bewertet werden konnten. An die Umsetzungsphase schloss sich eine Entscheidungsphase und eine potenzielle zweite (vorwöchtige) Umsetzungsphase an, die allerdings etwas von dem Event InnoDays abgekoppelt waren.

Ideenphase

In der Ideenphase wurden nicht einfach nur Ideen gesammelt. Es wurde auch Wissen vermittelt – z.B. zu Interviewtechniken und Prototyping. Auch die Nicht-Programmierer sollten erkennen, dass sie sinnvoll an der Umsetzung teilnehmen können. So konnten sie z.B. erfahren, dass man bereits viel über eine Idee lernen kann, wenn man „nur“ einen Papier-Prototypen herstellt.

Schließlich wurden die Ideen publiziert und es wurde mit den Füßen abgestimmt. Wer ausreichend viele Mitstreiter für seine Idee finden konnte, konnte diese in der Umsetzungsphase umsetzen. Ideen, für die sich keiner interessierte, wurden nicht weiter umgesetzt.

In dem Foto sieht man alle eingereichten Ideen. Auf der roten Seite (links) finden sich die selektierten Ideen, auf der blauen Seite (rechts) stehen die Ideen, für die sich keine Teams gefunden haben.

Umsetzungsphase I

In der Umsetzungsphase arbeiteten die Teams an ihren Projekten. Den Teams standen für die Arbeit durchaus „startuppige“ Räumlichkeiten bei Otto zur Verfügung:

Soweit ich das überblicken konnten, entwickelten dafür alle Teams lauffähige Software. Viele Teams haben ihren Code sogar direkt in die produktiv laufende Plattform integriert.

Die Ideen wurden am Freitag nachmittag im Planung vorgestellt und durch die Teilnehmer und eine Jury bewertet.

Es gab verschiedene Kategorien, die jeweils eigene Gewinner haben konnten.

Entscheidungsphase

Besonders war, dass mit der Kürung der Gewinner die Geschichte noch nicht zu Ende war. Die Gewinner gingen in einen Recall, in dem bewertet wurde, wie diese zur Otto-Strategie passten. Sollte es einen Match geben, sollte das Projekt zeitnah weitergeführt werden. Dazu war in der Roadmap ein Puffer von 4 Wochen vorgesehen.

Diese Integration in die Roadmap ist im Gegensatz zu anderen Hackathons eine Besonderheit. Das Unternehmen committet sich vorher darauf, auch mind. eine Idee auch weiter zu verfolgen. Dadurch kann effektiv dem Gefühl entgegengewirkt werden, dass die ganze Verstanstaltung am Ende nur „Opium für die Entwickler“ ist, um diese bei Laune zu halten. Otto zeigt mit seinem Ansatz deutlich, dass es um mehr geht: Es sollen tatsächlich innovative Ideen generiert werden, die auch ernsthaft für eine dauerhafte Umsetzung in Betracht gezogen werden.

Umsetzungsphase II

In der Umsetzungsphase II sollte dann im Rahmen der Roadmap 4 Wochen lang an einem der Gewinnerthemen weitergearbeitet werden. Jetzt, wo ich diesen Blogpost schreibe, ist mir nicht bekannt, ob und welches Projekt diese Entwicklungszeit erhalten hat.

Mehr zu den Otto InnoDays 2016

Die weiteren Blogposts in dieser Blogpost-Serie finden sich hier.

Erstmal sieht das alles ganz einfach und plausibel aus. Das Unternehmen möchte innovativer werden (wer möchte das nicht?) und bei vielen Entwicklern gibt es den starken Wunsch, die ganzen neuen Technologien mal auszuprobieren, die „da draußen“ gerade angesagt sind.

Also lässt man der Kreativität der Entwickler mal einen oder zwei Tage lang freien Lauf und guckt mal, was herauskommt. Die Veranstaltungen sind dann auch durchweg cool. Man kann die Energie spüren und die Entwickler haben sehr viel Spaß. Das alleine ist für viele Unternehmen bereits eine große Anstrengung und respektiere den Versuch sehr.

Probleme mit vielen Hackthons

Meist ist es aber eben auch nicht mehr als ein erster Versuch:

• Es gibt keinen definierten Prozess, was mit den Ergebnissen passiert. Es gibt lediglich die diffuse Hoffnung, dass irgendjemand „da oben“ schon die Genialität der Ergebnisse erkennen und dann die Projekte in die Roadmap aufnehmen wird. Passiert aber nicht.
• Die Ergebnisse sind meist extrem technisch (wer wollte nicht schon immer mal einen Hadoop-Cluster aufsetzen oder Docker in Docker laufen lassen?) und der Mehrwert für das Unternehmen bleibt unklar. Auch daher verwundert es mich nicht wirklich, dass niemand die Ergebnisse zu echten Projekten macht.
• Radikale erste Ideen sind so gut wie immer Mist. So werden dadurch zu guten oder sogar großartigen Ideen, dass sie über einen längeren Zeitraum durch verschiedene Köpfe gehen und mit anderen Ideen kombiniert werden (siehe [Sawyer2008]). Das leisten die Hackathons, die ich gesehen habe, kaum oder gar nicht.

So sind viele Hackathons nicht viel mehr als ein Strohfeuer, als kurz aufflammt, aber letztlich keine Wirkung hat. Es kann sogar zu Frustration führen, wenn die Teilnehmer diese Wirkungslosigkeit erkennen.

Siehe zu dem Thema auch meinen Blogpost zum Konzept der Slack-Time, in dessen Kommentaren Markus Andrezak das Konzept als „Opium für die Massen“ bezeichnet hat. Das trifft auch auf so manchen Hackathon zu: Tut er mehr, als die Entwickler zu beruhigen?

Otto InnoDays

Sicherlich ist es bereits eine bemerkenswerte Leistung, wenn ein Konzern wie Otto einen Hackathon wie oben beschrieben umsetzt und damit zeigt, dass sowas nicht den neuen hippen Internet-Unternehmen vorbehalten ist.

Trotzdem blieb für mich die Frage, was ich dabei lernen könnte.

Die ersten Otto InnoDays fanden 2015 statt – damals nur mit den internen Mitarbeitern der Entwicklung. 2016 wurden die InnoDays geöffnet für externe Mitarbeiter und für die Fachabteilungen. Das hört sich schon mal ganz gut an, weil es die Chance bot, aus dem reinen Techno-Fokus herauszukommen. Außerdem waren die Otto InnoDays 2016 sehr groß angelegt – mit einem Prozess, der letztlich zwei Wochen lang lief. Und die Organisation machte auch nicht irgendjemand „mal nebenbei“. Stattdessen stellte Otto nennenswert Kapazitäten für die Vorbereitung und durch Begleitung bereit. Die schienen es wirklich ernst zu meinen.

Damit waren meine Zweifel noch nicht ausgeräumt. Aber die Neugier begann zu überwiegen und so sagte ich zu.

Ziele und Ablauf der InnoDays 2016

Details… (folgen noch)

Otto InnoDays 2016: die ganze Geschichte

Dieser Blogpost ist ein Artikel in einer Blogpost-Serie.

Überblick über die ganze Blogpost-Serie…

Referenzen

• [Sawyer2008] Keith Sawyer: „Group Genius: The Creative Power of Collaboration“

Dieser Blogpost ist der Auftakt einer kleinen Blogpost-Serie zu dem Thema. Ich habe mit Otto vereinbart, dass ich hier keine Lobhudelei betreibe und offen alles beschreiben darf. Ich darf insbesondere auch das benennen, was in meinen Augen besser gemacht werden kann (lediglich persönliche Beleidigungen darf ich hier nicht veröffentlichen – will ich auch gar nicht :-). Und mir ist Einiges aufgefallen, was besser gemacht werden kann. Das sollte aber nicht den Blick auf das trüben, was schon erreicht wurde. Im Vergleich mit ähnlichen Veranstaltungen in anderen Firmen waren die Otto InnoDays 2016 auf jeden Fall ganz vorne mit dabei. Und wenn ich dann bedenke, dass Otto ein Konzern mit über 4.000 Mitarbeitern und kein eBusiness-Unternehmen mit nur 200 Mitarbeitern ist, ziehe ich meinen Hut. Von den Otto InnoDays 2016 können sich viele vermeintlich agilere Unternehmen eine große Scheibe abschneiden.

Ich plane, in den nächsten Wochen die folgenden Themen in dieser Blogpost-Serie zu behandeln:

Teil 1: Warum ich zuerst skeptisch war und dann doch teilgenommen habe.

Als Otto in Person von Sabrina Hauptman mich fragte, ob ich teilnehmen wollte, war ich mir unsicher, wieviel mir das wirklich bringt. Schließlich hatte ich schon ähnliche Veranstaltungen besucht: Hackathon, FedEx Day und wie sie alle heißen. Was sollte hier jetzt so besonders interessant sein – außer dass das Format jetzt auch von Konzernen praktiziert wird?

Details…

Teil 2: Die Ziele und der Ablauf

Die InnoDays sollten zum Querdenken anregen und auch Platz für disruptive Ideen bieten. Die InnoDays erstreckten sich insgesamt über zwei Wochen. Es begann mit einer Aufwärmphase, gefolgt von der Ideengenerierung. Die Ideen wurden dann gefiltert (Abstimmung mit den Füßen) und die selektierten Ideen prototypisch umgesetzt. Die Ergebnisse wurden zum Abschluss vorgestellt und von einer Jury bewertet. Außerdem gibt es einen definierten Prozess, wie die „Sieger“ in den Roadmap-Planungsprozess eingespielt werden.

Details…

Teil 3: Der Kulturwandel

Der Otto-Konzern will sich modernisieren und fit für das digitale Zeitalter werden. Dazu sind im Bereich eCommerce in den letzten Jahren beachtliche Erfolge erzielt werden. Skaliertes Scrum mit mit einer auf Verticals basierenden System-Architektur stellt die technische Basis bereit, auf der Business Agility (um mal ein Buzz-Word zu benutzen) möglich wird.

Die InnoDays sind ein weiterer Schritt in Richtung einer auf agilen Werten beruhenden Unternehmenskultur. Bei den InnoDays habe ich erlebt, wo diese Schritte bereits mutig gegangen werden, aber auch wo alte Strukturen immer wieder hervorbrechen.

Details…

Teil 4: Die Projekte

Es wurden insgesamt 18 Projekte durchgeführt. Ich habe mir diese inhaltlich angesehen und nach verschiedenen Kriterien klassifiziert. Wieviele disruptive Ideen waren bei den Projekten wirklich dabei? Wieviele Projekte basierten auf spinnerten Ideen, die sich am Ende nicht umsetzen lassen würden? Welche Projekte sprechen neue Zielgruppen an und welche optimieren „nur“ den existierenden Service für die existierenden Kunden? Und woran liegt es, dass es so gekommen ist, wie es gekommen ist?

Details…

Teil 5: Die großen Filter

Bei den InnoDays wurden Ideen bzw. Projekte mehrfach gefiltert. Zuerst wurden die Ideen durch Abstimmung mit den Füßen gefiltert. Bei der Abschluss-Präsentation wurden die Sieger herausgefiltert. Diese gehen in einen Roadmap-Planungsprozess, in dem erneut gefiltert wird.

Dieses Vorgehen entspricht dem Stand der Kunst für solche Veranstaltungen. Allerdings ist der Ansatz aus meiner Sicht noch nicht optimal. Radikale Ideen sind in ihrer ersten Fassung fast immer Mist. Sie müssen durch verschiedene Köpfe wandern, dort verändert und mit anderen Ideen kombiniert werden. Dann können wirklich großartige Dinge entstehen. Der große Filter-Ansatz verhindert diesen Prozess und tendiert daher dazu, mittelmäßige Ideen Realität werden zu lassen. Das ist schon mal nicht so schlecht, weil immerhin die schlechten Ideen ausgesiebt werden. Es geht aber viel besser: Diverge & Merge ist leistungsfähiger als Diverge & Filter.

Details…

Teil 6: Ein paar Thesen

Aus den InnoDays können Otto und andere Unternehmen viel lernen – auch über die internen Prozesse und Strukturen. Ich habe dazu ein paar Thesen zusammengeschrieben. Vielleicht helfen diese, in der Zukumft noch bessere InnoDays zu gestalten.

Details…

Teil 7: Zusammenfassung

Think, Create, Learn: das war das Motto das Otto InnoDays 2016. Wie stellt sich die ganze Veranstaltung rückblickend vor dem Hintergrund dieses Mottos dar?

Details…

Führung muss sich der Arbeitsorganisation unterordnen

Werfen wir zunächst einen Blick auf das klassische Modell von Führung: Das Unternehmen ist in funktionsorientierte Abteilungen (z.B. Marketing, Vertrieb, Entwicklung, Qualitätssicherung) zergliedert. Wenn die Abteilungen ausreichend groß sind, sind sie nochmal in Gruppen oder „Teams“ organisiert. Entlang dieser Zergliederung findet die disziplinarische und  fachliche Führung statt. Die Abteilungsleiter führen die Gruppenleiter, die Gruppenleiter führen ihre Mitarbeiter. Diese Form der disziplinarischen Führung passt zu dem klassischen Paradigma, Arbeit zu organisieren (Teile und Herrsche kombiniert mit funktionaler Zergliederung).

Die agile Welt folgt einem anderen Paradigma, Arbeit zu organisieren: Interdisziplinäre Teams vereinigen die Skills, die notwendig sind, um Wert aus Kundensicht zu schaffen. Es ist kaum zu erwarten, dass für diese andere Art der Arbeitsorganisation der klassische Ansatz disziplinarischer Führung funktionieren kann. Die Organisation disziplinarischer Führung muss sich der Arbeitsorganisation unterordnen. Dauerhaft kommt man bei flächendeckender agiler Entwicklung nicht um eine Reorganisation der disziplinarischen Führung herum kommen.

Funktionen von Führung können verteilt werden

Für eine Reorganisation disziplinarischer Führung müssen wir uns gedanklich von einem weiteren klassischen Dogma lösen, nämlich dass alle Funktionen disziplinarischer Führung bei einer Person liegen müssen. Dazu lohnt es sich, eine Liste mit den Funktionen zu machen, die heute im Unternehmen unter Führung verstanden werden. Dabei kommen typischerweise Dinge wie die folgenden heraus:

• Sicherstellen, dass die Mitarbeiter das Richtige tun.
• Sicherstellen, dass die Mitarbeiter effizient arbeiten.
• Arbeitsmittel bereitstellen.
• Für die Weiterentwicklung der Mitarbeiter sorgen.
• Urlaubsanträge unterzeichnen.
• Mitarbeiter einstellen.
• Mitarbeiter entlassen.
• Leistung von Mitarbeitern beurteilen.
• Gehälter festlegen.
• Für Mitarbeiterzufriedenheit sorgen.
• Unter- und Überlastung von Mitarbeitern verhindern.
• Fürsorge (z.B. Burnouts verhindern)
• Eskalationsinstanz
• etc.

Warum sollte so eine lange Liste von Funktionen unbedingt in einer Person gebündelt werden? Mitunter wird eingeworfen, dass es „so schön einfach“ wäre. Das ist definitiv der Fall, aber es ist das falsche Kriterium. Es geht nicht darum, ob etwas einfach im Organigramm aussieht, sondern darum, ob es wirksam ist. In einer agilen Welt ist die Bündelung der o.g. Funktionen in einer Vorgesetzten-Position nicht besonders wirksam.

Führungsfunktionen in Scrum

Mit dieser Idee der Funktionsverteilung kann man jetzt flexibel entscheiden, wo welche Funktionen von Führung liegen. Ein paar Dinge klärt Scrum bereits:

• Der Product Owner sorgt dafür, dass die Entwickler das Richtige tun (durch Priorisierung des Product Backlogs).
• Das Entwicklungsteam entscheidet darüber, wie die Arbeit konkret organisiert wird.
• Der Scrum Master sorgt dafür, dass das Team effizient arbeiten kann (z.B. durch Hindernisbeseitigung).
• Das Entwicklungsteam sorgt zusammen mit dem Scrum Master dafür, dass bei der Arbeit weder Unter- noch Überlast entstehen.

Und der Rest?

Damit bleiben eine Reihe von Führungsfunktionen zunächst ungeklärt, z.B. die langfristige Weiterentwicklung von Mitarbeitern, Einstellungen, Entlassungen und Gehaltsfestlegungen. Hier findet sich häufig die Auffassung, dass die Weiterentwicklung von Mitarbeitern und die Gehaltsfestlegung an derselben Stelle liegen sollte. Das ist aber gar nicht notwendig und häufig sogar problematisch. Es ist problematisch, weil für die persönliche Weiterentwicklung des Mitarbeiters offen über seine Schwächen und Fehler gesprochen werden muss. Wenn gleichzeitig über eine Gehaltserhöhung entschieden wird, wird der Mitarbeiter nicht besonders offen bzgl. vermeintlicher Schwächen sein. Und es ist nicht notwendig, weil eine erfolgreiche Weiterentwicklung Auswirkungen auf die Wirksamkeit des Mitarbeiters haben sollte und die Wirksamkeit sollte schließlich entscheidend sein, wenn es um Gehaltserhöhungen geht.

Dinge, die ich in der Praxis gesehen habe für die Führungsfunktionen, die per Scrum nicht fest verortet sind:

• Über den Urlaub entscheidet das Team selbst. (Und achtet dabei darauf, bestimmte Constraints einzuhalten, z.B. Verfügbarkeit von Support für die produktive Software).
• Über Einstellungen entscheidet das Team.
• Bei Einstellungen redet das Team auf Augenhöhe mit.
• Teams entscheiden darüber, ob Teammitglieder das Team verlassen müssen. Diese setzen sich dann auf die Ersatzbank und sind für andere Teams verfügbar.
• Die langfristige Weiterentwicklung der Teammitglieder liegt beim Scrum Master.
• Die langfristige Weiterentwicklung der Teammitglieder liegt im Team.
• Die langfristige Weiterentwicklung der Teammitglieder liegt in selbstselektierten Peer-Groups.
• Der Scrum Master verantwortet die Mitarbeiterzufriedenheit.
• Ein Feelgood-Manager verantwortet die Mitarbeiterzufriedenheit.
• Das Team verantwortet die Mitarbeiterzufriedenheit.
• etc.

Es gibt also nicht die eine richtige Art und Weise, Führung zu organisieren. Man wird mit verschiedenen Ansätzen experimentieren müssen, um die Form zu finden, die für das eigene Unternehmen passt. Und man wird sich darauf einstellen müssen, dass auch Mitarbeiterführung einem kontinuierlichen Verbesserungsprozess unterliegt.

Mit diesem Ansatz, Führungsfunktionen zu verteilen, wird übrigens jedes klassische hierarchische Organigramm vollkommen nutzlos.

Fixed salaries

We have fixed salary levels (roughly 9% difference from level to level).

Transparent salaries

These salary levels are transparent within it-agile and everybody at it-agile knows who is at which salary level.

No positions

We have no fixed positions at it-agile, just roles. Therefore the salary is not bound to a position. In principle everybody could „climb“ to the highest salary level.

Setting the salary level

We experiment a lot with the process to find the appropriate salary level for the it-agile people. What we have done (and dismissed) in the past:

• The CEO sets the salary of each colleague (except himself).
• A group of senior people set the salary of each colleague.
• The peergroup (a self selected group responsible for the personal development of a colleague) sets the salary of the colleague.
• The salary set is set by some kind of crowd voting.

The current state is: A group called „salary checkers“ (Gehaltschecker) that is elected by the it-agile colleagues sets the salaries of the colleagues and owns the process of finding the salary. Whenever a colleague want’s to get to the next salary level he is obligated to consult colleagues about his request. He has to select also critics for the consultation. When the colleague thinks the request is justified (based on the feedback he got during the consultation) he approaches the salary checkers with his request. The salary checkers check if the consultation was done properly and the feedback justifies the next salary level. If this is the case he is „promoted“.

We don’t have fixed criteria to determine the salary level. It’s more about: Where do I stand related to the colleagues below my salary level, to the colleagues at my current salary level und to the colleagues at the next higher salary level.

And the salary checkers still improve the process.

The book „The Alchemy of Growth“ (Merhdad Baghai, Stephen Coley, David White) describes the 3 Horizons model that differentiates three levels of innovation and growth.

1. Horizon 1 is about the core business where the company make its main money. In horizon 1 you won’t do very risky things but innovation is still necessary to optimize the product/service and get ahead of the competition (or to stay ahead of the competition).
2. Horizon 2 is about the upcoming future business. In horizon 2 companies develop the business models and products/services that should make essential money in 2 to 4 years.
3. Horizon 3 is about the vague ideas with an unclear future. These are the startup-like ideas and statistically 9 out of 10 ideas won’t make it into relevant products/services.

Every horizon has to be managed differently and needs different optimization criteria (like KPIs), types of people, processes and structures.

Horizon 1

The purpose of the products/services on horizon 1 is not only to pay the salaries and make money for the shareholders but also to finance horizon 2 and 3. The products/services of horizon 1 need a compromise of stability and innovation for optimization. The goal of the optimization is to ensure (or even improve) the market position. The successful products/services need to be improved (and often cost reduction is an important part of this improvement).

The products/services and the market in horizon 1 are well understood and relatively stable. Therefore it is possible to calculate business cases for innovations. Every innovation should have a short payback period and the payback forecast will often match the reality.

Horizon 2

The purpose of horizon 2 is to develop the products/services that will move to horizon 1 in a few years. The innovations of horizon 2 often need new organizational structures and processes. The business model is not yet validated and relevant users needs are still unknown. Therefore detailed long term planning doesn’t make much sense. A rough sketch of the key features and best guess for budget and time (e.g. one team with 8 developers for 6 months) are as accurate as it can get. The details are figured out during the development with short feedback cycles and intense market/customer contact.

For the products/services in horizon 2 there is a high confidence that they will be successful in the market. Therefore minimizing time-to-market is essential. The team should work full time on the product/service and must not be restrained be bureaucratic stage gate processes.

When horizon 1 and 2 are mixed, conflicts will arise and most times horizon 1 wins (since it makes the money). But also in an environment where horizon 2 is isolated from horizon 1 conflicts will occur, when horizon 2 products/services are developed and move to horizon 1. Therefore horizon 1 innovations need a powerful driver (e.g. CEO).

Example: Steve Jobs drove the first iPhone and then the iPad development.

Horizon 3

The purpose of horizon 3 is to obtain and secure options and validate business ideas. In horizon 3 most of the bad ideas should be eliminated and most of the options won’t be exercised.

MVPs, (Minimum Viable Products), prototypes and mockups are king. Often there is no real product development necessary in horizon 3. Within horizon 3 we need to accept that most of our attempts will fail. We need to embrace failure and need to minimize learning cycles.

Product Ownership

Every horizon needs another type of product ownership. According to the three types of product owners Eric may serve horizon 3 best, Jeff may be necessary to drive a horizon 2 innovation and Marty may be best suited for horizon 1 innovations.

When we defined the SCaLeD principles we knew that practices would be needed and that we didn’t want to define another blueprint. So we accepted the gap for the moment.

Later I did a CSM class together with Peter Beck where the participants collected scaling practices. While the participants brainstormed we thought about how to structure the results and came up with the Agile Scaling Cycle (the name came into being during a presentation about scaling I did some weeks later).

The Agile Scaling Cycle is a simple three step cycle. It starts with „reduce dependencies“. Autonomous teams are a cornerstone of agile. Therefore we reduce dependencies between teams as much as possible.

Then we start to work and in the second step of the Agile Scaling Cycle the teams have to coordinate the remaining dependencies.

During the work problems (often pointing at organizational dysfunctions) will occur. These feed the third step of the Agile Scaling Cycle: develop the organization. After that we should have more options to reduce dependencies so we start over again with the first step „reduce dependencies“.

We have gathered lots of practices for reducing dependencies during the last decade:

And we gathered lots of coordination practices as well:

For developing the organization we often work with a transition team:

1. During Sprint Planning identify the features that need contributions from several teams during the upcoming Sprint (e.g. with a dependency matrix).
2. Focus the Scrum of Scrums meeting around these dependencies. (And dismiss the Scrum of Scrums if there are no relevant dependencies – which is actually a good thing.)
3. Let the teams with dependencies send one or two delegates to the Scrum of Scrums. The delegates are developers – not the Product Owners and not the Scrum Masters. Delegates may be the same during the Sprint or teams may choose to rotate the delegates.
4. Find an appropriate periodicity for the Scrum of Scrums. Sometimes a daily Scrum of Scrums is what the teams need, sometimes one or two Scrum of Scrums per week are sufficient. The teams should decide during the Sprint Planning.
5. Timebox the Scrum of Scrums to 15 minutes if it is done on a daily base (weekly Scrum of Scrums may have longer timeboxes).
6. Visualize the state of the features with dependencies during the Scrum of Scrums (e.g. with a dependency matrix).
7. Let one of the team Scrum Masters moderate the Scrum of Scrums.
8. Discuss three questions (similar to the one used in the Daily Scrum):
   1. What did my team achieve since the last Scrum of Scrums regarding the features with dependencies?
   2. What impediments occurred in my team regarding the features with dependencies?
   3. What do the teams plan to do until the next Scrum of Scrums regarding the features with dependencies?

Also consider alternatives to the central Scrum of Scrums meeting, e.g.:

• Teams may visit the regular Daily Scrums of other teams if they have a dependency.
• Teams may visit each other on demand. This is especially suitable in open office settings that encourage communication and cooperation between teams.
• Teams may form task forces for the features with dependencies. Scrum of Scrums may be established per task force. Over the time of several Sprints patterns regarding the task force members may become visible. These are often good starting points for reorganizing team structures to improve team autonomy.
• The ideal of the Scrum team is the autonomous team without dependencies. Although a dependency free situation won’t be achievable we strive for reducing dependencies. If we are successful the teams don’t need any coordination meetings during the Sprint.

Let’s start with the Agile Scaling Cycle: We start with reducing dependencies between teams and with the outside context. Then we do some work and need to coordinate the remaining dependencies. During this work we generate insights and detect organizational impediments. These direct us during the further development of the company. The evolved structures and processes of the company give us additional options for reducing dependencies and we start a new loop through the Agile Scaling Cycle. The whole cycle is driven by the agile scaling principles (which are just the agile/lean principles reformulated for scaling; see http://scaledprinciples.org).

The trick here is to reduce dependencies to the point where coordination becomes dead simple. When we went through the Agile Scaling Cycle several times the company should be more mature, teams should be less dependent and in consequence we need very few coordination practices. Therefore the first formula to compute the scaling maturity on a scale from 0 to 10 (the higher the score more mature) could be:

ScalingMaturityLevel = 10/NumberOfCoordinationPractices

Of course some coordination practices are more agile than others. A dependency matrix is less agile than a shared Sprint Review. So we could weight the practices by the additional weight they put on the process. But that would be another blogpost and in the end I’m not convinced that maturity models are valuable.

In a recent Twitter conversation around that theme Dave Snowden wrote, „if you don’t know why it worked you end up being fooled.“ That statement helped me to understand my gut feeling better.

I think the really important part of „Use what works, ditch the rest!“ is your definition of „works“. Let’s be more precise: Scrum wasn’t made to „work“ in your environment. It is designed to make the organizational dysfunctions visible, so that you can remove them. In that way you shouldn’t expect Scrum to „work“. And if you ditch Scrum since it doesn’t „work“, you ditch an opportunity to evolve the company.

Sidenote: It doesn’t matter if you use Kanban instead of Scrum. Slack time generated by WiP limits doesn’t „work“ in most companies either.

Don’t get me wrong: I do not propose cargo-cult dogmatism. In alignment with Dave Snowden you should have experienced agile practitioners on board who know why Scrum and Kanban are designed the way they are and help you understand why something does or doesn’t work in your context. Then you really learn and get the opportunity to improve.

In conclusion the „Use what works, ditch the rest!“ is OK for me, when the definition of „works“ is that our problems become visible so that we can attack them.

I think the misconception of the employees is caused by a communication fail. As George Bernard Shaw said:

The single biggest problem in communication is the illusion that it has taken place.

The managers know why they want Scrum and normally they even have communicated it:

• once
• in an email
• hidden between a lot of other stuff

And that is just not enough to make a real change happen. Even if employees have read the message there is a lot of doubt:

• Does the manager really know what Scrum is?
• Would he really do what is necessary?
• Was the message just ad-hoc and now there is another most-important thing?

Therefore managers should

• communicate the intended change (together with the „why“) personally and face-2-face
• renew the message continuously
• model the wanted behavior themselves

Scaled Agile Framework (SAFe)

Das Methodenframework SAFe von Dean Leffingwell erfährt im Moment viel Beachtung und ist höchst umstritten:

• Video, das SAFe in 7 Minuten erklärt: http://www.agilerescue.de/safe-in-7-min/ (Anmerkung von mir: Das, was in dem Video als „Scrum“ beschrieben ist, deckt sich in relevanten Teilen nicht mit dem, was ich als „Scrum“ kenne.)
• Webseite: http://scaledagileframework.com
• Kritik von Ken Schwaber: Der Scrum-Erfinder argumentiert ähnlich wie Jutta und weist darauf hin, dass man – wenn man sich für SAFe entscheidet, sehr genau die business-relevanten Fortschritte überwachen sollte, die man sich von Agilität verspricht.
• Kritik von David Anderson: Der Software-Kanban-Erfinder sagt, dass SAFe bereit seit langem bekannte Praktiken anderer Autoren zusammengestellt hat und dass durch diese methodenhafte Zusammenstellung das genaue Gegenteil von dem gemacht wird, wofür Kanban steht: schrittweise Verbesserung. David meint, dass schrittweise Verbesserung a la Kanban besser in die aktuelle Zeit passt.
• Kritik von Jutta Eckstein: Jutta argumentiert, dass Agilität ein Kulturwandel bedeutet und dass SAFe zu prozesslastig sei, um diesen Wandel zu unterstützen.
• Ron Jeffries: SAFe – Good But Not Good Enough
• Ron Jeffries: Issues with SAFe
• Dave Snowden: SAFe – the infantilism of management
• Chris Matts: SAFe vs. Theory of Constraints
• Daniel Gullo: SAFe SPC Training: A Reflection
• Tobias Mayer meinte auf Twitter über SAFe: „Decent way of managing dependencies across teams. It misses the better question though: how do we not have dependencies.“
• Ilja Preuss auf Twitter: „I always had the hunch that SAFe is for those who want to „do agile“ without having to give up waterfall…“
• Peter Stevens hat SAFe mit anderen Ansätzen wie DAD und LeSS verglichen.
• Sallyann Freudenberg: A retrospective on using the Scaled Agile Framework at Travis Perkins

Die deutschsprachigen SAFe-Protagonisten, mit denen ich selbst gesprochen haben, stimmen der o.g. Kritik interessanterweise im Wesentlichen zu. Sie argumentieren aber, dass SAFe trotzdem ein erster Schritt hin zu ein ganz klein wenig mehr Agilität sein kann, dass man SAFe sowieso nicht so implementieren würde, wie es beschrieben ist und dass man direkt nach der Implementierung damit anfangen müsste, es sofort zu ändern (überspitzt: wieder zu demontieren).

Ein SAFe-Trainer meinte, er sähe die größte Gefahr von SAFe darin, dass viele SAFe-Trainer und Coaches Agilität nicht verstanden hätten und daher keinen sinnvollen Einsatz von SAFe sicherstellen könnten. Wer sich tatsächlich für SAFe entscheidet, sollte also viel Aufwand darin stecken, den agilen Erfahrungshintergrund der Trainer/Coaches intensiv zu durchleuchten (das gilt natürlich generell für die Auswahl von Coaches/Trainern). (Vielleicht sollte man sogar prinzipiell immer jemanden mit an Board holen, der SAFe für Unsinn hält

Disziplined Agile Delivery (DAD)

DAD von Scott Ambler hat lange nicht die Aufmerksamkeit wie SAFe erreicht. Das erklärt vielleicht auch, warum es deutlich weniger Kritik dazu gibt.

• Webseite: http://disciplinedagileconsortium.org
• Peter Stevens hat DAD mit SAFe und LeSS verglichen.

Large Scale Scrum (LeSS)

LeSS von Craig Larman und Bas Vodde ist eigentlich gar keine echte eigene Methode, weil schlicht das Scrum-Framework für die Skalierung interpretiert wird.

• Einführungsartikel
• Peter Stevens hat LeSS mit SAFe und DAD verglichen.

Agility Path

Agility Path von scrum.org liefert im Gegensatz zu SAFe, DAD und LeSS keine Struktur für skalierte Agilität, sondern definiert den Prozess, wie man zu dieser Struktur kommt. Ähnlich wie SAFe und DAD ist es direkt kommerzialisiert.

• Webseite: http://www.agility-path.com

Auch bei Agility Path könnte man diagnostizieren „im Westen nichts Neues“. Das, was Agility Path ausmacht, haben Ken Schwaber und andere agile Praktiker schon vor Jahren beschrieben. Man begleitet die Einführung und Ausbreitung von agil kontinuierlich und setzt dafür ebenfalls Inspect&Adapt ein (häufig bildet man ein Transitionsteam dafür).

Enterprise Transition Framework (ETF)

Das ETF von Agile42 scheint mir im Grunde fast identisch mit Agility Path zu sein. Vielleicht ist einer der Gründe für die Existenz, dass Agile42 die Scrum-Zertifizierungen der Scrum Alliance anbietet und ein Gegenpol zu Agility Path von der Konkurrenz-Zertifizierungsorganisation scrum.org schaffen wollte.

• Webseite: http://www.agile42.com/en/agile-transition/etf/

We don’t need no new methods

Und dann gibt es noch die Gruppe derjenigen, die meinen, dass man für agile Skalierung keine neuen Methoden braucht und schon gar keine mit Trademarks. Die Prinzipien, die wir für die agile Skalierung brauchen, kennen wir bereits seit Jahren. Die Praktiken für die Skalierung sollten schrittweise passend zum Unternehmen gefunden werden. Inspirieren sollte man sich bei der Suche nach geeigneten Praktiken von der Praxis (z.B. bei anderen Unternehmen) und nicht von Methoden. (Dieser Gruppe gehöre ich selbst an).

• Webseite mit Skalierungsprinzipien: http://scaledprinciples.org
• it-agile dazu: http://www.it-agile.de/agile-skalierung
• Scrum Sense dazu (inkl. Vergleich mit SAFe, DAD, LeSS): http://www.scrumsense.com/blog/scaling-scrum-organisation
• Skalierungsprinzipien von Arlo Belshee
• Skalierung bei Spotify
• Skalierung bei Nielsen Media Research
• Skalierung bei Jimdo
• Skalierung bei Wooga

Was fehlt?

Wenn Ihr noch Ressourcen kennt, die das Bild vervollständigen, hinterlasst mir einen Kommentar zu diesem Artikel. Ich werde den Artikel dann ergänzen.

At it-agile each employee (with some minor exceptions due to probation period) is a shareholder with the same shares. These sum up to more than 60% of the company. The result is a special power cycle: The CEOs have formal power over the employees (and may lay off people). On the other hand the employees may instruct the CEOs or even replace them with somebody else. This setting forced us to search for appropriate decision mechanisms. On our quest we tried several approaches. An obvious one is democratic decision. Funny enough this worked fine for a while but it turned out that it didn’t scale for us when we exceeded an employee number of 15 to 20 (now we are 30 something). This blog post describes the current way we decide at it-agile.

Current State

When it comes to decisions, I think we value some principles:

• The decision mechanism should be appropriate (especially regarding impact for other employees and reversibility) for the decision at hand.
• Consensus is nice but often not necessary (it is often too costly to create consensus with 30 people) but it is important to have a high commitment of the employees on the decision.
• Decisions should be reversible (there are very few exceptions where it is not feasible or possible to ensure reversibility).
• Therefore wrong decisions aren’t that bad. We may learn that the decision was wrong or suboptimal and then create a better decision soon.
• Decision making should be decentralized.
• Relevant perspectives should be respected when making a decision.

Currently we use these decision mechanisms:

• When a decision impacts only you, you may decide yourself directly. (For example we have very few very simple guidelines (“simple rules”) for travel expenses and you are empowered to decide for yourself according to these guidelines – and you publish the travel expenses for your colleagues).
• When a decision impacts only your team, you may decide with your team. Here you should use the decision mechanism that is established within your team (often teams use Konsent).
• When a decision impacts other colleagues we try Konsent (with thumb voting). When we are not able to make a decision within 10 minutes we choose a “decider” who has to consult his colleagues and then decides (consultative individual decision, in german it is called “konsultativer Einzelentscheid”). For choosing a decider we ask for proposals and rationale. If there are several proposals for the same decision we choose in Konsent. It turned out that choosing the decider that way is fast and effective for us.

Consultative Individual Decisions

The consultative individual decision making process has these steps:

1. Identify a needed decision and choose an appropriate decider with Konsent.
2. The decider consults an appropriate set of people (within and/or outside his team/company).
3. The decider decides based on the perspectives he gathered.
4. The decision is published within the company (at it-agile the decider publishes whom he consulted, which perspectives were relevant and what his decision is).
5. All other colleagues accept the decision and practice forgiveness.
6. We all together learn from this decision making process and improve for the next decision.

At the moment we identify necessary decisions and appropriate deciders during our monthly Company Sprint switchovers. When it becomes clear that a decision is needed and we are not able to decide as a group (of 30 people) within a few minutes we select a decider. The decider then has a timebox until the next Sprint turnover to decide. We add a task to the Company Task Board so that we remember to review the decision.

How we got here

In our nine years history we tried nearly every decision-making mechanism we could find. In the beginning a lot of the decisions were made by the CEO. Since we wanted to be a participative company we tried to move more and more decisions to the employees. That worked fine in the beginning. People started to decide for themselves. Bigger issues were discussed and decisions were made with majority decisions at our company tuning days.

When we grew beyond 20-25 people the discussions and decisions at the tuning days became more and more dull and slow. We invested a lot of time and energy and often didn’t come to consensus. We tried majority decisions. Still we had a lot of time-consuming discussions and when the decision had only a narrow majority we slipped into a bad mood. The narrow majority didn’t want to force something onto a big minority. And when we had a narrow majority decision the large minority questioned the decision shortly after the decision again and again.

We knew how to apply Konsent (see http://en.wikipedia.org/wiki/Consent) for a smaller number of people (team size). But we haven’t found out until now how to run it efficiently with 30 people.

We had a decision crisis for months and since we didn’t know any other alternative we switched back to central CEO decisions for important aspects. That allowed us to make decisions again but still wasn’t what we were aiming for: a participative company.

And then we had a workshop with Niels Pfläging where he explained the Beta Codex model. We recognized that we followed the Beta Codex principles without knowing it but that our central decision model didn’t fit into the picture. After discussing the problem with Niels he proposed Consultative Individual Decisions. At first the concept sounded a bit weird. Would we empower an arbitrary employee to decide about an investment of 100.000 EUR? But since we already had a history of doing weird things (like introducing teams without having a clue how that concept could be applied in a coaching context like ours) we decided to give it a try.

We designed an experiment with 4 decisions: three of the decisions were proposed by the CEOs and one was added by the employees during the Sprint switchover where we started the experiment. We formulated our thesis (“consultative individual decisions” increase the number of options heard before deciding and increase the commitment on decisions) and set a timebox (due to Christmas and New Year we set it to two months).

After the two months we reviewed the decisions at the company Sprint turnover. Three decisions were made. One decision wasn’t made. We had learned that the decision was too big and the time was too early. We then decided to delay the decision for 2 months (when we would know more about the topic). And we learned that it is valid if a decider makes a decision that doesn’t match exactly his mission.

Our evaluation showed that the overwhelming majority of people thought that consultative individual decisions lead to an increased number of options heard and higher commitment. Some people thought the quality was as before and nobody thought it was worse than before. Consequently we added consultative individual decisions to our repertoire of decision-making mechanisms. And we applied it immediately:

We had a CEO decision that we would only hire employees living in Hamburg (to increase personal contact between employees). During the retrospective of the Company Sprint switchover that decision was questioned by a working group. The group proposed another approach. We checked if we could get Konsent for that proposal. Within a few minutes it turned out that we couldn’t. Therefore made it a consultative individual decision and chose a decider.

Acknowledgements

Thanks to my colleagues Ilja Preuß, Christian Dähn and Manuel Küblböck for their feedback and input for this article.

• Begeisterte Kunden
• Zufriedene produktive Mitarbeiter
• Globale Optimierung
• Unterstützende Führung
• Kontinuierliche Verbesserung

Markus Gärtner hat die Prinzipien zu globaler Optimierung in seinem Blog detaillierter beschrieben und kommentiert. Die Prinzipien zu zufriedenen produktiven Mitarbeitern hat Andreas Schliep detaillierter beschrieben und kommentiert. Ich möchte hier die Prinzipien rund um begeisterte Kunden etwas genauer betrachten:

Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen.

Ich meine, dass für Unternehmen der Kundennutzen im Fokus stehen sollte und nicht das Geld. Ich bin (wie viele andere auch) davon überzeugt, dass begeisterte Kunden ein sehr verlässlicher Indikator für den langfristigen finanziellen Erfolg des Unternehmens sind. Ein starker finanzieller Fokus führt hingegen meist zu unzufriedenen Kunden (Qualität von Produkt und Service wird reduziert, um Kosten zu sparen) und damit langfristig zu finanziellen Einbußen. In diesem Kontext waren uns zwei Prinzipien wichtig:

1. Definiere, was Wert bedeutet schafft
2. Produziere kleine, lieferbare Inkremente

Definiere, was Wert bedeutet und schafft

Das gemeinsame Verständnis über die wertschöpfenden Elemente muss gerade in einer skalierten Produktorganisation bei allen Mitarbeitern vorhanden sein. Leitbilder helfen dabei, die strategischen Ziele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Orientierung.

Bei der Entwicklung mit nur einem Team ist dieses Prinzip relativ leicht umgesetzt. Das Team arbeitet im direkten Kontakt mit der Business-Seite (Product Owner, Anwender, Kunden) und baut darüber sehr schnell ein Verständnis darüber auf, was die Kundenbedürfnisse sind und wie das entwickelte Produkt diese Bedürfnisse befriedigt. Dadurch steigt die Verbundenheit des Teams mit den Kunden, den Kundenbedürfnissen und dem Produkt. In der Folge bringt das Team selbst Ideen dazu ein, wie die Kunden durch aktuelle Technologien begeistert werden können. Bessere Produkte, begeisterte Kunden und nicht zuletzt zufriedenere Mitarbeiter sind die Folge. In skalierten Umfeldern besteht die Gefahr, dass zusätzliche Hierarchien für die Koordination der Teams eingeführt werden, die die Teams wieder stärker von den Kunden und der Wertschöpfung entfernen. Auch in skalierten Umfeldern sollte jedes Teammitglied wissen, ob und wie das Gesamtprodukt die Kunden begeistert und was der Beitrag des eigenen Teams dazu ist.

Produziere kleine, lieferbare Inkremente

Inkremente bauen aufeinander auf und beinhalten stets den Nutzen und die Funktionalität der vorherigen Inkremente. Daher eignen sie sich ausgezeichnet zur Herstellung und Messung von Mehrwert. Ein lieferbares Inkrement eines Produktes hat somit qualitativ alle Eigenschaften, die man zur Auslieferung braucht, wobei die Produktorganisation Stück für Stück die fehlenden funktionalen und nicht-funktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert eines Inkrements sofort in Nutzen für den Kunden umgesetzt werden. Doch auch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremente die Basis für die kontinuierliche Verbesserung des Produkts, sie minimieren Risiken und reduzieren Komplexität.

Scrum fordert auslieferbare Produktinkremente nach jedem Sprint – es darf keine offenen Restarbeiten an den Funktionalität dieses Inkrements geben. Dadurch werden Risiken effektiv minimiert und es entsteht Transparenz über die reale Leistungsfähigkeit des Teams. Außerdem können Produktinkremente bei Bedarf sofort durch Kunden benutzt werden. Die Time-2-Market reduziert sich. Dadurch wird Feedback aus dem Produktivbetrieb früher generiert und die Wertschöpfung durch das Produkt beginnt früher. In skalierten Umfeldern ist es deutlich anspruchsvoller, lieferbare Produktinkremente zum Sprintende fertig zu stellen. Schließlich müssen dafür die Beiträge aller Teams noch während des Sprints integriert werden. Trotzdem sollte man dieses Ziel auch in skalierten Umfeldern verfolgen. Risikominimierung ist schließlich in skalierten Umfeldern noch wichtiger als für ein einzelnes  Team (der potenzielle Schaden in einem Großprojekt ist einfach deutlich größer). Ich finde hier ein Toyota-Motto hilfreich: „Wenn etwas schwierig ist, mache es häufiger!“ Dann wirst Du nämlich lernen, wie es einfacher gehen kann.

Holger Koschek hat bereits eine ausführliche Besprechung des Buches in seinem Blog veröffentlicht. Holger bemängelt Schwächen in der Übersetzung. Ich freue mich über konkrete Verbesserungsvorschläge für eine eventuelle zweite Auflage der deutschen Ausgabe: Einfach E-Mail an: stefan.roock AT it-agile.de (Oder: wer mir das Buch mit entsprechenden Annotationen zusendet, bekommt von mir ein frisches Exemplar zurück).

Ich möchte über Holgers Buch-Beschreibung hinaus auf ein paar Punkte hinweisen, die mir beim Übersetzen durch den Kopf gingen:

1. Das Buch führt eine Reihe von interessanten Fallbeispielen an. So kann man z.B. lernen, wie es für Adobe möglich und sehr effektiv war, auch in einem Multi-Team-Setting in jedem Sprint vollständig integrierte auslieferbare Produktinkremente herzustellen.
2. In den Fallbeispielen sind die Product Owner immer hochrangige Manager und nicht umgeschulte Business-Analysten, die zu vorgegebenen Features die Details aufschreiben. Ich habe über die Besetzung der Product-Owner-Rolle hier gebloggt.
3. Die Sprints in den Fallbeispielen sind relativ lang (eher Monatssprint als 2-Wochen-Sprints). Das harmoniert meiner Meinung nach sehr gut mit der Besetzung der Product Owner-Rolle durch Top-Manager. Auch über die Sprint-Länge habe ich an anderer Stelle gebloggt.
4. Zu den langen Sprints passt die Sichtweise auf Sprints als Investitionseinheit. Jeder Sprint soll einen positiven ROI (Return on Investment) haben und wenn der Product Owner nach dem ersten Sprint des Projekt beendet, soll er trotzdem ein Produkt haben, das er einsetzen kann und dessen Wert die Kosten des Sprints übersteigen.
5. Wie Holger bereits schreibt, zieht sich das Thema empirisches Management als roter Faden durch das Buch. Ich denke, dass dem Aspekt des empirischen Managements in der Praxis immer noch zuwenig Aufmerksamkeit gewidmet wird. Eine Kurzeinführung in empirische Prozesskontrolle findet sich z.B. hier. Was das für die Scrum-Meetings bedeutet, habe ich in einem Blog-Post beschrieben.
6. Im zweiten Teil des Buches geht es um verschiedene „Implementierungsweiten“ von Scrum: Scrum auf Projektebene (Scrum PRN), Einrichtung einer dauerhaften Organisationseinheit zur Durchführung von Scrum-Projekten (Scrum Software Studio), Scrum für das ganze Unternehmen (Enterprise Scrum).
7. Und zum Abschluss gibt es Hinweise, wie Scrum mit Scrum eingeführt werden kann.

Der erste Teil des Buches ist meiner Meinung nach eine für Manager verständliche Einführung in Scrum. Der zweite Teil des Buches kann auch für erfahrene Praktiker die eine oder andere Inspiration liefern.

Hier ist ein Auszug:

Die Konzerthalle im Sydney Opernhaus fasst 2.700 Personen. Dieses Blog wurde in 2013 etwa 34.000 mal besucht. Wenn es ein Konzert im Sydney Opernhaus wäre, würde es etwa 13 ausverkaufte Aufführungen benötigen um so viele Besucher zu haben, wie dieses Blog.

Klicke hier um den vollständigen Bericht zu sehen.

• Transparency (we need to be able to see the facts and should not rely on things that aren’t provable)
• Inspection (we have to evaluate and interpret the transparent facts)
• Adaptation (we modify the plan according to the inspection)

The Sprint Review, the Sprint Retrospective and the Daily Scrum are empirical management meetings in Scrum. In the Sprint Retrospective for example we first create transparency about the way we work (the Gather Data phase) then we inspect what we have found (the Generate Insights phase) and then we adapt the way we work (the Decide What To Do phase).

Applying these three steps of empirical management to the Daily Scrum and Sprint Review meetings often is an interesting exercise since a lot of “Scrum” teams miss adaptation and sometimes even inspection. And it gets worse when teams use additional meetings like a Scrum of Scrums where there are no “by-the-book-checklists” around on how to do them. So they just pollute the meeting we status reports and don’t inspect and adapt.

When looking at a meeting I suggest discussing if it is an empirical management meeting. If it is I would design the meeting backwards with the end in mind. Who should adapt what? When we know that we can easily find out how to inspect and finally what transparency we need.

So here is my “checklist” for the design of an empirical management meeting:

1. Define what you want to adapt in what way. (Adaptation)
2. Find out what you need to learn in order to be able to adapt. (Inspection)
3. Find out what you need transparency about to do the inspection. (Transparency)

If you want to adapt the release plan as the result of the Sprint Review we need to inspect velocity during the Sprint Review and would therefore check what features where implemented and count story points. If we want to adapt the Product Backlog with new ideas that would improve the product we would probably have customers at the Sprint Review and gather feedback and ideas from them.

There are some alternatives around. One that comes to mind quickly is team based rewards. The reward is not given to individuals but to teams. To distribution of the reward among the team members can be done in several ways. Things I have seen:

1. The reward is distributed according to a predefined formula that may take the formal position in the company into account. (The senior developers gets a greater share than the junior).
2. Everybody gets the same share (and this distribution is clear beforehand).
3. The team determines the shares.

Option 1 conforms the formal hierarchy and that may hinder self-organization and high-performance. But it may be a first step to migrate from individual performance appraisals to team rewards.

Option 2 is very easy and I have seen it several times. I have never seen dysfunctions in the team caused by this approach.

Option 3 has the best chance to come to a fair distribution of the reward. The challenge is to moderate the discussion within the team. (Remember that most people think they perform over average, see illusory superioty). I know of two simulations where the team came to a consensus. But in these cases the whole thing might change when it would become reality. And I know of one case where it was actually done. The team always found the „compromise“ that everybody would get the same share. And after that everybody was pissed off for 3 months since that thought this distribution would be unfair.

Therefore I would aim for option 2 or even better: Dismiss rewards completely. Extrinsic motivation isn’t very useful when it comes to knowledge work (see Dan Pinks Surprising truth about motivation).

1. Each specialist could work for two teams.
2. The specialists could form their own team that acts as a service provider for the other teams.

While both options may work I like to highlight a third option:

Figure out which are the five important teams, put the specialists full-time in these teams and let the other five teams to their own devices. The first reaction often is: „No, no, no. That is a really dumb idea.“ But what would be the consequences? The most important projects/teams would move forward very fast and the less important projects would move forward slowly.

The two options mentioned in the beginning would lead to all teams moving with average speed (if you manage to bring flow to the workload of the specialists).

What would be the more valuable approach for your company?

Recently an InfoQ article re-opened the discussion with interesting insights into Googles 20% slack model. It seems that at Google most employees don’t use their slack (self-chosen or management prohibited it).

That made me think of two slack models I have experienced first-hand – one at it-agile (every employee had 30 days slack per year) and one at a client (every developer had a contingent of something about 12 days per year using the Goldcard model). In my point of view both models failed to deliver what was expected: business relevant innovation. And I think I know the reason.

Imagine the typical developer working according to the prioritization of a Product Owner. Now we grant the developer 10 days per year slack time. He can use the day for whatever he wants to do. The developer thinks: „What should I do with my slack time? Hm. I can do, whatever I want. Let’s see, there is this new cool programming language. I will have a look at it.“

The effect is a technological focus of the slack time. In such a setting you can expect that developers know more new technologies. And that is fine if this has a relevant impact on your business.

But most of my clients primarily need business innovation. While knowing the newest technologies is important for a lot of business innovations it is not enough. You need to know customers‘ problems and needs as well.

Google has an advantage here: Google develops products for consumers like me and you. Therefore the engineers might be potential customers of Google products and a now their own problems and needs. Ergo: developers were able to develop e.g. Google Chrome or GMail in their slack time.

But in most companies the developers aren’t potential customers of their own products. I think that a slack model has to have certain constraints to generate business innovation. One might be that the slack time has to be with and at clients (perhaps something like the sunglass iPad development at Nordstrom may be the result).

What di you think? What are your experiences with slack time models?

I wrote an article together with my brother Arne Roock adressing these questions. The article is published in the current edition of the „Agile Review“ by it-agile. The article is available as PDF for download. (There is also a german version of the article).

Zu diesen Fragen habe ich zusammen mit meinem Bruder Arne Roock einen Artikel verfasst, der in der aktuellen Ausgabe der „Agile Review“ von it-agile erschienen ist. Es gibt den Artikel auch als PDF zum Herunterladen. (Es gibt auch eine englischsprachige Version des Artikels als PDF).

Das Buch vertritt die These, dass für die Leistungsfähigkeit von Teams und Unternehmen die vorherrschende Kultur wichtig ist. Sie stellen ein 5-stufiges Modell der Kulturentwicklung in Teams/Unternehmen vor:

1. „Life sucks“ – Das Leben an sich ist schlecht und es wird auch nicht besser werden. In dieser Stufe kommt es häufig zu Gewalt gegen andere oder sich selbst – wenn das Leben sowieso an sich schlecht ist, ergibt es auch wenig Sinn, sich an moralische Maßstäbe zu halten.
2. „My life sucks“ – Das Leben anderer Leute mag gut sein, aber mein Leben ist schlecht. Auch wenn der Übergang von „Life sucks“ zu „My life sucks“ sich häufig wie eine Verschlechterung anfühlt, ist es ein Fortschritt. Die Erkenntnis, dass das Leben nicht für alle schlecht ist, enthält die Chance, dass es für mich auch besser werden kann.
3. „I am great (you are not)“: Ich bin großartig, viele andere leider nicht. Daher muss ich immer alles selbst erledigen. Dieser Zustand ist der vorherrschende Zustand in den Unternehmen in den USA (und sicher auch in den meisten anderen westlichen Ländern).
4. „We are great (they are not“: Jetzt steht das Team-/Unternehmensergebis im Vordergrund nicht mehr das, was ein einzelnes Individuum leistet. Das Team/Unternehmen grenzt sich dabei gegen andere Teams/Unternehmen ab und definiert sich auch dadurch, dass es besser ist.
5. „Life is great“: Jetzt verschwindet die Abgrenzung gegen andere und ein höheres Ziel (Noble Goal) definiert das Team oder das Unternehmen.

Laut den Autoren kann man bei der Kulturentwicklung Stufen nicht überspringen. Wenn man sich auf Stufe 2 befindet, kann man sich nicht einfach zu Stufe 5 weiterentwickeln, man muss den Weg über die Stufen 3 und 4 nehmen.

Das Buch zeigt Techniken, mit denen man (anhand der verwendeten Sprache) den Zustand von Teams/Unternehmen bewerten kann sowie Techniken, wie man die Kultur weiterentwickeln kann.

Das ganze ist übrigens nicht einfach ausgedacht, sondern mit Studien belegt und so finden sich in dem Buch immer wieder Fallbeispiele zu den einzelnen Stufen.

Von mir eine eindeutige Leseempfehlung für alle, die sich für Unternehmensentwicklung interessieren.

• Ein Cheat-Sheet gibt es als PDF.
• Und es gibt eine Webseite zum Buch.

Scrum originated outside the IT (development of cars, copiers, printers, photo cameras, computers, see Nonaka’s & Takeuchi’s famous article „The New New Product Development Game“) but most Scrum implementations are in software development. But non-IT strikes back and Scrum starts to spreads into non-IT areas. Some real world examples:

• Develop service products.
• Develop and manufacture cars (e.g. Wikispeed, Johnson Controls)
• Manage enterprise transitions.
• Execute training classes.
• Manage consulting.
• Organize sales.
• Manage accounting.
• Organize scientific research.
• Schools (see Facebook)

Every area has its own specific challenges. But let’s start with some general observations.

When applying Scrum to non-IT it is in my experience helpful to start with the product concept. What is the created product (or service) we are talking about? When we try to develop and manufacture a car with Scrum this pretty obvious: it is the car. When it comes to more intangible areas we may have to spend some time thinking. Some examples:

• Sales: Is the product a set of orders? Or is the product a set of long-lasting customer relationships? The decision what the product is has a huge impact on the way we think about the work of sales.
• Training classes: One might guess the product is knowledge but that doesn’t cover the whole story. The knowledge was there before the training classes and wouldn’t need the class for creating it. For a CSM class one might think the product is a set of Certified Scrum Masters. That is a valid product and it would focus the training class on test preparation. Since I don’t want to do test preparation and prefer to prepare participants for work I prefer to think of the product as “more skilled participants” (or more specifically “more skilled Scrum Masters”).
• Enterprise transition: The product is an agile enterprise. This seems to be pretty easy but it has a significant impact on the work of the transition team: A set of Powerpoint presentations doesn’t make a valid product increment.
• Scientific research: Often the success of scientific research is measured in publications. Therefore one could think of these publications being the product. But I think this isn’t appropriate. The number of publications is a KPI (Key Performance Indicator) like the revenue for a software product. In the same way you wouldn’t see the revenue as the product you wouldn’t see the publications as the product. I think a more appropriate product is insights.

When the product concept is clear the next step is pretty easy: What are valid product increments and what does “potentially shippable” mean for these product increments. For scientific research an insights might be shippable if it is new to the world of science. In the case of enterprise transition the product increment usually is a more agile enterprise and it is already shipped (= implemented) when the Sprint Review happens. In the case of car development and manufacturing a drivable car may be a valid product increment. But parts of the car that can be inspected, assessed and as a part delivered may also be valid product increments. When you want to create a very fuel efficient car by developing an innovative fuel efficient motor the motor might be a valid product increment. How to produce a product increment like a more agile enterprise every Sprint (at least once a month) may be again very challenges. I will address that later.

Now that we have a concept for product and product increment I like to address the question of the Product Owner. How do we measure success and who is the right person to be the Product Owner for that product. To find an appropriate Product Owner two questions should be answered: Who is empowered to prioritize features (or who could be empowered to do so)? Who is accountable for the product (who is an appropriate “single wringable neck” for the product)?

• For a training class the trainer is the Product Owner. In my training classes we regularly have a discussion if the participants are the Product Owner. I then ask: “Imagine you are pissed off by the training class and leave it disappointed. Who is responsible? You as the participant or me the trainer?” The trainer is the “single wringable neck” and therefore is the Product Owner of the training class.
• For an enterprise transition the Product Owner is a top level manager, e.g. the CEO.

The Product Backlog is quite easy to build. What is necessary to create the product? It may be appropriate to fill the Product Backlog with goals (not features). In sales for example you typically would have goals like “win a deal of at least 100.000 USD at customer XYZ”. When applying Scrum for training classes the learning modules or learning objectives may provide the Product Backlog Items.

The next step is to form the Development Team. The team needs all the skills necessary to produce product increments. When we have a clear understanding of the product we want to deliver it is quite easy to decide who should be in the team. For an enterprise transition the team needs to have managers and leaders of the company (otherwise the team is not able to achieve changes).

As the Scrum Master you need an experienced Scrum Master (of course) but as a rule of thumb you a more experienced Scrum Master than for an average software development project. The body of knowledge about how to apply Scrum for non-IT is much smaller than for software development. That means that the Scrum Master needs a more solid understanding of the Scrum principles and he needs to facilitate insights about how to apply Scrum in new ways.

When you have chosen an appropriate product the Sprint Review is easy. When you have problems demonstrating and inspecting product increments and gathering feedback about the product chances are high that your product concept is inappropriate.

During the Sprint Retrospective the Scrum Team (Product Owner, Development Team and Scrum Master) inspects its way of working and comes up with action items to improve their way of working.  I haven’t encountered any specific challenges here when applied to non-IT.

The mechanics of Sprint Planning and Sprint Backlog are easy to apply but during Sprint Planning a problem may become visible: The team has no idea how to create product increments at least every month:

• How could we possibly change the organization in just one month?
• How could we create a car in a month?
• How could we win a new customer in just a month?

The team has to find out how to create product increments every Sprint and we need to bear the tension that is created: We need to create product increments every Sprint and we don’t know how. Constraints like these create innovations. Just extending the Sprint length or faking the product concept (“Powerpoint presentations are the new product”) would kill this possibility to improve. We need to forge and apply new ways of working and there is no promise that we will succeed. In all the areas I listed at the beginning of this article teams have managed to find these new ways of working. I am confident that others can do it also.

In some cases we have to tweak the Sprints. A training class might last for two days. Since we want to gather feedback from the participants during the training we might end up with a Sprint length of 2 hours or a half-day. That might question the justification of the Daily Scrum. While there are ideas how to apply Daily Scrums in such a situation I generously skip them in training classes with a Sprint length of a half-day. (But I have applied four Daily Scrums per day for software development successfully).

Some domains require the team members to work highly distributed. Consultants may form a team but work at different clients. Sales people also normally work alone or in pairs when they work with clients. Still coordinating with the rest of the team to achieve a higher mission (create the product) is worthwhile. But is more challenging to apply appropriate mechanisms and the Scrum Master may have more work to do to make people cooperate that were used to work on their own for years or decades. Sometime it might be appropriate to transform the Daily Scrum into a Weekly Scrum.

When Scrum is not appropriate

The list of areas where Scrum is applied may suggest that Scrum could be applied everywhere. That may be true but it wouldn’t be efficient. Scrum needs teamwork. When teamwork isn’t necessary or teamwork isn’t achievable Scrum doesn’t make sense. When you just have routine work with low variability to do and there is nothing to lean, Scrum is inefficient (why would you talk so much during Planning, Review, Retrospective and Daily Scrum?).

But sometimes there are surprises. I would have thought that accounting is just routine work that doesn’t need a team. But I know of several accounting teams that say that teamwork is appropriate for them.

Summary

Scrum can be applied to a lot of knowledge work domains where teamwork is appropriate. For most areas outside IT there is only a small body of knowledge about how to apply Scrum. When trying to apply Scrum in a new area prepare to be challenged. I love to hear your experiences and of course I offer my help as a coach when you want to apply Scrum to areas outside IT.

In the Sprint Planning the team pulls work from the Product Backlog (the Scrum Guide says that the development team „selects“ Product Backlog Items for the Sprint).

One re-occurring question is whether the team is allowed to deviate from the prioritization – for example when a Product Backlog Item is too fuzzy or when the development team thinks an Product Backlog Item is just bullshit.

The answer is: it depends.

The very first reason fort he pull principle is to avoid overload with its negative consequences (lower quality, burnouts, developers quitting jobs etc.). Therefore it is totally valid to expect the team to pull work strictly according to the prioritization. While older literature is sometimes a bit ambiguous about the „selection“ of Product Backlog Items the current version of the Scrum Guide is pretty clear about that: „The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.“ (emphasis added by me)

But.

Kent Beck once told me that he likes to ask developers if they would invest their own money into the product they are working on. I use this question from time to time when working with teams and I will never forget a larger retrospective at a client where I asked the team exactly Kent’s question: „Would you invest your own money into the product you are developing?“ The team laughed and answered: „We think it would be more valuable to buy Greek government loans.“

That is great feedback for the Product Owner. The team isn’t convinced about the product but it should be (remember the Scrum value „commitment“). The Product Owner should start asking questions: Is the product idea bullshit? Does the prioritization of features lead to weak product while the product idea may be great? Does the team lack the information about the market and users needs to understand the product and the prioritization of features? Working with these questions provides the opportunity to enhance the product a lot. But it requires hard work on the side of the product owner.

A Product Owner who is open for these kinds of discussions may apply the pull principle not only for limiting the amount of work to the team’s capacity but also to the meaning of work. The team would only pull Product Backlog Items into the Sprint when it is convinced that these items are valuable fort he product.

I have seen a lot of confusion about these two types of the pull principle. To make clear what we are talking about we could call the original pull principle „workload pull“ since its motivation is to find the optimal workload. The extended pull principle could be called „purpose pull“.

The workload pull delegates the decision about how much work can be done to the team. The purpose pull delegates the decision about what should be done to the team.

Valve (a company famous for its computer games) applies purpose pull on a product level. Developers choose the products they are working on. If a Product Owner has an idea for a new game but is not able to motivate developers to join his project the game wouldn’t be implemented. (see http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf)

Typical open source projects apply purpose pull on the product level as well as on the feature level. Everybody decides for himself on what product to work (and is free to quit whenever he is fed up) and within the product development the developers are free to choose the features to implement.

The following table summarizes the two pull principles:

Scrum as a framework supports workload pull as well as purpose pull. (Applying purpose pull to the fullest possible extend would eliminate prioritization by the Product Owner completely and then you leave the Scrum framework). Every project has to determine the appropriate pull level.

When every single Sprint has a positive ROI you can just plan from Sprint to Sprint. When a Sprint planning provides the information that this Sprint would not generate more value for the company than it costs, you just stop the development. You have created something with a positive ROI with the previous Sprint(s) and everything is fine.

Think about it. How cool is that!

Impossible? No. I have seen it working.

Hard to achieve? Of course. You need to resign from traditional project planning and really think about how to create small valuable software increments. And adapting a new perspective is always challenging.

P.S.: One may ask what I mean with ROI. For me a Sprint has a positive ROI when you could just stop after the Sprint and have created a value that is higher than the Sprint costs.

But: There are a lot of other options for estimation in Scrum.

Why estimating the Product Backlog?

The first important question is why you want to estimate the Product Backlog. Typically the Product Owner, the management or the customers want to have a release plan. To create a decent release plan the Product Owner needs a good enough estimation of the features that will make the release. (If nobody needs a release plan you may not need to estimate the Product Backlog at all).

The Product Backlog often contains items for following releases. The Product Owner should question the need for estimating these. Often he needs to create the plan for the current release but not plans for all following releases. Therefore the items with low priorities often don’t need to be estimated at all.

How to estimate the Product Backlog

For the items that need to be estimated there are alternatives to Story Points. The team could  estimate in person days, of course. Or they could use T-shirt sizes (S, M, L, XL) or even simpler they could just count the items in the Product Backlog. But counting isn’t estimating, is it?

When you just count items you have an underlying assumption: the variation in size of these items is small enough so that counting will produce a good-enough result. So you estimate that the items are more or less of the same size. You could say that you estimate all items to be one story point.

When to use which estimation technique

When are Story Points appropriate and when is counting sufficient? The so called ”sources of variabilities“ (a concept from Lean Thinking) have a big impact on the decision. Sources of variability make estimations fuzzy or instable. Typical sources of variability in software development are:

• Missing contributions of other departments or companies.
• Missing skills within the development team.
• Wrong or incomplete understanding of what has to be done.
• Exchange of team members.
• Modifications of the Product Backlog (new features are added).
• Illniss of team members.
• Urgent incidents.
• …

The sources of variability interfere with the estimations. It is for example worthless to invest a lot of time in a very precise estimation if the team members are exchanged every week. These exchanges would make the performance of the team totally unpredictable. In that case the precision of the estimation doesn’t matter.

Here is a rule of thumb: The more sources of variability the less precision.

You should do imprecise estimations when you have a lot of sources of variability. Don’t invest your time to refine these estimations (red area in the figure). Invest your time in eliminating sources of variability (moving to right in the figure). It is the bigger leverage. But be aware of the fact that not all sources of variability are bad. Changes to the scope is intended in Scrum – it is the root cause for the Sprint Review. Removing all sources of variability would kill innovation. Therefore focus on the unwanted sources of variability.

After you eliminated the biggest unwanted sources of variability you could make your estimations more precise.

The following figure relates typical estimation instruments to the estimation precision.

P.S.: Scrum is aware of unwanted „sources of variability“. It just uses another name: impediments.

Is Scrum a method? According to the Oxford dictionary a method is „a particular form of procedure for accomplishing or approaching something, especially a systematic or established one“.

Is Scrum a methodology? According to the Oxford dictionary a methodology is „a system of methods used in a particular area of study or activity“.

, method or methodology. Remember that Scrum doesn’t say a word about how to estimate, how to do the software architecture, unit testing etc.

Scrum is a framework. The Oxford dictionary defines a framework as „a basic structure underlying a system, concept, or text“.

This means that every team builds it own p Scrum is none of these. Scrum is just to unspecific to be a process rocess / method / methodology using the Scrum framework as the basic underlying structure.

And that means that there is no best practice for a staffing the Product Owner, for the behavior of the ScrumMaster or the Sprint length.

In the „Shades of Scrum“ blogpost series I explain possible implementations of parts of the Scrum framework with the underlying forces that may make one choice more suitable in a specific situation than another choice:

• The ScrumMaster role: The article explains how the ScrumMaster role may change over time according to the ever growing capabilities of the team.
• 3 Product Owners and a Product Owner Shaped Object: The article describes 4 implementations of the Product Owner role and argues that one of the more common implementations isn’t a valid Scrum Product Owner.
• Sprint length: The article compares shorter and longer Sprint lengths and shows that longer Sprint lengths have their value – not only for beginners.
• Waterfall, Pipelining and Sprints: Most companies aren’t capable of doing perfect Scrum from day 1. They need to transition from Waterfall to Scrum, maybe with Pipelining as an intermediate step. The article shows pros and cons of the Waterfall, Pipelining and Scrum Sprints and helps to define an appropriate process for the specific whole value stream.
• The Sprint Planning and the pull principle: The team pulls work into the Sprint during the Sprint Planning. The article discusses different types of pull.
• Estimation of the Product Backlog: The article presents different approaches to estimation and discusses when to use which approach.
• Empirical Management Meetings: The article highlights that fact that most Scrum meetings are empirical management meetings and therefore there should be transparency, inspection and adaptation in the meetings. The article gives guidelines on how to optimize these meetings for your context.
• Scrum outside IT: Scrum is used mainly for software development today but starts to spread out to other areas. The blogpost shows concrete example of Scrum outside IT and presents an approach to handle projects outside IT with Scrum.

We all know the traditional approach to software development – the sequential waterfall model.

Activities like analysis, design, implementation and test are done sequentially – an activity is completed before the next activity is started. The work is done by specialists like business analysts, software architects etc.

And there is Scrum: All activities are done in parallel in Sprints by a cross-functional team.

Combining Waterfall and Scrum

Moving from Waterfall to Scrum is a big step for most companies. Most companies are not capable of doing this change in a short period of time. Therefore a combination of Waterfall style phases and Scrum sprints is very common. Typically the Waterfall style phases embed the Scrum sprints.

For example market research and product definition would be done in Waterfall style. UI design, programming and component tests would be done in Scrum sprints. And then integration tests, roll-out and sales would again be done in Waterfall style.

The problem with this kind of combination of Waterfall and Scrum is not it used but that companies stay with it. A lot of companies that practice this combination of approaches find out that the advantages are limited:

1. End-to-end responsibility is hard to establish due to the silos and hand-overs.
2. Long time to market: Since the phases before and after the sprints stay the same the overall lead time often is reduced only by a few percentages.
3. Long feedback cycle: The end-to-end feedback cycle is nearly as long as with the waterfall.
4. Feedback may invalidate a large amount of work: If the last activity (e.g. sales) generates relevant feedback for the first activity (e.g. market research) a lot of work done during the activities in between may be invalidated.

Notice that Waterfall is not a bad idea in general. Especially when there are low risks and few things to lean, Waterfall may be a suitable approach.

Pipelining

Pipelining is a more beneficial approach. Pipelining simply means that several teams work in parallel sprints where one team generates the input for another team.

Pipelining is much better than the waterfall approach but in the end it just reduces batch sizes without changing the general way of working. Compared to Scrums all-in-one-team approach the drawbacks are the same as with the waterfall approach.

The first important aspect is that the feedback cycle is not one sprint but – in the case of three teams – three sprints.

The second aspect is that pipelining is a very poor approach to address learning.Pipelining assumes that the upstream team (team 1 in our example) hands over its output to the downstream team (team 2 in our example) and proceeds with the next sprint. But when the downstream team discovers something about the work done by the upstream team  it is challenging to integrate that discovery into the work flow of the upstream team.

If for example a downstream team does testing, how would the upstream team handle the discovered bugs?

Fold the pipeline into Sprints

When you work with pipelining the whole thing can be folded into Sprints. When we have for example 3 teams doing pipelining with a Sprint length of 1 week it is easy to put all the participants in one team with a Sprint length of 3 weeks. The team then may decide to do some kind of pipelining but is empowered to modify the way of working within the sprints to suit current needs. And even if the team opts for pipelining it is more likely that the team members cooperate.

Conclusion

Scrum isn’t generally better than Waterfall. Both approaches have their specific pros and cons.

In general Scrum is better suited when a lot of things are unknown and therefore learning has to be incorporated in the project. In the end it boils down to the question what and how fast we need to learn – or where the risks are. When the roll-out of the software is of low risk it may be suitable to do it with pipelining or even Waterfall.

Therefore the question is not if Waterfall or Scrum is better suited. The question is, where we should use Waterfall and where we should use Scrum. And when we choose to use Waterfall pipelining is in most cases the better implementation – the smaller batch sizes (aka work in progress) generate shorter lead times.

Related reading

1. Shades of Scrum: Sprint length – the article describes some advantages of longer Sprint lengths (which may be the result of folding a pipeline into Sprints)
2. Twelve emerging best practices for adding UX work to Agile development – In this article Jeff Patton suggests to use pipelining for User Experience (UX) work.

The general thinking here is that shorter Sprints lead to more frequent inspect&adapt regarding the product (Sprint Review) and the process (Sprint Retrospective). When a team is capable of doing 3 week Sprints it should therefore try to work with 2 week Sprints and then 1 week Sprints.

But I think there is missing an important aspect: When the team is capable of delivering within a certain Sprint length there are actually two possibilities for further improvement:

1. Shorten the Sprint length to reduce feedback cycles and allow more frequent inspect&adapt.
2. Deepen the teams capability by reducing the Definition of Ready (start the Sprint with a less formal specification) or increasing the Definition of Done (e.g. by including live deployment).

Which direction to take is – of course – dependent on the specific context.

Shorten the Sprint length is valuable if

1. the Product Owner is actually able to react that fast to feedback about the product
2. the team is able to create and implement process improvements that fast

Deepen the teams capabilities by reducing the Definition of Ready is valuable if

1. cross-functional work seems valuable not only for the implementation but also for the definition of the „what“ (remember the benefits of cross-functional work: more creativity, higher quality)
2. the Product Owner is overloaded (e.g. he is a Jeff type of Product Owner but is forced to work like a Walter or Marty)

Deepen the teams capabilities by increasing the Definition of Done is valuable if

1. the product increment isn’t really shippable until now (e.g. integration tests are missing; the demo is done in a branch)
2. there are often problems in the downstream processes (e.g. operations has problems with deploying the product increment into production)

Consequences

• When your team becomes more capable you should discuss if you want to shorten the Sprint length or deepen the capabilities of the team.
• When your team is capable of doing the current Sprint length but not a shorter one, you should discuss if it would be valuable to extend the Sprint length and deepen the capabilities of the team.

Related Posts

• Shades of Scrum: Product Owners and a Product Owner Shaped Object
• Definition of Ready: a double edged sword

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

• Clearly expressing Product Backlog items;
• Ordering the items in the Product Backlog to best achieve goals and missions;
• Ensuring the value of the work the Development Team performs;
• Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
• Ensuring the Development Team understands items in the Product Backlog to the level needed.

Product Owner Personas

I have seen four different types of Product Owners. I have created little personas to describe them: Walter, Marty, Eric and Jeff.

Walter

Walter is very accurate when preparing the next Sprint. He knows the domain very well and doesn’t need the support of the team for Sprint preparation. He only calls the developers for Sprint preparation when he needs an estimate for a newly created Product Backlog Item. In the Sprint Planning Walter hands over very clear and detailed specifications of what has to be done in the Sprint.

Walters Product Backlog Items are described very carefully and have a detailed list of acceptance criteria. Therefore there is no need for intense contact with the development team during the Sprint.

Marty

Marty asks the development team regularly for help during Sprint preparation. He writes some of the Product Backlog Items together with the development team and often details Product Backlog Items and their acceptance criteria together with the team.

Marty is available during the Sprint to clarify details that are not described by the Product Backlog Items.

Eric

Eric does not only work as a Product Owner; he is also a member of the development team. He creates and manages the whole Product Backlog together with the development team. When the Sprints begins, the Product Backlog Items are often very rough and a lot of stuff is detailed and clarified during the Sprint.

Jeff

Jeff has some distance to the development team. Normally he interacts with the development team only during Sprint Planning and Review. His Product Backlog Items are coarse grained leaving out most of the details. The development team has to figure out the details itself. Jeff may provide a Product Backlog Item „Birthday list“ and the team has to figure out the filter criteria, printed data and layout.

Conclusion

In my point of view three of the described Product Owner personas are valid Scrum Product Owners and one is only a Product Owner Shaped Object (POSO). From an outside view the POSO complies with the Scrum rules but he doesn’t incorporate the Scrum mindset.

Walter

Walter is the POSO and his complete name is Walter Falls. His way of working is still sequential waterfall. He specifies the requirements and the team does the execution. What is missing here is the overlap of development activities (namely analysis and development) and the collaboration between the Product Owner and the development team.

Walter is a guy you would meet in a lot of Scrum implementations, because his way of working is very similar to the way the people have worked in waterfall projects for years. When doing a transition to Scrum Walter may be a suitable temporary type of Product Owner. But you should keep in mind that it is only an intermediate step and that Walter should transform into one of the other Product Owner personas.

Marty

Marty is the Product Owner that is described by the most of the Scrum literature and he is the most common valid Scrum Product Owner. I have chosen the name ‚Marty‘ since I think this type of Product Owner is what Marty Cagans book „Inspired“ implies.

Marty is relatively easy to implement and is therefore quite often. For a team beginning with Scrum Marty is normally a good choice. And then it may evolve into Eric or Jeff.

Eric

A lot of people think that Eric and Jeff aren’t valid Scrum Product Owners since they don’t provide all the details to the development team. Often the following statement referring to the dotted lists with the Product Owners responsibilities from the Scrum Guide is ignored:

The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.

As long as Eric (or Jeff) remain accountable their approach to the Product Owner role is completely valid.

Eric is the most collaborative Product Owner regarding the interaction with the development team. Eric is a good choice when the what (the Product Backlog Items) is very unclear and need to be refined and redefined within the Sprint based on feedback gained during the Sprint. Teams doing Lean Startup with Scrum normally end up with Eric as the Product Owner. (And that is the explanation for the name. The cross-functional Lean Startup team described by Eric Ries is very similar to a Scrum team with Eric as the Product Owner).

Jeff

Jeff is the less supportive Product Owner but gives the development team the greatest freedom. The development team is not only responsible for the how but also defines large parts of the what. Jeff needs a mature development team with deep domain knowledge. Typically a Jeff Product Owner comes with long Sprints (e.g. a month) because the development team needs more time within the Sprint to figure out the details of the Product Backlog Items.

Jeff is suitable when the Product Owner can’t dedicate a lot of time to the Product Owner role. An example could be a CEO or other manager who assumes the Product Owner role. But this is only successful, when the development team has enough domain knowledge and is trusted adding all the details of the Product Backlog Items in a meaningful way.

And for the name: As far as I understand the first Scrum software project done by Jeff Sutherland at Easel incorporated a Jeff as Product Owner.

„The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.
The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.“

This definition states what the Scrum Master has to do but not how. And this is not a bug, it’s a feature. How to assume the Scrum Master role is highly dependent on the context. I like the situational leadership model to think about how the Scrum Master should do his job.

1. Telling: When a team hasn’t done Scrum before it is unable to do Scrum and insecure if Scrum would really work for them (bottom right cell of the diagram). In this situation the Scrum Master should tell the team members what to do. Providing lots of options to the team will often result in paralysis. The team just doesn’t have the experience to choose one of the options. In addition to the Scrum framework the Scrum Master may tell the team to estimate in story points and use Planning Poker for it.
2. Selling: After a short period of „Telling“ and delivering shippable product increments the team will move up to the top right cell. Now the team is secure that Scrum could work for them but is still unable of doing it (since it just did what the Scrum Master told them to do). Now the team is ready to take over a bit more responsibility and the Scrum Master moves to selling. He gives advice to the team and tries to convince them to do the right thing. In the „Selling“ state the Scrum Master explains in much more detail the whys of his advices. Now the Scrum Master may let the team decide if that want to estimate with story points or ideal days and wether they would use Planning Poker or something else. But the Scrum framework would not be modified by the team.
3. Participating: Now the Scrum Master leaves most of the decisions to the team (and just jumps in when there is something really critical). The consequence is that the team becomes more capable but insecure again. „Can we be successful with Scrum when we do it ourself without the Scrum Master managing the whole thing for us?“  The team starts to self-organize in the „Participating“ state. Now the team may decide to do the Sprint Planning in another way and may remove the Daily Scrum (but not the Sprint Planning, Review or Retrospective).
4. Delegating: Then the team experiences that it can succeed with Scrum without being dependent on the Scrum Master. Now the Scrum Master really acts as a coach leaving all decisions to the team. That means that the team may remove or adapt every single part of the Scrum framework.

In my experience switching between the left and right columns of the diagram is a challenge for most Scrum Masters. Some Scrum Master have the tendency to adhere strictly to the Scrum rules and give strict rules to the team. They are successful in the „Telling“ and sometimes in the „Selling“ state but often mess up the transition to the „Participating“ state. They just can’t let the team go.

And there are the Scrum Masters with a coaching mindset. They work successfully in the „Participating“ and „Delegating“ states but are challenged by unable teams. They often have problems providing the concrete guidelines to the team that it needs then.

One interesting question is of course: „Where is my team?“ A simple test is to not show up in a Daily Scrum. Will the team do a proper Daily Scrum? Then it is probably no longer in the „Telling“ state. What about the retrospectives? Is the team creative in finding solutions for its problems and does it implement the solutions successfully? Then the team is probably in the „Participating“ state. Or does the team just creates a list of things that other people should do? Or does the team create action items but fails in implementing them regularly? Then the team hasn’t reached the „Participating“ state yet.

Lean Startup verstehen

Stefan Roock: „Lean Startup“, Artikel in Objekt-Spektrum 1/2013, deutsch

Dieser Artikel gibt einen kurzen Überblick über Lean Startup und sollte hilfreich bei der generellen Einordnung des Ansatzes sein. (Der Artikel ist tatsächlich noch nicht erschienen. Aber solange dauert es nun auch nicht mehr

Eric Ries: „The Lean Startup“, Buch, englisch & deutsch

Eric Ries ist derjenige, der Lean Startup unter diesem Namen bekannt gemacht hat. Daher ist das Buch in gewisser Weise ein Must-Read. Man sollte allerdings nicht zuviel erwarten. Das Buch argumentiert gut, warum und wann der Ansatz nützlich ist. Er gibt aber wenig Hilfestellung dabei, wie man Lean Startup konkret anwendet.

Das Buch gibt es auch in einer deutschen Übersetzung. Die habe ich aber nicht gelesen und kann daher nichts zu deren Qualität sagen.

Ash Maurya: „Running Lean“, Buch, englisch

Dieses Buch ist deutlich handlungsleitender als „The Lean Startup“ und daher meine Empfehlung für alle, die sich ernsthafter mit Lean Startup auseinander setzen wollen.

Lean Startup für den eigenen Kontext bewerten

Doreen Timm, Sandra Reupke-Sieroux: „Lean Startup – Lessons Learned“, Artikel in Agile Review 2/2012, deutsch

Dieser Erfahrungsbericht beschreibt, wie 7 Kollegen von it-agile einen Monat lang ein Startup nach dem Lean-Startup-Ansatz betrieben haben. Dabei werden insbesondere auch die kritischen Punkte deutlich herausgestellt, die nicht funktioniert haben. Es ist daher ein sehr nützlicher Artikel, der hilft, nicht nochmal in die selben Fallen zu tappen. Wer die „Agile Review“ noch nicht besitzt, kann sie bestellen bei info@it-agile.de.

Stefan Roock: „Pivots in grown companies„, Blogpost, englisch

Der Artikel beschreibt ein wichtiges strukturelles Problem bei der Anwendung von Lean Startup in „erwachsenen“ Unternehmen, die eine funktionale Abteilungsstruktur haben. Wenn man Lean Startup in „erwachsenen“ Unternehmen anwenden möchte, ist es aus meiner Sicht wichtig, diese Fußangel zu kennen. Dann kann man sie früh adressieren und angemessen damit umgehen. Es zeigt außerdem, dass Lean Startup in „erwachsenen“ Unternehmen durchaus auch Unternehmensentwicklung bedeuten kann.

Lean Startup anwenden

Stefan Roock: „Lean Startup: a classification of MVPs„, Blogpost, englisch

Der Artikel präsentiert eine Klassifikation von MVPs (Minimum Viable Product), die dabei hilft, den passenden MVP-Typ für die vorliegende Fragestellung zu identifizieren.

Steve Blank: „The Startup Owners Manual“, Buch, englisch

Das Buch von Steve Blank ist umfassend und entsprechend dick. Es ist eher als Nachschlagewerk konzipiert als ein Buch, das man von vorne bis hinten durchliest. Entsprechend ist das Buch nützlich, wenn man konkret beginnt, mit Lean Startup zu experimentieren.

Unterstützung durch it-agile

„Lean Startup mit Scrum“, Schulung, deutsch

Diese Schulung vermittelt praxisnahes Wissen zu Lean Startup. Mehr Informationen findet sich unter http://www.it-agile.de/leanstartup-mit-scrum.html

Lean Startup Coaching

Natürlich ist Coaching viel teurer als ein Buch oder eine Schulung. Dafür ist die Vermittlung von Wissen und Fähigkeiten durch Coaching viel schneller und direkter anwendbar. Wer externe Lean-Startup-Expertise für sein Team sucht, wird fündig unter: http://www.it-agile.de/innovative-produktentwicklung.html

Lean Startup Team

Wer eine neue Produktidee hat und ein komplettes, erfahrenes Lean-Startup-Team sucht, wird hier fündig: http://www.it-agile.de/innovative-produktentwicklung.html

Aber seht Euch das Programm selbst an: http://xpdays.de/twiki/bin/view/XPDays2012/Programm

Ich werde übrigens auch eine kurze Session auf den XP-Days anbieten zur Zusammenstellung von Teams.

• We have introduced autonomous business teams to enable scaling and support local experimentation. The business teams synchronize monthly at a whole-day face-2-face meeting and with an offset of two weeks at a shorter monthly telco.
• After we introduced the teams we discovered some limits to the teams‘ capabilities. Not every team was able to generate sufficient customer demand to „make a living“. Therefore we created a virtual sales team (consisting of members of business teams) that focused on demand creation.
• There was a institutionalized group called „senior consultant group“ consisting of the two CEOs and the two most senior consultants. This group decided to dissolve since most of its responsibilities were transfered to the employees and business teams over team.
• One left over was the process for deciding on salaries. Employees had and have peer groups with whom they discuss their personal development and peer groups may suggest increases in salaries. The final decision was made by the „senior consultant group“. As this group dissolved completely we introduced a „SalaryChecker“ group consisting of four people elected by all employees. (The two CEOs were proposed as candidates for the group but didn’t accept the nomination. The current „SalaryChecker“ group consists of the two „seniors“ of the original board and two other employees.
• Intrinsifier published an article about it-agile.

When you pivot in a real startup the situation is quite simple. The product team recognizes the need to pivot and then does the pivot.

In a discussion with Markus Andrezak I realized that the situation is quite different when you want to pivot in a grown company. Then the pivot often affects not only the product team but completely different departments. And therefore you may need to get the commitment of the CEO to pivot. In a larger company this may increase the time you need for the pivot to weeks or months.

An Example

Let’s look at an example of a marketplace platform with a transaction oriented pricing model like eBay or Amazon: The company earns money everytime a transaction is completed. According to this model the KPIs of the marketing department are based on transactions. The KPIs of the sales force may be based on new registered sellers.

Now let’s assume that in our imaginary example company revenues have stopped to grow. After some investigation the product team thinks it should pivot the transaction based model and just connect buyer and seller. While the product may need only minor modifications it changes nearly everything for marketing and sales. The marketing KPIs based on transactions become senseless and need to be replaced. For the sales force the change may be even more dramatic. Perhaps registered sellers are not that important any more. Perhaps there is even no need for a sales force any more?

The product team would not be able to make these changes happen within the company on its own. The changes would need the intervention of the CEO.

Rationale

The situation described in the example is not a special exception. It is the result of the nature of a pivot. A pivot is not just a modification to a product feature. Pivots address the product strategy – revenue streams, cost structure, key partners, target group, customer needs as well as key features.

The most aspects of the product strategy are built into a grown company. The revenue streams and key partners affect sales. Target group and customer needs affect marketing. The cost structure affects operations. And so on.

Therefore: In a grown company a pivot is a major change to the whole company.

The consequences are:

• You need to analyze what parts of the company may be affected by the pivot.
• You often need commitment or at least explicit support for the specific pivot by the CEO.
• You may have to market your pivot to the whole company.
• The pivot may take weeks or months.

Früher oder später werden Softwaresysteme unwartbar. Änderungen werden so teuer, dass sie faktisch unbezahlbar werden. Irgendwann werden die Schmerzen so groß, dass ein neues System entwickelt wird. Und das Spiel beginnt von vorne. Dabei handelt es sich aber nicht um ein Naturgesetz. Wir können Software entwickeln, die sich langfristig zu moderaten Kosten weiterentwickeln lässt – und das, obwohl wir auch bei der initialen Entwicklung nur moderate Kosten verursachen

Der vollständige Artikel findet sich hier.

1. Coverage: The number of reached customers. (An interview is done with few people, an Ad-Words campaign may reach thousands).
2. Product Fidelity: How similar is the MVP to the end product? (A software prototype has a higher fidelity than a paper mockup).

Here are the MVPs I am aware of:

The size of the dots is the length of the feedback cycle. An interview is done in a few minutes. A software prototype needs hours or days to program and then days or weeks to gather the feedback.

How to use it

The classification is useful to find the appropriate MVP. When teams start learning Lean Startup they tend to use high fidelity, high coverage MVPs and pay the price: The need weeks to get feedback. But in the very beginning many of our assumptions are just plain wrong and we want to learn that as fast a possible. Therefore first MVPs should be as fast as possible. Using low fidelity, low coverage MVPs from the bottom left help to achieve that. When we validated some assumptions with low fidelity, low coverage MVPs we move up and to right: higher fidelity, higher coverage.

More MVPs

I am keen to discover other MVPs (the empty space in the middle of the diagram looks like there is something missing). What are the MVPs you know of?

The Definition of Done is a well known concept in Scrum: The Scrum team defines when a feature is Done and may be demonstrated during the Sprint Review. The Definition of Ready is a newer concept that is less common. The Definition of Ready states the conditions under which a User Story (or more general a Product Backlog Item) is ready to be included into the Sprint. The goal is to avoid working on User Stories in the Sprint that are too fuzzy to be successfully finished within the Sprint. This is definitely a good intention since often development start to work on a User Story although their understanding of the User Story is too weak. In that case working on the story may be blocked due to necessary clarification or work may loose focus due to different interpretations of the User Story.

On the other hand the Definition of Ready may be used to create an over regulated process that impedes collaboration between Product Owner and development team: Whenever there are communication problems between Product Owner and development team the Definition of Ready is extended by a new policy. After several „improvements“ the Definition of Ready requires the Product Owner to specify each requirement correct, complete and consistent pre-checked by another Product Owner and a Software Architect to avoid any ambiguity or missing details.

This is NOT Scrum and it is NOT Agile.

The Agile Manifesto has something to say about the intended relation between the Product Owner and the development team:

• „Individuals and interactions over processes and tools“
• „Business people and developers must work together daily throughout the project.“
• „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“
• „The best architectures, requirements, and designs emerge from self-organizing teams.“

Don’t forget about the underlying values and principles of agile development! For the Definition of Ready I recommend: The smaller the better. The team becomes more and more capable of handling incomplete information. Therefore the Definition of Ready should be shrinking over time and not growing (while normally the Definition of Done is growing with the capabilities of the team).

Moreover the Definition of Ready should focus on the process not the artifacts (like User Stories). I prefer „Product Owner and Development Team defined the acceptance criteria of each User Story collaborating in a workshop.“ over „Each User Story has acceptance criteria.“ as part of the Definition of Ready.

References

• Agile Manifesto: http://agilemanifesto.org/

Selbstorganisation über Teams hinaus und sogar im ganzen Unternehmen ist möglich. Ich habe Folien auf Slideshare hochgeladen, die zeigen, wie Selbstorganisation auf Unternehmensebene funktioniert: Folien

Die Folien stammen von einem halbtägigen Workshop, den ich bei einem Kunden zu dem Thema „Selbstorganisation im Unternehmen“ durchgeführt habe. Wer so einen Workshop auch gerne bei sich im Unternehmen durchgeführt haben möchte, kann sich dazu gerne bei mir melden.

Classical risk management in software development comes from waterfall like approaches tailored for simple and complicated domains. In a nutshell you create a list of all risks at the beginning of the project. Every risk has a probability and a potential damage. Multiplying probability with damage yields a kind of „risk cost“ which is then used to prioritize the risks. After that we define countermeasures or mitigations for the risks. Here is a short introduction to classical risk management.

In my experience the focus of classical risk management  is on creating a plan that can be executed without big surprises. And second is focus is on avoiding the risk to ensure project success.

For this traditional approach it is crucial to anticipate cause-effect relations. That is possible in simple and complicated domains but not in complex domains. Therefore traditional risk management is of limited value in complex domains (yes, I tried it for some years).

Feedback driven approaches like Scrum have built in risk management for a lot of typical risks:

• Does the software match customer needs?
• Will we deliver in time?
• Does the software scale?
• etc.

But we believe there is more to it. Let’s have a look at a story told by Don Reinertsen at the LSSC 2012 conference about fire fighting. Fire in forests behaves in a complex way. It is impossible to forecast what the fire will do in the near future. There is the influence of wind and rain and even the fire itself may create relevant wind.

The fire fighters do risk management in a when-then pattern. „When the fire crosses this boundary, then we will evacuate this town.“ It is not possible to guarantee that the fire will cross this boundary. Therefore we make a plan to minimize damage not to avoid the damage completely.

We think that this pattern of risk management is applicable also for software/product development. We identify the risks that may cause critical damage and were we need to react really fast. For these risks we create a plan what to when the risks becomes reality.

This is exactly what one of my clients did when the global financial crisis started. „When sales drops below this point we will reduce costs here and use money from another business area to avoid layoffs.“

With such a plan the appropriate preparations can be done in advance (e.g. not signing long term contracts that bind a lot of money and put new investments on hold). And it creates a safe atmosphere for employees. They see that there is a plan and that this plan does not include layoffs.

Conclusion
In complex domains risk management ist more „when X will occur we will do Y“ than „to avoid X we will do Y“. (That doesn’t imply that traditional approach had no place n complex domains. It is just less important.) But one thing stays the same: More important than risk lists are the collaborative discussions about risks with and within the team.

P.S.: I used the term „risk management“ throughout this blogpost although I think it is misleading. Risks in complex domains can’t be managed. We only can prepare to be able to react accordingly. But by now I don’t have a better term. I love to see proposals in the blogpost comments.

P.P.S.: I like to thank my colleagues for the discussions about the topic, namely Arne Roock, Norbert Hölsken, Christian Dähn, Jens Coldewey, Sebastian Sanitz (and I hope that I didn’t forget anyone).

Fair enough!

But: Sometimes we gather new insights when we make the probem worse. What would one do if we had to replace the programming language (e.g. migrating a COBOL system to Java)? You wouldn’t just install the Java compiler and try to compile the COBOL source files, would you?

You would rewrite the whole system step by step having potentially shippable code all the time. When this approach works for replacing the programming language it should work for an easier problem like replacing infrastructure as well. And it does.

Rewrite the system on the new platform/infrastructure feature by feature. Of course you make heavy use of copy&paste to reuse the existing code.

Is it worth it?
At first sight the incremental approach needs higher efforts. There has to be something on the plus side to make the approach attractive:

• Bugs are easier to fix: When you make a mistake during the big bang migration you will not recognize it until you have finished the whole migration. But then you introduced the error weeks or months ago and it will take you a really long time to figure out how to fix the bug. Using the incremental approach shortens the time from producing the bugs to detecting and fixing the bugs. That makes it much easier to fix the bugs and therefore reduces the effort.
• Remaining time is easier to estimate: When you proceed feature by feature you can compute an average velocity and create a rough forecast when all features are done.
• Release early: With proper prioritization you can deliver the migrated system to some customers long before all features are migrated. (You could start with the features for the customer who needs the smallest feature set). These early customers would give feedback about the system in production and so lower the risk of the whole migration.

Forcing Hard Decisions

A Sprint in Scrum is timeboxed. Every Sprint has the same length and it ends when the time has come – no matter how much we completed. Jim Highsmith wrote on Twitter about timeboxes: „I’ve always said timeboxes weren’t about time, but about forcing hard decisions.“ I think this is an important statement since it questions what a lot of Scrum teams do: Plan what to do during the Sprint and get the approval for that in the Sprint Review. When we look at the Sprint through Jims Eyes we get something different. First we have to think about the „hard decisions“ we want to force. There are definitely several options. In my point of view there are two very important questions nowadays, that are related to each other:

1. Did we validate or invalidate our assumptions?
2. Did we produce value for customers and users?

The Sprint timebox forces us to decide how to proceed based on the feedback we got. Should we pivot or persevere? Should we stay with the current Product Backlog or adapt it?

Without timeboxes it is – of course – still possible to force these hard decisions. But most of us like to avoid hard decisions and tend to postpone and postpone and …

Creating Rythm and Flow

Tobias Mayer wrote on Twitter: „Reading anti-timebox tweets. It’s amusing how much disgust is aimed at a unit of time. Units of time create rhythm. Rhythm creates flow.“ He added a blog post called „Timebox != Commitment“ where he explains his perspective on timeboxes. It is NOT:

1. Set a timebox size
2. Commit to a bunch of work
3. Realize you are failing to complete it all
4. Rush to finish
5. Produce crappy work
6. Be exhausted
7. Go to #2—repeat until dead, or company goes out of business

But it is:

1. Set a timebox size
2. Engage in dialog with requester/s. Review requests, prioritize
3. Select a request, small enough to fit inside the timebox
4. Complete the work to the satisfaction of the requester
5. Breathe [reassess remaining requests if necessary]
6. Go to #3—until there is no request that can fit in the remaining time.
7. Stop work [if time remaining, take Slack time]
8. Reflect. Learn from mistakes, and adapt accordingly
9. Go to #2—repeat until all requests met, or deadline arrived at.

This perspective is supported by the latest modifications to the Scrum-Guide published by Ken Schwaber and Jeff Sutherland: The development does not commit to the Sprint Backlog but does a forecast (like a weather forecast) about what might be achieved.

Other options

Scrum-like Sprints are one possible implementation of timeboxes. I know of at least two other possible implementations. Here are the three options I am aware of:

1. In Scrum we batch together a set of features during the Sprint Planning and use this feature set for the Sprint Review.
2. In Kanban planning and release/review cadences are often decoupled. Review cadences can still be used in a timeboxed way (in the sense of Jim Highsmith to force hard decisions). In this case we batch together some features for review but not for planning.
3. Eric Ries suggests to have a kind of deadline per feature in his book „The Lean Startup„.

In the end it is just the question of when and what to batch together and that is a question of transaction/coordination costs. Batching features together for a review is an easy-to-implement solution when we want to get face-2-face feedback from customers and users. When we have a lot of active users and work a lot with Lean Startup-like cohort metrics and the like we may not need to batch together features for review. Batching features together for planning is an easy solution when the „feature requesters“ are not continuously available. When the „feature requester“ is available all the time (e.g. because the Product Owner role is shared across the team) it may not be the best solution.

• Before the start of the StartupMach we only had decided on the problem to solve (online discussions) and the technology we would use (Rails). So we invested the first day for some conceptual work.
• At the second day we started the development of the first ideas. We had the first product (Duscuss2Decide) live at day 3 and the second (Discumeter) at day 5. After that we had more than 15 releases per day. The rule was simply: whatever you commit into the master (aka Trunk/Head) will go live immediately.
• Typically we started the day with an informal wrap up of the product usage (a kind of review if you want). Then we discussed what to do during the day (kind of planning). And then we did it. For both „meetings“ together we invested 30 to 90 minutes.
• During the day we had 2 to 4 sync meetings to check where were and how to proceed (kind of Daily Scrum).
• We did no Task Breakdown but Story Splitting on a very tiny level. We worked with MMFs (Minimal Marketable Features) that we broke down into User Stories. Most stories were done in less than 2 hours.
• We managed work in progress by gut feeling. Normally we all would work on the stories of one MMF (single piece flow). That way a MMF normally needed one day to complete.
• We did Pair Programming in most cases and often switched pairs at the sync meetings.
• We had two retrospectives. One in the middle of march, one at the end of march.
• There were no roles. No Product Owner, no ScrumMaster, no Testers etc. Just team members. During our second retrospective we had a discussion about the roles. The conclusion was that we sometimes would have profited from a ScrumMaster for facilitating discussions and forcing us to face uncomfortable facts. And we thought that the absence of a Product Owner person was helpful. The team was not only empowered to decide on how to do the work but also on what to work on.

It was a great time. We had a lot of fun, we learned a lot and it felt very productive. Although we didn’t acquire millions of venture capital for our products, Discuss2Decide seems to have value for users. There are some regular users of the tool and most online discussions at it-agile are done with the tool today.

Will it travel?
Will the „process“ travel to other contexts? I don’t know. I think there were two special ingredients that are uncommon and may have been crucial:

1. With the seven team members we had roughly 45 years of experience with Agile of different flavors in the room: Scrum, XP, Kanban, FDD.
2. All team members shared a common cultural background (it-agile) that showed up as an extreme openness for other’s ideas, perspectives and needs.

Read more about the Startup March.

• Das Skript mit Fotos aus dem Theaterstück gibt es als PDF.
• Ein kurzer Ausschnitt aus dem Theaterstück als Video findet sich hier. 
• Ein kurzes Interview zu dem Thema mit Arne und mir gibt es hier.

References

• Tobias Mayer discussed the cultural aspects of projects vs. teams: Team Culture, Project Culture.
• Karl Scotland suggested to favor teams over projects in Kanban, too: Linking Flow, Value and Capability.
• Jurgen Appelo says it is short-sighted to organize cross-functional teams around projects: „Teams“ (The Same Mistake All Over)
  

„Don’t!“

„What?“

„Ok, you are used to say people what to do. But Scrum is about not saying people what to do. You should not start the journey to self-organisation with command&control as the first step.“

„So I am not allowed to do anything? I just have to sit here and hope that something changes for the better? You are kidding!“

„Of course you can do something. To make change happen you have to do something. But focus on the goal not on a specific approach like Scrum, XP or Kanban. So what is your primary goal?“

„I want shorter time to market and better products.“

„Fine. You could tell the team that you want to see running software demonstrated to happy customers every 14 days. And you leave it to the team how it achieves this goal. You should offer your help when impediments occur and you could offer to hire a coach. But the most important thing is: don’t interfere with the work the team is doing. Focus on their achievements.“

References

This blogpost is very much in line with Tobias Mayers Scrum: a 5-step guide for managers.

Me and my collegues will write and talk about our experiences with Lean Startup, customer development, agile to the extrem, continuous deployment (we had about 15 live deployments per day) and more. I will collect all these ressources at this page.

Here is, what we have by now:

• Even before we started Henning wrote about the idea of the StartupMarch: „Lean Startup March: Ich bin dabei“ (german)
• Henning blogged about his impressions about only 3 days: „Lean Startup March: discuss2decide.com – 1. Auslieferung an Tag 3“ (german)
• Henning wrote about Lean Startup and the sometimes limited value of numbers: „Lean Startup March: Zahlen, bitte!“ (german)
• Henning created a short video with some impressions of our team. (german)
• Markus interviewed the participants before, during and after the Startup March. (german)
• Manual wrote about some of our experiences and lessons learned: „The it-agile Startup March: Lessons learned“ (english)
• Doreen blogged about incremental UI design and incremental UX: „Inkrementelle Designentwicklung“ (german)
• I talked about Lean Startup and our experiences at the JAX conference 2012 in Mainz. The german slides are on slideshare.
• I wrote a blog post about the „process“ we used: Lawless Agile
• Manuel blogged about all the errors we made when we tried to work with metrics: Metrics are useless on day one of a startup

In letzter Zeit gibt es vermehrt Diskussionen darum, wie eine agile Organisation aussehen müsste. Radical Management, Management 3.0, STOOS etc. sind die aktuellen Schlagworte. Eine sehr frühe und sehr weitreichende Implementation dieser Ideen findet sich beim basilianischen Unternehmen SemCo. Der Besitzer Ricardo Semler beschreibt in „Maverick“, die SemCo-Geschichte. Und auch wenn das Buch bereits 1993 geschrieben wurde, hat es an Aktualität bis heute nichts verloren. Ich empfehle das Buch allen, die sich für agile / empowerte / menschenfreundliche / moderne / scrummige / schlanke Organisationsstrukturen und Führungsstile interessieren.

In dem Artikel beschäftigen wir uns mit der Frage, was überhaupt Qualität ist und stellen die klassische Qualitätsdefinition („Qualität ist die Übereinstimmung der Realisierung mit den Anforderungen.“) in Frage. Wir stellen die kundenorientierte Qualitätsdefinition („Der Kunde definiert, was Qualität ist.“) dagegen und bringen diese mit agilen Verfahren wie Scrum und Kanban in Zusammenhang. Nicht zuletzt zeigen wir auf, wie die kundenorientierte Qualitätsdefinition in der Softwareentwicklung besondere Herausforderungen an die interne Qualität des Systems stellt.

Auf der JAX-Konferenz werden wir übrigens zum gleichen Thema zu sehen sein, allerdings in einem etwas ungewöhnlicherem Format (Schauspiel).

We founded it-agile seven years ago. This is a good reason to reflect on what we have achieved regarding management and organization within it-agile. Some of the things listed below were already in place seven years ago, others are just a few days old.
We believe that our employees are it-agile with the implication that the best employees would make the best it-agile. And we do not just aim for satisfied customers, we want to delight our customers. To express these believes we have a defined purpose:

“Create fulfilling jobs for our employees to delight customers.”

We achieve this purpose by:

• Transparency and openness: Nearly every information is visible for every employee including the wages, travel expenses and time sheets of every colleague (the CEOs are just colleagues also). On a company level the economic data etc. are accessible for everyone.
• Peer groups: Employees have self selected peer groups that work with the employee on personal improvements and suggest promotions.
• Pull principle: We have implemented the pull principle for coaching and development. Customer requests are visible for the whole company and employees pull these. So employees may choose to prefer jobs in their local area and decide on themselves if they are capable of doing the job.
• Meetings at it-agile are optional. Every employee decides for himself if he attends.
• As long as the results are achieved everybody can work when and where he wants. (Of course this has to be coordinated with colleagues and customers since most of the results can’t be achieved without colleagues and customers.)
• Every employee has 30 days of slack were he can do whatever he wants: go to conferences, work on a self selected project, read books, go to trainings, … Of course it is transparent within it-agile what everybody did.
• Employees don’t apply for holidays. They decide on themselves when they take their 30 days of holiday.
• Overtime: There is no pressure for working overtimes. Sometimes employees decide themselves to work overtime to achieve important results. The overtime is collected in a work hour account. Employees decide when to withdraw time from that account.
• Expenses: Employees decide how they travel and what equipment they need for their work. They don’t ask for permission. They just buy what they need.
• Profit sharing: About 2/3 of the company profits are distributed to the employees (in principle every employee gets the same percentage).
• Company ownership: About 2/3 of the company is owned by the employees. This implies ultimate empowerment: The employees can change ANYTHING. They could even fire the CEOs or change the purpose of the company completely.

Is it successful?

We have more employees, we have higher revenues and we have higher margins today than we had in the beginning. You never can be sure if the described principles created this growth or if it just was good luck. But I think we were and are successful.

Will it travel?
In general the described concepts shouldn’t be taken as a blueprint for another organization (although there are similarities with other companies like SemCo). I think we wouldn’t have been able to start with out current state even if we had known it. I think that we observed a kind of co-evolution during the last seven years. We made a small modification to the organization of the company. That enabled a small progress of company culture. This progress in company culture then enabled the next small modification of our company structure and rules. And so on…

Will it scale?
We started it-agile with 10 people. Now we are 35. In my point of view the things we did enhanced empowerment and autonomy which are important building blocks for our growth. The changes we made enabled growth. I think for further growth we have to intensify empowerment and autonomy even more.

The Future
Since there is no big boss at it-agile you never know what will happen next. There are some very interesting and challenging discussions in the moment.

BTW 1: We are hiring agile coaches and developers. (Notice; Sometimes people seem to think they wouldn’t match our expectations and therefore don’t apply for a job at it-agile. There is only one way to find out: Let’s talk!)
BTW 2: We offer consulting to managers who want to transform their company/business unit in an agile way towards more empowerment and autonomy.

References

• Christian wrote about his first impressions at it-agile (in german), especially the transparency.
• Bernd did a presentation about some of our changes at the Lean Kanban Central Europe Conference 2011.
• Henning and Jens presented some aspects of it-agile (in german) at the XP-Days Germany 2011.
• Jens wrote about self-organization at it-agile (in german) in his blog.
• Markus wrote about mentoring and peergroups at it-agile in his blog.
• Bernd wrote about the it-agile slack model in his blog.

Die Folien für beide Vorträge finden sich inkl. Foliennotizen auf Slideshare:

• Folien zum regulären Vortrag
• Folien zum Pecha Kucha
• Video des Pecha Kucha

Inhaltlich geht es darum, dass meiner Meinung nach viele Produkte / Systeme zu wenig Nutzen erbringen und wir dieses Problem nicht dadurch lösen, dass wir Anforderungen schneller umsetzen. Wir müssen es dadurch lösen, dass wir wertvolle Features entwickeln, auch wenn wir dadurch etwas langsamer werden.

One of my clients (serving several customers with custom made solutions) decided to introduce Scrum. They grouped people together that worked in the same projects or for the same customers. The result were three Scrum Teams. The next step was challenging. Who should be the ScrumMasters and who should be the Product Owners? Should there be full time ScrumMasters or would it be a better fit if the ScrumMasters were also developers? Who could be a Product Owner? In one team there were several options. Would one candidate be pissed off if the management chose the other guy? In another team there seemed to be no perfect match. Should the second Product Owner candidate of the one team be transferred to the other team although this would mean loosing his experiences with his existing customers?

I introduced the idea that self organization is a powerful tool to solve challenging problem. Here we were: We had Scrum Teams that could self organize and we had a challenging problem (filling the Scrum roles). So it was decided to let the Scrum Teams decide who would be ScrumMaster and Product Owner. This was done in a workshop with all teams. The result was to some extend surprising to the management but they stuck to their commitment to let the teams decide.
I don’t know how good the selected ScrumMasters and Product Owners will manage their jobs. Independent of their future performance I think there are several interesting aspects in this story:

• The teams selected ScrumMasters and Product Owners in an hour or so. When management tried to select the roles it took much longer and provided no result.
• The Product Owners and ScrumMasters were selected by the teams and not assigned by management. I think that will help development team, ScrumMaster and Product Owner to act as ONE team without some kind of boss.
• If problems with the ScrumMasters and Product Owners would occur it should feel naturally for the Scrum Teams to select new persons for the roles.
• The management demonstrated trust into the employees and empowered the teams.

When I mentioned the self selection on Twitter there was doubt that the approach would be suitable for the Product Owner role. I can understand the doubts but like to think along these lines (assuming that there are sufficient Product Owner skills in the Scrum Team):

• If the Scrum Teams selects the person who would be selected by the management anyway, the management demonstrated at least trust into the team.
• If the Scrum Team selects another person, things really become interesting and there is great opportunity to learn something. Why does the team have another opinion than the management? Which opinion is more relevant to the success of the team? Is there a need and the possibility to reach consensus between team and management?

P.S.: I think it is totally valid for the management to assign the Product Owner. But is that really the best option – especially for a mature agile organization?

Aikido master Endō Seishirō shihan stated: „It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.“ (from [1])

Shu-Ha-Ri in Scrum

These learning stages can be applied to Scrum, too. A team starts with Shu. It practices Scrum by the book: the flow with the roles, the meetings/ceremonies and the artifacts. Premature adaptations to Scrum in the Shu stage often lead to the famous ScrumBut situations (see [2], [3]). A team enters the Ha stage only after it has shown its ability to use Scrum as it was intended and has achieved a deep understanding of the spririt of Scrum. Then it may (and I think it should) adapt Scrum on their understanding of the spirit of Scrum. After a team has been in Ha state for a probably long period of time it may enter Ri and dismiss all rules.

From Shu to Ha

Two interesting (and interrelated) questions arise here:

1. How do you know that you have practiced enough in Shu state and you may enter Ha state?
2. What are typical adaptations for Scrum in Ha state?

From Ha to Ri

References

1. Wikipedia article about Shu Ha Ri: http://en.wikipedia.org/wiki/Shuhari
2. My presentation about ScrumBut and Shu-Ha-Ri (in german): http://www.slideshare.net/roock/scrum-but-agil-aber-xpdays-germany-2010
3. ScrumBut from Ken Schwaber: http://www.scrum.org/scrumbut
4. Agile Manifesto: http://agilemanifesto.org

Eine Besonderheit sind dabei die extrem kurzen Zyklen, die man anstrebt. Wir haben erst vor wenigen Tagen an einem halben Tag eine Customer-Problem-Solution-Hypothese definiert und ein MVP entwickelt.

Offensichtlich ist dieser Ansatz nicht nur dann sinnvoll, wenn man ein Startup gründet. Passend dazu definiert Eric Ries Startup als Produktentwicklung unter großer Unsicherheit. Das Buch adressiert als das Startup in der Garage genauso wie eine Produktneuentwicklung in einem Konzern.

Ich finde, das Buch ist sehr gut geschrieben und es stellt einen wichtigen Meilenstein in der Entwicklung unserer Branche dar. Allerdings fokussiert das Buch darauf, den Leser vom grundsätzlichen Ansatz zu überzeugen. Es bleibt manchmal etwas schwammig, was man konkret machen soll/kann. Außerdem handeln die meisten Beispiele von Internet-Anwendungen. Für andere Produkttypen ist etwas mehr Transferleistung notwendig. Bestimmt kommt demnächst ein Nachfolgebuch „Implementing the Lean Startup“ heraus, in dem konkret beschrieben wird, wie man es denn nun macht. Trotzdem ist auch dieses Buch absolut empfehlenswert.

For those who don’t know the G Forces presentation: it is all about shortening release cycles from months to weeks to days to hours to minutes.

What became clear to me: The release cadence is not the real point. It is all about feedback. You have to be able to incorporate feedback according to your release cadence. Releasing every day doesn’t help too much if you need a month to collect feedback and react on it.

Perhaps we should reflect that with our metrics. What about Feedback Cycle Time and Feedback Coefficient as new metrics for teams?

Feedback Cycle Time would be the time you need from the release of feature A until you are able to release feature B that incorporates the learnings from feature A? For example: You release feature A to production on 1st of february 2012. Then you collect data from the production usage of B for 1 week. You discuss the findings for one week and take another week to redefine some of the features in the backlog. And then you need 3 weeks for implementation, test and release of feature B that incorporates the learning. In this scenario your Feedback Cycle Time would be 6 weeks.

The Feedback Coefficient would be Number of Features for which feedback was collected / Number of Released Features. For the Feedback Coefficient it doesn’t matter if the feedback was positive or not. The only important thing is the learning. When we are honest most teams today achieve a Feedback Coefficient of zero or very near to zero. The optimum would be 1.

I think both metrics would focus on a weak spot in many teams: The teams try to maximize throughput and minimize lead time but don’t really care about feedback from the market.

Dear Thought Leader,

I really appreciate what you did for our community and the progress of our industry in general.

But sometimes I am puzzled. That happens when you bash an idea or even worse a person. The ideas you had and the concepts you developed are great enough to stand for themselves. You don’t have to bash other ideas/persons to make your concepts look brighter.

Here are some examples that might highlight what I am talking about:

“X clearly didn’t understand what Y means.” How do you know? Did you do an in-person test with X to check his understanding of Y? How does it feel for X when you say that? What will be his reaction? Will he check his understanding or is it more likely that X just defends himself?

“In his blog entry X addresses Y but sadly stops at Z and didn’t thought of A.” How do you know that X didn’t thought of A? Perhaps he did and decided to leave it out to keep the article short?

„Y is a stupid idea. It would lead to (unwanted) Z.“ At least when people are involved how do you know that Y would lead to Z every time in every situation, especially when you tried Y never or only a few times? Do you think the advocate of Y is lying when he says that Y worked at his place?

I don’t suggest stopping arguing! Arguing is possible without devaluing other ideas/persons.

One could say “X wrote a nice blog post about Y. I’d like to add some thoughts on Z.” or “X presented Y in a way that puzzled me. I would rather think that …” or “Y didn’t work when I tried it. Therefore I tried something different that I’d like to present.” or even „Y simply does not resonate with me. Therefore I used Z.“

If you defined something very clear and X presented it just plain wrong you could just call or email X and make the correction. Don’t spend your previous keynote time correcting one person. There are hundreds in the audience who want to learn something from you.

My wish for the future is that we all learn to become better at arguing without bashing and devaluing.

Yours respectfully,

Stefan Roock

P.S.: I am am sure that I bashed other peoples/ideas as well but that doesn’t make it any better.

Other teams start with Kanban, eliminate columns of their Kanban board, reduce WiP and increase teamwork.

The results are very similar: There is a short backlog of things that create customer value (sometimes called Minimal Marketable Features, MMFs). The team picks the item with the highest priority and splits it into smaller User Storys or Tasks. When an MMF is completed it will be delivered. That’s it. The would result in a 3 column board: ToDo, Doing, Done. This board design is similar to a Scrum taskboard but the „process“ is different. Since there are no iterations there is no distinction between a product focused backlog and an iteration focused backlog.

The interesting thing here is that this is mainly what Arlo Belshee named „Naked Planning“. He did that already in 2007 (perhaps even earlier) but only few people recognized it! Nowadays Naked Planning is sometimes reframed to be simplified or small Kanban.

Perhaps both of the above teams should say they are doing Naked Planning (or trying to do) and try to improve even further by having a deeper look at Arlos work (like doing Single Piece Flow for MMFs and limiting the number of MMFs in ToDo zu seven).

As far es I know this video is Arlos first description of Naked Planning (2007): http://www.youtube.com/watch?v=6t4bZtnnQJA

„I love to code, but I have to coach.“

Viele Anwesende stimmten durch Gemurmel oder eindeutige Gesichtsausdrücke zu. Es findet sich hier ein durchaus gängiges Muster. Ein sehr guter Entwickler wird zum Coach, weil nur so höhere Gehälter zu erzielen sind. Und so landen Entwickler in Coaching-Jobs, die sie eigentlich nicht wollen.

Ich selbst habe mich auch immer – zumindest zum Teil – dazu gezählt. Ich hatte aber auch immer Spaß beim Coachen und Trainieren. Vor ein paar Jahren habe ich versucht, das für mich klar zu kriegen und dafür eine Vision für mich geschrieben. Hier einige Auszüge daraus:

Ich möchte mich in meinem beruflichen Leben kontinuierlich weiterentwickeln und wünsche mir Anerkennung meiner Arbeit und meiner Person. Dazu möchte ich in motivierten agilen Teams anspruchsvolle Software-Produkte entwickeln. Dabei spielt für mich ein großer Gestaltungsspielraum eine ebenso wichtige Rolle wie der enge Kontakt mit den Kunden/Anwendern. Meiner Meinung nach können nur im engen Kontakt zu Kunden/Anwendern Lösungen entstehen, die die Bedürfnisse der Kunden/Anwender befriedigen.

Das in den Projekten Erlernte möchte ich reflektieren und vergegenständlichen, als wichtige Elemente meiner Weiterentwicklung. Für das Vergegenständlichen funktioniert das Schreiben von Artikeln und Büchern sowie das Halten von Vorträge und Schulungen gut für mich.

Wie man sieht, stand das Programmieren im Zentrum. Alles, was sich um Coaching und Training drehte, war ein Anhängsel oder gar nicht erkennbar. Als ich die Vision aufgeschrieben habe, ist mir natürlich aufgefallen, dass diese Vision nicht wirklich zu meinem Job als Coach passte. Aber irgendwie fühlte ich mich mit dem Coaching-Job dann auch nicht so unglücklich. Tatsächlich war es sogar so, dass ich für Coachings und Trainings viel mehr Anerkennung erhalten habe als jemals zuvor für Programmierung.

Der oben zitierte Ausspruch auf der SoCraTes-Konferenz hat mich erneut an meine Vision erinnert und mein zwiegespaltenes Verhältnis zum Coaching. Ich habe das zum Anlass genommen, nochmal über meine persönliche Vision zu reflektieren. Dabei ist mir klar geworden, dass die Anerkennung nur eines meiner Bedürfnisse ist. Das andere Bedürfnis schien bereits in der originalen Vision durch: „Bedürfnisse von Anwendern befriedigen“. Tatsächlich geht mein Bedürfnis noch weiter: Ich möchte Fußspuren hinterlassen, etwas verändern, einen Impact haben. Das geht über die Entwicklung von Software. Aber wenn ich ehrlich bin, war das meistens nicht der Fall. Die meisten Systeme hatten keine nennenswerte Auswirkung. Das geht viel einfacher, wenn ich als Coach und Trainer arbeite! Tatsächlich glaube ich, dass ich durch meine Arbeit nicht nur Unternehmen wirtschaftliche Vorteile sondern nebenbei auch die Arbeitssituation vieler Entwickler verbessert habe.

Seit mir das klar geworden ist, fühle ich mich viel besser in meiner Rolle als Coach und Trainer. Trotzdem habe ich auch weiterhin Spaß am Programmieren. Nicht umsonst investiere ich viel Zeit in CodersDojo. Ich würde aber nicht mehr jedes Programmierprojekt machen wollen. Es sollte schon herausfordernd sein und in Clojure oder mindestens Ruby entwickelt werden. Und wahrscheinlich würde ich mich auf jeden Fall in die Product-Owner einmischen wollen. Wer so ein Projekt zu bieten hat, kann sich gerne bei mir melden. Solange mache ich meine Hobby-Projekte und bin als Coach und Trainer glücklich.

P.S.: Ich weiß von Beraterkollegen, dass sie nicht sehen, dass sie Anerkennung für ihre Coaching-Arbeit bekämen oder wirklich etwas verändern würden. So ging es mir am Anfang meiner Beratertätigkeit auch häufig. Mit der Zeit sind diese Situationen aber immer seltener geworden. Vielleicht muss man nur lange genug durchhalten, bis man die nötige Erfahrung hat

How it works
Single piece flow means that the whole team works at one User Story at any given point in time. Only when the whole User Story is done the team moves to the next User Story.

Why it
Single Piece Flow works due to several positive effects:

1. Single Piece Flow forces the whole team to cooperate continuously.
2. This ensures that every team member is informed about state and progress of each User Story. Furthermore the team members learn from each other through intense cooperation.
3. On this basis it is easy for team members to help each other.
4. Point 3 together with the fact that a team generally is faster in implementing a User Story leads to a shorter lead time of the User Story.
5. Shorter lead time and reduced Work-in-Progress means for the team that it has to remember only few things for a short period of time. And this fact reduces the number of bugs and decreases the time needed for bug fixing.

Really?
You may doubt what I wrote. Perhaps Single Piece Flow reduces the lead time per User Story. But does it enhance overall throughput or does it lead to under utilization of the team members and higher costs?
Maybe… Luckily it is easy to check. Just try it for one Sprint and then inspect&adapt. You are welcome to share your findings in the comments of this blog article.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

But I prefer a simpler mechanism and just adding impediments to the existing Task Board which I have described here in a PDF.

Every team member answers two questions:

1. What did I achieve since the last Daily Scrum? (and update the taskboard)
2. What are my impediments? (and make impediments visible at the taskboard)

Then the team updates the Sprint Burndown Chart (yes, let the team draw it on a big sheet of paper).
Now the team sees the current state of the Sprint at the taskboard and the prognosis at the Sprint Burndown Chart.
Then ask the third question in a slightly modified form: How can we as a team organize until the next Daily Scrum to create the most progress towards the Sprint Goal?

That will avoid stickyness to tasks (“I worked on the database schema and will work on it again”). Instead the team plans together who should work on what. Perhaps Henning should help Stefan with the database schema? Perhaps it would be better to stop working on the database schema for now and focus on another more important task?

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

While I think that Envisioning is often necessary I am often shocked when I see what companies do during „Envisioning“:

• The Envisioning lasts weeks or months when hours or days would have been sufficient.
• Comprehensive fine grained product backlogs are created.
• Detailed designs are created.
• etc.

That is not Envisioning. That are the early phases of a waterfall project. Therefore some people consider the Envisioning an anti pattern in Scrum.

Before I join these people I want to try to explain better what Envisioning should be and what not.

During Envisioning I value

• learning important things over designing things
• having business and technical people in the Envisioning team over having only the Product Owner doing the Envisioning
• Product Owner and Team listening to and working together with real customers and users over giving research orders to marketing
• checking assumptions about the market, customers, users over dealing with corporate stage gate processes
• checking technical assumptions with prototypes over having long design discussions within the team
• sketching things on flip charts over creating power point slides
  

At it-agile we created a Scrum team to restructure some aspects of our software development unit. For the first Sprint the Sprint Goal made it necessary to interview customers. So far so good.

But when I was at the site of a coaching client with potential interview partners it wasn’t that easy. I had a full email inbox and it was hard to get in touch with the potential interview partners. It would have been much more comfortable to postpone the interviews. And if I hadn’t committed to the Sprint Goal I would have postponed the interviews. But the commitment made me focus on what really mattered and it pulled me out of my comfort zone and do the interviews. And in the end it was the right thing to do. Learning something about customers was much more valuable than reading emails.

In this story my commitment to the Sprint Goal made me leave my comfort zone.

This is just one of the possible positive aspects of the commitment concept done right. Others include building trust, having an additional feedback mechanism, create focus etc.

Ein Buch, in dem ein windsurfender Scrum-Coach aus Norddeutschland mit Namen Stefan vorkommt, muss einfach ein großartiges Buch sein Die „Kraft von Scrum“ ist demnach großartig. Das Buch ist eine Scrum-Einführung nicht nur für Manager, verpackt in romanartige Geschichte, in der besagter Scrum-Coach Stefan einem angeschlagenen Software-Unternehmen durch die Einführung von Scrum den Weg aus der Krise weist.

In der Geschichte werden alle Elemente von Scrum am praktischen Beispiel eingeführt, so dass der Leser einen guten Eindruck davon gewinnt, was Scrum ist. Die Geschichte drumherum hat trotz windsurfendem Scrum-Coach keinen großen Inhalt. Sie ist halt Mittel zu dem Zweck, Scrum zu erklären und dafür ist sie vollkommen in Ordnung.

Das kleinformatige 150-seitige Buch lässt sich schnell durchlesen. An der im Vorwort genannten Lesezeit von 2-3 Stunden bin ich aber kläglich gescheitert. Naja, vielleicht habe ich einfach noch nicht die Qualitäten, um Manager zu werden…

Obwohl Scrum für mich nichts Neues mehr ist, hatte ich dennoch Spaß an der Lektüre und empfehle das Buch gerne weiter. Vielleicht ist es ja das passende Geschenk für den eigenen Chef? Für meinen Chef allerdings nicht; er hat das Buch schließlich ins Deutsche übersetzt und die Lokalisierung vorgenommen. In diesem Zuge wurde aus dem Scrum-Coach auch der windsurfende Stefan, warum auch immer

Direkt bei Amazon kaufen: „Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagement-Methode“

But why work physical tools better than software tools?

Software tools are used with another focus than physical tools. Software tools are used for managing (e.g. for managing the Sprint Backlog). Physical tools facilitate communication and cooperation. When somebody moves an index card at a card wall, the other team members can see that directly and step into a discussion. When somebody changes the status of a ticket in an issue tracker nobody notices immediately and starting a discussion is unlikely.

And facilitating communication is more important than easy management?

This question is easy to answer with a look at the agile manifesto: The first value statement of the agile manifesto reads „Individuals and interactions over processes and tools“. And principle number six says: „The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.“

Yes, communication and cooperation is king.

So whatever tool is used communication and cooperation should be the goal, not management. And I think that this goal is easier to achieve with physical tools than with software tools. But in the end the decision is up to the team.

Things to try

• The team should at least try physical tools for one Sprint to make an informed decision.
• As ScrumMaster shield the team from existing tools and do the mapping from the physical tool to the software tool during the trial period.

Im Mai wird das Buch „Agile Entwicklungspraktiken mit Scrum“ im dpunkt-Verlag erscheinen. Roman Pichler und ich sind die Herausgeber. Wir wollten ein deutschsprachiges Buch herausgeben, in dem die in Scrum gängigen Entwicklungspraktiken nach dem aktuellen Stand der Technik beschrieben sind. Dazu haben wir namhafte Coaches angesprochen und sie gebeten, jeweils ein Kapitel beizusteuern. Wir selbst haben ebenfalls das eine oder andere Kapitel beigesteuert und versucht, für einen einheitlichen Stil des Buches zu sorgen, so dass sich eine möglichst durchgängige Leseerfahrung ergibt. Ich hoffe, das ist uns gelungen

Die Autorenliste umfasst Alex Bepple, Jens Coldewey, Jutta Eckstein, Peter Friese, Andreas Havenstein, Johannes Link, Martin Lippert, Bernd Schiffer und Henning Wolf. Die Themen des Buches umfassen die Architekturvision und den inkrementellen Entwurf, Continuous Integration, Testgetriebene Entwicklung, Refactoring mit und ohne Refactoring-Browser, automatisierte Akzeptanztests, Pair Programming, Collective Ownership, Coding-Dojos und Code-Katas, Modellgetriebene Entwicklung und Entwicklungspraktiken bei verteilter Entwicklung.

Es ist seit langem bekannt, dass in größeren Scrum-Projekten kein Weg daran vorbei geht, dass das Team passende Entwicklungspraktiken auswählt. Die Entscheidung, welche Techniken eingesetzt werden, obliegt in Scrum dem Team. Aus unserer Sicht sollte das Team aber die in Frage kommenden Techniken kennen und beherrschen, um eine qualifizierte Entscheidung treffen zu können. Wir hoffen, das unser Buch einen Beitrag dazu leistet.

Wer sich bereits intensiv mit eXtreme Programming auseinandergesetzt hat, dem wird vieles bekannt vorkommen. Wir hoffen, aber auch diesen Lesern einen Mehrwert bieten zu können, indem das Buch den aktuellen Stand der Technik beschreibt.

„Agile Entwicklungspraktiken mit Scrum“ bei Amazon bestellen!

Bedürfnisse und Features auseinander zu halten fällt vielen Product Ownern sehr schwer. Heraus kommen dann Formulierungen, in denen Bedürfnisse und Key-Features identisch sind – nur leicht anders formuliert. Beispiel: „Menschen, die andere Menschen anrufen wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“

Wenn man vor der Frage steht, ob etwas wirklich ein Bedürfnis ist, hilft die Maslowsche Bedürfnispyramide. Sie hat diese Stufen (von unten nach oben):

1. Physiologische Bedürfnisse: Atmung, Schlaf, Nahrung, Wärme, Gesundheit, Wohnraum, Kleidung, Sexualität, Bewegung
2. Sicherheit: Recht und Ordnung, Schutz vor Gefahren, festes Einkommen, Absicherung, Unterkunft
3. Soziale Bedürfnisse: Familie, Freundeskreis, Partnerschaft, Liebe, Intimität, Kommunikation
4. Anerkennungsbedürfnisse: Höhere Wertschätzung durch Status, Respekt, Anerkennung (Auszeichnungen, Lob), Wohlstand, Geld, Einfluss, private und berufliche Erfolge, mentale und körperliche Stärke
5. Selbstverwirklichung: Individualität, Talententfaltung, Perfektion, Erleuchtung, Selbstverbesserung

Jetzt müssen wir uns lediglich die Frage stellen, auf welche Stufe unser „Bedürfnis“ fällt. Wo würde man das vermeintliche Bedürfnis „telefonieren“ verorten? Genau! Es passt da nicht rein. Man kann telefonieren, um in Kontakt mit seiner Familie oder seinen Freunden zu bleiben. Dann wäre genau das das Bedürfnis und wir könnten z.B. schreiben: „Menschen, die im sozialen Kontakt mit ihrer Familie bleiben wollen, können mit dem Festnetz-Telefon Call-2000 über das Festnetz telefonieren.“

• Upfront Architekturvision vs. inkrementeller Entwurf während der Sprints
• die Rolle des Architekten in Scrum
• Einsatz von Tools zur Architekturüberwachung in Scrum

Das Interview gibt es in einer Kurzfassung (siehe http://vimeo.com/19394558, 42 Minuten) und vollständig (siehe http://vimeo.com/19389234, 53 Minuten).

Red Pencil Code Kata

Nützliche Test-Mnemomics finden sich hier: http://www.qualityperspectives.ca/mnemonics.html

Ich komme eher aus der Programmier- als der Testecke und fand die Testing-Dojos vor diesem Hintergrund sehr spannend. Ich konnte dort sehr effektiv mitkriegen, wie die Tester arbeiten. Ich empfehle damit explizit auch allen Entwicklern, Testing-Dojos zu besuchen. Es kann wirklich sehr wertvoll sein, die Arbeit der Tester besser zu verstehen. Und es ist natürlich sehr wertvoll, selbst besser testen zu lernen.

The Blog-Health-o-Meter reads Wow.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 13,000 times in 2010. That’s about 31 full 747s.

In 2010, there were 41 new posts, growing the total archive of this blog to 506 posts. There were 37 pictures uploaded, taking up a total of 21mb. That’s about 3 pictures per month.

The busiest day of the year was January 7th with 150 views. The most popular post that day was Festpreise und schneller durch Scrum.

Where did they come from?

The top referring sites in 2010 were stefanroock.de, blogs.isixsigma.com, twitter.com, google.de, and stefanroock.blogspot.com.

Some visitors came searching, mostly for stefan roock, prolog cut, code kata, webcastellum, and roock.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Festpreise und schneller durch Scrum January 2010
4 comments

Kanban: Definition of Lead Time and Cycle Time March 2010
7 comments

Code Kata Bunkai: Prime Factors January 2010
11 comments

Profil ansehen February 2009

Scrum vs. Kanban: Ziel und Weg March 2010
4 comments

Das Buch kommt schnell auf den Punkt. Für jemanden, der Lisp noch nie gesehen hat und für den funktionale Programmierung ganz neu ist, könnte das Buch evtl. etwas schwer verständlich sein.

Ich finde, das Resultat ist eine einfache, fokussierte Sprache, die einfach zu lernen ist und Spaß macht. Dazu trägt auch bei, dass Clojure bewusst funktional ist und kein OO-Hybrid. So wird man als OO-Entwickler gezwungen, sich einer anderen Perspektive beim Programmieren zu öffnen und das ist auf jeden Fall nützlich – und sei es nur zur Horizonterweiterung.

Neben der eigentlichen Sprache bietet Clojure einige eigene Bibiotheken, insbesondere für die Programmierung paralleler Algorithmen. Durch die funktionale Struktur von Clojure-Systemen gestaltet sich dieses Themengebiet in Clojure viel einfacher als z.B. in Java. Ich bin zwar der Meinung, dass parallele Algorithmen im Moment deutlich überschätzt sind. Aber wenn man meint, dass man es braucht, dann sollte man sich Clojure auf jeden Fall mal ansehen.

Und wenn man keine parallelen Algorithmen braucht, sollte man sich Clojure auch ansehen und z.B. die eine oder andere Code-Kata in Clojure programmieren. Es hat schon seinen eigenen Charme, vollständig funktional zu programmieren.

1. Movement trumps sitting. So we moved all the time and sat down very seldom.
2. Talking trumps listening. We talked in pairs or in small groups during the whole training.
3. Images trump words. Whenever possible Sharon used drawings, metaphors, stories etc.
4. Writing trumps reading. We read few things and wrote down insights individually or as a workgroup.
5. Shorter trumps longer. The content delivery was split up in very small chunks, each shorter than 10 minutes.
6. Different trumps same. We applied lot’s of different practices to learn the content.

I highly recommend the training and the book to everybody who does training.

The Liskov Substitution Principle
The Liskov Substitution Principle (LSP): „[…] states that, if S is a subtype of T, then objects of type T in a computer program may be replaced with objects of type S (i.e., objects of type S may be substituted for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).“ (Source: Wikipedia).
The more formal definition of the LSP is: „Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.“ (Source: Wikipedia).
And to be complete, here is the definition of subtype: „In programming language theory, subtyping or subtype polymorphism is a form of type polymorphism in which a subtype is a datatype that is related to another datatype (the supertype) by some notion of substitutability, meaning that program constructs, typically subroutines or functions, written to operate on elements of the supertype can also operate on elements of the subtype.“ (Source: Wikipedia).

While subtype and LSP sound similar, there is a difference: The subtype relation normally is interpreted as a syntactical property. If the required methods are available on an object, everything is valid. The Liskov Substitution Principle goes beyond that and adds a requirement on the semantics of the methods.

Example (in pseudo code)

class A {

    public void m() { ... do something ... }

}

class B extends A {

    public void m() { 
        throw new Exception();
    }

}

In this case B is a subtype of A. B has the same methods as A. But the LSP may be violated. If the clients of A expect m to not throw an exception, B’s implementation of m breaks the LSP. Regarding the formal definition of the LSP („Let q(x) be a property provable about objects x of type T.“). The property q would be that the execution of m won’t throw an exception. This property is true for A’s implementation of m but not for B’s implementation of m. Therefore you shouldn’t use objects of class B where a client expects objects of class A. While that would be syntactically correct it isn’t semantically valid.

The Liskov Substitution Principle in class typed languages
In most statically typed object-oriented languages (like C++, Java, C#) the subtype relation is defined by inheritance between classes. When a class B inherits from a class A the defined type B is a subtype of A. The example above showed that the LSP may be violated due to specific method implementations provided by B.
Some languages (like Java) provide an interface concept. Interfaces only define the signature of methods but don’t provide method implementations. Classes implement interfaces and provide the method implementations. With interfaces the LSP is still a useful concept. The clients of an Interface C rely on a certain behaviour of the objects implementing the interface. Again the clients of C may assume that m won’t throw exceptions.

interface C {

    public void m();

}

class A implements C {

    public void m() {
        throw new Exception();
    }

}

In the example code A’s implementation of m will break the LSP.

These situations are clear and well understood. But what happens in programming languages with duck typing (like Ruby)?

The Liskov Substitution Principle in duck typed languages
In programming languages with duck typing (e.g. Ruby, Python, Smalltalk) classes don’t really define types. There is no type checking when assigning objects to variables or passing objects as method arguments. There is a kind of type checking when a method is called. It is checked that the method exists with a matching number of parameters.
Since classes don’t define types, inheritance in duck typed languages has nothing to do with the subtype relation or the LSP.
In a way clients define interfaces in an implicit way. Let’s look at an example:

def my_method1(a) do
    a.m1()
    a.m2()
    my_method2(a)
end

def my_method2(a) do
  a.m3()
end

Calling my_method1 with an object a will succeed if the object a provides the three methods m1, m2 and m3. This is the implicit interface the object a needs to implement. And with this implicit interface comes the clients expectation about the behaviour of m1, m2 and m3. That’s just the same as with the Java interface. If an object b provides m1, m2 and m3 but doesn’t fit the expected behaviour, the LSP is violated.

Conclusion
The LSP isn’t tied to inheritance or class based typing. It applies to duck types languages as well as to systems without inheritance. LSP is a concept that applies to all kinds of polymorphism. Only if you don’t use polymorphism of all you don’t need to care about the LSP.

Ich werde dort über ScrumBut vortragen und würde mich freuen, Euch zahlreich auf den XP-Days zu treffen.

Abstract meines Vortrags

Es gibt immer wieder die Frage nach Anpassungen an Scrum. Für Anpassungen, die man nur macht, um Probleme nicht lösen zu müssen, hat Ken Schwaber den Begriff ScrumBut geprägt. Im diesem Vortrag geht es um die Frage, welche Anpassungen an Scrum gerechtfertigt sind und von welchen man lieber die Finger lassen sollte.

Das Buch richtet sich an Produktmanager/Product Owner und ist aufgeteilt in drei Teile: People, Process, Product. Das Buch hat seinen Schwerpunkt auf Internet-Anwendungen. Viele der dargestellten Konzepte sind auf andere Anwendungstyper aber problemlos übertragbar.

Der People-Teil hat mir nicht so viel gegeben. Was dort steht, ist alles richtig, aber vieles davon schien mir selbstverständlich. Das ist vielleicht meinem agilen Hintergrund geschuldet. Anderes erschien mir zu unkonkret.

Die Teile über Prozess und Produkt fand ich viel besser. Hier stehen absolut richtige und wichtige Dinge für Produktmanager / Product Owner. Vor einem Scrum-Hintergrund liefert das Buch unter anderem konkrete und nützliche Hinweise dazu, was der Product Owner vor dem ersten Sprint zu tun hat. Besonders gut hat mir gefallen (weil es in der Praxis leider häufig anders gehandhabt wird):

• Cagan macht deutlich, dass es einen Unterschied zwischen Anwenderanforderungen und Produktfeatures gibt. Nicht alles, was sich Anwender wünschen, muss oder sollte umgesetzt werden.
• Das bedeutet aber nicht, dass der Produktmanager keinen Kontakt zu Anwendern haben muss. Das Gegenteil ist der Fall; er muss von Beginn an sehr engen Kontakt mit den Anwendern pflegen und kann diese Aufgabe auch nicht delegieren.
• Produktideen müssen validiert werden. Das kann bis zu einem gewissen Maße bereits vor Beginn der eigentlichen Entwicklung (erster Sprint) geschehen. Dazu sind Prototypen notwendig, die man direkt Anwendern zeigt und Feedback einholt. Auch das muss der Produktmanager persönlich tun und kann es nicht delegieren.

Es gab nur einen Punkt, wo ich eine andere Meinung vertrete als Cagan: Er erweckte bei mir mehrfach den Eindruck, als schwebe ihm eine sehr strikte Trennung zwischen Produktmanagement und Entwicklung vor. Ich glaube, dass man sich damit viele Chancen vertut und stattdessen eine sehr enge Zusammenarbeit zwischen beiden Parteien anstreben sollte, in der die Entwickler nicht einfach nur das liefern, was der Produktmanager bei ihnen bestellt, sondern zusammen mit dem Produktmanager konzipieren.

Fazit: Ein äußerst wertvolles Buch für jeden Produktmanager/Product Owner (auch wenn nach Wasserfall entwickelt wird).

Im Einzelnen (+ bedeutet, dass es besser ist als Thinkpad/Ubuntu, – bedeutet, dass es schlechter ist, = bedeutet, dass es ungefähr gleich ist):

Gehäuse
+ Aluminium fühlt sich edel an
– sieht aber mit etwas Abstand eigentlich genauso aus wie billiges Plastik
– ist etwas rutschig, wenn man zugeklapptes Gerät aufrecht trägt
– lädt sich bei passendem Wetter elektrostatisch auf, so dass man beim Anfassen manchmal leichte Stromschläge bekommt
– mattes Display kostet Aufpreis
+ Akku kann man nicht einfach so austauschen und es gibt anscheinend keinen Zweitakku
– es gibt keine Docking-Station, aber fast alles ist USB also tut es auch ein USB-Hub

Tastatur
+ beleuchtet
– Return-Taste sehr klein
– Cursor-Tasten sehr klein
– kein POS1/Ende: Im Prinzip durch andere Tastenkombinationen ersetzbar, aber die sind nicht in allen Apps verfügbar oder kollidieren mit Spaces
– keine Page-Up/Page-Down-Tasten
– Anschlag: nicht so gut wie bei Lenovo Thinkpad, aber besser als bei Billig-Dell
= Was auf PC „Ctrl“ heißt hier „Cmd“ und „Ctrl“ auf dem Mac ist was ganz anderes. Daran habe uch mich aber schnell gewöhnt.
– []|{} ist nicht auf die Tasten drauf gedruckt. Ich weiß, wo die Zeichen sind, habe beim Tippen aber doch immer eine leichte Verzögerung.

Trackpad
+ sehr groß und dadurch gewöhnungsbedürftig: am Anfang hatte ich da immer mehrere Finger drauf und habe versehentlich Gesten ausgeführt; daran habe ich mich aber schnell gewöhnt und habe jetzt Probleme mit den kleinen Trackpads der PC-Notebooks
+ durch die Größe arbeitet man eher mit beiden Händen (eine für Bewegung, eine für Klicken, was wiederum ganz angenehm sein kann)
+ Gesten für Scrollen, Zoomen, Drehen etc.

Sleep-Mode
+ Der Rechner erwacht super-schnell aus dem Sleep-Mode.

Betriebssystem/Oberfläche
+ die allermeisten Mac-Programme haben eine sehr gefällige und einheitliche Optik. Das ist deutlich angenehmer als unter Ubuntu.
– Spaces kommen nicht an Linux heran: sind mit der Maus nur umständlich zu benutzen
– Spaces: keine Visualisierung der offenen Fenster in der Menüleiste, dadurch schlechte Übersicht, was man wo auf hat
+ Dock: Nett
= Drucken ging nicht auf Anhieb mit MP620; ich musste Treiber bei Canon runterladen; immerhin gibt es welche für Mac und sie funktionieren auch gleich einwandfrei
= Spot-Light ist nützlich (ähnlich dem Ubuntu-Äquivalent)
– Finder kann kein FTP/SFTP (im Gegensatz zu Ubuntu Nautilus)
– Der Finder hat insgesamt ein paar nette Features und teilweise total verwirrendes Verhalten. Das scheint mir mal ein Komplett-Rewrite angesagt.
– Nach wir vor finde ich merkwürdig und auch eher störend, dass Programme weiterlaufen, auch wenn alle Fenster geschlossen sind.
– Die Anzeige der Akku-Restlaufzeit scheint mir ziemlich erratisch. Nach dem Laden des Akkus zeigt der Mac 5:30 Stunden an. Nach 30 Minuten harmloser Aktivität sind noch 2 übrig.

Applikationen
+ Skype ist einfacher zu installieren als unter Ubuntu; Video funktioniert auf Anhieb; keine Audio-Probleme
+ DVD geht sofort. Allerdings hat der mitgelieferte DVD-Player deutliche Usability-Defizite (z.B. beim Einschalten des Vollbild-Modus)
– MPEG, WMV gehen nicht auf Anhieb und man muss Zusatzkram im Internet finden und runterladen
– Safari öffnet Links immer in neuen Fenstern und man kann das in Safari selbst nicht umstellen. Wenn man „defaults write com.apple.Safari TargetedClicksCreateTabs -bool true“ in der Console startet und dann Safari neu startet, werden Links in Tabs geöffnet. Das ist mir alles zu nervig und ich benutze dann doch lieber Firefox auf Mac.
– Installation von Komponenten und Software ist in Ubuntu über das Software-Center viel eleganter gelöst als auf Mac. Aber vielleicht macht Apple hier ja mit dem geplanten Mac-App-Store Boden gut.
+ Synchronisation mit dem iPhone geht unter Mac natürlich nahtlos und ist unter Ubuntu leider eine ziemliche Katastrophe. Ubuntu erfordert eigentlich ein Android-Handy.

Programmierung
+ Ruby/Rails gleich drauf
= Installation aber sonst wie Linux: Compilefehler bei gem install webrat, weil man erst 2,5 GB XCode-Kram installieren muss
– Vervollständigung mit Tab in der Shell funktioniert nur Top-Level, aber nicht mehr danach (git pull origin master)
– Für Navigation in einer Zeile in der Shell muss man sich eigene Tastenkürzel merken oder irgendwas konfigurieren, was ich nicht verstanden habe.
+ TextMate ist ganz cool

Wie gesagt, meine persönliche Bewertung für meine speziellen Einsatzkontexte. Ich nutze z.B. durch meine Reiserei viele Multimedia-Funktionalitäten (DVD im Hotel), Skype zum Telefonieren etc. Wenn ich den Rechner nur zum Programmieren verwenden würde, würde ich Ubuntu den Vorzug geben.

We will puplish the results after the poll ended.

Die PDFs der Folien finden sich hier zum Download.

Ich hatte meinem Vortrag begonnen mit einem Beispiel für wirklich schlecht strukturierten Code (siehe Folien) und habe ein paar Fragen ans Publikum gestellt. Die Antworten finde ich ganz interessant (die Zahlen stimmen im Detail wohl nicht, weil ich sie aus der Erinnerung rekonstruiert habe – die Größenordung passt aber).

• Wer ist sich sicher, dass es so schlecht strukturierten Code bei ihm im Projekt/Unternehmen gibt? Meldungen: 40
• Wer ist sich sicher, dass es solchen Code bei ihm nicht gibt? Meldungen: 1
• Wer ist sich unsicher? Meldungen: 5
• Wer kennt TDD? Meldungen: 30
• Wer nutzt TDD? Meldungen: 20
• Wer kennt SOLID? Meldungen: 20
• Wer nutzt SOLID? Meldungen: 10

Das Ergebnis passte auf jeden Fall gut zur Argumentationslinie meines Vortrags. Obwohl zumindest ein Teil der Teilnehmer TDD und SOLID kennen und nutzen, scheint es nur geringe Auswirkungen auf die Code-Qualität zu haben. Nach meiner These nützt das beste Handwerkszeug nichts, wenn man es unter Druck nicht anwendet.

Daher mein Argument, wir müssten Berufsehre für unsere Branche etablieren: Wir sind stolz auf unseren Code und schreiben nichts, was unter diesem (subjektiven) Qualitätsstandard liegt. Nichts. Niemals. Und wenn wir dort angekommen sind, werden uns Vorgehensweisen wie TDD und Entwurfsprinzipien wie SOLID wirklich wichtige Dienste leisten.

Warum man das Manifesto for Software Craftsmanship unterzeichnen und sich ein Clean-Code-Armband besorgen sollte, steht in den Folien.

Inzwischen habe ich auch viele Beispiele aus meiner beruflichen Praxis, die die Handskizzen-These des Napkin-Ansatzes unterstützen. Ich arbeite z.B. in meinen Schulungen gänzlich ohne Folien, sondern erstelle Visualisierungen während der Schulungen auf Flipcharts. Es gab bisher keinen einzigen Teilnehmer, der das bemängelt hätte. Es gab aber sehr viele, die das Vorgehen explizit gelobt haben. Ein anderes Beispiel ist eine Konzeptarbeit für ein großes deutsches Unternehmen. Ich habe die ganze Konzeption am Flipchart gemacht und auch die Management-Präsentation der Ergebnisse mit Flipcharts gehalten. Die Resonanz war außerordentlich positiv. Auf Wunsch des Kunden hin habe ich danach die Flipcharts 1:1 nach Powerpoint überführt, nur eben professionell mit den Zeichen- und Formentools von Powerpoint. Kommentar des Kunden: „Danke für die Powerpoint-Präsentation. Hm. Die Flipcharts waren irgendwie doch besser.“

Unfolding the Napkin ist das Folgebuch zu The Back of the Napkin, das ich bereits in einem früheren Blogpost empfohlen hatte.

Beide Bücher widmen sich dem Thema der Visualisierung, um Probleme darzustellen und zu lösen. Der passende Untertitel zu „Unfolding the Napkin“ lautet entsprechend: „The hands-on method for Solving Complex Problems with Simple Pictures“. Während das erste Buch die Konzepte eher theoretisch erläutert, ist „Unfolding the Napkin“ ein Praxisbuch mit vielen Übungen, die man direkt für sich ausprobieren kann. Ich fand „The Back of the Napkin“ schon sehr schön, finde „Unfolding the Napkin“ aber noch besser. Ich vermute, dass man „Unfolding the Napkin“ auch dann sehr gut verstehen kann, wenn man „The Back of the Napkin“ vorher nicht gelesen hat.

Meiner Meinung nach ist das Buch extrem wertvoll für jeden, der Probleme oder Konzepte erstellen oder präsentieren will oder muss: Trainer, Berater, Entwickler, …

Kanban has two key properties:

1. Limit work in progress to an upper limit with a preference for lower limits.
2. Pull from upstream processes.

Therefore in Nabnak you would

1. Ensure that work in progress never falls below a bottom limit with a preference for higher limits.
2. Push work to downstream processes.

OK, that sounds completely ridiculous. But when would you possibly do such a thing. Perhaps when two conditions hold true:

1. Developers are so expensive that a high utilization outperforms all other metrics.
2. At the same time developers are too dumb to pull work. Somebody has to push the work to them.

These two conditions seem mutually exclusive. Therefore Nabnak is in fact complete nonesense. But guess what: I am not the inventor of Nabnak – I just gave it a fancy new name. Nabnak was formerly known as waterfall.

You may not like Kanban but it is not a new name for waterfall. If there is a new name for waterfall it is reversed Kanban: Nabnak.

P.S.: In fact there may be useful applications of a minimum work in progress limit for certain columns of a Kanban board. I may blog about that in another article.

Sorry, but that is bullshit. If the Scrum meetings feel like wasteful overhead, it is almost always your own failure.

Focus is one of the Scrum values. If your Scrum meetings feel wasteful, they need better focus. Stop doing the things that don’t provide value.

Let’s look at the meetings one by one.

Estimation Meeting

During the estimation meeting two things should happen:

1. The product backlog items are estimated by the team.
2. More important: Knowledge is shared between Product Owner and Team and the Team participates in definition, splitting and refining product backlog items.

If the Product Owner doesn’t have to forecast a release date or development effort, he could simply skip point 1. An alternative could be to use a very rough estimate and simply use an estimation of 1 story point for every backlog item.

If the product backlog items are simple and clear point 2 may not be neccessary. In that case you could simply skip it.

If both points aren’t neccessary you can skip the whole meeting. There is a reason that the estimation meeting is not an official part of Scrum.

Sprint Planning

The goal of the sprint planning is of course to plan the Sprint. It is dependent on the team how it is done best and how much effort the team has to invest. I have seen teams doing a Sprint Planning in a few minutes.

Doing a task breakdown is a proven practice during the Sprint Planning but it is not a must. If the team can generate value with only considering the stories, the team doesn’t need to do a task breakdown during the Sprint Planning. The team could do an ad-hoc task breakdown when it begins working on the story. If the stories are really tiny the team may need no task breakdown at all.

Sprint Review

If the Product Owner is colocated with the development team he should have seen the implemented stories before the Sprint Review. Therefore there may be no need to present the stories again to the Product Owner during the Sprint Review. But there is much more to the Sprint Review. The Product Owner should invite the stakeholders to the Sprint Review meeting so that they can get a first-hand impression about status and progress of the development.

Sprint Retrospective

The Sprint Retrospective is the focus point where the teams tries to improve. If the retrospectives feel like waste, the facilitator is probably not doing his job effectivly.

Daily Scrum

The 15 minutes of the Daily Scrum should help the development team to focus on the next step within the Sprint. The team finds out where it stands and defines the plan for the day. A team may or may not use the full 15 minutes. But if there is a team the members simply have to coordinate. Within very small teams (e.g. 2 persons) there may be no need for a Daily Scrum. But even in these cases I have seen Daily Scrums to be very useful.

Similar to the retrospectives: If the Daily Scrum feels like waste, probably the ScrumMaster isn’t facilitating effectivly.

Assumptions

There are two assumptions underlying this blog post:

• You want to work with a team and not just a group of people.
• You want to work with timeboxed Sprints.

If one of these assumptions doesn’t hold true, one may come to other conclusions.

Nützliche Literatur zu dem Thema findet sich z.B. in den beiden Büchern „Coaching – erfrischend einfach“ von Daniel Meier und Peter Szabo sowie „Wege zur erfolgreichen Teamentwicklung“ von Daniel Meier.

Das erste Buch erklärt die Ideen und Techniken des lösungsorientierten Coachings auf individueller Ebene. Der Hintergrund ist allgemeines Coaching und nicht speziell IT. Die beschriebenen Techniken lassen sich aber leicht auf IT-Kontexte (z.B. für die Arbeit als ScrumMaster) übertragen. Das Buch ist angenehm kurz und leicht verständlich geschrieben.

Das zweite Buch beschreibt, wie man Lösungsorientierung für Teams einsetzt. Auch dieses Buch ist leicht verständlich geschrieben.

Wer sich näher mit dem Thema Lösungsorientierung beschäftigen möchte, dem lege ich diese beiden Bücher als Einstieg nahe (und natürlich das oben beschriebene Retrospektiven-Training