Ich bin agiler Berater und Geschäftsführer der it-agile GmbH. In diesen Blog schreibe ich unregelmäßig meine Gedanken zu Themen wie Agile Methoden, Softwareentwicklung, Lean, Business, Internet und anderem.

19.12.11

Certified ScrumMaster Test: Jetzt wird's ernst!

Seit Oktober bin ich auch Certified Scrum Trainer und darf Zertifizierungsschulungen zum Certified ScrumMaster (CSM) und Certified Scrum Product Owner (CSPO) geben. Bisher gibt es beim CSPO gar keinen Test und beim CSM nur eine "Selbstevaluation" (die genau genommen mehr den Trainer als die Teilnehmer bewertet). Aber in 2012 wird der CSM-Test neu aufgesetzt und zwar wie folgt:
  • Ab Januar 2012 enthält der Test komplett neue, andere Fragen als bisher.
  • Wer diesen Test bis Ende März 2012 ausfüllt, kann nicht durchfallen. Voraussetzung für den Test bleibt wie bisher die erfolgreiche Teilnahme an einem CSM-Kurs.
  • Ab Anfang April 2012 besteht man den Test oder fällt durch.
  • Ab Anfang April 2012 haben CSM-Kandidaten die Möglichkeit den Test binnen 60 Tagen nach ihrem Kurs bis zu zweimal ohne zusätzliche Kosten durchzuführen. Nach den 60 Tagen fällt eine Gebühr von 25$ an für eine erneuten Test. Nach drei erfolglosen Versuchen empfiehlt die Scrum Alliance, erneut einen CSM-Kurs zu besuchen, bevor der Test wiederholt wird.
  • Der neue Test umfasst 35 Fragen und hat kein Zeitlimit zum Ausfüllen. Kandidaten können sich Bookmarks auf Fragen setzen, Antworten zu Fragen ändern und sogar den Test stoppen, um später binnen der 60-Tages-Frist darauf zurückzukommen.
  • Am Ende des Tests werden den Kandidaten die Fragen angezeigt, die sie falsch beantwortet haben. Es wird aber keine Liste möglicher Antworten mehr angezeigt. Dies soll sicherstellen, dass zum einen die Prüfungsfragen geschützt bleiben, und zum anderen sollen die Kandidaten ihre Kursunterlagen erneut studieren, bevor sie den Test wiederholen.
  • Kandidaten, die beim ersten Mal durchfallen, können sofort erneut den Test durchführen (und müssen nicht abwarten). Der zweite Versuch kann aber auch zu einem späteren Zeitpunkt innerhalb der 60-Tages-Frist erfolgen.
  • Sobald Kandidaten den Test durchgeführt und bestanden haben, können sie ihren Status alle 2 Jahre erneuern. Die Scrum Alliance wird ein "Professional Development Unit Program (PDUs)" dafür aufsetzen bis spätestens Januar 2012. CSMs müssen dann PDUs sammeln, um ihren Zertifizierungsstatus zu behalten. Details hierzu folgen später.
  • Die aktualisierten Lernziele der CSM-Kurse können bei der Scrum Alliance heruntergeladen werden. Sie stellen die Basis für Struktur und Inhalt des neuen CSM-Tests dar.
Der CSM-Test wird vorerst nur auf Englisch möglich sein. Andere Sprachen und ein Test für die CSPO-Kurse werden aber wohl folgen.

1.11.11

Agile Projekte mit Scrum, XP und Kanban im Unternehmen durchführen

Schon lange habe ich mir ein Buch gewünscht, in dem es einfach nur viele agile Projektberichte gibt. In diesen Berichten soll es nicht nur alles super und toll gelaufen sein, sondern auch mal gekracht haben, auch mal etwas schwerer gefallen sein. Ich würde dann gerne lesen, was die Leute im Projekt daraus gelernt haben, wie sie agil mit dem Problem umgegangen sind.
Endlich gibt es dieses Buch.
Ich musste es zwar selber herausgeben, es lebt aber von den vielen Autoren der Projektberichte, bei denen ich mich auch hier bedanken möchte (im Buch mache ich das natürlich auch). Es finden sich Berichte über Scrum-Einführungen in Teams, Scrum und Kanban im Mix fürs Unternehmen, agil für Startups, Kanban für Maintenance und Verwaltung und noch viel mehr in diesem Buch.
Ich hoffe, dass es den Lesern genau so gut gefällt wie mir!

23.5.11

Agile Entwicklungspraktiken mit Scrum

Roman Pichler und Stefan Roock haben ein Buch zu Agilen Entwicklungspraktiken mit Scrum herausgegeben. Ich durfte dem Buch ein Kapitel zum Thema Pair-Programing beisteuern. Deshalb weiß ich auch, welche Mühe sich Roman und Stefan gemacht haben, trotz der unterschiedlichen Kapitelautoren (davon auch allerhand meiner it-agile-Kollegen) zu einem einheitlichen und durchgängigen Stil für das Buch zu kommen. Das ist ziemlich gut gelungen und dafür kann ich mich persönlich nur bedanken. So liest sich mein Kapitel nämlich viel besser als vorher.
Das Buch ist eigentlich Pflichtlektüre für alle, die sich ernsthaft mit agiler Softwareentwicklung auseinandersetzen wollen. Schließlich sind viele der agilen Versprechungen eigentlich agile Grundvoraussetzungen, so z.B. die ständige Wartbarkeit im Sinne von Erweiterbarkeit und Änderbarkeit der erstellten Software. Die stellt sich aber ohne agile Entwicklungspraktiken nicht von alleine an.
Ich kann das Buch wärmstens empfehlen!
Wer nicht so gerne liest, der sollte über einen Agile-Developer-Skills-Kurs nachdenken, der auch die Grundlage für das Scrum Alliance Zertifikat Certified Scrum Developer ist. Bei so einem Kurs muss ich auch mal wieder mitmachen, dann bekomme ich auch mal wieder die Gelegenheit zum Pair-Programming (obwohl ich die zum Glück dank Slack bei it-agile auch anderweitig regelmäßig habe).

11.4.11

Die Kraft von Scrum


Ich habe mich im letzten Jahr mal an einem ganz anderen Buchprojekt beteiligt: Die Kraft von Scrum: Inspiration zur revolutionärsten Projektmanagement-Methode
Das Buch ist die deutsche Adaption eines in den Niederlanden sehr erfolgreichen Buches (von dem ich die englische Fassung adaptiert habe). Es ist auch deshalb anders, weil es sich im Stil eher um eine durchgängige Geschichte handelt. Eine Geschichte einer erfolgreichen Scrum-Einführung. Das Buch ist leicht zu lesen, hat in jedem Kapitel eine knappe Zusammenfassung und ist ganz bewusst auch so gemacht, dass Manager es schnell in 2-4 Stunden lesen können. Anschließend sollten sie dann einen Überblick über das Potential von Scrum haben.
Mir ist es am schwersten gefallen, nicht alles an Scrum-Möglichkeiten im Buch unterzubringen. Das Buch beschreibt eine beispielhafte Scrum-Enführung, wie sie passieren könnte. Aber es behandelt eben bewusst nicht alle Eventualitäten und Besonderheiten, die man von einem umfassenden Scrum-Buch vielleicht erwarten würde. Das war aber auch nicht das Ziel. Weniger sollte mehr sein. Ich hoffe, es ist gelungen, und ich freue mich über Feedback.

18.3.11

Auf die Schnelle: TOP 3 für Retrospektiven

Gerade gestern hat mich ein Kunde gefragt, was denn die TOP 3 der Dinge sind, die es zu bedenken gilt, wenn man jetzt gleich mal eine Retrospektive in einem Team durchführt. Erst dachte ich, dass man das so eigentlich nicht beantworten kann (und vielleicht auch nicht sollte). Schließlich gibt es tolle Literatur dazu und tolle Schulungen, aber es hat mich doch gereizt, also habe ich geantwortet:


TOP 1: Gleich am Anfang klarmachen, dass die Veranstaltung nicht zum Blaming (auch nicht zur Selbst-Beschuldigungen!) da ist und nicht zum Jammern. Wir wollen ehrlich schauen, was gewesen ist, auch was doof war, aber immer mit dem konstruktiven Blick in die Zukunft. Einstimmung: "Stellt Euch immer vor, Euer Gegenüber wolle Euch helfen!" (nicht ganz einfaches Gedankenexperiment für alle.)


2. Es passiert nicht nur Schlechtes. Beim Sammeln von Themen und Fakten immer auch darauf achten, dass man auch die guten Sachen mitnimmt. Man kann z.B. mit einer Übung wie sad-glad-mad (jeder schreibt etwas auf, was ihn traurig gemacht hat, UND etwas, was ihn froh gemacht hat, UND etwas, was ihn verrückt oder wütend gemacht hat). Dann wurde jeder gesehen, man muss trotzdem gemeinsam priorisieren, worüber man dann weiter redet und kann nie alles vollständig bearbeiten.



3. Nicht zu schnell zu Lösungen kommen. Klingt vielleicht paradox, aber es ist soooo wichtig, dass man erst einmal versteht, warum die Ding so gelaufen sind, wie sie gelaufen sind und sich den dahinterliegenden Problemen nähert. Sonst wählt man die falschen Lösungen. Beispiel-Technik dafür: "5 Why", also mehrmals hinterfragen, warum es so kam, bis man nach ca. 5 mal raus hat, was es wohl eigentlich ist (leider oft ja auch eine Menge an Dingen). Lieber aus einer Retro nur mit einer Lösung rausgehen, die dafür alle überzeugt als 10 halbherzige Maßnahmen, für die sich keiner zuständig fühlt (also: an Zuständigkeit beim Lösungbeschließen denken: Wer macht es bis wann?).

Ob es geholfen hat? ich weiß es (noch nicht). Hilft es Euch?