Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Ulf Brandes, Pascal Gemmer, Holger Koschek & Lydia Schültken: Management Y

Allen, die als Nicht-ITler ins Thema Agilität und vor allem Führung im agilen Kontext einsteigen wollen, sei dieses Buch wärmstens empfohlen. Wer – wie ich – schon länger mit diesen Themen unterwegs ist, wird allerdings wenig neues entdecken.

Der Aufbau des Buches erinnerte mich sehr stark an Fearless Change. Zunächst wird im Teil Mehr Menschlichkeit im Management! die grundlegende Motivation für das Buch erklärt. Die von den Autoren vertretenen Ansichten teile ich auch – bis auf die Tatsache, dass Taylor unverdient mal wieder viel zu schlecht wegkommt.

Im zweiten Teil des Buches wird Management Y aus vier Sichten beschrieben: Organisation gemeinsam erleben, Liefern, was gebraucht wird, Menschen ehrlich begeistern und Kunden wirklich verstehen.Der zweite Teil ist eine Runde Sache und für Einsteiger super. Alle vier Blickwinkel werden kompakt beschrieben und moderne Wege gezeigt, sich ihnen zu stellen. Einziges Manko ist, dass bestimmte Modelle sehr stark im Fokus stehen – vielleicht weil sie den Vorlieben der Autoren entsprechen.

Mit insgesamt 24 Pattern ist der dritte Teil sehr hilfreich, wenn man sich in der Welt agiler Praktiken orientieren will. Wer regelmäßig in der Community unterwegs ist, Blogs liest oder schon andere Bücher zum Thema kennt, wird aber nur schwerlich etwas Neues finden.

Der Ausblick am Schluss ist für mich persönlich etwas zu esoterisch. Ich mache zwar regelmäßig Yoga und meditiere auch sehr gerne – aber das passt nicht zu einem Buch, dass das Wort Management im Titel trägt.

Der Titel ist auch das, was ich an dem Buch im Wesentlichen kritisieren muss. Ich bin ein großer Verfechter des Management 3.0 und empfand das Buch von Jurgen Appelo als einen Meilenstein der Management-Literatur. Management Y hat mit Management …wenig zu tun. Es ist eher eine Ideensammlung und ein Startpunkt für Menschen, die sich mit dem Thema Agilität auseinandersetzen wollen. Wer sich mit Führung – oder Management – in agilen Organisationen auseinandersetzen will, kommt nach wie vor an Appelo nicht vorbei.Mein Fazit:

Für mich persönlich war es viel zu flach. Es gibt dennoch vier Sterne bei Goodreads, weil die Zusammenstellung im Buch für Einsteiger super ist – und die sind mit Sicherheit auch die Zielgruppe :-)

Vertraue der Macht – Schätzen ohne Bezugssystem

Ein große Herausforderung für Teams in neuen Projekten ist die initiale Schätzung der anstehenden Aufgaben. Selbst wenn man eine abstrakte Einheit wie Story Points zur Bewertung der Größe von Aufgaben heranzieht, ist die erste Schätzung alles andere als trivial. Ich habe festgestellt, dass gerade Planning Poker für die erste Schätzung nur sehr eingeschränkt geeignet ist.

Planning Poker ist eine gute Methode, um Schätzungen für Aufgaben zu ermitteln, wenn in den Domänen und Technologien bereits Wissen vorhanden ist. Gerade am Anfang eines Projektes gibt es aber genau dieses Wissen oft nicht und Teams tun sich schwer, diese Schätzungen für einzelne Items abzugeben. In solchen Situationen hat es sich bewährt, Aufgaben nur relativ zueinander zu schätzen und das Bezugssystem erst im Nachhinein festzulegen. Da Story Points eine abstrakte Einheit sind, die nicht mit einem festen Faktor in andere Einheiten umgerechnet werden kann, ist das problemlos möglich.
Continue reading

Back to COBOL – natürlich mit Unit Tests

Ich hätte nie gedacht, dass ich mich nach über 10 Jahren noch einmal mit COBOL beschäftigen würde. Aber nun habe ich ein Team, das mit COBOL arbeitet und Scrum machen soll.

Nun sind COBOL und Scrum zwei Dinge, die die meisten Menschen, die ich so kenne, nicht oft in einem Satz verwenden. Das soll aber kein Grund sein, sich nicht mit der Materie zu beschäftigen. Letztes Wochenende habe ich OpenCOBOL – neuerdings GNU-Cobol – via homebrew auf dem Mac verfügbar gemacht.

Das war aber nur der erste Schritt, denn mein eigentliches Ziel war die Grundvoraussetzung für agile Software-Entwicklung mit COBOL zu nutzen. Na? Genau: Unit Tests! Mit CobolUnit gibt es dafür auch ein Framework, das aber schon seit einer Weile nicht maintained wird. Die letzten Commits sind von 2009, das versprach ein Abenteuer.
Und das wurde es dann auch. Ich habe mich von Fehlermeldungen wie
error: indirect goto in function with no address-of-label expressions
zu
ld: can't link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file '/Users/gbeine/GitHub/gbeine/COBOLUnit/COBOLUnitLib/lib/libCobolUnit.dylib' for architecture x86_64
durchgearbeitet.

Am Ende ist es mir gelungen, CobolUnit mit GNU-Cobol in der Version 1.1 und dem GCC 4.9.1 zum Laufen zu bringen. Das Resultat schaut recht erfreulich aus:

|--- Suite1
| Test 'CTU0S1T1 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
| Test 'CTU0S1T2 * SUCCESS * (006 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

|--- Suite2
| Test 'CTU0S2T1 * SUCCESS * (008 Assertions, 000 Failures. 000 errors)
|--- SUCCESS

********************************************************************
* SUCCESS *
* (003 test cases, 003 success, 000 failures, 000 errors) *
********************************************************************
(00 min:00 sec:01 ms)

Meine Änderungen dazu habe ich – natürlich – auf GitHub zur Verfügung gestellt. Nur für den Fall, dass das außer mir noch irgendwo auf der Welt irgendjemand nutzen möchte…

Einheit Story Points?

Nach der Frage um den Sinn des Schätzens und den Storys der Größe 1 drehte sich die dritte Frage, die ich auf der Agile World diskutieren durfte, war ob Schätzgrößen Einheiten haben oder nicht.

Mike Cohn schreibt in seinem Blog, dass die Größe von Backlog Items eine nicht spezifizierte Funktion aus Risiko, Aufwand und Unsicherheit ist. In einem anderen Artikel schreibt er, dass es einen Zusammenhang zwischen Aufwand und Größe einer User Story gibt.
Continue reading

“Ich will mein Vetorecht!” – Über Vertrauen in agilen Projekten

Agile Vorgehensweisen benötigen Vertrauen. Dieses Vertrauen muss innerhalb des Teams entstehen, es muss zwischen dem Auftraggeber und dem Team entstehen – und es muss zwischen Führungskräften und dem Team entstehen.

Wenn ich Teams begleite, entsteht das Vertrauen innerhalb des Teams häufig sehr schnell und stabilisiert sich. Gelingt es einem Team, früh Resultate zu zeigen, wird es zumeist mit dem Vertrauen des Auftraggebers belohnt. Dieses Vertrauen wächst mit der Kontinuität, in der das Team wertvolle Software liefert.

In Workshops zu Einführung agiler Softwareentwicklung gehe ich immer auf dieses notwendige Vertrauen ein. Ich spreche es gegenüber dem Team an, gegenüber den Kunden – sofern diese teilnehmen – und natürlich gegenüber den Führungskräften. Mit letzteren erlebe ich allerdings sehr oft etwas, das mich immer auf’s Neue zum Nachdenken bringt.
Continue reading

User Stories der Größe 1

Nach der Agile World hatte ich mit einem Artikel über Schätzereien begonnen, eine Diskussion auf der diesjährigen Agile World auszuwerten. Heute möchte ich den angekündigten zweiten Artikel präsentieren, der sich mit der Frage beschäftigt: Wie praktikabel sind absolute Aussagen?

Im Zusammenhang mit dem Verzicht auf Schätzen hat mich die Aussage, dass User Stories, die größer als 1 sind, generell nicht funktionieren, am meisten erstaunt. Ich halte solche pauschalen Aussagen für zu kurz gedacht. Unabhängig davon, in welchem System man sich bewegt. Eine absolute Größe ohne Bezugssystem ist für eine Schätzung nicht zu gebrauchen.
Continue reading

Schätzereien

Auf der Agile World hatte ich in diesem Jahr eine extrem spannende Diskussion zum Thema Schätzen.
Es ging im Wesentlichen um drei Fragen:
1. Ist Schätzen sinnvoll?
2. Wie praktikabel sind absolute Aussagen?
3. Sind Schätzgrößen einheitenlos?

Meine Gedanken zu diesen drei Fragen möchte ich hier noch einmal zusammenfassen – vielleicht sind sie ja für andere nützlich, die in ähnliche Diskussionen verwickelt werden.
Continue reading

David J. Anderson: Kanban

David J. Anderson: Kanban

David J. Anderson: Kanban

Andersons Kanban-Buch kann man als Meilenstein des Change Managements im IT-Bereich betrachten. Nicht nur, dass es Anderson gelang, mit Kanban eine konsequente Übertragung der Prinzipien des Lean Manufacturing auf den Bereich der Softwareentwicklung zu übertragen. Vielmehr hat er es geschafft, darüber hinaus die Einführung solcher Prinzipien methodisch so aufzubereiten, dass es Managern möglich wird, die notwendigen Veränderungen systematisch durchzuführen.

Das Buch ist in vier Teile gegliedert.
Zunächst wird dem Leser das Dilemma des agilen Managers, nämlich die Suche nach einer konstanten Arbeitsgeschwindigkeit und die grundlegende Funktionsweise eines Kanban-Systems nahegebracht. Danach erläutert Anderson die fünf Schritte, die eine Einführung von Kanban ermöglichen und erklärt anhand von Beispielen aus seiner Management-Praxis, wie sie umgesetzt werden können. Abgeschlossen wird der zweite Teil des Buches mit einer Betrachtung von Kaizen-Kultur.

Im dritten Teil geht es dann mit den praktischen Fragestellungen richtig los. Visualisieren der Prozesse, Einsatz von Kanban zur Koordination, Lieferrhythmen und Work-in-Progress-Limits, um ein paar Stichworte zu nennen. Natürlich geht Anderson auch auf Reporting, Metriken zum Monitoring des Fortschritts und des Reifegrades der Kanban-Implementierung und auf das Thema Skalierung ein. Extrem positiv fallen die vielen verschiedenen Szenarien auf, anhand derer Anderson seine Ideen erklärt.

Der vierte Teil beschäftigt sich mit Problemen, die sich auf die kontinuierliche Verbesserung des Kanban beziehen, wie Variabilität bei den Aufgaben und begrenzt verfügbaren Ressourcen. Abgeschlossen wird das Buch durch den Kanban-Einführungsbericht eines Unternehmens.

Was mir nicht gefallen hat, war Andersons Bashing von Daily Standup Meetings. Hier gehen unsere Meinungen weit auseinander, insbesondere, weil das Standup Koordinationsaufwände transparent macht – etwas, das Anderson immer wieder als wichtig beschreibt. Die deutsche Übersetzung ist an einigen Stellen holprig, referenziert zum Teil völlig anders beschriftete Abbildungen und – das hätte ich bei einem korrigierten Nachdruck nicht erwartet – strotzt nur so vor Rechtschreibfehlern.

Fazit: Das Buch gehört zu den Must-Reads für Agilisten, denn viele Konzepte aus der Welt des Lean können auch in Scrum und Extreme Programming erfolgreich angewandt werden.

Eine Lanze für Junior ScrumMaster

Zu Zeiten in denen ich als ScrumMaster von Team zu Team durch die Welt reiste, war eine Frage, die mir häufig begegnete:
Wieviel Entwicklungserfahrung haben Sie denn?

Ich fand das immer seltsam. Viel interessanter wäre doch die Frage gewesen:
Wieviele Teams sind mit Ihnen erfolgreich agil geworden?

Aus irgendeinem Grund regiert aber der Glaube, ScrumMaster müssten erfahrene Entwickler sein. Das habe ich auch in vielen Unternehmen, die ich begleitet habe, erlebt. Der Karrierepfad eines ScrumMasters begann in der Regel erst, wenn man bereits Senior Entwickler war. Dabei sind die Fähigkeiten eines Senior Entwicklers völlig andere als man die für die Rolle des ScrumMasters benötigten.
Continue reading

Post Mortem: bitte positiv!

Es gibt Unmengen an Methoden, Post Mortems oder Retrospektiven zu gestalten. In der Praxis dominiert aber in der Regel die klassische Variante mit den zwei Fragen: Was lief gut? Was lief schlecht? Diese Variante ist zwar besser als gar nichts, sie richtet den Blick aber primär in die Vergangenheit.

Aus den gut und schlecht gelaufenen Aspekten Maßnahmen abzuleiten, ist ein Knochenjob und verläuft nicht selten im Sande. Ich möchte im Folgenden eine Möglichkeit vorstellen, wie man Post Mortems und Retrospektiven positiv gestaltet, in die Zukunft blickt und Maßnahmen ohne viel Aufwand ermittelt.
Continue reading