Das Commitment des Product Owners

In Scrum committet sich das Entwicklungsteam auf das Sprintziel. Und der Product Owner? Der committet sich auch auf die Sprint-Planung! Genauso wie das Entwicklungsteam darf er das Ergebnis der Sprint-Planung nur dann akzeptieren, wenn er es für sinnvoll hält. Das bedeutet insbesondere auch: Der Product Onwer committet sich nur dann auf das Ergebnis der Sprint-Planung, wenn aus seiner Sicht die Entwicklungsgeschwindigkeit des Teams zufriedenstellend ist. Wenn der Product Owner meint, die Geschwindigkeit sei zu niedrig und das Projekt nicht ökonomisch sinnvoll durchführbar, muss er sein Commitment verweigern. Das Ergebnis: es gibt kein Commitment und damit keinen nächsten Sprint.
Und dann? Dann spricht man über die Situation: Ist das Team unpassend zusammengesetzt? Fehlt es an Aus-/Weiterbildung? Gibt es ein anderes Team, dass den Anforderungen des Product Owner besser genügen kann? Etc. Und wenn die Antwort immer "Nein" lautet, dann muss sich der Product Owner die Frage stellen, ob sein Projekt überhaupt ökonomisch sinnvoll ist.
Und bei allem sollten wir ganz gelassen bleiben. Wenn der Product Owner sein Commitment nicht geben kann, ist das keine Krise. Es ist das Ende einer Illusion.

Post bewerten

Pair-Programming-BOT für TDD

Sebastian hat dieses Kleinod gefunden: Den virtuellen Pair-Partner. Das ist lustig.

Aber es ist nicht nur lustig. Ich glaube, das Ding kann in der Tat ganz gute Dienste leisten, wenn man TDD erlernen möchte. Dann ist es nämlich tatsächlich sehr nützlich, genauso dogmatisch vorzugehen, wie der BOT das tut.

Post bewerten

Pecha Kucha auf der JAX 2009

Auf der diesjährigen JAX wird es auf dem Agile Day eine Pecha Kucha
Session geben. Pecha Kucha ist eine spezielle Form der Präsentation.
Es werden mehrere Präsentationen verschiedener Autoren zu agilen
Vorgehensweisen in Folge gezeigt. Jede Präsentation besteht aus genau
20 Folien, die jeweils genau 20 Sekunden angezeigt werden.

Dafür suche ich Referenten. Wer Interesse hat (und möglichst sowieso
auf der JAX oder mind. der Gegend ist), möge sich bei mir melden.

Mehr Infos zu Pecha Kucha:

• http://de.wikipedia.org/wiki/Pecha_Kucha
• http://www.wired.com/techbiz/media/magazine/15-09/st_pechakucha
  

Post bewerten

Rezension zu: Refactorings in großen Softwareprojekten

Ralph Johnson hat die englische Übersetzung des Refactoring-Buches von Martin und mir gelesen und findet es gut. Da fühle ich mich jetzt ja schon ein wenig geadelt...

Post bewerten

Stories schneiden

Bernd Schiffer hat in seinem Blog ausführlich und gut beschrieben, warum und wie man Stories zerschneiden sollte, um sie klein zu kriegen.
Dazu habe ich noch eine Ergänzung, die Straßenmetapher beim Dimensional Planning. Bei diesem Ansatz unterscheidet man die "Schönheit von Stories" und verwendet eine Straßenmetapher (Diese Art des Kleinschneidens ist in Bernds Ausführungen bereits implizit enthalten.) Stories können in vier Ausführungen realisiert werden:

• Feldweg: minimal billige Lösung, die irgendwie funktioniert. Beispiel: Ich will eine Rechnung drucken. Dazu setze ich SQL direkt in der mySQL-Konsole ab. Die ermittelten Daten übertrage ich von Hand in MS-Word und drucke die Rechnung von dort aus.
• Kopfsteinpflaster-Straße: sehr einfache Lösung, die schon Vereinfachung/Mehrnutzen bringt. Beispiel: Die Rechnung wird automatisch gedruckt, enthält aber nur die gesetzlich vorgeschriebenen Daten wie Kunde, Gesamtbetrag und MWSt.
• Alphaltierte Straße: gute Standardlösung. Beispiel: Die Rechnung bekommt noch die Positionen dazu.
• Autobahn: Top-Lösung. Beispiel: Der Kunde kann seine Rechnung personalisieren.

Diese Metapher kann man zum einen gut dazu verwenden, um mit dem Product Owner auszuhandeln, wieviel überhaupt notwendig ist. Das kann die Abschätzung des Product Backlogs vereinfachen.
Und dann kann man diese Ausbaustufen auch zeitlich betrachten (auch innerhalb eines Sprints). Zuerst baut man den Feldweg und erweitert ihn dann in Richtung Kopfsteinpflaster-Straße etc.

Post bewerten

Studie zu Projektmanagement

Wissenschaftliche Untersuchungen sollte man unterstützen. Es nützt uns allen, wenn wir besser verstehen, warum welche Dinge (nicht) funktionieren.
Also bitte mitmachen.

Post bewerten

Pull und Kanban - über die Entwicklung hinaus

Das Pull-Prinzip stammt aus dem Lean-Production und ist ein (mehr oder weniger expliziter Aspekt) agiler Softwareentwicklung. Die Idee ist, dass man nicht Arbeit in eine Ressource (z.B. Team) hineindrückt (push), sondern die Ressource sich selbst neue Arbeit holt (pull), wenn sie keine mehr hat. So wird Überlastung der Ressource vermieden.

In Scrum holt sich das Team im Sprint-Planning soviel Arbeit ab, wie es meint, im Sprint realisieren zu können - auch wenn der Product-Owner gerne mehr realisiert haben möchte. Er darf nicht mehr Arbeit in die Sprint drücken. Das Team wendet also Pull an.

Wenn man das Pull-Prinzip weiterdenkt, muss man mind. die Prozesse nach der Entwicklung mit einbeziehen (upstream processes). Faktisch findet in vielen Organisationen nach dem Sprint noch abschließende Qualitätssicherung und Überführung in den Betrieb statt. Dort sollte man natürlich auch nach dem Pull-Prinzip verfahren. Das Team drückt also nicht mit einer festen Live-Deadline die Ergebnisse des Sprints in die Qualitätssicherung und den Betrieb. Stattdessen holen sich Qualitätssicherung und Betrieb ihre Arbeiten, wenn ihre Auslastung es zulässt.

Wie setzt man das konkret um? Ganz Basic-Lean gedacht würde sich der Product Owner an das letzte Element der Wertschöpfungskette wenden und seinen Feature-Wunsch äußern, z.B. "Ich möchte, dass ich die Kontakthistorie von Kunden einsehen kann." Diesen Auftrag würde er auf einen Zettel schreiben und an den Betrieb geben.

Der Betrieb würde daraus einen (Sub-)Auftragszettel an die Qualitätssicherung formulieren: "Ich möchte eine qualitätsgesicherte Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können."

Die Qualitätssicherung macht daraus einen Auftragszettel an das Entwicklungsteam: "Ich möchte eine Funktionalität haben, die den Anwendern erlaubt, die Kontakthistorie von Kunden einzusehen. Außerdem muss die Funktionalität geclustert auf einem Tomcat mit mySQL betrieben werden können. Die ganze Funktionalität muss soweit möglich mit FIT akzeptanzgetestet sein und es muss Beschreibungen geben, was noch manuell zu testen ist."

Dann beginnt das Entwicklungsteam, diesen Arbeitsauftrag abzuarbeiten. Wenn es fertig ist, liefert es die Systemfunktion an die Qualitätssicherung zusammen mit dem zugehörigen Auftragszettel. Die Qualitätssicherung verfährt entsprechend an den Betrieb und dieser an den Kunden.

Der ganze Arbeitsfluss wird also über Auftragszettel gesteuert. Diese Auftragszettel heißen im Lean-Production Kanban.

Mit den Auftragszetteln wie beschrieben in der Softwareentwicklung vorzugehen, ist i.d.R. unnötig teuer. Es wird zu viele Missverständnisse geben. Viel besser ist das persönliche Gespräch. Also wendet sich der Product Owner direkt an das Team und erläuert, was er benötigt. Was uns dann der ganze Kanban-Ausflug bringt? Bei diesem Gespräch (Sprint Planning) müssen Qualitätssicherung und Betrieb einbezogen werden. Man faltet den Prozess mit den Auftragszetteln zusammen, um schneller zu sein. Die Beteiligten bleiben aber dieselben!

Post bewerten

Stehen, stehen, immer nur stehen?

Hier ist ein interessanter Blog-Eintrag, in dem beschrieben wird, dass die japanischen Lean-Unternehmen auf das Stehen stehen (was für eine formvollendete Formulierung :-)
Die dort genannten Gründe für das Stehen (bessere Ergonomie, herumlaufen ist wichtig etc.) gelten alle auch für die Softwareentwicklung. Unsinn? Nein! Mein Kumpel Henning hat seit seinem Bandscheibenvorfall einen Tisch, der sich auf Stehhöhe hochfahren lässt. Und daran haben wir auch schon Pair-Programming gemacht und es war auf keinen Fall unangenehmer als dies sitzend zu tun.
Irgendwie haben wir die Idee aber nicht weitergetrieben. Ich habe aber mehr und mehr das Gefühl, dass wir das nochmal tun sollten.

Post bewerten

Artikelserie Perspektivenwechsel in Java-Magazin und auf JAXenter

Es gibt eine Artikelserie namens "Perspektivenwechsel" im Java-Magazin, in der ich hin und wieder auch mitschreibe. In der Artikelserie werden unterschiedlichste Themen aufgegriffen, manchmal vielleicht auch etwas provokativ. Mit etwas Verzögerung erscheinen die Artikel auch online auf JAXenter.

Post bewerten

One Piece Flow

Wir wünschen für die agile Softwareentwicklung One-Piece-Flow. Idealerweise soll immer nur eine Story oder ein MMF in Arbeit sein. Dass One-Piece-Flow dem klassischen Modell (Batchen von Aktivitäten) überlegen ist, zeigt dieses Video sehr schön.

Post bewerten

Kundenorientierung und Kommunikation extrem

absolut lesenswerter Artikel

Und jeder der denkt "bei uns geht sowas nicht", könnte mal dazu denken: "Was muss ich tun, damit sowas bei uns geht?".

Post bewerten

XP and Frameworks

At the XP2000 conference I had a talk about eXtreme Programming and frameworks. Some people archive things for a really long time. One of them reread my article and asked me a few days ago if I did further research on it. I didn't really do research but I collected some experiences which lead me to some simple conclusions (which didn't changed too between 2000 and now):

• Use before reuse. First you have to use some code successfully and than you can think about generalizing it for reuse. That means that you have to invest effort to refactor application code to framework code. A lot of teams try to avoid this "rework" but in most cases the effect is that the framework becomes bloated and hard to use.
• Running application: You always have to have a running application on top of your framework that proves that the framework is useful. This application may be a demo application but that would restrict the "prove". A real application is much better.
• Supporting framework team: This is the really hard one. When your framework grows larger and supports more than one application team you normally need an own framework team. That is easy part, here is the hard part: The framework team has to have a perspective that the application teams are their customers and that they have to listen to the application teams and support them. Most frameworks teams I met had another attitude. They thought that they understand much better how to implement applications than the application developers know and that the application developers are dumb and foolish to a certain degree. That results in the attempt to prescribe how to develop with the framework. And that doesn't work, especially not if you try to support agile teams that should be self organized and empowered.
  

Post bewerten

Technical Debt

Martin Fowler hat einen Vorschlag gemacht, wie man Technical Debt "messen" kann. Das ist sicher ein guter Anfang.

Post bewerten

Color Modeling

Color Modeling ist die Modellierungstechnik, die Feature-Driven-Development (FDD) vorschlägt - aber nicht verpflichtend macht. Aber auch außerhalb von FDD kann Color Modeling sehr nützlich sein. Ich habe es (in adaptierter Form) in Scrum/XP-Projekten eingesetzt.
Insgesamt finde ich, dass die Technik zu wenig bekannt ist und unterschätzt wird. Daher freut es mich, dass jetzt eine gute Erläuterung zu Color Modeling mit ein paar Erfahrungswerten aufgetaucht ist.

Post bewerten

Ivar Jacobson über die Zukunft der Softwareentwicklung

The future of software development practices.

Post bewerten

Software-Putzer?

Nico Josuttis schreibt in seinem Blog über Software-Putzmänner und die nächste IT-Revolution. Er schlägt darin vor, schlechte Softwarequalität einfach als Fakt hinzunehmen und nicht immer zu versuchen, die Qualität zu verbessern. Vielmehr ginge es darum, mit dieser schlechten Qualität umzugehen. Als eine mögliche Alternative schlägt er Software-Putzkolonnen vor, die hin und wieder kommen und dann im Code aufräumen.

Dazu fallen mir gleich ein paar Sachen ein.

Zuerst zum Akzeptieren schlechter Qualität: Wenn die Qualität wirklich schlecht ist, wirkt sich das mannigfaltig unangenehm aus. Selbst der Product Owner bemerkt es. Nicht nur durch die langsame Entwicklungsgeschwindigkeit sondern auch dadurch, dass er aus technischen Gründen seine Priorisierungen ändern und seine Stories anders aufschreiben muss.

Und ich habe auch gerade ein aktuelles Projektbeispiel zur Hand, dass sich das Aufräumen lohnt. Beim Kunden dümpelte ein Team bei 30 Story Points je Sprint rum. Irgendwann hat das Team festgestellt, dass umfangreichere Refactorings im Bereich CSS notwendig sind, um schneller zu werden. Sie haben die Refactorings in Angriff genommen und die haben viel länger gedauert als zunächst gedacht - das ist nach meiner Erfahrung fast immer so bei größeren Refactorings. Aber sie haben es durchgestanden, obwohl es sogar soweit ging, dass nicht mehr alle Entwickler während des Sprints beschäftigt werden konnten. Nach dem Refactoring hat die Geschwindigkeit des Teams deutlich zugelegt. Heute liegt die Geschwindigkeit bei 80 Story Points je Sprint.
Mindestens in diesem Fall hat sich das Aufräumen schnell gelohnt und es wäre finanzieller Irrsinn gewesen, das Refactoring nicht durchzuführen.

Und zu den Putz-Kolonnen kann ich gleich zwei Erfahrungen beisteuern.
Erstens: Wir hatten bei it-agile mal so ein Dienstleistungsprodukt im Angebot. Das war ein Ladenhüter. Daher gibt es das jetzt nicht mehr als explizites Produkt bei uns. Wenn jemand sich dafür interessiert, beleben wir es aber jederzeit gerne wieder :-)
Zweitens: Wir hatten in einem Projekt mal sowas wie eine Putz-Kolonne in ganz zarten Ansätzen. Das hat in meinen Augen nicht funktioniert. Zum einen liefern die Projekte dann noch schlechtere Qualität - die Putz-Kolonne wird es schon richten. Zum anderen musste die Putz-Kolonne ständig bei den Entwicklern nachfragen, was bestimmter Code bedeutet. Und damit wurde das Team dann doch wieder mit Putzarbeiten belastet.

Langer Rede kurzer Sinn: Ich vertrete genau den konträren Ansatz. Wir als Entwickler sind für die technische Qualität des Systems verantwortlich. Wer schlechte technische Qualität abliefert, verstößt aus meiner Sicht gegen den Code of Ethics unserer Zunft und sollte sich was schämen. Niemand wird uns die Zeit und das Geld zum Aufräumen geben und die Putz-Kolonne wird auch nicht kommen. Wir als Entwickler müssen die Sache selbst in die Hand nehmen und zu unserer Verantwortung stehen!

P.S.: Zum Code of Ethics: Punkt 3 lautet: "PRODUCT - Software engineers shall ensure that their products and related modifications meet the highest professional standards possible." Das bedeutet meiner Meinung nach auch, hohe Qualität abzuliefern.

P.P.S.: Wer mehr darüber erfahren möchte, wie guter Code für agile Entwicklung aussieht und wie man den schreibt: ich werde auf der OOP darüber einen Vortrag halten.

Post bewerten

Priorisierung von Features

mal eine neue nette Idee zum Thema von David Anderson

Post bewerten

Aufgaben schätzen oder Aufgaben schneiden?

Viele agile Projekte arbeiten mit Stories, um die Anforderungen zu definieren. Die Komplexität von Stories wird mit abstrakten Story Points geschätzt. Bei der Sprint-/Iterationsplanung findet der sogenannte Task Breakdown statt: Die Stories werden in Aufgaben (Tasks) für die Entwickler zerlegt und diese Tasks werden dann in Personenstunden oder -tagen geschätzt (Commitment Driven Planning). Die Tasks sollten dabei möglichst klein sein. Häufig wird ein Tag als Obergrenze genannt. Dann hat man beim Daily Standup im Durchschnitt jedes mal mind. einen Tasks als erledigt zu vermelden.

Wir haben gute Erfahrungen damit gemacht, die Tasks nicht nur möglichst klein sondern auch möglichst gleich groß zu halten. Wenn alle Tasks gleich groß sind, muss man Aufwände nicht mehr zusammenrechnen, sondern muss nur noch Tasks zählen. Und wenn man irgendwo mal umplanen muss, ist das auch ganz einfach: Einen Task weghängen und einen neuen dafür dazu hängen. Die Vorteile sind in der Praxis deutlich spürbar.

Allerdings kommt man jetzt in eine Zwickmühle. Tatsächlich sind die Tasks konkret nicht alle gleich groß, sondern nur im Durchschnitt. Das kann dazu führen, dass das Team in einem Sprint/Iteration 20 Tasks schafft und in einem anderen 22 Tasks. Für Commitment Driven Planning reicht das Durchzählen der Tasks also nicht aus. Wenn man beim Sprint-/Iterationsreview feststellt, dass man ein paar Tasks mehr oder weniger geschafft hat als geplant, sagt das erstmal wenig aus. Die Abweichung könnte durch die natürlichen Schwankungen bedingt sein.
Das Problem ließe sich durch das Schätzen von Tasks in Stunden beheben, dann ist aber der Vorteil der gleichen Größe wieder futsch.

Daher hat eins meiner Teams mit "halben" Tasks experimentiert. Die meisten Tasks hatte die Normgröße. Einige wenige Tasks waren kleiner und wurden daher mit 1/2 annotiert. Das hat aber nicht so richtig gut funktioniert. Die bereits vorher sehr guten Commitments wurden dadurch nicht besser. Dafür wurde Sprint-/Iterationsplanung umständlicher und beim Review gab es immer wieder Verwirrung um das Tracking ("Zählen wir die halben Tasks für das Tracking jetzt voll oder nur halb?"). Folgerichtig hat das Team die halben Tasks wieder abgeschafft und arbeitet jetzt wieder unter der Annahme, dass alle Tasks gleich groß sind.

Interessant sind noch zwei Diskussionen, die wir geführt haben:
1) Boris Gloger hat vorgeschlagen, bei Sprint-/Iterationsplanung gar nicht mehr zu schätzen. Stattdessen fragt man das Team nach dem Task Breakdown einfach Story für Story "Würdet Ihr Euch darauf committen?" Tatsächlich reicht das vollkommen aus. Es geht darum, ein Commitment auf die Planung zu bekommen. Wie man das erreicht ist sekundär. Allerdings mochte das Team Boris' Ansatz nicht folgen. Sie meinten, sie könnten auf dieser groben Ebene nicht einschätzen, ob die Planung funktioniert.
2) Man könnte die Tasks auf eine einheitliche Größe zwingen. Dann würde man nicht Tasks auf ToDo-Zettel schreiben, sondern auf Slot-Zettel. Ein Slot hätte eine feste Größe (z.B. 1/2 Personentag) und man müsste die Tasks so formulieren, dass sie auf diese Größe passen. Bei sehr kleinen Aufgaben müsste man mehrere Tasks auf einen Slot-Zettel schreiben. Diese Herangehensweise hat das Team kontrovers diskutiert, letztlich aber abgelehnt. Es schien den Entwicklern zu unnatürlichen Tasks zu führen.

Im Ergebnis ist das Team als bei einer Sprint-/Iterationsplanung verblieben, die mit etwas unscharfen Werten hantiert - alle Tasks werden als gleich groß angesehen, obwohl sie das nicht sind. Das ist solange unproblematisch, wie das Team trotzdem ein Commitment auf die Planung abgibt und das tut es. Jetzt muss man mal beobachten, wie es sich mit der tatsächlichen Qualität der Planungen verhält.

BTW: Ich persönlich mag den Ansatz von Boris und ich tendiere zu dem Slot-Zettel-Ansatz, um alle Tasks gleich groß zu bekommen. Dass ggf. mehrere Tasks auf einem Slot-Zettel stehen, halte ich für unproblematisch, weil sie so klein sind. Man wird die Aufgaben eines Slot-Zettels ohnehin nicht aufspalten und parallel abarbeiten lassen wollen.

P.S.: Tasks gleicher Größe zu haben, reduziert Variabilität und reduzierte Variabilität führt laut Lean Development/Production zu einer höheren Produktivität. Siehe auch bei David Anderson.

Post bewerten

Wie misst man technical debt?

Das Konzept des Technical Debt (technische Schuld) ist schon alt: Wenn man Qualität opfert, um einen bestimmten Termin zu halten, geht man eine technische Schuld ein. Diese technische Schuld bezahlt man zunächst mit einer reduzierten Entwicklungsgeschwindigkeit. Wenn man die technische Schuld dann irgendwann zurückzahlen will, kostet es i.d.R. ein Vielfaches von dem, was man ursprünglich "eingespart" hat.

Soweit so gut. Leider hilft das Konzept in der Projektpraxis nicht so fürchterlich gut. Es gibt kein vernünftiges Verfahren, um Höhe und "Zinssatz" der technischen Schuld zu messen.

Hier gibt es jetzt mal einen Vorschlag, technische Schuld zu messen und zwar in WTFs pro Minute.

Lustig? Klar!
Ernsthaft verwendbar in der Projektpraxis: Da sollte man vielleicht mal drüber nachdenken...

Post bewerten

Einladung zu den XP-Days Germany 2008 in Hamburg

Das Programm für die XP-Days Germany 2008 in Hamburg steht jetzt fest (siehe Programm). Vorträge gibt es am 27.11.08 (Donnerstag) nachmittags und am 28.11.08 (Freitag) den ganzen Tag. Wir haben ein vielfältiges Programm, dass sowohl den Interessen von Neueinsteigern wie auch alter Hasen im Bereich der agilen Methoden gerecht wird.

Wie der Untertitel der Konferenz bereits deutlich macht: Die XP-Days bieten allen agilen Methoden ein Forum, nicht zur eXtreme Programming. Das zeigt sich auch dieses Jahr wieder am Programm. Die meisten Vorträge bieten Wissenswertes, dass sich mit jeder agilen Methode kombinieren lässt.

Der Samstag richtet sich an all diejenigen, die aktiv mitdiskutieren wollen. Dazu muss man kein Experte mit jahrelanger Erfahrung sein. "Nur" das Engagement ist wichtig. Folgerichtig gibt es für den Samstag kein vorab festgelegtes Programm. Stattdessen wird eine "Unconference" im Open-Space-Stil stattfinden.

Jetzt bleibt eigentlich nur noch eines zu tun: Anmelden und den Frühbucherrabatt sichern!

Post bewerten