RENEMT_DE

… das wünsche ich der geneigten Leserschaft. Entgegen völlig anderer Pläne werden wir den Jahreswechsel ganz in Familie verbringen. Nämlich zusammen mit unserem Sohn im Krankenhaus.

Also: Rutscht vorsichtig – sonst treffen wir uns hier noch. Und das wollen wir doch nicht, oder?

In einem Kommentar zu einem meiner privaten Artikel beschwert sich Kai Müller, dass er auf dotnetgerman zu viele “private [...] Belanglosigkeiten” lesen muss:

Hast Du eigentlich fast nur privates mitzuteilen? Seit Du wieder angefangen hast zu bloggen gab es zwei mäßige Beiträge zu Scrum, und ansonsten aber ganze fünf über Dein Privatleben … das nervt!

Klar muss ich Dein Blog nicht lesen, aber man kommt z.B. bei blogs.dotnetgerman.com ja gar nicht drumrum, ständig auch Deine Belanglosigkeiten lesen zu müssen .

Mach doch bitte wenigstens eine Kategorie für DNGB, und gut ist.

Lieber Kai,

vielen Dank für deine konstruktive Kritik. Vielleicht dürfte ich dazu ein paar Dinge anmerken.

1. Das hier ist MEIN Blog – d.h. ich kann hier schreiben, was ich möchte. Und ich schreibe nun mal sowohl “private [...] Belanglosigkeiten” als auch berufliche Erfahrungen.

2. dotnetgerman hat mich ungefragt in deren Crawler aufgenommen und ich habe – soweit ich weiß -  keinerlei EInfluss darauf, welcher Artikel bei Ihnen erscheint und welcher nicht. Da ich zukünftig aber nicht mehr über .NET-Entwicklung schreiben werde habe ich die Betreiber gebeten, mich nicht mehr bei sich zu veröffentlichen da ich schon einsehe, dass Artikel über Bettwanzen für Entwickler eher uninspirirend sind.

Ich wünsche dir – und allen anderen Lesern – trotzdem frohe Feirtage und ein gesundes Jahr 2010.

Your-Decision.de ist auf den Artikel “40 Seriously Funny Print Ads” im Webdesignerdepot-Blog gestoßen. Muss man sich unbedingt mal ansehen. Kleiner Vorgeschmack:

Hier hatte ich vor fast vier Jahren schon einmal drüber geschrieben: Riesenmikroben. Plüschige Parasiten und niedliche Menschheitsplagen zum Liebhaben. Nun habe ich es tatsächlich getan und mir eine Erkältung und eine Bettwanze nach Hause geholt:

Niedlich.

So sah es heute Vormittag vor der Firma aus. Bei angenehmen -9°C draußen. Drinnen war es etwas wärmer, zum Glück.

Als ich Scrum einführte hat das Team mit mir unsere “Definition of Done” erarbeitet. Seitdem hängt sie öffentlich an der Wand und jeder kann sie einsehen. Die Punkte ähneln vermutlich denen, die jedes gute Scrum-Team festgehalten hat: “Potential shippable”, so weit wie möglich mit Unit-Tests abgedeckt, unseren Coding-Standards entsprechend, getestet und dokumentiert.

Nun ist mir aufgefallen, dass wir jedes mal, wenn wir ein neues Release freigeben, überlegen müssen, ob das Changelog auch alle (für den Anwender interessanten) Änderungen enthält. Bei neuen Features ist das ja noch relativ einfach: Userstories abschreiben. Bei Bugs wird es schon schwerer – da müssen nämlich unter Umständen etliche rote Zettel am Taskboard durchgeschaut – und sich dann noch erinnert werden, was die Stichpunkte darauf bedeuten.

Um die Sache zu optimieren haben wir unsere Definition of Done erweitert: Die Aktualisierung des Changelogs, sobald eine Story (oder ein Bugfix) implementiert wurde ist neu dazu gekommen. So kann man die DoD auch prima als Checkliste dafür verwenden, ob ein Zettel am Taskboard auch tatsächlich nach “Done” umgehängt werden darf.

Boris Gloger, der mein Certified Scrum Master – Training durchgeführt hat, sagte zwei Dinge, die mir im Ohr geblieben sind.

“Als Scrum Master muss man sich mental von seinem Job verabschieden – erst dann kann man wirklich effizient arbeiten.”

und

“Scrum löst keine Probleme in einem Unternehmen – es macht sie nur sichtbar.”

(Von Stephan’s Place @ flickr)

Heute gab es für alle Mitgliedern der Entwicklungsabteilung Feedback-Gespräche in der Firma. Mit unserem Abteilungsleiter (der gleichzeitig auch PO ist) und unserer Human Resources – Verantwortlichen. Im Grunde sehr positiv, ich machen anscheinend einen guten Job Bermerkenswert war jedoch das HR-Feedback: Da waren einige Dinge auch etwas negativ aufgefallen.

Interessanter Weise sind die bemängelten Umstände direkte Auswirkungen des Fakts, dass ich mich bemühe – spätestens seit dem CSM-Training – den Scrum Master auch konsequent zu leben. Als Scrum Master ist man quasi ein Schäferhund: Man hält sein Team zusammen und treibt es in die richtige Richtung – man verteidigt es aber auch nach außen. Leistet das Team gute Arbeit braucht es sich keine Vorwürfe gefallen zu lassen. Arbeitet das Team hochkonzentriert darf man es nicht mit – natürlich immer “extrem wichtigen”, aber tatsächlich nicht kritischen – Fehler und Wünschen aus seinen Aufgaben reißen. Das senkt die Performance, weil die Entwickler umdenken müssen, um sich mit dem neuen Problem zu befassen.

Natürlich bedeutet das eine Umgewöhnung für alle Beteiligten. Früher kam jeder Anwender (und auch der CEO) mit Fehlern und Wünsche direkt zum ihm verantwortlich erscheinenden Entwickler. Heute muss er damit zum Scrum Master oder Product Owner, bekommt sogar einen Rüffel, wenn er sich nicht daran hält. Und Wünsche werden – im Gegensatz zu Fehlern – auch nicht mehr sofort berücksichtigt, sondern vor dem Hintergrund des Geschäftswertes bewertet und priorisiert.

Außerdem fordert Scrum Konsequenz. Es gibt nur eine Hand voll fester Rituale, mit festen Terminen und harten Timeboxen – und die sind von allen Beteiligten unbedingt einzuhalten. Es sei denn die Firma brennt. Sofern das Umfeld bis dato Pünktlichkeit bei Meetings und Konsequenz in deren ungestörter Durchführung eher als verhandelbar betrachtete erfordert natürlich auch das ein Umdenken.

Letztendlich steckt jedoch hinter den Scrum-Prinzipien ein ganz einfacher und verständlicher Zweck: Die (teure) Arbeitszeit der Entwickler optimal zu nutzen und nicht zu verschwenden. Eine konsequente Verfolgung dieser Ziele sollte daher jeder Firma Jubelschreie entlocken.

Letztendlich gibt es so etwas wie “ein bisschen Scrum machen” nicht. Entweder, die Firma steht vollkommen dahinter – oder sie macht kein Scrum.