Das kennt vielleicht jeder: Selbst gute eigene Vorhaben werden manchmal einfach nicht mehr durchgeführt. Was können wir leicht selbst dafür tun, die Selbstorganisation zu erhalten?

Was tun zur Stärkung der intrinsischen Motivation ohne sich unnötig zu disziplinieren?

1. Den Wert des Vorhabens formulieren.
   Wenn der Wert nicht hoch genug oder erstrebenswert ist, ist das schon zu Beginn ein Showstopper.
2. Optionen creiren. Was gibt es überhaupt für Möglichkeiten?
3. Ziele konkret vornehmen oder vereinbaren. Wann genau habe ich das Ziel erreicht?
4. Den ersten Schritt zum Ziel sofort aufschreiben und vielleicht sogar sofort angehen.
5. Abschließend das Ergebnis des Erreichten bewerten. Beibehalten oder ändern?

Kundenzufriedenheit ist im Agilen Manifest der höchste Wert. Diese hat Toyota durch große Qualitätsprobleme enttäuscht. Stand Toyota weltweit doch für zuverlässige Fahrzeuge. Vielleicht aus Übermut hatte 2002 der damalige Toyota Chef für 2010 einen Weltmarktanteil von 15% proklamiert. Letztes Jahr wurden 12% erreicht, nun fällt der Wert wieder. Auf dem Weg zu diesem immensen Größenwachstum hatte man den Kunden aus dem Visier verloren. Toyota steigerte mit Druck die Nachfrage nach ihren großmotorigen Geländewagen und hatte dann Mühe diese zu bedienen. Gegen den Rat der Gründerfamilie und anderen mussten Sonderschichten eingelegt werden. Die Qualität sank.

Nun kehrt Toyota zurück zu den Wurzeln. Der Enkel des Firmengründers hat Mitte 2009 wieder die Firmenleitung übernommen. Das Unternehmensziel sind nun innovative, umweltfreundliche Hybridfahrzeuge, deren Antrieb in den nächsten drei Jahren in der Praxis erprobt werden soll.

Siehe auch Süddeutsche Zeitung vom 16. Januar 2010 “Toyota unter Schock”

• Autonomie in der Arbeit,
• Anforderungsvielfalt der Arbeitsaufgaben,
• kreative Selbstwirksamkeit (die Überzeugung, Ergebnisse gezielt beeinflussen zu können) und
• ein ›gemischter‹ Komplex mit Teamklima, Kooperation und Kommunikation.

Mich verwundert es nicht, dass diese Bereiche den Agilen Werten verflixt ähnlich sind!

Autonomie in der Arbeit
Den stärksten positiven Einfluss scheint die Autonomie in der Arbeit auf Kreativität und Gesundheit zu haben.
Um die Autonomie zu erhöhen, sollten den Mitarbeitern weitgehende Tätigkeitsspielräume bei der Arbeit eingeräumt werden. Dazu gehören:

• der Handlungsspielraum, der den Mitarbeitern erlaubt, flexibel zu sein bei der Verfahrenswahl, dem Mitteleinsatz und der zeitlichen Organisation von Aufgabenbestandteilen,
• der Gestaltungsspielraum, der Möglichkeiten zur selbstständigen Gestaltung von Vorgehensweisen nach eigenen Zielsetzungen gibt und damit das Ausmaß an Variabilität einer Tätigkeit bestimmt und
• der Entscheidungsspielraum, der Mitarbeitern Entscheidungskompetenzen zur Festlegung von Tätigkeiten oder Aufgaben einräumt und damit das Ausmaß der Autonomie wesentlich bestimmt.

Quelle: Create Health! – Arbeit kreativ, gesund und erfolgreich gestalten. Bundesanstalt für Arbeitsschutz und Arbeitsmedizin (BAuA)

Der Microsoft Unit Test Wizard erstellt je existierender Methode das Gerüst einer Testmethode. Das dient jedoch eher Entwicklern, die ihre Tests im Nachhinein schreiben, um der Firmenvorgabe zu folgen. Um den designbestimmenden Aspekt der testgetriebenen Entwicklung zu nutzen, müssen auch bei Altanwendungen die Tests vor der Funktionserweiterung geschrieben werden.

Da Unit Tests nur auf öffentliche Klassen und Methoden zugreifen können, eignen sie sich als Test der Schnittstellen. Ein Black Box Test also. Gerät der Unit Test bei einer umfangreichen Klasse mit vielen privaten Methoden zu aufwändig, ist das ein Hinweis, dass Funktionalität in Hilfsklassen ausgelagert werden können. Dort sind die Methoden dann öffentlich und lassen sich so über einen Unit Test abdecken.

Anwendungsfälle (Use Cases) oder sehr kleine User Stories eignen sich aber grade wegen dieser Einschränkung hervorragend als Testfälle.

Auch wenn es bei TDD sehr verlockend ist, sofort drauflos zu coden, lohnt es sich vorher ein paar Minuten über das Design der Schnittstelle nachzudenken. Das deckt oft schwammige Punkte in der Anforderungsbeschreibung auf. Diesem lokalen Modell kann man sich dann mittels TDD sehr schnell nähern.

• Tägliche Teammeetings
• Burndown (oder -up) Grafiken je Iteration (Sprint) und für das gesamte Release
• Echte Fortschrittsmessung mit der Definition von DONE
• Anzahl der entdeckten Fehler nach DONE Meldung
• Review Meetings am Ende einer Iteration
• Grad der Testabdeckung

Daneben natürlich die üblichen Klassiker:

• Zeit
• Kosten

Muster hingegen sind Vorlagen zur Bewältigung komplexer Situationen.

Ein Rezept ist etwas zwischen einer Anleitung und einem Pattern.
Obwohl ein Kochrezept die Umwelt auf eine Untermenge beschränkt (Zutaten und Kochutensilien) und eine mehr oder weniger detaillierte Anleitung gibt, schmeckt das Resultat doch immer anders. Gleichzeitig erkennt man in den Ergebnissen Gemeinsamkeiten, also Muster.

Richtiges Anwenden einer guten Anleitung erbringt in der Regel das gewünschte Ergebnis. In komplexen Situationen gibt es hingegen viele Einflussfaktoren, die nicht dem Ursache-Wirkungs-Prinzip folgen. Ein Muster beschreibt eine Situation daher niemals komplett.

Siehe auch:
http://de.wikipedia.org/wiki/Entwurfsmuster
Linda Risiungs Pattern Almanac http://www.smallmemory.com/almanac/

Prinzip:
Mit der Einfachheit der Karten kann man den grundlegenden Ablauf der Zusammenarbeit und auch den Fortschritt wesentliche besser sehen, als mit einer Softwarelösung (ein häufiger Vertreter sei hier Bugzilla genannt).

Lösungsweg:
Die ersten 2-3 Iterationen mit Karteikarten beginnen und entsprechend des Feedbacks aus den Retrospektiven kann man mit einer Software den Prozess ergänzen. Zum Beispiel mit einem Ablagesystem für Detailinformationen wie einem Wiki.

Falls es wirklich nötig ist kann man die Karteikarten dann auch mit einer Software ersetzen. Das Team kann die Erkenntnisse und Erfahrungen über dem Planungsprozess mit den Karten dann besser auf das Softwaresystem übertragen.

Effekt:
Im ersten Sprintplanungs-Teil, in dem sich das Team die Anforderungen auswählt, zu denen es sich committed, wird der Restaufwand in idealen PT abgeschätzt. Über mehrere Iterationen hinweg werden also immer wieder die gleichen Anforderungen neu abgeschätzt. Das kostet Zeit und ist ermüdend. Dadurch wird der zweite Sprintplanungs-Teil, in dem die Anforderungen in Tasks herunter gebrochen und auf Stundenbasis geschätzt werden nur mühsam und wird nur unvollständig gelebt.
Vor allem die Entwickler, die es nicht gewohnt sind große Aufgaben in kleine aufzuteilen haben damit Schwierigkeiten.

Lösungsmöglichkeit:
Wenn die Anforderungen ohnehin schon in idealen Personentagen geschätzt werden, kann SP1 und SP2 zusammengefasst werden.
Dabei werden direkt die (restlichen) Aufgaben je Anforderung ermittelt, in Stunden abgeschätzt und notiert.
Lediglich neue Anforderungen könnnen vorab grob in PT geschätzt werden.
Das Sprint Burndown Chart kann somit ggf. auch ohne Aufteilung der Anforderungen in Aufgaben mit der Summe der Anforderungsaufwände auf der Y-Achse gestartet und bei vollständiger Erledigung abgetragen werden.

Bei jedem, der es gewohnt ist in Manntagen zu schätzen und nun zum ersten mal in Story-Points abschätzen soll, krümmt sich die Hirnmasse zu einem gordischen Knoten zusammen. Hier ein einfacher Weg vom alten ins neue System.

Schritt 1:
Die Abschätzung geschieht wie gehabt in idealen Personentagen (PT). Einzige Neuerung: Es sind nur noch bestimmte Abstufungen erlaubt. Z.B. entsprechend der beliebten Fibonacci Folge: 0 – 0,5 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100, unendlich.

Für den ersten Sprint sollte sich das Team nicht viel mehr als etwa die Hälfte der kompletten Teamkapazität vornehmen.

Schritt 2:
Am Ende eines Sprints wird die Velocity berechnet. Wieviele ideale Tage konnten wir im vergangenen Sprint umsetzen? Wenn da dann z.B. 89 Tage rauskommen, dann für den nächsten Sprint ebenfalls nur 89 PT vornehmen, auch wenn der Kalender 140 anzeigt.

Wer möchte, kann sich den Korrekturfaktor berechnen, als Quotient aus idealen und erreichten Tagen. Zum Beispiel: 126 abgeschätzte PT / 89 erreichte PT = 1,4. Eine mit 10 PT initial geschätze User Story bzw. Use Case dauert also eher 14 MT.

Schritt 3:
Nach einigen Iterationen hat man erlebt, dass die Einheit Personentage tatsächlich relativ ist und man genauso gut Storypoint dazu sagen kann. Vor allem bekommt man in dieser Zeit Referenz-Stories, die als Vergleich mit neuen Stories dienen.

Ergänzung: Auf Taskebene ist die o.g. Folge in Tagen zu grobgeanular. Für Tasks einfach die gleiche Folge mit idealen Stunden als Einheit anwenden.

Gelassenheitsgebet, Quelle: http://de.wikipedia.org/wiki/Gelassenheitsgebet