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.

In der Diskussion auf der Agile World kam die Aussage auf, Story Points wären eine einheitenlose Größe (Quantity). Das kann nicht korrekt sein, denn Story Points beschreiben lediglich die Größe (Size) von Backlog Items. Das könnte man auch mit T-Shirt Sizes oder anderen abstrakten Mechanismen erreichen. Tatsächlich kann man sogar eine Umrechnung von Story Points in T-Shirt-Sizes definieren. Demzufolge können Story Points keine Größe (Quantity) sein. Und tatsächlich sind Story Points keine quantifizierende Eigenschaft von Backlog Items, sondern nur die Maßeinheit des Wert einer solchen Größe (Quantity), nämlich der Größe (Size) des Backlog Items. Die Größe (Size) des Backlog Items ist – nach Mike Cohn – eine Funktion f(Aufwand, Risiko, Unsicherheit) und mit einer gewissen statistischen Unsicherheit – die aus Risiko, Unsicherheit und Schätzfehlern resultiert – in Aufwand umrechenbar ist.

Bestätigt wird das auch durch den üblichen Sprachgebrauch. Mir ist noch niemand begegnet, der von den Story Points seines Backlogs als Eigenschaft gesprochen hätte. Man spricht immer nur von der Größe des Backlogs in Story Points. Oder T-Shirt Sizes. Oder Schokostreuseln.

Der Trugschluss, Story Points seien keine Einheit, kommt meiner Meinung nach daher, dass man vermeiden möchte, auf eine feste Formel festgenagelt zu werden, mit der man Story Points in Aufwand umrechnen soll. Ich kann mir gut vorstellen, dass es Leute gibt, die solche Dinge verlangen. Dass es nur mit statistischer Varianz möglich ist, zeigt Mike Cohn in dem oben zitierten Artikel. Und dass man es nicht benötigt, weil man auch ohne Umrechnung zu den Aussagen kommt, die relevant sind, wird von Henrik Kniberg in seinem Product Owner in a Nutshell erklärt.

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

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.

Abgesehen davon widerspicht eine solche Aussage massiv dem agilen Manifest. Dort heißt es nämlich: Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans. Und das Festlegen darauf, dass alle User Stories die Größe 1 haben sollen ist nichts anderes als Befolgen eines Plan. Pläne haben aber einen massiven Nachteil, wenn sie mit der Realität konfrontiert werden: Es kann sein, dass die Realität anders funktioniert, als der Plan vorsieht. Gerade bei Softwareentwicklung machen wir diese Erfahrung immer wieder. Was macht man dann mit einer Story die doppelt so groß ist? Ablehnen? Zerschneiden, auch wenn die einzelnen Stories dann keinen Business Value mehr beinhalten? Als Pragmatiker nehme ich in so einem Fall einfach eine Story der Größe 2 ins Backlog. Das klappte bisher immer hervorragend ;-)

Ein weiterer Grund für meine Ablehnung solcher Aussagen ist, dass sie auf dem Confirmation Bias beruhen. Jemand, der so eine absolute Aussage trifft, hat in der Regel in einem bestimmten fachlichen Kontext die Erfahrung gemacht, dass sein Ansatz funktioniert. Daraus schließt er, dass dieser Ansatz valide ist – was für diesen Kontext auch zutrifft – und läuft los, um Bestätigung zu suchen. Und hier schlägt der Confirmation Bias zu. Menschen neigen dazu, nur bestätigende Informationen aufzunehmen, wenn sie von etwas überzeugt sind. Ein korrektes Vorgehen wäre es, nach Beispielen zu suchen, die eine solche Aussage widerlegen, denn sie ist von Natur aus nicht beweisbar.

Natürlich bin ich ein Verfechter möglichst kleiner User Stories. Kleine User Stories reduzierten das Risiko für eine Fehlentwicklung, sind leichter zu schätzen und ermöglichen einen höheren Fluss bei kleinerem Work In Progress. Nichtsdestotrotz sollten User Stories so beschaffen sein, dass sie Business Value in die Software bringen und keinen toten Code hinterlassen. Ich habe die Erfahrung gemacht, dass folgende Daumenregel sehr gut funktioniert: User Stories sollten kleiner sein, als die Hälfte der Velocity. Aber auch dafür gibt es Ausnahmen, so ist das Leben.

Im ditten Teil meiner Nachbrenner zur Agile World geht es dann um die Frage zur Einheit von Schätzgrößen.

Antifragilität und Software-Architektur

Ich bin ja seit längerem ein Anhänger von Nassim Nicholas Taleb. Seine Art, Risiken und Wahrscheinlichkeiten zu betrachten hat mich beeindruckt und geprägt. In meiner Arbeit als Agile Coach und Software-Architekt kann ich die Ideen zu Schwarzen Schwänen fast jeden Tag sinnvoll anwenden. Insofern wundert es mich nicht, dass Antifragilität als Konzept auch Einzug in die Welt der Softwarearchitektur hält.

Sein Buch Antifragilität führt als Untertitel “Eine Anleitung für eine Welt, die wir nicht verstehen”. Wenn man das Buch aufmerksam liest und auch mit dem Schwarzen Schwan und den Narren des Zufalls vertraut ist, versteht man aber schnell, dass dieses Buch keine Anleitung für die Welt ist. Es ist eine Anleitung, sich selbst Anleitungen zu erdenken. Also eine Meta-Anleitung.

Taleb definiert Antifragilität als das Gegenteil von Fragilität, als die Eigenschaft eines Etwas, im Falle des Eintritts eines Schwarzen Schwans, also eines unvorhersehbaren Ereignisses, besser zu werden. Üblicherweise werden Robustheit oder Resilienz als das Gegenteil von Fragilität betrachtet, aber beide gehen Taleb nicht weit genug, sorgen sie im besten Fall doch nur für die Erhaltung des Status Quo, wenn ein Schwarzer Schwan eintritt.

Russ Miles’ Idee, antifragile Software-Architekturen auf Microservices basieren zu lassen, wird in meinen Augen Talebs Ideen nicht gerecht. Was Taleb als Antifragilität beschreibt, ist eine Eigenschaft, die durch zwei Dinge ermöglicht wird: Zufall oder Lernen. Ein Beispiel für Antifragilität, die aus Zufall resultiert, ist die Natur. Taleb selbst verwendet dieses Beispiel in seinem Buch, um Antifragilität (Natur) von Resilienz (ein Wald) und Robustheit (ein einzelner Baum) zu unterscheiden. Antifragilität, die aus Lernen resultiert, lässt sich nicht so leicht in Metaphern kleiden und ist weniger offensichtlich.

Um sie zu verstehen, muss man zunächst die 5 Orders of Ignorance von Phillip G. Armour verstehen. Johann-Peter Hartmann hat sie in seinem Talk über Management Brainfucks sehr gut in deutscher Sprache zusammengefasst:
(0OI) Lack of Ignorance: Ich weiß etwas
(1OI) Lack of Knowledge: Ich weiß etwas bestimmtes nicht.
(2OI) Lack of Awareness: Ich weiß nicht, was ich nicht weiß.
(3OI) Lack of Process: Ich weiß nicht, wie ich herausfinde, was ich nicht weiß.
(4OI) Meta Ignorance: Ich weiß nicht, dass es unterschiedliche Arten von Nichtwissen gibt.

Antifragilität durch Lernen bedingt, dass man um die Existenz der Meta Ignoranz weiß. Nur dann kann man sich mit der Ignoranz zweiter und dritter Ordnung beschäftigen. Diese beiden Stufen des Nichtwissens sind nämlich genau die, denen ein Schwarzer Schwan zu verdanken ist. Dinge, die ich weiß oder Dinge, von denen ich weiß, dass ich sie nicht weiß, sind harmlos, denn sie können mich nicht überraschen. Es ist möglich, sich auf sie vorzubereiten – also entweder die Fähigkeit zur Robustheit oder zur Resilienz in Bezug auf sie zu entwickeln.

Genau in diese Kategorie fallen alle Konzepte von Software-Architekturen, wie z.B. Komponentenbasierte Architekturen, Serviceorientierte Architektur und auch Paradigmen wie Verteilung, ReST, BigData – und eben die Microservices. (Hint: Als alter Unixer sind die für mich absolut nichts Neues – SCNR)

Was ich an Russ Miles’ Ideen kritisiere, ist die Verbindung von Antifragilität mit einem konkreten Architekturkonzept. Keine Architektur, die wir als Softwerker heute umsetzen können, bewahrt uns von Schwarzen Schwänen oder wird bei ihrem Eintreten besser. Das kann Software-Architektur heute nicht leisten und das wird sie auch in Zukunft nicht leisten können. Denn die Software-Architektur selbst kann nur die Ignoranz nullter und im besten Fall erster Ordnung adressieren.

Um Antifragilität in die Software-Achitektur zu bringen, darf man sich nicht auf die Technik, Konzepte oder Paradigmen konzentrieren. Diese sind per se nicht Antifragil, da sie sich weder zufällig weiterentwickeln noch selbst lernen können. Man muss sich also auf die Menschen konzentrieren, die solche Architekturen konstruieren. Diese Menschen, wir Software-Architekten, können lernen und erfüllen somit eine der Vorbedingungen für Antifragilität. Und was wir lernen müssen, um Software-Achitektur antifragil zu machen, zeigen die zweite und dritte Stufe des Nichtwissen. Wir müssen lernen, mit Dingen umzugehen, von deren Existenz man nichts weiß und wir müssen lernen, solche Dinge systematisch zu erkennen.

Dieses systematische Erkennen geht mit etwas einher, das in der Welt der Software-Entwicklung nur ungern akzeptiert wird: der Akzeptanz des Unvorhersehbaren, des nicht Planbaren, jenen Dingen, die Software-Entwicklung vermeintlich kompliziert und teuer machen. Diese Akzeptanz ist aber notwendig, um Antifragilität in die Welt der Software-Architektur zu bringen. Es ist unabdingbar, die Existenz von Ignoranz zweiter und dritter Ordnung akzeptieren und damit auch die Unmöglichkeit, Architekturen, ja noch nicht einmal Meta-Architekturen, zu konstruieren, die per se antifragil sind. Antifragile Software-Architektur bedeutet bewussten Umgang mit Nichtwissen und Akzeptanz von Emergenz durch den Software-Architekten.

Antifragilität, die Verbesserung durch den Eintritt eines Schwarzen Schwans, ist dann nicht mehr eine Eigenschaft der Architektur, sondern vielmehr des Architekten.

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