sebs.freeflux.net

So, ich hoffe jetzt das ich den Kollegen vom Egolab nicht an den Karren fahre. Leider enthält sein Artikel über den agilen Kram, wenn man es direkt auf Scrum abwälzt ne Menge Fehler, die werd ich mal kommentieren. Und da ich das Fremdwort für Naturmedizin nicht im ersten aufschlag schreiben konnte habe ich einen anderen Begriff für den Titel gewählt, vielleicht kommen dann auch endlich mal Leser auf dieses Blog. ;) 

http://blog.egolab.de/archives/99-Tanatose-in-agilen-Environments.html#extended

Fangen wir mal an den sympathischen Käfersammler dezent zu analysieren: 

Er schreibt: Scrum Teams schätzen im scrum planning meeting mit verschiedenen Methoden die Aufwände der Features aus dem Projekt-Backlog, die sie im nächsten Sprint bzw. der kommenden Iteration abarbeiten wollen - oder von der Komplexität und der Sprint-Dauer ausgehend umsetzten können.

Nein, tun sie nicht und das zweimal nicht. Also einmal ist der Titel des Meetings Estimationmeeting, bei uns auch die sog. Schätzitals (Lat. Gentitalus-Timus). Diese finden immer mal wieder während des Sprints statt und nicht zu Start oder Ende. Planning hingegen dient dazu die Entwickler zu einer Zusage zu bewegen was in den nächsten 4 Wochen stattfindet. Einige Anmerkung zum Estimationmeeting is not planning Komplex:

• Es findet nicht am Sprint Start oder Ende statt
• Items werden nicht nur einmal sondern öfter geschätzt, bei mehreren Iterationen oder schon vorliegender Erfahrung werden die Schätzungen genauer
• Es wird nur ein Item betrachtet und nicht die Dauer des Sprints in Betrach gezogen. Dies würde zu defensiven Schätzungen führen.
• Eine Schätzung wird nicht in Zusammenhang mit einem Start und Ende der Bearbeitung gebracht.

Er schreibt: Beliebtes Tool ist das strip planning poker, auf das ich hier nicht näher eingehen möchte.

Hier tut es im Falle eines Falles auch eine gepflegte Schlägerei, bei der sich dann im Zweifel der Chef durchsetzt, man will ja nicht durch Frakturen im Leitungskreis der Firma den nächsten Aufstieg in die Abteilug mit der tollen Kaffeemaschine verderben. Eine weitere Alternative sind auch Duelle zwischen den Entwicklern mit Schusswaffen bis nur noch einer steht, the last man standing ist ja dann auch nach Darwin der stärkste. Dazu sollte man aber über genügend Nachschub an gewogenen Softwareentwicklern mit gesundem Agressionspotential verfügen. Die Mailingliste der php-internals sollte aber hier Abhilfe schaffen, wer sich dort einmal durchgesetzt hat, der kann in Real-Life-Gewalt nur gut gebildet sein.

Er schreibt: Nun ist es nicht unüblich, dass sich ein Team mit der Komplexität oder dem Arbeitsaufwand für die Umsetzung eines Features verschätzt.

Fast richtig, es ist ganz normal und auch gewollt. Auf Dauer sollten die Fehleinschätzungen doch geringer werden. Erstmal ist wichtig das jeder seine Schätzitals auf den Tisch legt wobei ich nicht weis wie das bei weiblichen Entwicklerinnen läuft, die machen mit unskein Scrum (mehr). nach 2 Drei Iterationen hat sich das dann geregelt. Hinweise

• Be zu großen differenzen (der zeitschätzungen, nicht der Genitalien) einfach das feature zerteilen. Es ist die Arbeit wert. Lieber ein kleines Ding aber auf Abruf als ein Riesenteil das unter premature Finalization leider oder gar nicht kommt. Die Entwickler muessens ja wissen. Nicht das sie nur kleine Teile lieben .. aber  ... lassen wir das.
• Abweichungen können auch auf fehlende Information schliessen lassen. Also hier den Kunden/Product Owner nochmal Hausaufgaben machen lassen und gar nicht erst lang rumdrucksen .. am Ende kommt ja doch heraus wie groß es ist.

Er schreibt: Da so eine Fehleinschätzung auf dem Zeithorizont in beide Richtungen geschehen kann, schreibt das Scrum vor, dass bei verbleibender Zeit geeignete Features aus dem Backlog in den Sprint mit einfließen müssen.

Großes Kino, vielleicht setzt der Herr vom Egolab sich hier zu oft mit Insekten auseinander und nicht z.B. der Konditionierung von Mäusen. Einem Entwickler für das Erbringen von Extraleistungen einen Extratask aufs Auge zu drücken wäre als gäbe man der Maus die man grade zum drücken des Schalters zur Essensausgabe Konditioniert hat einen 220V Stromschlag. Super.

Er schreibt: Das bedeutet aber, dass sich Teammitglieder in ihrer Abgabe von Restzeit-Schätzungen (estimated hours) pro Feature nicht tot stellen. D. h., sich für den rest des Sprint nicht auf die faule Haut legen und Blogartikel schreiben, die niemand lesen muss. 

Jaja, ihr macht die Dikataturnummer, wenn ich meinen 8er Task (wahrsch. auch noch Stunden) in 6 Abgearbeitet habe dann bekomm ich als Belohnung noch gleich mal 2 Stunden Extraarbeit, die sich dann aber irgendwie, weil der Server grad spinnt oder die Replikation Opiate nimmt als 4 rausstellen. Spitze. Ich pers. würde noch vor Antritt meiner Stelle alle youtube videos von sich totstellenden Hunden anschauen und mir Medikamente zur Verlangsamung des Herzschlages besorgen die dann auch sicherstellen das der sofort gerufene Wiederbelebungsexperte mich vor beginn der Teufelsaustreibung (Diagnose: bloggbesessen!) gleich für komplett tot erklärt. Bei uns gabs auch das eine oder andere komische Gesicht als ich das dem Management erzählt habe: Ein Team das fertig ist mit dem Sprint geht heim bzw. grillen, oder wie in unserem Falle, beschäftigt sich mit dem ganzen Schrott der noch so anfällt: Sog. technische Tasks. Die fallen an, werden aber nie gemacht. Alternativ mal ein paar Tage Extraurlaub (Die Schätzitals baumeln lassen). Es gibt immer was zu tun, aber oft gehörts nicht zum Sprint. Wenn man nicht will das die Firma um einen Implodiert schaut man halt das da was vorwärts geht (hat z.B. das ssh immer noch nur 256 verschiedene Passworte?)

Der sich einstellende Fluchtreflex kann vom Scrum-Master dahingehend sublimiert werden, in dem er den war room unter Verschluss hält.Mehrmalige Anwendung ist ratsam und wird den gewünschten Effekt erzielen.

Alternativ folgende (unvollständigen Basics einhalten) 

• Nichts ins Planning aufnehmen was nicht 24h vorher geschätzt wurde
• Nach 2-3 Iterationen ist klar wieviel das Team arbeiten kann und auch die Schätzungen sind genau
• Auch ein netter Diktator führt zum Fluchtreflex (siehe Kim Jong Ill), einfach Deployen und den LeutenLuft zum Atmen lassen. Oder sind die alle nur eingestellt weil der Scrummaster denkt das sie auf Ohrfeigen als Encouragement mehr Verantwortung als reaktion zeigen? 
• Mit keinem Verhalten defensives Schätzen fördern, einfach schätzen lassen und jeder muss das vertrauen haben das er sich mit der Schätznummer keinen Ärger oder Stress einfängt.
• Mal für 5 Pfennig nachdenken wie man funtioniert hat als man noch nicht der Agile-Kaiser in Scrum-Rom war, der Abends in seinen Palast in der ewigen Stadt geht und sich da von halbnackten liebessklaven den Nacken massieren lässt (während er den anderen Scrum Teams in seiner privatarena beim Schätzitals-Abschlachten zusieht) 

Soweit so breit, ich  hoffe jetzt ist keiner sauer auf mich oder so, aber ich weis inzwischen wie der Hase läuft. Insbesondere die Abteilung "Mimimi-bei-uns-geht-das-so-nicht" mit ihrer soziodemografisch gleichmässigen Aufteilung über Fixed-Price-Dienstleister, Interne Teams und "was da sonst noch so rumläuft" mit der statistischen Auffälligkeit "Ich bin zertifizierter Scrum-Maser/ProductOwner" /ja/( ) /nein/(x) ist immer ganz laut mit dem Hinweis darauf das es ned so gut läuft im agilen Zeug aber theoretisch wäre es ja ne gute Idee. Leute, es geht hier wirklich um die Details, erst mal stick to the fucking rules. Die Mechaniken dahinter sind wrklich komplex und müssen ordentlich getestet werden. Aber zwei Sachen kenne ich aus unserem Team nicht wirklich: Leute die sich nicht engagieren wenn das (Sprint)Backlog leer ist (im Gegenteil) und Sprints mit mehr als 8% Minusabweichung. 

Und zum Abschluss die inoffizielle Message dieses Blogs

http://www.youtube.com/watch?v=6wS5xOZ7Rq8&feature=channel_page

s/egolab/jo @ 26.03.2009 02:44 CEST
Sebs, fein! Der PuDnkt ist ein ganz anderer: Scrum klappt. Nicht-Richtig-Scrum klappt nicht (unabhängig von meiner hingepfuschten Darstellung).

Eigentlich ganz einfach ;-)

xenjo @ 26.03.2009 02:48 CEST
Bevor ich's vergesse.

Gaylord Aulke @ 10.08.2009 13:32 CEST
Ich kann (als wegen meines Vornamens vorbelasteter) solche Fachbegriffe nur unterstützen!

Was Xenjo angeht: Jeder der ihn erlebt hat weiß: Er ist der geborene Diktator. Mehr Dominanz wäre schon jugendgefährdend.

Aber das Grundthema beider Blogeinträge kann ich auch aus meiner (teils leidvollen) Erfahrung absolut bestätigen:
Bei agilen Methoden ist es extrem wichtig, dass man sie (im Detail) richtig umsetzt.

Das widerspricht leider landläufigen Management-Einstellungen, nach denen es nur wichtig ist, dass etwas erledigt ist und nicht, wie gut es im Detail gemacht wurde. Ich glaube viele agile Ansätze gehen deswegen in die Hose.

House Of Harlow @ 24.05.2010 22:13 CEST
I sell House Of Harlow come and take a look, its great.

Designer Clothing @ 21.06.2010 22:47 CEST
I sell Designer Clothing come and take a look, its great.