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

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Mike Cohn: Agile Estimating and Planning

Wer immer wieder Projekte sieht, in denen das Chaos regiert, in denen die Projektleitung nur reagiert statt zu steuern, dem sei Mike Cohns Agile Estimating and Planning ans Herz gelegt. Ein Buch, das dem Leser eine neue Perspektive darauf gibt, wie Projekte funktionieren können, wenn man nur endlich beginnt, Projekte und ihre Plannung besser zu verstehen.

Das Buch macht einem Lust darauf, Projekte nur noch agil zu planen. Zwar merkt man Cohns deutliche Vorliebe für User Stories und Scrum, aber die Ideen und Konzepte aus diesem Buch sind auch Problemlos mit anderen Methoden des Requirement Engineering oder agilen Vorgehensweisen kompatibel.

Zum Einstieg erfährt der Leser, warum Planung notwendig ist und warum sie so oft daneben liegt. Aus den Gründen für letzteres leitet Cohn ab, dass Planung eigentlich nur agil funktionieren kann – eine Erkenntnis der man unweigerlich zustimmen muss, wenn man neben der agilen auch die Welt des V-Modells kennt.

Im zweitel Teil des Buches nimmt Cohn dem Leser die Angst, zu schätzen. Es wird klar, dass Schätzen inhärenter Bestandteil von Planung ist und die einzige Möglichkeit, besser zu planen, darin besteht, besser zu schätzen. Dazu muss man mit dem Schätzen allerdings erst einmal beginnen. Mit echtem Schätzen, versteht sich. Cohn erklärt, wie man im Team schätzen kann, wann man neu schätzen muss und wann Story Points oder Ideal Days die bessere Grundlage sind.

Der dritte Teil des Buches geht auf die Fragen ein, anhand welcher Werte man priorisieren sollte. Steht das Budget im Vordergrund? Oder eher die Funktionalität? Man erfährt, wie man beides gewichten kann und den Kunden zufrieden stellt. Zum Abschluss des dritten Teils erfährt der Leser noch einiges wichtige über das Splitten von Stories, wie man anhand von Datenstrukturen, Geschäftsprozessen oder Cross-Cutting-Concerns splittet um ein Projekt beherrschbar – und damit planbar – zu machen.

Wie man einen agilen Plan mit einer Zeitplanung versieht, wird im vierten Teil des Buches erklärt. Ausgehend vom Release-Plan geht es zum Plan für Iterationen, entweder basierend auf der Velocity oder basierend auf Commitments. Auch die Unterschiede zwischen Release- und Iterationsplan werden erklärt. Interessant ist auch das Thema Schätzen der Verlocity und wie man in agilen Plänen mit Puffern umgeht. Ein kurzes Kapitel widment sich der Frage, wie man agile Pläne für Projekte mit mehr als einem Team aufstellen kann.

Da auch in agilen Projekten gefragt wird, wie weit das Projekt den voran gekommen ist, erklärt Cohn im fünften Teil des Buches, wie man Release- und Iterationsplänge beobachten kann und Maßnahmen ableitet. Es wird auch darauf eingegangen, wie man über und mit agilen Plänen kommuniziert. Die beiden letzten Teile widmen sich zum einen der Frage, warum agile Planung funktioniert und einer Fallsstudie zum Thema agile Planung.

Fazit: Agile Estimating and Planning ist die konsequente Fortsetzung von User Stories Applied. Wer Projekte plant, egal ob agil oder klassisch, für den ist dieses Buch ein Muss.