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.

Vorab muss ich sagen, dass ich zum Thema Schätzen keine absolute Meinung vertrete. Ich habe in Projekten gearbeitet, in denen Schätzungen hervorragend funktionierten, ebenso wie ich bereits in Projekten unterwegs war, die ohne Schätzungen sehr gut zurecht gekommen sind.
Gut gefahren bin ich bisher mit der Daumenregel, dass im Product Backlog geschätzte Elemente enthalten sein sollten, im Sprint Backlog nicht. Möchte ein Team das Sprint Backlog schätzen, finde ich das aber auch ok. Das Team muss sich gut damit fühlen und solange die Schätzung die Koordinationskosten nicht extrem in die Höhe treibt, kann ich damit leben.

Ist Schätzen sinnvoll?

Wenn ich als Product Owner unterwegs bin, brauche ich Schätzungen. Wozu, hat Henrik Kniberg in seinem Video Product Owner in a Nutshell hervorragend erklärt. Ohne Schätzungen kann ein Product Owner keinen Forecast machen. Der Forecast ist aber wichtig, um Investoren ein gutes Gefühl zu geben.
Wenn ich Investor bin und mein Geld in ein Softwareprojekt stecke, möchte ich wissen, wann – nach welcher Menge investierten Geldes – ich mit einem Ergebnis rechnen kann. Das muss nicht beim ersten Sprint klappen, auch nicht beim zweiten. Aber wenn die ersten fünf Sprints ergebnislos bleiben, werde ich mich einmischen. Das ist mein gutes Recht, es ist schließlich mein Geld.
Natürlich interessiert es mich als Investor nicht, wie viele Stunden für welches Feature investiert werden. Aber nach fünf Sprints möchte ich vom Product Owner wissen, wie die Velocity des Teams ist und wie die Items im Backlog geschätzt sind. Nur so kann ich entscheiden, ob das Projekt die Investition wert ist oder nicht.
Das vergessen viele vermeintliche Agilisten leider viel zu häufig. Dabei steht genau das im ersten der zwölf Prinzipien des Agilen Manifest:

Unsere höchste Priorität ist es,
den Kunden durch frühe und kontinuierliche Auslieferung
wertvoller Software zufrieden zu stellen.

Das wichtige Wort dabei ist wertvoll. Die Frage, wann eine Software wertvoll ist, hängt für einen Investor – neben vielen anderen Dingen – eben auch vom Aufwand ab, der bezahlt werden muss.

Für Investoren – und damit auch den Product Owner – ist Schätzen also durchaus sinnvoll. Das Team zieht keinen unmittelbaren Nutzen aus einer Schätzung. Deshalb sollte auch nicht das Team entscheiden, ob geschätzt wird oder nicht. Es darf aber darauf bestehen, dass die Schätzung auch als solche betrachtet wird und keine Garantie ist.

Im nächsten Eintrag werde ich auf User Stories der Größe 1 eingehen.

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. Im zweiten Teil 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.

Ich denke, der Weg eines ScrumMasters muss nicht mit der Rolle eines Entwicklers beginnen. Ebenso wie es Junior Entwickler gibt, die ihre Ausbildung abgeschlossen haben und dann in der Praxis noch das Handwerk lernen, kann es auch Junior ScrumMaster geben.

Von einem solchen Junior ScrumMaster würde ich erwarten, dass er ein grundlegendes Verständnis für die Entwicklung von Software hat. Ich würde aber nicht erwarten, dass er ein begnadeter Programmierer ist. Unbedingt notwendig ist ein Gespür dafür, wie es Menschen geht, was sie bewegt und wie man an ein Team herangehen kann.
Das Gespür hat man – oder nicht. Es gehört zu den Fähigkeiten, die nicht wirklich erlernt werden können, die nur durch Erfahrung besser werden. Deshalb sollte man junge Softwerker, die diese Fähigkeiten haben, nicht in die Entwicklung stecken, sondern einem erfahrenen ScrumMaster als Mentee an die Hand geben.

Ich treffe regelmäßig auf gut eingespielte Teams, deren ScrumMaster ihnen nichts mehr geben kann, weil das Team einen hohen Reifegrad erreicht hat. Man könnte dem ScrumMaster eines solchen Teams einen Junior zu Seite stellen. Dieser Junior kann dann in drei bis sechs Monaten aufgebaut werden und nach Ablauf der Zeit den ScrumMaster ablösen. Die restliche Ausbildung des Juniors schafft das Team. Ja, wirklich, die können das.
Der “alte” ScrumMaster kann sich dann um ein neues Team kümmern. Oder um ein schwieriges Projekt. Oder er wird Agile Coach.

P.S. Ich hatte das Glück, zwei solchen Junior ScrumMastern zu begegnen. Beide waren junge Damen und beide hatten ihre Teams in kurzer Zeit sehr gut im Griff. Ich habe nie erfahren, ob sie gute oder schlechte Entwicklerinnen geworden wären. Und es spielt auch überhaupt keine Rolle.

Lokale Umgebungen für Perl, Python und Ruby

Hin und wieder hat man auf einem System keine root-Rechte oder möchte diese nicht nutzen. Und oft will man gerade in solchen Situationen Perl-Module, Ruby Gems oder Python Eggs verwenden, die auf dem System nicht verfügbar sind. Erfreulicherweise bieten alle diese Sprachen Mechanismen an, mit denen sich Erweiterungen im Heimatverzeichnis des Benutzers installieren lassen.
Wie das im Einzelnen geht, beschreibt dieser Artikel.

Weiterlesen

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.
Weiterlesen

Multi-Domain SSL-Zertifikate

Wer selbst Webserver betreibt, die verschlüsselte Bereiche anbieten sollen, kennt sicherlich das folgende Problem:
HTTPS benötigt pro virtuellem Webserver eine eigene IP-Adresse, weil die Verschlüsselung aktiv wird, bevor der Mechanismus greift, der die Unterscheidung von Name Based Virtual Hosts ermöglicht.

Dieses Problem führt dazu, dass man meistens die Wahl zwischen mehr oder weniger schönen Alternativen hat. Da ich in Projekten immer wieder damit konfrontiert bin – und auch privat des Öfteren danach gefragt werde – möchte ich beschreiben, welche Möglichkeiten man mittlerweile hat, um elegant und ohne irritierende Warnmeldungen damit umzugehen.

Weiterlesen

Technical Debt: Vortrag auf der SEACON 2014

Mein Vortrag zum Thema Technische Schulden – Reden wir drüber! wurde für die SEACON 2014 angenommen.

Technical Debt ist für Software-Entwickler die unangenehmste Form von Schulden. Trotzdem entstehen sie, jeden Tag, in jedem Projekt. Der Vortrag bietet Software-Entwicklern und Software-Architekten eine Anleitung, wie sie mit Projektleitern und Managern über dieses Thema sprechen können. Zu hohe Kopplung kann die Ursache eines zu niedrigend Incoming Cash Flows sein, ebenso wie die zyklomatische Komplexität mit der Total Cost of Ownership korrelliert. Auf amüsante Weise wird erklärt, wie sich für jede Ursache von Technical Debt ein Weg finden lässt, diese mit betriebswirtschaftlichen Begriffen so darzustellen, dass auch ein Manager das Problem begreifen kann. Denn wenn der Manager nicht zum Entwickler kommt, muss der Entwickler eben zum Manager gehen.

Ich freue mich schon sehr auf die Konferenz, auf der ich zum ersten Mal als Mitarbeiter der adesso AG sprechen werde.

Postfix und Dovecot mit StartSSL-Zertifikaten

StartSSL stellt eine günstige Möglichkeit bereit, wie man unkompliziert an SSL-Zertifikate kommt.

Allerdings haben die Zertifkate den Nachteil, dass sie ein Chain-Zertifikat benötigen. Sonst bekommen Nutzer trotz eines eigenlich gültigen Zertifikats Warnmeldungen angezeigt.

Weder Dovecot noch Postfix haben für die Chain-Zertifikate eine Konfigurationsoption. Es geht aber trotzdem sehr einfach, wie im Folgenden gezeigt wird.
Weiterlesen

cron mit LDAP-Nutzern unter Debian

Will man für Benutzer, die im LDAP verwaltet werden, eine crontab erstellen, wird diese unter Debian Wheezy eventuell nicht ausgeführt.

Stattdessen erhält man in /var/log/syslog die Meldung

/usr/sbin/cron[2656]: (lupinchen) ORPHAN (no passwd entry)

Das Problem ist schon uralt: cron erkennt offenbar keine LDAP-Benutzeraccounts.
Die Lösung ist trivial – wenn man sie kennt.
Die besteht darin, den nscd zu starten.

/etc/init.d/nscd start

Schon läuft der cron so, wie man es erwartet und führt auch crontabs für LDAP-Benutzer aus.

Quellen:

Sicheres Anwendungs-Monitoring mit SNMP – Vortrag auf den Chemnitzer Linux-Tagen 2014

Das Vortragsprogramm der Chemnitzer Linux-Tage 2014 ist online und mein Vortrag zum Thema Sicheres Anwendungs-Monitoring mit SNMP wurde ins Programm aufgenommen.

Der Vortrag gibt Unix-Nutzern einen Einblick, wie man Net-SNMP zum Monitoring und Steuern beliebiger Anwendungen nutzen kann.
Der Schwerpunkt liegt dabei auf dem Thema der Absicherung des SNMP-Dienstes mit Hilfe von SSL/TLS und Authentifizierung.
Als Beispiele dienen hierzu SNMP4J und Net-SNMP.