Archiv für den Monat Juli 2013

Certified Scrum Product Owner Schulung

Im Zeitraum vom 18. bis 20. Juni nach ich an einer Certified Scrum Product Owner Schulung bei den Trainern Dr. Jürgen Hoffmann und Peter Beck teil. Den Kurs hatte über die wibas GmbH gebucht. Als Veranstaltungsort wählte ich die NTT DATA Ettlingen Academy.

 

Location

Das Angebot an kostenfreien Parkplätzen war optimal, sodass unnötig langes Suchen am frühen Morgen ausblieb. Die verfügbaren Räume waren schön hell mit genügend Platz für die knapp 20 Kursteilnehmer. Leider mangelte es an einer Klimaanlage, was mir bei tropischen 35°C besonders negativ auffiel. In den kleinen Pausen konnte man sich mit frischem Obst und Gebäck stärken; zur Mittagszeit gab es Essen in der Kantine, welche einen schönen Balkon mit Teich zur geistigen Erholung bot.  Bedenkt man die kurze Strecke für Karlsruher war es geradezu ideal..

 

Die Trainer

Eine kurze Recherche ergab, dass es sich um zwei etablierte, langjährige Trainer handelte, die in der Community recht arriviert sind. Deshalb bekamen die Teilnehmer das, was sie vermutlich am meisten hören wollten: Praxisberichte. Die Frage “Wie habt ihr das bei euch gemacht” kam so ziemlich jedem über die Lippen. Hierfür gibt es von mir “volle Punktzahl”. Die Aussagen waren klar, die didaktischen Methoden variierten in einem gesunden Maße und durch die Backlogs der einzelnen Gruppen konnte jeder in die Themenfokussierung eingreifen. Negativ fielen mir folgende Dinge auf:

Aufgrund meiner T-Shirt Wahl, welche meine Entwicklerwurzeln offen zeigte, wurde wohl der Eindruck bei den Trainern perpetuiert, dass man mich auch als solchen “coachen” sollte. Zumindest empfand ich dies teilweise so bei Gesprächen. Als ich mich zur Aussage, dass es gängige Praxis sei die Entwickler die Product Backlog Items schreiben zu lassen, kritisch äußerte und darüber diskutieren wollte, wurde dies einfach abgetan. Inzwischen habe ich vermehrt in der Community, unter anderem am .NET Open Space, das Thema aufgeworfen. Mein Resümee: Gängige Praxis sieht anders aus. Allerdings möchte ich fairerweise an dieser Stelle anmerken, dass selbst in der Fachliteratur (u.a. im Werk von Boris Gloger) ähnliche Aussagen stehen. Mir geht es jedoch darum, dass ich mich eine Schublade gesteckt sah, sodass eine konstruktive Diskussion in diesem konkreten Fall nicht zu Stande kam.

Ein weiterer Punkt waren ein paar wenige (!) fragwürdige Aussagen. Eine davon implizierte, dass die Definition of Done immanent unvollständig sein müsse, wenn das Produkt keine 100%ige Evolvierbarkeit aufweise.

Rein subjektiv gefielen mir die ausgewählten Planspiele nicht. Das lag vielleicht daran, dass es sich nicht um Geschäftsprozesse handelte. Vielleicht auch an den konkret gewählten Szenarien, wie das Bauen eines Lego-Parks für Kinder. Bei der zu Beginn gewählten Teambildungsmaßnahme mussten Seesterne gelegt werden. Eine gängige Praxis, wie ich von Bekannten mit selbiger Zertifizierung erfahren habe. Allerdings wurde es so umgesetzt, dass die Teams bereits blind in den Raum kommen, die Materialien finden und Position begeben mussten. Wenn aber die erste Gruppe direkt am Eingang stehen bleibt, dann ist das Resultat, dass mehrere Teams vorerst einfach rumstehen müssen, bis der erste Durchgang beendet wurde. Der Lerneffekt ist für mich genauso gegeben, wenn die Teams bereits im Raum mit den Materialien platziert wären. Sehr positiv wiederum kann ich über das Fallbeispiel zur Schätzung in Story Points im warmen Garten berichten. Die Teams sollten sich hierbei auf die Komplexität zum Entfernen von Gegenständen für den bevorstehenden Besuch von Obama (der an diesem Tag tatsächlich in Berlin war) einigen. Das fing bei Aschenbechern an, ging über Tische und hörte bei Autos auf.

 

Zur Schulung

Als einziges Angebot, welches ich in der näheren Umgebung finden konnte, ging dieser Kurs über 3 Tage. Die üblichen Schulungen sind in der Regel auf 2 Tage ausgelegt. Planspiele sind aber relativ zeitaufwendig und der Wunsch nach Erfahrungsberichten der Trainer führt zu starken Verzögerungen. Deshalb kann ich nur jedem empfehlen 3-tägige Seminare zu bevorzugen.

Die Kosten lagen auf gängigem Marktniveau. Bei entsprechendem Vorlauf wird Frühbucherrabatt gewährt.

Als Schulungszeiten waren 10-18 Uhr am ersten Tag und 9-17 Uhr an den darauffolgenden Tagen geplant. Diese wurden recht gut eingehalten, was nach meiner Erfahrung bei Schulungen sonst nur selten funktioniert.

Bereits vor Kursbeginn erhielt ich eine E-Mail mit Vorschlägen zur Vorbereitung. Während der Schulung wurde ein eigens dafür eingerichteter DropBox Ordner kontinuierlich aktualisiert. Darin landeten neben kostenlosen Ebooks die Fotoaufnahmen der erstellten Materialien (quasi eine Timeline der Flip Chart Blätter), sowie diverse Vorlagen und weiterführende Materialien. Ein dediziertes Dokument mit den erarbeiteten Inhalten gab es nicht.

Das klar kommunizierte Ziel war es jeden in die Lage zu versetzen, entscheiden zu können, ob Scrum mit seinen Prinzipien und Werten für das eigene Unternehmen geeignet ist und sich etablieren lässt. Der Fokus lag natürlich auf der Rolle des Product Owners, ist aber auch nach Aussagen der Trainer mit der des Scrum Master zu 80-90% deckungsgleich. Die restlichen 10-20% wurden dann aber speziell hervorgehoben bzw. ggf. auch intensiver erörtert.

Wer viele Planspiele, viel Eigenarbeit, viel Stehen und wenig PowerPoint Slides bevorzugt, kommt definitiv auf seine Kosten. Mir persönlich hätte ein wenig mehr “klassische” Schulung mit theorielastigerem Vorgehen besser zugesagt. Nach meinem Gefühl kommen dadurch mehr Fragen auf, v.a. abseits der der trivialen Oberflächenthemen. Das bestätigte sich für mich im Nachhinein beim Lesen der oben genannten Lektüre von Boris Gloger wieder. (Wenn Folien übrigens schlecht sind, dann weil der Autor Fehler gemacht hat, nicht weil diese per sé schlecht sein müssen, siehe meine Buchempfehlung.) Allerdings verhält es sich so, dass ich nach einer theorielastigen Sitzung der Einzige war,  der diese positiv bewertete. Deswegen gilt: Die Schulung muss nach der eigenen Präferenz ausgewählt werden.

 

Fazit

Auf einer Skala von 1 bis 10 gibt es von mir eine 7 mit dem klaren Hinweis, dass ich die Schulung für Menschen mit anderem Lernmodus durchaus bei 9-10 sehen würde. Darüber hinaus halte ich eine derartige Schulung für ganze Scrum Teams durchaus für förderlich, speziell wenn sich Fallbeispiele und Themen mitbestimmen lassen. Es bleibt ein positiver Rückblick mit kleinen Makeln und dem Ratschlag, dass auch das Seminar das Lesen entsprechender Fachliteratur nicht ersetzt (vice versa!).

WordPress deaktiviert Suchmaschinen Indizierung

Kürzlich hat WordPress bei einem Update das Standardverhalten für die Google Indizierung geändert. Seit der Aktualisierung ist die Indizierung durch Suchmaschinen deaktiviert. Ob euer Blog davon betroffen ist, könnt ihr einfach über den W3C Link Checker prüfen:

w3c

Zur Reaktivierung müsst ihr euch einloggen, in den Admin Bereich gehen und dort unter Einstellungen – Lesen im Abschnitt „Sichtbarkeit des Blogs” auf “Suchmaschinen erlauben, diese Seite zu indexieren”.

image

Die entsprechende WordPress Hilfeseite dazu gibt es hier. In diesem Foreneintrag wird nochmal darauf hingewiesen, dass es eine Weile dauern kann bis ihr wieder im Index landet.

Build Script Interaktion mit TeamCity

Kürzlich standen wir vor der Aufgabe aus dem Build Skript, welches bei uns in Ruby geschrieben ist, Informationen an TeamCity, unseren Build Server, zu senden. Konkret wollten wir die interne Versionsnummer unseres Produkts in der Oberfläche anzeigen. Dazu muss lediglich im Skript eine Konsolenausgabe getätigt werden, die einem gewissen Format entspricht. In Ruby ist das der Befehl ‘puts’:

puts „##teamcity[buildNumber ‚#{build}‘]“

Dabei ist ‘build’ unsere interne Versionsnummer, die wir zuvor ermittelt haben. In einem Batch-Skript wäre dann der Echo-Befehl abzusetzen. Hier findet sich die passende Hilfe von JetBrains, welche weiteren Möglichkeiten es gibt.

Alexander Groß bietet hier ein fertiges Ruby Skript an, welches ihr bei euch einbinden könnt.

Meine tägliche Portion Git – Passwort Eingabe deaktivieren

Wer nicht bei jeder Git Operation wie dem Pushen oder Pullen ein Passwort eingeben will, der muss dazu den Private Key im Verzeichnis %userprofile%\.ssh\ ändern. Dazu führt man in der Git Bash folgenden Befehl aus:

ssh-keygen -f id_rsa -p

Enter old passphrase:

Key has comment ‚id_rsa‘

Enter new passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved with the new passphrase.

 

Wer erst noch ein Schlüsselpaar erzeugen muss, kann natürlich von Anfang an das Passwort auslassen. Eine sicherere Alternative ist es einen SSH Agent zu installieren, der den Key entschlüsselt vorhält.

NET Open Space – Interview mit Constantin Klein

In meinem Interview am .NET Open Space in Karlsruhe (#nossued) spreche ich mit Kostja über seine favorisierten Sessions und den Vergleich zw. typischen Konferenzen und dem Open Space als Unkonferenz.

Der Link, der euch direkt auf YouTube führt, findet ihr hier. Ich würde euch allerdings bitten beim Teilen den Blog Link zu verwenden.

NET Open Space – Interview mit Manuel Naujoks

In meinem Interview am .NET Open Space in Karlsruhe (#nossued) spreche ich mit Manuel über seine favorisierten Sessions und den Vergleich zw. typischen Konferenzen und dem Open Space als Unkonferenz.

Der Link, der euch direkt auf YouTube führt, findet ihr hier. Ich würde euch allerdings bitten beim Teilen den Blog Link zu verwenden.

NET Open Space – Interview mit Gregor Biswanger

In meinem Interview am .NET Open Space in Karlsruhe (#nossued) spreche ich mit Gregor, Inhaber von web-enliven, über seine favorisierten Sessions und den Vergleich zw. typischen Konferenzen und dem Open Space als Unkonferenz.

Der Link, der euch direkt auf YouTube führt, findet ihr hier. Ich würde euch allerdings bitten beim Teilen den Blog Link zu verwenden.

%d Bloggern gefällt das: