Agile Entwicklung
Premierminister, werde agil!
03. Mrz
Es gibt eine britische Website, auf der man online eine Petition an den Premierminister schreiben und unterzeichnen kann. Auf dieser Site findet sich eine neue Petition, die der Regierung empfiehlt, die Art und Weise, wie öffentliche Projekte eingekauft und abgewickelt werden, zu überdenken – in Richtung von inkrementellen und agilen Vorgehensweisen. Der Petitionstext (Übersetzung von mir):
Wir, die Unterzeichner, haben keine Lust mehr, zu hören, wie viel von unserem Geld für fehlgeschlagene IT-Projekte der Regierung verpulvert wird.
Wir glauben, dass dies im Wesentlichen an der Art und Weise liegt, mit der diese Projekte ausgeschrieben und geliefert werden – nämlich, alle Anforderungen eines enormen Projektes im Vorhinein zu verlangen und sich darauf zu verpflichten. Das verurteilt Projekte dazu, fehlzuschlagen noch ehe sie begonnen haben.
Im privaten Sektor hat man sich bereits weitgehend von diesem falschen Modell zu einem inkrementellen Ansatz bewegt, der Änderungen im Verständnis und den Anforderungen erlaubt und die Wahrscheinlichkeit für einen Misserfolg enorm reduziert. Es ist an der Zeit, dass unsere Regierung das auch tut.
Wir bitten den Premierminister, den aktuellen Ansatz auf den Prüfstand zu stellen und für IT-Projekte der Regierung einen mehr inkrementellen und agilen Ansatz in Betracht zu ziehen.
Wow, das sollte hier in Deutschland auch gelten! Wo kann man hier eine ebensolche Petition abgeben? Ich wäre sofort dabei!
Projektverträge: Schlanke Regelungen ersparen Tauziehen
26. Feb
Heute erscheint die neue Ausgabe der Fachzeitschrift OBJEKTspektrum, diesmal mit dem Schwerpunktthema “Lean Development und Kanban”. Darin finden Sie auch einen Artikel von mir über agile Projektverträge. Hier die Zusammenfassung:
Umfragen unter Benutzern von IT-Systemen ergeben: Nur zwanzig Prozent der Funktionen eines IT-Systems werden “immer” oder “oft” benutzt, fast zwei Drittel hingegen “selten” oder “nie”. Diese Zahlen haben den Umgang mit Anforderungen in IT-Projekten verändert: Lernen im Projekt ist ausdrücklich erlaubt, Änderungen sind willkommen. Diese Situation stellt neue “Anforderungen an die Anforderungen”. Der Artikel zeigt, wie Anforderungen heute aussehen können, damit man mit ihnen sehr schlanke Projektverträge gestalten kann. “Money for nothing, changes for free” sind hier die zunächst unglaublich klingenden Stichworte. Auftrag geber und Entwicklungsorganisation ziehen am selben Strang, Änderungsanforderungen kosten ab jetzt kein zusätzliches Geld mehr und brauchen deshalb nicht mehr verhandelt zu werden.
Im Flow arbeiten! Der Kunde wird es danken!
23. Jan
Das folgende kleine Flash-Video habe ich erstellt, um Ihnen zu zeigen, wie es sich auswirkt, wenn Ihr Team traditionell im Stapel arbeitet (z.B. 5 Sachen spezifiziert, dann 5 Sachen entwickelt) oder wenn es im Flow arbeitet und nur 1 Sache spezifiziert, dann 1 Sache entwickelt, usw.
Der rund eine Minute lange Film zeigt anschaulich, wodurch der Unterschied für den Kunden zu Stande kommt. Mehr über Flow gibt es hier.
Features priorisieren in der Gruppe [OOP 2010]
15. Jan
Mein aktueller Kunde hat ein Stakeholder-Gremium, das sich regelmäßig trifft, um neue Anforderungen zu priorisieren, die das Entwicklungsteam baldmöglichst umsetzen soll. Es besteht aus Vertretern der relevanten Geschäftsbereiche, die jeweils mit einem Teil der Anforderungen im selben lauffähigen System zu unterschiedlichen Zeitpunkten “live” gehen wollen. Die Stakeholder müssen sich also (trotz unterschiedlicher Interessen) auf einheitliche Priorität einigen, die der Product Owner dann dem Entwicklungsteam gegenüber vertritt.
Ausgangssituation: Priorität gemeinsam festlegen
Sich zu einigen ist nicht ganz einfach. Man muss dabei folgende Fragen gleichzeitig beantworten:
- Wie viel geschäftlichen Vorteil bringt mir ein bestimmtes Feature?
- Bin ich bereit, den geschätzten Entwicklungsaufwand zu genehmigen?
- Was meinen die anderen Stakeholder dazu?
- Kriegen wir einen Konsens hin, so dass wir besser zwei ganze anstelle von vier halben Features beauftragen können?
Gestern war ich beim ersten Treffen dieses Gremiums, eingeladen als Coach für agile Methoden und Produktivität. Um möglichst einfach auf einen Konsens über die Prioritäten zu kommen, spielten wir das Innovationsspiel Buy a feature. (Danke an Michael Mahlberg, der die Idee hatte, dieses Spiel zu nehmen!)
Der Product Owner stellte die Stories (Features) aus dem Product Backlog mit Hilfe von User Story Karten vor. Die Entwickler hatten den Aufwand für diese Stories vorher in Story Points abgeschätzt, der Product Owner hatte den Aufwand auf den Karten vermerkt.
Spielregeln
Die Spielregeln für “Buy a feature” sind sehr einfach und wirkungsvoll:
- Jeder Stakeholder bekommt eine bestimmte Anzahl Münzen.
- Jedes Feature hat einen “Preis”, der durch den Entwicklungsaufwand bestimmt wird.
- Stakeholder “kaufen” nun die Features, die sie für wichtig halten, indem sie die Münzen auf die Story-Karten legen. Da sie nicht alles kaufen können, müssen sie priorisieren.
- Wenn eine Karte so viele Münzen bekommen hat wie ihr Preis angibt, gilt sie als gekauft und kommt ans obere Ende des Product Backlogs.
Als Münzen eignen sich farbige Plättchen, wie sie im Flohspiel verwendet werden. Die gibt es im Spielzeuggeschäft auch einzeln zu kaufen, ca. 5 Cent pro Stück. Eine separate Farbe pro Geschäftsbereich ist günstig, dann können Spieler ihre Münzen auch wiederfinden und auf andere Features legen, um z.B. einen Konsens zu bekommen.
Die Randbedingungen hatte ich wie folgt gesetzt:
- Ich gab nur so viele Münzen aus wie Story-Points in den ersten Sprint passen, orientiert an der Velocity des Teams.
- Der Product Owner stellte ungefähr doppelt so viele Features vor wie in den Sprint passen, damit die Stakeholder genügend Auswahl hatten.
- Die Stakeholder aus einem Geschäftsbereich bekamen mehr Münzen als die anderen, weil der erste “Launch” des neuen Systems im Wesentlichen die Belange dieses Geschäftsbereiches abdecken wird.
Der Ablauf des Spiels
Der Product Owner stellte die Features vor, jeweils als kurze Zusammenfassung der darin enthaltenen Funktionalität. Die Stakeholder stellten Fragen nach dem Inhalt, den Abhängigkeiten und der Abgrenzung der Features.
Danach bildeten die Geschäftsbereiche kleine Gruppen und diskutierten, welche Features für ihren Bereich Priorität bekommen sollten. Es bildete sich schnell eine diskutierende Traube von Leuten um die Karten, die auf dem Tisch lagen.
Nach ca. 10-15 Minuten begann der Sprecher des einen Geschäftsbereichs, seine Münzen auf die Features zu platzieren und argumentierte, warum er sich so entschieden hatte. Die anderen schlossen sich an und platzierten ebenfalls ihre Münzen. Da der Preis für manche Features zu hoch war, um durch einen einzelnen Bereich bezahlt zu werden, bildeten sich Allianzen um die Features, die als teuer und trotzdem wichtig erachtet wurden.
Eines der Features war besonders teuer, es handelte sich um die Entwicklung eines Grundkonzeptes, das für fast alle weiteren Sprints wichtig sein würde. Der Product Owner warb dafür, es trotz des hohen Preises zu kaufen. Einige Stakeholder argumentierten dagegen, mit der Begründung, je länger sie die lauffähigen Features testen könnten, die im ersten Sprint entstehen, umso besser. Ein Geschäftsbereich, dessen Launch-Datum noch weit in der Zukunft lag, sagte dann: “Für uns wäre dieses Feature extrem wichtig, doch ob das Konzept nun jetzt oder erst im nächsten Sprint kommt, ist uns egal. Wir stellen unser Geld deshalb den anderen zur Verfügung.” Wer hätte das für möglich gehalten?
Zum Schluss blieben einige nur teilweise finanzierte Features übrig. Die Gruppe verteilte deren Münzen so, dass ganze Features gekauft werden konnten. Alle Münzen waren ausgegeben, zehn Features für den ersten Sprint standen damit fest.
Ich fragte noch nach der Priorität dieser Features untereinander, da das Spiel ja nur eine reine Ja/Nein-Aussage liefert. Diese Reihenfolge ergab sich sehr schnell aus den Feature-Abhängigkeiten und aus der Frage: “Wenn die Entwickler in Stress kommen sollten, welches Feature darf dann am ehesten aus dem Sprint fallen?”. Wir sortierten die Karten nach dieser Reihenfolge, das Ergebnis sah aus wie auf dem Foto links.
Feedback vor und nach dem Spiel
Für die Gruppe der Stakeholder war es neu, Entscheidungen in wichtigen Dingen mittels spielerischer Verfahren zu finden. Zwei meldeten vor Beginn des Spiels Bedenken an: “Sonst haben wir solche Entscheidungen immer durch Diskussion gefunden. Ich glaube nicht, dass wir so ein Spiel brauchen.” Der Product Owner schlug vor, es erst einmal zu versuchen und falls es sich nicht bewährt, es wieder bleiben zu lassen. Ich erklärte, dass Diskussionen explizit erwünscht seien und niemand sofort kaufen müsse.
Nach dem Spiel fragte ich die Beteiligten nach ihrem Feedback. Es war einhellig positiv:
- “Die Visualisierung der Entscheidungen ist sehr gut.”
- “Man kommt sehr schnell zu einer Einigung.”
- “Es lockert diese Meetings auf und macht Spaß.”
Tja, da bleibt mir nur ein “Danke” an die Erfinder dieses Spiels. Ich kann es wirklich empfehlen!
Wann sollte man nicht agil arbeiten? [OOP 2010]
09. Jan
Gestern war ich in einem Gebäude mit Erdgeschoss und 8 anderen Stockwerken. Der Aufzug brachte mich in den 7. Stock, dann konnte ich mir aussuchen, auf einer Treppe oder mit einem anderen(!) Aufzug in den 8. Stock zu kommen, wo ich den Besprechungsraum, mein eigentliches Ziel, finden würde.
Einer der Teilnehmer am Workshop in diesem Raum sagte: “Vielleicht ist das Gebäude agil entwickelt worden, die Anforderung für den 8. Stock kam erst später. Oder vielleicht wurden die Tests eingespart?”
Allgemeines Gelächter in der Gruppe.
Das bringt mich auf die Frage: Wann ist es eigentlich sinnvoll, agil zu entwickeln und bei unvollständigen Informationen trotzdem weiterzumachen? Eigentlich ganz einfach: Agil zu entwickeln ist angebracht, wenn die Kosten für nachträgliche Änderungen geringer sind als die Verschwendung (waste, muda), die durch das Streben nach initialer Perfektion der Anforderungen ausgelöst werden würde.
Wann gilt diese Bedingung? Wahrscheinlich für fast alle “normalen” Softwareprojekte – für nur ganz wenige gilt sie nicht. In diesen Fällen sollte man dann besser nicht agil entwickeln.
Was meinen Sie – wann sollte man besser zuerst perfekt planen, dann umsetzen?
Prozess-Schutzmechanismen und Skipisten
09. Jan
Karl Scotland hat einen sehr interessanten Blog-Post über Sicherheitsmechanismen in Prozessen geschrieben. Seine wesentliche These: Prozesse hängen stark vom Können der Ausführenden ab – so wie es unterschiedlich schwierige Skipisten (schwarze, blaue, …) gibt, so gibt es unterschiedlich stark geschützte Prozesse. Je stärker die im Prozess eingebauen Schutzmechanismen, desto geringer sind unter Umständen Produktivität und die Reaktionsbereitschaft (Agilität). Mehr Risiko ermöglicht höhere Belohnung, bei entsprechendem Können der Skifahrer.
Lesenswert!
Kanban-Training im Februar 2010
21. Dez
Im Februar gebe ich ein zweitägiges Kanban-Training in deutscher Sprache. Kanban ist ein leichtgewichtiges Prozess-Framework für die Entwicklung von Software. Es überträgt die Kanban-Prinzipien, die ursprünglich im Umfeld von Lean Production entstanden sind, auf die Softwareentwicklung.
Anmeldung und Organisation übernimmt SIGS-DATACOM, auf deren Website Sie weitere Informationen über dieses Training finden können.
Ich freue mich, Sie in Köln zu sehen – das Training wird sehr spannend werden!
Scrum-Jobs wachsen stark
26. Sep
Job-Portale verfolgen Job Trends, also den Anstieg der Anfragen in bestimmten Aufgabengebieten, z.B. Projektmanagement mit Scrum, Agile und PMI. In den letzten drei Jahren zeigt sich ein eindeutiger Trend zu Scrum und anderen Agilen Methoden.
Ein Beispiel des Portals Indeed.com:
Mit TDD schreibt man Spezifikationen
17. Feb
Wenn man testgetriebene Entwicklung (TDD = test driven development) an Entwicklungsteams “verkaufen” möchte, trifft man oft auf Hindernisse oder Einwände:
- Wir können nicht Code testen, der noch nicht existiert
- Warum sollte ich Tests schreiben, das machen doch die Tester
- Ich bin ein guter Entwickler, ich brauche keine Tests als Beweis, dass mein Code funktioniert
- Entwickler sollten nicht ihren eigenen Code testen, das führt zu selbsterfüllenden Prophezeiungen
- Tester wissen viel besser wie man testet als Entwickler
- Testen in der frühen Phase kostet Zeit, die wir nicht haben
- usw.
Was dabei außer Acht gelassen wird: TDD ist viel eher eine Art und Weise zu spezifizieren als zu testen! Ich schreibe eine Spezifikation als Erwartung (expectation) hin, spreche darüber mit dem Kunden, ob er das genauso sieht und implementiere dann bis die Spezifikation “läuft”.
Selbst wenn jemand kein Java programmieren kann, kann er dieses hier mit etwas Übung lesen lernen und sich dadurch mit kommunikationsstarken Entwicklern (ja, die gibt’s!) abstimmen (siehe diese Seite über BDD = behaviour driven development):
public class BalancetransferServiceBehaviour extends TestCase { public void shouldTransferBalanceFromAccountWithSufficientFunds() { // create mock instances Mock fromAccount = mock(Account.class); Mock toAccount = mock(Account.class); // set expectations fromAccount.expects(once()).method(“debit”).with(20).isVoid(); toAccount.expects(once()).method(“credit”).with(20).isVoid(); } }
Der Code muss dazu nicht existieren – die ausführbare Spezifikation (früher sagte man auch: “der Test”) wird fehlschlagen, und der Entwickler kann den Code so schreiben, dass er die Spezifikation erfüllt.
[Diese Idee der ausführbaren Spezifikation ist schon sehr alt und wird jetzt anscheinend wieder in neuer Form populär. Witzig ist, dass es z.B. ein Open Source Tool (TestDox) gibt, das versucht, aus solchen Spezifikationen (Tests) normale Textdokumente zu generieren.]
Also sind Konflikte mit Testern eigentlich überflüssig, sobald diese sehen, dass es um maschinell ausführbare Spezifikationen als Vorgabe für Entwickler geht. Tester haben immer noch genug zu tun: Akzeptanztests, Usability-Tests, Performance- und Lasttests, Security-Tests, usw. — kein Problem!
Menschen statt Ressourcen [OOP 2009]
10. Dez
Manchmal reden Menschen von anderen Menschen als “Ressourcen”, so als ob sie Maschinen oder Möbel oder Gebäude wären. Das Wort Ressource kommt dann in so seltsamen Wendungen wie “Human Resource Management” oder “die HR-Abteilung” vor. Ein besonderes Beispiel findet sich in der Definition des Begriffes “Projekt” im CMMI-Glossar. Dort heißt es:
A project is a managed set of interrelated resources that delivers one or more products to a customer or end user. The set of resources has a definite beginning and end and operates according to a plan.
Ich kann nur sagen: Wenn ich in einem solchen Projekt arbeitete, käme ich mir als “verwaltete, in einer Wechselbeziehung stehende Ressource” ziemlich seltsam vor. Wann spricht es sich endlich herum? Software wird von Menschen gemacht, nicht von Ressourcen!
