Kommentierte Links (III)
Der (Mit)Gründer von Scrum zieht mit heftiger Wortwahl vom Leder gegen die größte Scrum-Vereinigung der Welt, die Scrum Alliance. Warum? Weil die Alliance versucht hat sich den Begriff
Scrum User Group als Marke eintragen zu lassen, wodurch sich niemand mehr ohne ihre Genehmigung so hätte nennen dürfen. Es ist anscheinend der zweite Versuch dieser Art
und auch der erste endete im Streit. Interessant auch die Diskussion in den Kommentaren: auf der einen Seite diejenigen die genau wie Schwaber wütend und empört sind, auf der anderen Seite aber auch Gegenstimmen die der Meinung sind, dass ein Markenschutz verhindern könnte, dass mitunter der größte Blödsinn noch unter dem Label Scrum verkauft wird. Mittlerweile hat die Scrum Alliance den Registrierungsantrag zurückgezogen (und passenderweise auch das
in den Kommentaren dieses Eintrages verkündet).
Ein wirklich guter Artikel, in dem dargelegt wird wie die klassischen Führungsaufgaben auf den Scrum Master, den Product Owner und das Team selbst verteilt werden können. Das ist dann wirklich eine flache Hierarchie! Interessant aus Change Management-Sicht ist in diesem Zusammenhang auch die Frage nach der Verwendung für die bisherige Management-Ebene, da die ja jetzt nicht mehr in ihrer bisherigen Funktion gebraucht wird (vor allem: wie verhindert man, dass die aus Angst um die eigene Existenzberechtigung alles sabotieren?). Überlegungen dazu gibt es in den Kommentaren.
Zugegeben, der Titel ist etwas kryptisch, dahinter verbirgt sich aber eine interessante Idee: Ein Test-, Agile- oder Scrum-Coach kann seine Coaching-Angebote auf einer Art Speisekarte festhalten, und seine "Kunden" können eines davon bei ihm bestellen. Mit dieser Methode können gleich mehrere Probleme gelöst werden - die zu coachenden Teams oder Teammitglieder. bekommen einen schnellen Überblick über die zur Verfügung stehenden Angebote, sie können selber entscheiden was sie brauchen (womit auch die Unsitte der "verordneten Coachings" beendet wird) und der Coach weiss besser was von ihm erwartet wird, bzw. welches seiner Angebote die Leute überhaupt interessiert.
Das Transskript eines langen Vortrags von Maciej Cegłowski. Seine Kernaussage ist, wenn ich es richtig verstanden habe, dass die
Digitale Revolution bereits vorbei ist und wir es nur nicht wahrhaben wollen (nicht wundern wenn es am Anfang nur um Flugzeuge geht, das ist eine Analogie). Dieses nicht wahrhaben wollen drückt sich dann darin aus, dass wir den Weitergang dieser Revolution zu erzwingen versuchen indem wir die an sich bereits fertigen und ausgereiften Programme und Tools nehmen und ihnen andauernd neue Features und Gadgets hinzufügen. Das Problem - diese neuen Funktionen erzeugen kaum noch Mehrwert, machen die Anwendungen aber unnötig komplex und fragil. Dazu mein Gedanke: Da Komplexität und Fragilität Ursachen für den Bedarf an Agilität in IT-Projekten sind kann ich davon ausgehen, dass meine berufliche Zukunft erstmal gesichert ist.
Die erste Variante habe in vergleichbarer Form schon in mehreren Projekten gesehen: neben dem Sprintboard werden auch alle möglichen anderen Sachen auf Nachbar- oder Unterboards abgebildet, vom Sprint-Kalender über den Burndown Chart bis hin zu den wichtigsten Features die (noch nicht) live sind. Was ich bemerkenswert finde sind die beiden runden Boards, die ich so bisher noch gar nicht kannte.
