Prototyping

Kürzlich gab es bei TED Talks einen Vortrag von Tim Brown, CEO, IDEO als Podcast. Es ging um Prototyping.

Think with you hands

Einer der wesentlichen Vorteile von Protoyping ist offensichtlich: das Erlangen von frühem Feedback. Darüber hinaus schafft man auf der Basis der Resultat ein gemeinsames Verständnis über Art, Inhalt und Ausprägung der Sache, die man produzieren möchte. Das Mittel des Prototyping unterstützt dabei die einfache Re-Konstruktion durch Anpassung und Ausbau - man schafft auf inkrementelle Weise eine Näherung zum Endresultat.

Wie macht man das?

Im Kern geht es beim Prototyping darum, ein einfache, schnelle und bedeutsame Lösung mit einem gewissen Abbild des Ziels zu schaffen. Dabei wendet man beispielsweise Scribble oder (gebastelte) Modelle an. Es ist durchaus erwünscht, dabei so viel wie möglich unterschiedliche Ausprägungen zu produzieren - Masse generieren. Man soll mit Ideen "rumspielen", prototypisieren und somit die Sache "anfassbar" machen. Nicht unerheblich ist in diesem Zusammenhang die Atmosphäre - sie sollte möglichst uneingeschränkt und frei sein, eben einen Spielraum für Kreativität schaffen.

Tim Brown beschreibt dies alles im Zusammenhang mit kreativer Arbeit. Warum soll das nicht auf Software zutreffen? Das ist die Frage! Ist Softwareentwicklung nicht auch ein kreativer Prozess? Können wir diese Ansätze adaptieren, um zu einem besseren, zielgenaueren und wertvollerem Ergebnis zu kommen? - Ja, natürlich - unbedingt!

Zusammenfassung

Tim Brown bricht am Ende des Talks das Thema herunter auf folgenden Prinzipien:

• Exploration
  Go for quantity - trust to play
• Building
  Thinkin with your hands - trust to be creative
• Role play
  Act it out

Ich meine, dass diese Prinzipien bedingungslos auf die Entwicklung von Software anwendbar sind. Prototyping ist ein probates Mittel zur inkrementellen Näherung der Lösung. Es schafft Vertrauen, produziert alternative Lösungsansätze und man erhält frühes Feedback, sowohl vom Kunden als auch von potenziellen Nutzern.

Go for prototyping!

Wir sind kreativ und wir sind agil!

Heute und morgen findet das namics.lab von Team Thomas in Diessenhofen statt. In kleinen Teams werden Dinge erarbeitet, die man schon immer mal machen wollte und im Arbeitsalltag nie Zeit gefunden hat. namics räumt den Mitarbeitern einen 2 Tage namics.lab ein, um genau das nachzuholen.

Ich bin ein einem Team von 4 Personen und wir wollen eine Facebook Applikation bauen. Ja, noch eine Facebook App! Facebook hin oder her, wir wollen mal bischen mit dem API, unseren Visionen/Ideen und dem viralen Netz "spielen"....

Zu meiner Verwunderung: man modelliert Personas, entwickelt User Stories und führt einen Business Value ein. Wow, das macht Spass. Das kleine Team ist enorm kreativ, wir werden morgen Abend was cooles haben....

Bilder vom lab.camp: http://flickr.com/photos/29559712@N06/sets/72157607669216309/

Erfolgreich dank Scrum, oder doch nicht?

Man stelle sich vor - man trainiert, arbeitet hart an sich, bereitet sich gut vor und dann kommt endlich der lang ersehnte Tag des Marathons, 42 km - los gehts! Man checkt immer wieder die Zeit, passiert die Zwischenstation, schaut sich um - wer ist vor mir, wer ist neben mir und dann, plötzlich ist der Zieleinlauf in Sichtweite - 5 sec. 4 sec. 3 sec. 2 sec. 1 sec - ZIEL! Der Blick zur Uhr - Enttäuschung und ziemlich genau das emfpand ich nach Abschluss des letzen Scrum Projekts.

Um den getrübten Eindruck mit meinem Team zu teilen haben wir das thematisiert und – ich war völlig überrascht – das Entwicklerteam hatte einen weitaus positiveren Eindruck als ich. Das konnte ich kaum glauben und habe versucht herauszufinden, warum ich das anders sah.

Ich stellte dem Entwicklerteam die Frage, warum das Projekt rückblickend so positiv für Sie war. Die Erkenntnis - durch unserer Vorgehen wurde ein Prozess vorgeben, den man bislang vermisst hatte. Es wurden Code Reviews durchgeführt, Pair Programming, automatisiertes Testen, Don’t-repeat-yourselves und damit verbunden aktives Refactoring, Visualisierung der Arbeit mit deren aktueller Status, Wer macht Was im täglichen Meeting und vieles mehr. All das wurde positiv bewertet. Gut!

Fast schon überwältigt habe von den positiven Schwingungen musste ich mich also Fragen – warum empfandest Du das anders als das Team? Nun, ich musste nicht lange überlegen, fand eine Reihe Argumente Warum aber sah das Team das anders?

Ich realisierte, dass mein Team und ich nicht vom selben sprachen: Scrum und agil!

Was das Team in dem Projekt erstmals angewendet hat, waren verschiedene Praktiken aus eXtreme Programming (XP), und zwar iterativ. Scrum hingegen ist nach meiner Interpretation, eher ein Framework für agile Software Entwicklung, genauer: ein Management Modell für agiles Vorgehen und genau hier haben wir extreme Abstriche gemacht.

Wir hatten keinen richtigen Product Owner, aber einen internen Projektleiter, der den Kunden „gespielt“ hat. (Proxy-Customer) Wir hatten keinen ScrumMaster. Diverse Scrum Rituale wurde, auch aufgrund der fehlenden Rollen und deren Aufgaben, weggelassen. Es gab Arbeiten, die von Personen erledigt wurden, deren Zugehörigkeit zum Team nicht gegeben war.

Subtrahiert man das alles von der Scrum Theorie, was bleibt dann übrig?

• Big Bang Delivery am Projektende, statt regelmässiges Feedback mit kurzen Release Zyklen
  
• Kein Feedback vom Kunden während der Realisierung, nur interner Input
  
• Keine Priorisierung der Arbeit , da keine wirkliche „Business Value“ Beurteilung
• Keine Früherkennung von „Fehlern“, da kein Feedback
  
• Kein ROI Bewertung während der Entwicklung, da kein Feedback
  
• Fragen und Abklärungen nur über Dritte, kein direkter Kundenkontakt
• Sequentielles, phasenorientiertes und teilweise unabgestimmtes Vorgehen

Kurz –das ist nicht agil, das ist kein Scrum!

Was haben wir daraus gelernt?

Bei den Software Entwicklern kommt XP und iteratives Vorgehen gut an, es macht ihnen Spass und Scrum ist kein Scrum, solange:

• kein "richtiger" Product Owner am Tisch sitzt und Scrum aktiv lebt
• nicht alle notwendigen Ressourcen „scrumisiert“ sind und sich zum Team bekennen
• solange man kein fixed time, fixed scope und fixed budget vorfindet
• wenn bereits (zeitlich) früher gelagerte Projektphase durchlaufen wurden, z.B. Analyse, Grobspezifikation, Detailspezifikation, Design, etc

Treffen die genannten Punkt zu,

1. ist das Ökosystem nicht Scrum kompatibel
2. kann man die Realisierung(-sphase) mit XP Praktiken empfehlen

69er - Projektende

Heute, nach nunmehr 4 Sprints à 2 Wochen ist das 69er Projekt zu Ende.

In Ruby gibt ein Prinzip: DRY - Don't repeat yourselves - und gemäss DRY möchte ich die Dokumentation vom 69er Projekt hiermit beenden, ich würde mich nur wiederholen. Trotzdem möchte ich noch ein Resümee ziehen und ein paar Zahlen zeigen, z.B. das Product Burndown Chart:

Im 69er Projekt wurden total 88 Story Points realisiert, im Schnitt 22 Story Points pro Sprint. Geplant war zu Beginn eine Velocity von 20 SP's pro Sprint. Das Team hat geliefert - das Backlog ist leer und wir haben noch ca. 20% Budget.

Heute, am Demo Day von Sprint 4 löst sich das Team auf, die Entwicklungen sind eigentlich abgeschlossen. Der Product Owner war anwesend und letztendlich haben wir heute ein Abnahme gemacht. Es wurden noch ein paar Dinge aufgenommen, die nachgebessert werden sollten ... Klingt nach einem neuen Sprint? Hm.

Bislang habe ich im Projekt ein bischen die Kappe des Scrum Masters aufgehabt und das Team "geführt", sobald man vom agilen Vorgehen abgekommen war. Mühsam, aber unter dem Strich sehr wichtig. Da ich bisher davon überzeugt war, dass neben mir auch andere im Team den agilen Prozess verinnerlicht haben und durchaus gewillt sind, so zu arbeiten, habe ich mich heute in der Retrospective als "Moderator" zurückgehalten und das Team machen lassen.

Kurz gesagt: ich war entäuscht. Niemand hat die Funktionalität gezeigt, die im Sprint 4 entwickelt wurde. Stattdessen war "hm, was haben wir denn alles so gemacht" rum-geklicke angesagt. Viel unötige Diskussionen, Fragen zur Spezifikation und Feedback bzw. Änderungswünsche. Darüber hinaus wurde keine Retrospective gemacht.
Die anstehenden Arbeiten wurden nicht genauer besprochen, in Tasks zerlegt, geschätzt, priorisiert - eben all das, was wir nunmehr 3 Sprints durchgezogen haben. Ich hätte erwartet, dass man eine Sprint 5 Planung macht und dem agilem Vorgehen weiter folgt. Naja.

Da kommt mir die einleitender Aussage von der Projektleitung zu Beginn des Projektes in den Sinn - sie ist zieht sich durch das gesamte Projekt:

"Wie ihr das macht, ist egal. Es muss am Ende nur funktionieren."

69er - Sprint 3 Retrospective

Gestern, 09. September war erneut eine Retrospective im 69er Projekt, nunmehr in der dritten Iteration.

Summary:
Auch in diesem Sprint war das Team schneller, aber leider auch schlechter. Der agile Arbeitsturnus hat sich so langsam eingespielt und das Team lebt Scrum. Trotzdem ist die Stimmung nicht gut. Der fehlende ScrumMaster ist für das Team spürbar. Viele Hindernisse die sich zu Blocking entwickeln, ohne Aussicht auf Behebung!

Das Ergebnis:
Geplant waren 20 Story Points bei einer verfügbaren Zeit von 78h, sportlich! Von den geplanten User Stories konnten 4 nicht fertig gestellt werden! Warum? 

Es gibt bei diesen Stories ein externes Partner-Unternehmen, auf dessen Service die Applikation angewiesen ist. Die Integration des Services ist zunächst trivial, trotzdem klemmt es. Das Partner-Unternehmen lässt uns hängen - das Team kommt nicht voran. Andere User Stories wurden einfach nicht gut genug getestet und vielen schlichtweg durch, als sie dem Product Owner präsentiert wurden. 

Und so sieht es aus:


Retrospective:

Was war nicht gut?

1. Die Rails Entwickler machen viele Tasks, die nicht Rails related sind - das ist langsam und macht kein Spass
2. Design ist noch immer nicht abgeschlossen, muss ständig neu angefasst werden - wird nie fertig
3. "Springende" Ressourcen sind nicht im agilen Prozess, sie leben ihn nicht
4. Viele externe Hindernisse, die das Team nicht lösen kann und sich "niemand" drum kümmert
5. Stimmung schlecht, Ergebnis stimmt nicht - wir erreichen unsere Ziele nicht

Uhhpf! Nicht gut ...

Was können wir besser machen?

1. Niemand arbeitet allein auf dem Projekt (auf täglicher Basis). Wir arbeiten nur, wenn mindestens 2 Teammitglieder arbeiten, bessere Resourcenplanung ausserhalb des Teams.
2. Reviews schneller(früher) machen, Arbeit (früher) abschliessen
   
3. Product Owner ist zwingend anwesend beim Planning und Demo Meeting

Nun steht der letzte Sprint vor der Tür. Das Product Backlog ist noch immer gut gefüllt und das Projektende ist absehbar. Werden wir es schaffen?

Zurück zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 3 Planning & Estimation Meeting

Der 3. Sprint im 69er Projekt steht an und es gilt erneut: Team, let's plan!, ABER bei diesem Planning & Estimation Meeting gibt es eine Besonderheit, die ich in meinem agilen Dasein bisher auch noch nicht erlebt habe - der Product Owner ist nicht anwesend.

Wir haben vom PO mit auf dem Weg bekommen, dass auch im kommenden Sprint der Schwerpunkt auf dem User Interface liegen soll, denn nach nunmehr etlichen Iterationen beim Design haben wir eine finale Version, endlich.

Ok, wie sieht es mit den Ressourcen aus?


Plannning & Estimation

Da wir in diesem Sprint nicht so viel verfügbare Ressourcen haben, geht das Team mit weniger geplanter Arbeit in den Sprint. Nimmt man den Durchschnitt aus Sprint 1 und Sprint 2 beträgt die Velocity bisher 23 Story Points/Sprint. Um den limitierten Ressourcen Rechnung zu tragen, wollen wir 20 Story Points annehmen.

Das Team geht Story für Story aus dem Backlog durch und fragt zunächst, ob alle Fragen benantwortet sind, oder anders gesagt, wissen wir, was hier die Aufgabe ist. Wenn nicht, wird das an der Story vermerkt und diese zurückgelegt. Der interim ScrumMaster geht diesen Stories im Sprint nach und klärt die Fragen.

Gut, nachdem alle Stories im Backlog sortiert wurden nach klar und unklar, beginnt das Team die Arbeit zu schätzen. Dabei werden pro User Story kurz die Task herausgebrochen (nur grob) und überschlagen. Am Ende kommt man auf die Story Points pro User Story.

Und so sieht Sprint 3 aus:

Das Team hat 20 Story Points angenommen. Diese 20 SP's entsprechen ca. 81h Arbeitsaufwand. Verfügbare Arbeit ist 78h, d.h. wir haben ein kleines over commitment.

[Update]

Weiter zur Sprint 3 Retrospective

Zurück zur Sprint 2 Retrospective

69er - Wir brauchen einen ScrumMaster

Im der letzten Retrospective von Sprint 2 hat das Team bemängelt, dass es viele Hindernisse gibt, die offensichtlich viel Engagement benötigen und im Team keine Zeit dafür besteht. Jedes Teammitglied steht unter Druck, denn man hat sich auf eine Ziel committed und man möchte das Spiel gewinnen. Treten Hindernisse auf, geht man diesen nach, soweit es möglich ist. Werden die Hindernissse zu gross, geht dem Team die Luft aus.

Bei einem der Posts zum 69er Projekt habe ich einen Kommentar bekommen, der auf die Pitfalls von Scrum eingeht. Es geht im wesentlichen um die Frage, ob man ohne ScrumMaster ein Scrum Projekt führen kann und was unsere Erfahrungen sind.

"In addition to the disengaged ScrumMaster, there is the team where a worker bee also tries to be ScrumMaster. This works fine as long as the team does not encounter too many impediments. If the team does encounter impediments, however, either the impediments will not be resolved (because the worker bee role is consuming too much time) or the work will not be completed (because the worker bee is now running around trying to eliminate impediments). For this reason, I no longer have team members perform the ScrumMaster role while actually doing work on a sprint (unless it is a very small amount of work)." Boris Gloger, Pitfalls in Scrum

Nun ja, genau diese Erfahrungen kann ich bestätigen. Kleine Hindernisse kann das Team selbst lösen. Werden diese zu Blocking oder mengenmässig grösseren Hindernissen, leidet das Team und damit das Ergebnis.

Beim 69er Projekt wurde das offen in der Retrospective Sprint 2 diskutiert. Das Team bat um einen ScrumMaster. Da man sich allerdings bereits im 3. von 4. Sprints befindet und eine Einarbeitung Zeit und Aufwand bedeutet, hat das Team davon abgesehen.


Die Erkenntis:
Im nächsten Scrum Projekt nur noch mit ScrumMaster.

69er - Sprint 2 Retrospective

Am Dienstag vergangene Woche war erneut ein Sprint im 69er Projekt vorüber und es wurde präsentiert, was wir hatten.

Summary:
Das Team war erneut schnell, schneller als geplant und schneller als selbst eingeschätzt, aber es häuften sich auch die Probleme ...

Das Ergebnis:
Geplant waren für Sprint 2 total 25 Story Points (SP's), bei einer verfügbaren Zeit von 144h Stunden. Von den geplanten User Stories wurden nur 18 SP's umgesetzt, 7 SP's waren Not Done. Trotzdem hat das Team während des Sprints zusätzliche User Stories angenommen und somit insgesamt 28 Story Points verdient.

Interpretation, Sprint Burndown:
Das Team hat in der Retrospective das Burndown Chart analysiert und kam zu folgenden Erkenntnissen:

• Wir sind schnell, aber ...
• Viele offene Pendenzen, Hindernisse - daher kein Progress bei 4 Stories (Blocking)
  
• Aufgrund der Blockaden musste das Team andere User Stories vorziehen, da sonst keine Arbeit
  
• Vorgezogene User Stories waren oft nicht abgeklärt- viele offene Fragen, Unklarheiten
  

Retrospective:

Was war gut?

• User Story of Taskboard, quasi manuell, nach wie vor gut
  
• Resourcen konnten arbeiten, wie geplant

Was können wir besser machen?

• Vorgezogenen User Stories oft unklar, Plannig Phase fehlte, viel Input vom PO während des Sprints notwendig
• Es gab eine Demo vom System mitten im Sprint, nicht zum Demo Day wie geplant
• Administrative Arbeiten inkl. Aufwände fallen an, gehören aber nicht zu einer Story und tauchen nicht in der Sprint-Planung auf, was machen wir damit?
• Code Freeze vor dem Deployment wurde nicht für alle Teammitglieder kommuniziert, daher gab es anschliessend viele Merge-Konflikte im Subversion
• Release-Umgebung zur Demo nicht up-and-running, ungeplanter Aufwand im Sprint
• Es gibt keine Release Notes, was haben wir bisher gemacht?
• kein ScrumMaster zum Hindernisse lösen
• Sprint Übersicht ist gut, aber Gesamtperspektive fehlt - wo stehen wir? Werden wir das schaffen?
• Anwesenheit beim Daily Scrum nur sporadisch

Nun, wenn wir die Stimmungbaromether ablesen sieht es nicht mehr so gut aus - wir müssen handeln!

Zurück zum 69er - Sprint 2 Planning & Estimation Meeting
[Update]
Weiter zum Sprint 3 Planning & Estimation Meeting

69er - Sprint 2 Planning & Estimation Meeting

Nach erfolgreichem Sprint 1 im 69er Projekt hat das Team nun ein Sprint 2 Planning Meeting durchgeführt.

Aufgrund der Erkenntnisse aus der Sprint 1 Retrospective soll der Fokus im kommenden Sprint auf dem User Interface liegen. Daher wurden solche User Stories vom Product Owner hoch gewichtet, die darauf einen Einfluss haben. Wichtig ist, dass am Ende des Sprints die bisherige Arbeit über den Product Owner hinaus noch anderen Stakeholders des Auftraggebers präsentiert werden soll.

Ok, was werden wir machen?

Wir haben eine andere Verteilung bei den Kompetenzen in diesem Sprint, eher User Interface lastig, und kommen daher insgesamt auf 144h verfügbare Zeit.

Vom Team angenommen wurden 25 Story Points.

Weiter zur Sprint 2 Retrospective

Zurück zur Sprint 1 Retrospective

69er - Sprint 1 Retrospective

Am Dienstag war beim 69er Projekt Sprint 1 Demo Day und Retrospective. Team: Safe!

Dashboard?
Originally uploaded by Jürg

Summary:
Alles in allem kann man sagen, dass das Team unglaublich viele Arbeitspakete bewältigen konnte, mehr als erwartet.

Das Ergebnis:
Geplant waren 12 Story Points, 132h verfügbare Zeit
Realisiert wurden 19 Story Points in 143h. 31 geplante Stunden konnten nicht bezogen werden. Eine User Story wurde vom Product Owner nicht abgenommen, also 18 Story Points insgesamt.

Interpretation, Sprint Burndown:
In der Retrospective hat das Team das Burndown Chart und die Zahlen interpretiert und ein Fazit gezogen. Dabei kam heraus, dass man

• zu pessimistisch geschätzt hat
• Arbeit geplant hatte, die man (noch) nicht machen konnte, daher zu "schnell" war

Hintergrund: Look&Feel der Anwendung sind noch nicht final definiert. Interaction-Designer und Usability Experten arbeiten noch daran, trotzdem hat das Team im Sprint 1 bereits Funktionalitäten entwickeln könnnen, allerdings ohne visuellen Aspekt. Strenggenommen sind diese User Stories nicht DONE. Daher hat das Team eine virtuelle Persona konzipiert (Design-Checker) und eine User Story angehängt, die zur GUI Implementierung in einem späteren Sprint genutzt werden soll. Geplante und verschobene Aufwände/Tasks aus Sprint 1 wurden dort angehängt. Dieser Umstand erklärt den schnell Fortschritt.

Desweitern wurde durchleuchtet, warum das Team mit 31h Restguthaben in der verfügbaren Zeit mit 142h abrechnen konnte, obwohl nur 132h geplant waren. Ein Grund liegt auf der Hand: wir haben mit einem 6h-Tag geplant und kommen daher bei den verfügbaren Ressourcen auf 132h, worst case Szenario quasi. Ein anderer Grund war, dass die geplanten Ressourcen im Verlauf des Sprints nicht eingesetzt werden konnten. Eine Rahmenbedingung, deren man sich bewusst war, daher die 6h-Tag Planung.

Retrospective:

Was war gut?

• Vorbereitende Arbeiten waren sehr gut , z.B. Infrastrukur war bereits da, als das Projekt im Sprint 1 begonnen hat
• Dokumentation im Wiki ist sehr gut, so findet man das verteilte Projekt Know-How
• ein Biergarten Besuch ;-)
  
• sehr guter Austausch im Team- man weiss praktisch immer, woran alle arbeiten
• Review ist sehr gut, verteilt das Wissen im Team, man lernt viel
• Daily Scrum wird als nüztlich empfunden, er ist kurz gehalten, fokussiert
• Product Owner ist zufrieden mit der Arbeit

Was können wir besser machen?

• Stunden aufschreiben! Am Sprint Ende war nicht ganz klar, wieviel Stunden wir aufgewendet haben
• Einschränkungen, Editierbarkeit im GUI bitte disuktieren, nicht einfach machen - z.b. nach Daily Scrum
• Was haben viele Tasks, die keine Story haben z.B. Testumgebung aufsetzten. Was machen wir damit?

Die Stimmungsbarometer untermauern den aktuellen Befund - alles im grünen Bereich!

Zurück zum Sprint Burndown Chart und Taskboard
Demnächst: Sprint 2 Planning Meeting

69er - Sprint Burndown Chart

Ok, Sprint Burndown Chart! Das Team trifft sich jeden Tag zu einem Daily Scrum, max. 15min. Das gesamte Team ist anwesend, teilweise auch der Product Owner.

Nachdem jedes Teammitglied seinen heutigen Tag am Taskboard geplant hat, nimmt der Scrum Master die Zahlen in das Sprint Burndown Chart auf. Es wird während des Daily Scrum ausgedruckt und an das Taskboard geheftet - und natürlich beurteilt, jeden Tag!


Das Burndown Chart hier zeigt den 4. Tag im Sprint. In der oberen Tabelle werden die heutigen Ressourcen eingetragen, in der unteren die Restzeit.

Man kann erkennen, dass zwar 3 User Stories bereits auf Done sind, aber die verbleibende Zeit per heute knapp wird. Man sieht auch, dass eine Entwickler Ressource am 4. und 5. Tag mit 0 Stunden verfügbar ist, obwohl mit 6h geplant wurde. Ausserdem kann man sehen, dass bei diesem Tempo bald keine Arbeit mehr da ist, trotz Verknappung der Ressourcen. Der Product Owner wurde bereits am 3. Sprint-Tag informiert, ist nun anwesend und kann vorschlagen, was man als nächstes in den Sprint aufnehmen kann.

Zurück zum Taskboard
Demnächst:
Weiter zur Sprint 1 Retrospective

69er - Taskboard

Es sind bereits drei Tage im Sprint 1 des 69er Projekts vergangen. Wo stehen wir?

Im vergangenen Beitrag 'Sprint 1 Planning & Estimation Meeting' habe ich angekündigt, einen Einblick in unseren Daily Scrum zu geben und hier sind wir - unser Task Board:



(Wir wollten das Rad nicht nochmals erfinden, daher haben wir uns beim Taskboad von Mountain Goat Software orientiert.)

Wie läuft der Daily Scrum ab?

Das gesamte Team ist anwesend, inkl. Product Owner. Der Daily Scrum geht maximal 15 Minuten. Jedes Teammitglied geht gedanklich die Tasks durch. Dabei werden:

• überfüssige Task entfernt
• fehlende Tasks hinzugefügt
  
• verbleibende Aufwände pro Task überprüft und gegebenenfalls korrgiert (nach oben oder unten)
  
• Zustand der Tasks überlegt
  

Anschliessend gehen wir User Story für User Story durch jedes Teammitglied beantwortet folgende Fragen:

• Was hab ich gestern gemacht?
• Was mache ich heute?
• Was sind meine Hindernisse?

Untermauert wird die Fragerunde mit dem Verschieben von Tasks oder Korrektur des Aufwands. Hindernisse markiert das Team mit brüllenden Fussballstars! Peter Cech steht für fehlende Informationen, Oliver Kahn für blockierendes Hinderniss. (siehe Taskboard, rot eingerahmt)

Jeder bekommt die Chance, mitzuteilen wo er steht, wie er vorankommt und ob er Hilfe braucht.

Der Daily Scrum wird abgeschlossen mit der Frage, wie der heutige Einsatz am Projekt sein wird. Scrum geht davon aus, dass ein Team fix an einem Projekt arbeitet, quasi den gesamten Tag, die gesamte Sprintdauer und letztendlich das gesamte Projekt. Sehr ideal, aber leider nicht realistisch, denn wir Arbeiten auch noch für andere Projekte. Wir haben Scrum hier adaptiert und eingeführt, dass wir die verbleibende Restzeit im Sprint davon abhänig machen, wieviel jeder am Sprint arbeitet, auf täglicher Basis.

Nach dem Daily Scrum wird das Sprint Burndown Chart generiert und and das Taskboard (rechts oben) gepinnt. Es ist Gegenstand für den kommenden Daily Scrum, am nächsten Morgen - und alle freuen sich auf den kommenden Morgen, wenn es endlich wieder heisst - Gentlemen, Daily Scrum!

[Update]
Weiter zum Sprint Burndown Chart
Zurück zum Sprint 1 Planning & Estimation

69er - Sprint 1 Planning & Estimation Meeting

Heute hat das Team gemeinsam die Aufwandschätzung und Planung vom Sprint 1 für das 69er Projekt absolviert. Für alle ein ganz neue Aufgabe, die mit dem agilen Vorgehen nach Scrum eingeführt wurde. Trotz 4 arbeitsintensiven Stunden kann sich das Ergebnis sehen lassen:

Wie gehen mit vier User Stories und 12 Story Points in den ersten Sprint. Basierend auf dem aktuellen Wissenstand haben wir im schlechtesten Fall 98h Aufwand, den wir 132h unterbringen müssen.

Zurück zu Sprint Zero
[UPDATE]
Weiter zum Taskboard

69er - die Persona bitte

Für das 69er Projekt haben wir in der frühen Konzeptionsphase mit Benutzergruppen die Bedürfnisse der potenziellen Nutzer erarbeitet. Als Ergebnis haben wir viel Anwendungszenarien erhalten. Wir haben das Use Cases genannt - ganz klassisch mit UML dokumentiert.

Schnell wurde klar, dass sich Benutzer der gleichen Benutzergruppe unterscheiden würden, ganz einfach aufgrund ihrer unterschiedlichen Interessen und Bedürfnissen.

Ein Use Case Beispiel (nicht im 69er Kontext):

• Akteur: User
• Aktion: kann Abstimmen

Wenn man diesen Use Case bespielsweise in den Kontext einer Wahl des nächsten Präsidenten betrachtet, könnte man folgendes festellen: User ist nicht gleich User!

Je nach politischer Gesinnung, finanziellem Hintergrund, persöhnlichen Präferenzen, äusserlichen Einflüssen, Anonymität der Mitteilung, etc. kann es User geben, die eben NICHT dafür, sondern dagegen stimmen würden.

Also haben wir die User unterschieden und pro Charakter eine Persona konzipiert.

Mike, 52, Prof. für Physik
Mike lebt allein, er hat keine Kinder. Mike betreibt gern Outdoor Sport und nutzt dafür jede freie Minute. Es ist ein naturverbundener Mensch, verabscheut Hass und Gewalt.

Dank Mike haben wir eine ganz neue Sicht auf den Anwendungsfall:

• Akteur: User
• Aktion: kann dagegen stimmen

Persona sind also ein wichtiges Mittel, um unterschiedliche Bedürfnisse gleicher Benutzergruppen zu modellieren. In unserem 69er Projekt werden der Persona User Stories zugeordnet. Jede Persona hängt am Task Board, so dass man sich immer das Benutzerverhalten in den Erinnerung bringen kann.

69er - mein neues Scrum Projekt

Ab Montag, den 28. Juli 08, beginnt für mich (endlich) wieder einmal ein Scrum Projekt, das Vierte nunmehr.

Ich möchte meine Erfahrungen und Erkenntnisse auch hier erneut auf meinem Blog dokumentieren. Da es sich um ein Kundenprojekt handelt und keine projektspezifischen Details beschrieben werden können, gebe ich dem Projekt einen fiktiven Namen: 69er

Das 69er Setup sieht momentan so aus:

Team

• 2-3 Entwickler
• 1 Publisher/Flasher
• 1 Designer
• 1 Product Owner
• 1 Scrum Master (wird von einem Team-Mitglied übernommen, abwechselnd)

Technology

• Ruby on Rails
• Flash
  

Zeit

• 9 Wochen à 5 Arbeitstage, d.h. 4 Sprints à 2 Wochen plus 7 Tag

Das Product Backlog

Das Backlog ist gut gefüllt, wir haben an der Zahl 23 User Stories, deren Aufwand und Komplexität bislang noch nicht klar ist. Womöglich werden die User Stories noch zerlegt und somit in der Anzahl vermehrt.

Was ist bisher geschehen?

Der Auftraggeber hat das Team angefragt, seine Vision von einem Kundenportal in einem recht sportlichen Zeitfenster zu realisieren. Nach einer sehr kreativen Konzeptionsphase wurde die Vision zunächst in verdauliche Einheiten heruntergerebrochen und die high-level Rahmenbedinungen festgelegt, z.B. soll es einen Web Applikation entwickelt werden.

Das Team hat, basierend auf der Vision, mögliche Benutzergruppen und deren Nutzungsbedürfnisse erarbeitet mit dem Auftraggeber abgestimmt. Letztendlich wurden einige Persona und deren User Stories in ein Product Backlog aufgenommen und eine grobe Sprintplanung gemacht. Dies, zusammen mit einer groben Aufwandschätzung, Wireframes und der Beschreibung der Vorgehensmethode, wurden dem Auftraggeber als Offerte zugestellt. Nach formalen Anpassungen kam es zur Beauftragung. Was wir haben:

• provisorisches Product Backlog
  
• provisorische Sprint Planung
• provisorische Resourcenplanung

Scrum Adaption

Der Auftraggeber anerkennt unser Vorgehensvorschlag nach Scrum, wird allerdings nicht in seiner Funktion als Product Owner teilnehmen. Daher hat das Team beschlossen, einen Product Owner Proxy einzusetzen - der Key Account Manager auf Unternehmensseite. Er kennt den Auftraggeber, dessen Vorstellungen und Wünsche. Er ist in der Lage, das Projekt erfolgreich abzuwickeln und kann die Aufgaben eines Product Owners nachkommen. Der Scrum Master wird vom Team gestellt. Diese Rolle soll abwechselnd pro Sprint neu vergeben werden.

Wie gehts weiter?

Für das Scrum Team ist dieses Vorgehen bislang unbekannt, zumindest praktisch. Daher ist es jetzt wichtig, alle ins Boot zu holen, um gemeinsam ein akzeptables Vorgehen zu erarbeiten. Zu Begin der nächsten Woche wird es für das Team eine kurze Einführung in Scrum geben. Anschliessend werden wir gemeinsam folgende Punkte angehen:

• DONE Definition erarbeiten
• Setup der Tools und Entwicklungsumgebung
• Offene Punkte und indentifizierte Hindernisse
  

Los gehts mit dem Sprint 1 Planning & Estimation Meeting

Demnächst, hier auf dem Blog!

Ham and Eggs - Und Scrum?

Was haben Hühner und Schweine mit Scrum zu tun? Ein Video der Rails Conference 2008 verschafft einen Überblick.

ArmerKater.de

Ich lese den Blog armerKater.de, un neulich hab ich die Slides dort gefunden, urspünglich vom PM-Blog. Sehr gut.

| View | Upload your own

Der agile Mentor - Planning Meeting Sprint 1

Im Anschluss an die Retrospective von Sprint Zero kam der eigentlich wichtige Teil, zumindest für mich. Mein nächstes Ziel war es, eine Aufwandschätzung vom Team zu bekommen, um einen Sprint planen zu können. Damit das gesamte Team hinter diesem Ziel steht, habe ich eine List angewandt: Wir haben geschaut, was im Sprint Zero realisiert werden konnte. Bis zu diesem Zeitpunkt wurden keine User Stories verwendet, also haben wir die abgeschlossenen Arbeitspakete im Plannungstool einfach mal zusammengezählt: 21 von 26, nicht schlecht! Oder doch?

Also fragte ich,

• ob dass ein gutes Ergebnis sei? - konnte man nicht richtig beanworten, wahrscheinlich schon
• hatte man sich über-committed? - konnte man nicht richtig beantworten, eher nicht - es sind ja ständig neue Dinge dazu gekommen
• wieviel Aufwand steht hinter 21? - konnte man nicht beantworten
• warum wurde 26 nicht erreicht? - ja, man hätte noch viele Dinge gemacht, die man da nicht sehen könne
• wo stehe man denn im Hinblick auf den Endtermin - konnte man nicht beantworten, eher so ein Bauchgefühl

Viel Verwirrung - und ich kam mir vor wie ein Lehrer vor seiner 8.Schulklasse, der eben verkündet hat, dass man auf der Klassenfahrt kein Alkohol trinken darf, toll!
Was soll denn das? Wo führt das hin? Warum müssen wir das tun?

Ratlosigkeit! Nach ein paar Sekunden Schweigen habe ich vorgeschlagen, dass wir die kommenden zwei Wochen planen (hatten wir bei Sprint Zero nicht gemacht). Wir wollen uns gemeinsam ein Ziel setzten und dieses erreichen und - viel wichtiger - wir wollen wissen, was wir in zwei Wochen erreichen KÖNNEN

Wir befragten das Plannungstool - was gibts überhaupt noch zu tun?

Schnell wurde festgestellt, dass man im Planungstool Tasks, Issues, Bugs, Packages, Components, SubTask u.v.m. auf gleicher Ebenen behandelt und viele Zusammenhänge, z.B SubTask --> Tasks --> Components bestehen. Ausserdem fehlte die Aufwandschätzung pro Arbeitspaket, unabhängig von der Granularität. Von meinem Standpunkt aus sah das alles unübersichtlich aus. Ich konnte mir absolut kein Bild darüber machen, was noch getan werden musste und wie Arbeitspakete zusammen hingen- keine Ahnung, und ich war nicht allein! Also beschloss man, schnell ein paar Arbeitspakete zu eleminieren und zusammenzufassen - eben aufräumen.

Ich beobachtet das Geschehen und so langsam wurde mir klar, dass das Plannungstool eher ein Gedächtnisstütze jedes Einzelnen war. Alles, was einem so eingefallen ist bei er Bearbeitung von Issues, wurde als Task, SubTask, Component, Issue oder was auch immer hinuzugefügt. Damit änderte sich die Menge und Inhalt der Informationen im Tool quasi stündlich. Das Plannungstool diente der Dokumentation.

Planung? Auf dieser Basis unmöglich!

Nach der Bereinigung verständigte man sich auf eine Entität für planbare Arbeitspakete im Plannungstool - Task. Components, SubTasks, Issues und alles andere sind Dokumentation, Tasks sind Arbeitspakete, planbare Arbeitspakete.

Ok, ich gab dem Team die Aufgabe, für die nächsten Tasks die Aufwände zu schätzen. Was die nächsten Tasks sind, sollte das Team selbst entscheiden. Ich beschäftigte mich damit, die verfügbaren Ressoucen abzuklären.

Am Ende beschloss das Team Arbeit für 184h anzunehmen.

Zürück zur: Retrospective Sprint Zero
Weiter zur: Retrospective Sprint 1

Der agile Mentor - Retrospective Sprint Zero

Nachdem im Sprint Zero der Daily Scrum von Team eingeführt wurde, lebte die Kommunikation auf - in manchen Punkten mussten Teammitglider sogar gebremst werden. Im Grossen und Ganzen haben wir es erreicht nicht mehr als 15 min pro Daily Scrum zu nutzen.

Vierzehn Tage später, am Ende von Sprint Zero plante ich eine Retrospektive, um den Puls des Teams zu fühlen. Dabei wurden folgende Punkte mit Verbesserungspotenzial festgehalten:

• Daily Scrum schweift teilweise ab
  
• AJAX Exception Handling fehlerhaft
• Close Event bei Lightboxe löst einen Reload aus - Usability!
• viel unused Code, viel FIXME und TODO
• Testabdeckung mangelhaft
• Exception bei Suche
• Wireframe zum Task - Wo liegt der? Bessere Vorbereitung!
• Tooling und Infrastruktur Handling kompliziert

Ok, gut!

Wir haben die Punkte angesehen und ein paar herausgenommen, die im kommenden Sprint 1 verbessert werden können.

Zurück zu: Sprint Zero
Weiter zum: Planning Meeting Sprint Zero

Der agile Mentor - Sprint 0

Nachdem ich mich mit der Projektsituation und der Arbeitsweise des Team vertraut gemacht hatte, brauchte ich einen Plan - ganz entgegen den Scrum Prinzipien.

Zunächst gab es vier Punkte, die ich dem Team nahebringen wollte:

1. tägliche Status-Meetings (max. 15 min)
2. fokussiertes Arbeiten im 2 Wochentakt - wir wollen alle 2 Wochen etwas produzieren
3. Aufwandschätzungen zu den Arbeitspakten vom Team
4. Planung der kommenden 2 Wochen

Um diesen Plan umzusetzen und das Commitment vom Team zu bekommen habe ich ein Meeting zu einem Kaffee einberufen. Bereits nach wenigen Argumenten waren das Team dafür, dass man tägliche Statusmeetings einführen sollte, denn oft gingen wichtige Informationen unter oder waren nicht für jeden im Team verfügbar. Da das Team räumlich eng beieinander sass, machten wir die die Stand-up's an einem Arbeitsplatz, wer nicht da war nahm per Skype teil.

Mehr nicht! Das war die erste und einzige Neuerung. Als nächstes wollte ich den 2 Wochen Takt inklusive Planung einführen. Ich hatte etwas Zeit gewonnen, die nächsten Punkte vorzubereiten.

Was daraus wurde und was das Team von den Stand-up's hielt, sollte ich in der ersten Retrospective erfahren.

Dranbleiben!

Zurück zur: Scrum Einführung
[Update]
Weiter zur: Retrospective Sprint Zero

Get Started: Workreportr

Vor etwas mehr als einem Monat habe das Ruby on Rails Buch endlich mal aufgeschlagen und war sofort begeistert. Schnell war mir klar - das musst du mal machen! Ok, ich brauchte ein Übungsprojekt und hier sind wir nun ...


Get Started:

Das Projekt heisst Workreportr und es lebt bei amazee.com.

Da amazee eine social collaboration Plattform ist, kann jeder mitmachen. Also bitte, einfach beitreten und mitwirken.

Danke, jp

Der agile Mentor - Scrum Einführung

Vor kurzem wurde ich bei einem externen Projekt als agiler Coach hinzugezogen. Bei diesem Team hatte ein Entwickler bereits Erfahrungen mit Scrum. Es wurde der Wunsch geäussert, nach Scrum vorzugehen. Der zuständige Projekt Manager überliess diese Entscheidung dem Team und so arbeitete man nach Scrum. Kurz vor dem ersten Release wurde ich als Entwickler und agiler Mentor hinzugezogen.

Nach wenigen Tagen ergab sich folgende Bild:

Vor dem Projekt wurde ein detaillierte Spezifikation geschrieben, die zum Projektbeginn von einem Entwickler in Arbeitstasks runtergebrochen wurde, ohne Aufwandschätzung. Der Endtermin war fix. Man zerlegte die Realisierungzeit in kleine Teil-Releases und verteilt die Arbeitspakete (gleichverteilt, x Tasks pro Release). Daraus abgeleitet ergab sich eine grobe Releaseplanung bis zum Projektende. Verschiedene Elemente von Continous Integration wurde installiert: Version Control, Build Server, Unit Testing. Rollen, Regel und die Scrum Rituale, Planning & Estimation Meeting, Sprints, Demo, Retrospective und Daily Scrum wurden nicht angewendet. Der Kunde, in seiner Funktion als Product Owners oder im allgemeinen, war im Verlauf der Realisierung nicht involviert. Es gab eine ausführliche Definition von DONE, kaum jemand hielt sich dran. Wöchentlich wurden Status Meetings abgehalten. Als Projektmanagement und Entwicklertool wurde Jira eingesetzt. Wenige Wochen vor dem ersten Release wusste man nicht, ob man fertig würde. Zusammenfassend kann man sagen: kein agil, kein Scrum!

Ok, ich habe mir also eine Strategie zurechtgelegt, wie Scrum vom Team angenommen und vollumfänglich implementiert werden könnte. Grundsätzlich gab es zwei Optionen:

• Sofortige Scrum Einführung mit allen Ritualen, Rollen und Regeln, quasi "von jetzt auf gleich", oder
• Sequentielle Implementierung, nach und nach ein weiteres Element aufnehmen.

Aus der Erfahrung heraus schien mir die erste Option zu unrealistisch. Ein etabliertes, produktives Team ist alles andere als glücklich, wenn ein Aussenstehender ein neues Vorgehen einführt, dazu noch eines, was so radikale Veränderung mit sich bringt und kaum Akzeptanz findet. Ich entschied mich also für die zweite Option.

Als ich zum ersten Mal mit Scrum in Berührung kam, war ich in einem Projekt als Software Engineer tätig, was mässig erforgreich war. Der Kunde wurde mehrfach hingehalten, die Reaktionszeit war schlecht und die Bug Rate war sehr hoch. Die Projektleitung wurde ausgetauscht und mit der neuen Person kam ein neues Vorgehen - agil nach Scrum! Der ScrumMaster hat zu Beginn nur eine Regel eingeführt - wir wollen fokussierter arbeiten und alle 3 Wochen etwas nützliches produzieren.

Ich legte mir einen Plan zurecht - was daraus geworden ist und welche Erfahrungen ich gemacht habe?

Dranbleiben.

Warum machst DU Scrum?

Neulich wurde ich mit dem Vorwurf konfrontiert, Scrum der Karriere wegen zu verfolgen. Hm, nun ja - man kann zweifellos zugeben, dass man zu einen kleinen Personenkreis zählt, denn bislang ist die Scrum Gemeinde in Europa recht klein, und dass, obwohl Scrum keineswegs etwas Neues ist.

Aus meiner Sicht gibt es nur ein Alleinstellungsmerkmal bezüglich der Karriere - man arbeitet anders.

In einem Beitrag Erfolg! habe ich drei Sichten beschreiben, die Erfolg definieren:

• Stufe 1: persönlicher Erfolg
• Stufe 2: technischer Erfolg
• Stufe 3: unternehmerischer Erfolg

Aus Entwicklersicht behaupte ich, dass man mit Scrum zwangsläufig mit Stufe 3 auseinander setzen muss - quasi der Entwickler der dritten Generation.

Ich sehe das als absolutes Job-Enrichment! Mit Scrum kann ich meine Arbeit so erledigen, dass ich alle Stufen erreiche. Aber Moment mal, kann man das mit klassischem Projektvorgehen, z.B. nach Wasserfall nicht ereichen?

Nun, die Antwort muss jeder selbst finden. Ich allerdings fand mich bei diesem Vorgehen immer wieder mit der Tatsache konfrontiert, dass ich Dinge machen musste, bei denen ich bereits zu Beginn wusste, dass sie wenig Erfolg bringen werden, weder persönlich, noch technisch, noch unternehmerisch.

Man hat eine detaillierte Spezfikation vorliegen und die arbeitet man ab. Nicht selten stellt man während dessen fest, dass die Spezifikation nicht alle Fragen beantwortet oder sich sogar in wichtigen Punkten wiederspricht. Dazu kommt, dass man in früheren Phasen der Analyse oder Konzeption als Entwickler garnicht involviert ist - Argumente und Hintergründe, warum z.B. genau DIE Architektur gewählte wurde, ist oft nicht transparent. Architekten, Business Analysten, GUI Experten und Designer gehen in zu Beginn oft parallel vor, sodass die Spezifikation nicht aus einem Guss ist und teilweise nicht aufeinander abgestimmt wird. Und zu guter letzt ist meistens mehr als die Hälfte der Zeit bzw. Budget bereits aufgebraucht, bis man mit der Realisierung beginnen kann ...

Ich habe Scrum eher auf die harte Tour kennengelernt und habe mich anfänglich nicht damit identifizieren können. Heute, nach diversen Erfahrungen mit agilen Projekten nach Scrum würde ich das Thema agil als Evolutionsstufe bezeichnen. Zurück führt kein Weg mehr!

tinyPM 1.1 Agile Project Management Tool Released

tinyPM, wie der Name bereits verrät, ein schlankes Tool zum Managen von agilen Projekten.

Ich habe mir kurz die Zeit genommen und die Software ausprobiert. Wirklich gut, hat mich überzeugt. Einfach, schlank, auf das wesentliche reduziert, sehr usable und leicht zu bedienen. Kaum Schnick-Schnank und bis zu 5 Usern auch noch Freeware (Communitiy-Edtion).

Features:

• Backlog
• User Stories
• Iteration Planung
  
• Taskboard
• und vieles mehr ...

Goodies:
Ich find, dass einige Dinge sehr schön gelöst sind:

• Automatische Taskgenerierung (Dinge, die man bei jeder User Story braucht)
• Verschlagwortung von User Stories und Tag Cloud
• Sehr übersichtliches Dashboard
• History, woran habe ich gearbeitet (filterbar)
• Wiki, einfaches und gutes Wiki im Tool - für die Brainstorming's

Summary:

Ich bin ja ein Fan von Flip-Chart und White Boards, aber das Tool hier ist echt mal nicht schlecht. Einfach mal ausprobieren, lohnt sich.

Ergebnisse: Blitzumfrage/Training

Die Umfrage zu Scrum-Trainingsbedarf war eine Woche aktiv und leider sind nur 7 Antworten gekommen. Die grosse Frage ist, können wir diese Ergebnisse überhaupt brauchen?

Tun wir ein Moment so, als ob die Ergebnisse relevant sind, und schauen wir, was sie bedeuten würden. Wie ist der deutschsprachige Scrum-Markt anders als die globale Scrum-Markt?

Akzeptanz der CSM

Das erste was auffällt ist die hohe Akzeptanz der CSM. Bei der internationale Umfrage hat man etwa gleich viel Interesse für zertifizierte und nicht zertifizierte Ausbildung. Hingegen bei den deutschsprachigen spricht eine klare Mehrheit für den CSM.

Woran liegt das? Ich kann mir vorstellen, das Scrum eher in den Startlöchern hierzulande steht. Das heisst, es sind die 'early adopters', die auszubilden sind. Also die, die für Scrum werben und für sich einen Zukunft mit Scrum sehen. Für sie ist die Zertifizierung wichtig.

Hingegen im englisch sprachigen Ausland, die uns ein bischen im voraus ist, ist man womöglich eher mit Ramp-Up und Roll-Out beschäftigt: grössere Zahlen von Entwicklern und Projektleitern, die ausgebildet werden müssen, wo die Kosten eine grössere Rolle spielen.

Bei beiden Sprachgruppen stellt man fest, das agile Planung und Schätzung ein wichtiges Thema ist. Wie kann man ein agiles Projekt aufgleisen...

Und die Sprachfrage

Nicht überraschend, man hat eine starke Vorliebe für Kurse auf Deutsch und man ist nur mittelmässig von Kursen auf Englisch begeistert -- aber auch nicht total abgeneigt, was meine persönliche Erfahrung eher nicht entspricht. Diese Erfahrung bezieht sich auf Firmen, die die Ausbreitung überlegen. Hier ist Englisch weniger akzeptabel, da die Kenntnisse sehr unterschiedlich sind. Die early Adopters haben wohl ihre erster Kontakt über den Englisch sprachigen Schriftweg gemacht und haben dabei weniger Berührungsängste.

Sind die Ergebnisse brauchbar?

Rein statistisch gesehen, sicher nicht. Die Umfrage ist weder wirklich representativ, noch sehr breit verbreitet. Und dennoch, in manchen Bereichen, v.a. die Akzeptanz der CSM-Ausbildung wie auch die Sprach-Frage, entspricht die Umfrage meine Erfahrungen. Ferner habe ich bei diversen Umfragen beobachtet, die Verhältnisse zwischen den Stimmen werden sehr früh ersichtlich. Also meiner Meinung nach: sicher nicht perfekt, aber auch nicht wertlos.

Ich für mich habe vor, so zu tun, als ob die stimmen würden. Ich habe mir den Ziel gesezt, die CST-Stufe zu erreichen (na gut, die englische Version dieser Umfrage und die vereinfachte Bedingungen haben dazu beigetragen). Ich weiss, was mein nächster Kurs sein wird. Schauen wir mal! So ist das Leben, man entscheidet auf Grund von unvollständigen und womöglich unrichtigen Daten...

Blitzumfrage: Scrum-Trainingsbedarf

Vor ein paar Wochen habe ich auf meinem Blog eine Umfrage zum Thema Scrum Ausbildung gestartet. Da ich in der Schweiz wohne, trotzdem aber lieber auf English schreibe, ist die Thema Sprache interessant. Konkret: wie wichtig ist es, dass Scrum-Ausbildung auf Deutsch angeboten wird? Sind die Bedürfnisse bei deutschsprachigen Firmen ähnlich, oder hat die englisch sprächende Welt diese Umfrage dominiert?

Also habe jp gebeten, die Umfrage zu wiederholen - was eine Gegenaufforderung produziert hat — und hier sind wir ;-)

Vorher hatte ich eine Blitzumfrage zum Nokia Test durchgeführt, die gezeigt hat, dass viele Firmen eigentlich gar kein Scrum machen (und das, obwohl die Mehrheit der Teilnehmer über die 'scrumdevelopment'-Gruppe davon erfahren haben!). Und so hat sich die Frage gestellt, wie Firmen ihren Scrum Ausbildungsbedarf einschätzen.

Zurzeit wird die Scrum Ausbildung als ein Art Zunft organisiert. Der erste Schritt ist dabei, Certified Scrummaster (CSM) zu werden. Das ist die Grundlage für alle weiteren Stufen, das wichtigste ist allerdings der Certified Scrum Trainer (CST). CSTs dürfen wiederum neuen CSMs ausbilden. Zurzeit gibt es etwa 25'000 CSTs, allerdings nur 54 CSMs. Bis vor kurzem musste man bereits 5 Jahre CSM sein, bevor man sich als CST bewerben durfte.

Das Kern der Scrum Ausbildung in der CSM Kurs. Dabei bieten die meisten CSTs zusätzliche Kurse für besondere Nischen. So weit ich weiss, gibt es nur 4 deutschsprachige CST's, Boris Gloger, Andreas Schliep, Joseph Pelrine und Roman Pichler, auch wenn nicht alle ihre öffentlichen Kurse auf Deutsch durchgeführt werden.

Also stellt es sich die Frage, ob dieser Angebot dem Bedarf gerecht ist. Was braucht Ihre Firma für Scrum Ausbildung?

Unten habe ich eine Liste von Möglichkeiten zusammengestellt, die hoffentlich dem Bedarf in den deutschsprachigen Ländern gerecht wird. Bitte in der Umfrage oben rechts alles ankreuzen, was zutrifft:

Zu meinem Ausbildungsbedarf, bzw zu den Bedarf meiner Firma gehören:

• Zertifizierte Scrum Ausbildung (CSM)
  
• günstigere, nicht zertifizierte Training
• Starthilfe Workshops
  
• Workshops für Fortgeschrittene
• Agile Schätzung und Planung
  
• Agile Vertragswerke
  
• Lean Strategie-Workshops
  
• XP (SW Engineering)
• Offene Kurse
  
• Firmen-Kurse
  
• Web-basierte Ausbildung (Webinars)
  
• Podcasts
  
• Kurse auf English
• Kurse auf Deutsch
• Kurse auf Französisch
• Kurse in anderen Sprachen
  
• Englisch wäre akzeptabel
  
• Englisch ist nicht akzeptable
  
• Kein Bedarf an Training
• anderes
  
• Weiss nicht/ist egal

Zum Datenschutz: obwohl ich an die Ergebnisse nicht uninteressiert bin, die Umfrage-Software von Blogger.com sammelt keine persönliche Informationen (oder falls doch, mir sagen sie nichts). Also werde ich mit niemandem Aufgrund der Stimmabgabe kontaktieren (es sei denn, Sie nehmen aktiv Kontakt mit mir auf).

Die Ergebnisse (samt Vergleich mit der englischen Ausgabe) werde ich hier zusammenfassen, nachdem die Umfrage abgeschlossen ist.

Gastbeitrag Peter Stevens

Peter Stevens, der Autor von http://scrum-breakfast.blogspot.com, hat bei mir angefragt, ob ich nicht ein Umfrage auf meinem Blog posten könne, die er auf seinem Blog bereits in Englisch durchgeführt hatte. Darauf hin habe ich ihn eingeladen auf meinem Blog einen Gastbeitrag zu schreiben.

Wir dürfen gespannt sein. Bis bald.

Wie wird man agil?

Ob man sein Auto wäscht, einen Schrank von Ikea zusammenbaut oder Software entwickelt, man folgt einem Prozess, teils intuitiv oder entlang einer schriftlichen Anleitung per Text oder Piktogrammen.

Agile Softwareentwicklung ist kein Prozessmodell und es gibt nicht DEN agilen Weg. Agil ist ein Bewusstsein, eine Haltung. Das agile Manifesto fast das gedankliche Modell in 4 Werten und 12 Prinzipien zusammen.

Die agilen Werte.[http://agilemanifesto.org/]

Die agilen Pinzipien.[http://agilemanifesto.org/principles.html]

Agil sein bedeutet, dieses Werten und Prinzipien zu folgen.

Erfolg!

Erfolg! Was genau heisst das? Traditionell definiert sich Erfolg durch Lieferung on time, on budget und gemäss Spezifikation.

Doch an dieser Definition ist ganz richtig! Man kann Projekte on time, on bugdet und gemäss Spezifikation abwickeln und mit dem Ergebnis verdient man keinen Cent. Andererseits gibt es Projekte, die über Budget, über den Deadlines und mit weniger Funktionen als spezifiziert abgeschlossen werden und man verdient damit viele hundert Dollar.

Es muss also noch etwas geben, ausser Deadlines einzuhalten. Was?

Als ich noch studierte habe ich oft nebenbei Websites mit PHP programmiert, viel herumgespielt, ausprobiert und umgebaut, bzw. weggeworfen. Solange ich Spass hatte, war ich erfolgreich, auch wenn etwas nicht funktioniert hatte. Mein Definition von Erfolg beruhte auf persönlichen Erfolgserlebnissen, he - Programmieren macht Spass!

Später, bei meiner ersten Anstellung als Software Engineer, wurde die Codebasis schnell sehr gross. Teilweise wusste man garnicht, warum oder wo etwas überhaupt funktioniert. Plötzlich wurde Wart-, Pfleg-, und Integrierbarkeit von Code wichtig. Ich musste lernten sauberen, eleganten und pflegbaren Programmcode in einem Team zu schreiben. Erfolg definiert sich nun so: technisch hervorrangend.

Trotz technisch hervorrangendem Programmcode wurden viele Projekte ein Desaster! Ich musste feststellen, dass Software neben mir und dem Team noch viele andere Stakeholder hatte, dessen Bedürfnisse es zu befriedigen galt - Endbenutzer, Betrieb'ler, Projektleiter, Controller und natürlich mein Chef, der mir meinen Lohn zahlt. Ich lernte, dass der Wert einer Software die gesamten Kosten abdecken muss. Erfolg hatte plötzlich eine unternehmerische Dimension!

Alle drei Dimensionen von Erfolg schliessen sich nicht aus, vielmehr sind alle besonders wichtig, denn nur im Zentrum findet man die Antwort auf die Frage, was neben Deadlines noch wichtig ist.

Ohne persöhnlichen Erfolg ist man schwer motivierbar. Ohne technischen Erfolg gleicht die Codebasis häufig einem Teller Spagetti und ohne unternehmerischen Erfolg wird sich das Team vom Unternehmen abwenden und eine neue Herausforderung suchen.

Der unternehmerische Erfolg wird von Softwareentwicklern oft zu Gunsten des persönlichen und technischen Erfolgs vernachlässigt, denn die sind einfacher zu erbringen und dafür ist jeder Softwareengineer letztendlich auch verantwortlich. Absurder Weise erwartet man aber, dass sich die Softwareentwickler dem übergeordneten Ziel - unternehmerischer Erfolg - unterordnen. Manager und Entscheidungsträger interessieren sich nicht für sauberen, eleganten und pflegbaren Code und die persönlichen Vorlieben der Entwickler - sie sind an Ergebnissen interessiert, am Return of Investment von einem Projekt.

Leider gibt das Management den Teams den Weg nicht vor, man erwarten dass das Team die Details klärt und einen richtigen Weg wählt. Wenn das erhoffte Ergebnis ausbleibt, werden Massnahmen eingeleitet, die sicherstellen, dass Entwicklerteams die gewünschten Erfolge bringen. Die Kosten sind an der Stelle ein beliebtes (Streit)Thema. Es gibt dann aus Managementsicht drei Ansätze:

• Vorgabe harter Deadlines um Entwicklungzeit zu reduzieren
• Outsourcing der Entwicklung in scheinbar billigere Länder
• beides

Wenn einem diese drei Punkte bekannt vorkommen, ist es vielleicht Zeit den unternehmerischen Erfolg bei Entwicklungsteams überhaupt ins Spiel zu bringen.

Warum agil?

Agil ist populär, viele Grosse Unternehmen gehen agil vor: Google, Microsoft, Symantec und viele mehr. Sie alle haben agile Prinzipien adaptiert, teilweise sogar eine eigene agili-irgendwas Methode entwickelt. Erwartungsgemäss schiessen derzeit auch agile Zerifizierungsfirmen aus dem Boden, die auf der agilen Welle mitschwimmen und gegen Entgelt "Certified Agile Consultant" Titel vergeben - die Zertifizierungspraktiken sind oft zweifelhalf. Vielerorts genügt die Teilnahme eines Kurses zur Erlangung des Titels, von Zertifizierung keine Spur. Überbewerten Sie das nicht!

Professor Frederick P. Brooks, Jr., University of North Carolina USA, behauptete 1986, dass sich binnen 10 Jahren keine einzige Technologie oder Management-Methode die Produktivität, Nachhaltigkeit oder Einfachheit um den Faktor 10 erhöhen würde. In seinem Buch aus dem Jahr 1995:

"The Mythical Man-Month: Essays on Software Engineering, 20th Anniversary Edition" MA: Addison-Wesley

kommt er zum Ergebnis, dass es keinen Königsweg gibt.

Agil ist auch kein Köngisweg! Grundsätzlich sollte man agil nicht anwenden, wenn man ausschliesslich die Produktivität erhöhen möchte!

Die Vorteile von agil rühren daher, dass man anders arbeitet, und nicht schneller! Agil Arbeiten ist ein Lernzprozess für jedes Team, und dass kann 2 bis 3 Iteration dauern. Während dessen wird man langsamer sein, nicht schneller! Das Team muss agil praktizieren und lernen, ähnlich einem kleinem Kind, dem man Basketball spielen beibringt. Zunächst wird jedes Kind den Ball in die Hand nehmen, ihn für sich beanspruchen und ihn nicht mit den anderen Teilen. Es dauert seine Zeit, bis man den Kindern vermitteln kann, dass es ein Teamspiel ist und man den Ball abgeben muss.

Agil mag momentan gerade "cool" und "in" sein, aber das ist kein Grund, agil vorzugehen. Wenn man agil vorgehen möchte, dann gibt es nur eine Frage:

Wird uns agiles Vorgehen dabei helfen, erfolgreicher zu sein?

Wenn man diese Frage beantworten kann, weiss man ob agil richtig für einen ist.

In den kommenden Posts werde ich ein paar Punkte aufzeigen, die bei der Beantwortung der Frage helfen können:

• Wann ist man "erfolgreich" - wenn Deadlines erfüllt werden?
• Welche Arten von Erfolge gibt es? Welche sind für agil wichtig?
• Wie sieht eine Organisation aus, die agiles Vorgehen nachhaltig unterstützt?
  

SpringOne 2008, Antwerpen

Auch dieses Jahr ist die namics bei der SpringOne in Antwerpen, Belgien vertreten. Die SpringOne ist einen Entwickler Konferenz, bei der sich Spring Entwickler und Spring Anwender treffen, um neue Features und Ideen von Spring Core, Spring Enterprise oder Spring in Production zu diskutieren.

Wer live dabei sein möchte: RSS- Feed, Flickr

SpringOne2008

Guidewire Case Study beim Scrumbreakfast #7

Professor Stuart Read vom IMD Lausanne hat am Scrumbreakfast #7 eine Case Study von Guidewire vorgestellt. Anders als erwartet hielt Stuart keine herkömmliche Präsentation, sondern gestaltet den Scrumbreakfast als Diskussion bzw. Workshop.

Guidewire ist ein Unternehmen, was mit Scrum aufgebaut wurde, von der ersten Stunde an. Nicht nur, dass es Sprint Team gibt, um Software zu entwickeln, nein - Guidewire ist eine komplett agil aufgebaute Organisationsstruktur. Die Firma reorganisiert sich jeden Monat. Teams wurden neu zusammengestellt, Funktionen und Rollen neu verteilt und interessanter weise zogen sogar die Teams mit ihrem gesamten Desktop um.

Beim Scrumbreakfast #7 traff Stuart auf eine Gruppe von Scrum Anwendern (und solche, die im Begriff sind, Scrum einzusetzen) und wollte von den praktischen Erfahrungen lernen.

Stuart begann den Workshop mit der Frage, welche Personen für agile Teams eingestellt werden sollten: keine Indiviualisten, Teamplayer, Early Adaptors und Output-orientierte Personen. Darüber hinaus wurde darauf eingegangen, wie man den Recruiting Prozess gestalten könne: das Team entscheidet. Der gesamte Entscheidungs- und Organisationsprozess bei Guidewire kommt von der Basis - Bottom-up.

Dann stellte Stuart die Frage, ob man als Kunde eine Software von einem Unternehmen kaufen würde, wenn sich dessen Organisation ständig ändert. Hat man da Verrtauen? Vertrauen, das ist wohl das Kernelelement. Regelmässig liefern, was man versprochen hat - der Schlüssel zum Erfolg.

Guidewire hat in der Zwischenzeit mehr als 350 Mitarbeiter und soll an der Börse notiert werden. Erstmalig in der Erfolgsgeschichte des Unternehmens gab es nun ein Problem - fehlende Hierachie. Es gab keinen CTO, keinen CEO, keinen CFO etc. Wie führt man ein Unternehmen an die Börse, wenn es keine definierten Strukturen hat?

"Wer ist der CTO von Guidwire?"

"Ja, welchen meinen Sie, den von diesem Monat oder den vom vorherigen?"

Stuart fragte uns Teilnehmer, wie wir das Unternehmen beraten würden? Ein paar Minuten später lieferte er die Anworten:

• Die Entwickler-Teams werden in Pods von 3 bis 6 Personen organisiert.
• Jeder Pod hat einen Pod Leader, quasi einen Team Captain.
• Wird ein Team zu gross, gibt es einen Split.
  
• Jedes Team arbeitet an einem spezifischen Teil des Produkts.
• Jeder im Team ist in der Lage, an allen spezifischen Elementen des Teil-Produkts zu arbeiten.
• Die physische Umgebung wurde an dem Team angepasst, um die Kommunikation zu erhöhen - alle sitzen beieinander.
  
• Reviews von Pods werden vom Head des Produktteils durchgeführt, nicht vom Pod Leader.
• Pod Leader werden nach Kompetenz ausgewählt - er kann jeden Job, den ein anderes Teammitglied erledigen kann, auch selbst erledigen.

Guidewire, ein agil organisiertes Unternehmen, dass erfolgreich ist. Die Menschen, die dort arbeiten, würden wohl nie in einem stark hierarchisch organisierten Unternehmen arbeiten und umgekehrt auch nicht. Stuart erzählte, dass man einen CTO von der IBM bei Guidewire eingestellt habe, der das Unternehmen nach kurzer Zeit wieder verliess ...

Mein Resümee

Das Scrumbreakfest #7, organisiert von Peter, war ein interessanter Anlass, insbesondere, weil ich viele organisatorische Prinzipien und Ansätze die diskutiert wurden, bei meinem akutellen Arbeitgeber namics wiederfand. Und dabei ist mir eines klar: nach namics würde es definitiv schwer ein vergleichbares Arbeitsumfeld zu finden ...

barcampbodensee

Auf dem barcampbodensee gab es in den letzten zweit Tagen interessante Sessions, die sich mit diversen Methoden zum Entwicklen von Software beschäftigt haben.

Unter anderem wurde vorgestellt, wie man Game Software mit eXtreme Programming(XP) entwickelt. Dabei konnte man sehen, welche Elemente von XP zur Anwendung kommen, z.B. Pair Programming, User Stories und Continuous Integration.

In einer weiteren Session konnte man sich einen Überblick verschaffen, wie man mit Ruby on Rails eine Webapplikation baut und diese testet. Neben den Routinen, die Ruby on Rails bereits zum Testen mitbringt, wurde der Einsatz von Selenium zum GUI Testing gezeigt - alle automatisiert und integriert.


Mein erstes Barcamp, mein Eindruck: lohnt sich, macht Spass und man lernt viele interessante Leute und deren (teilweise verückte) Ideen kennen.

Was möchte ich tun?

Bisher habe ich das Thema Ruby on Rails mit geringer Wertschätzung immer unter "sollte ich mal irgendwann angehen" gelegt ...

Ok, jetzt ist es soweit. Ich habe mir von einem erfahrenen Ruby on Rails Kollegen Christian Felder ein Buch ausgeliehen: Agile Webdevelopment with Rails.

Get Excited

Nach nunmehr 6 Kapiteln Studium weiss ich eines - das ist DIE Technology um einerseits schnell eine Webapplikation zu realsieren und anderseits dies agil zu tun!

Das Buch selbst ist so aufgebaut, dass man entlang einer Kunden Beziehung einen Shop implementiert. Man trifft den Kunden regemässig und arbeitet die verschiedenen Aufgaben in Interationen ab - gefällt mir sehr gut, und es ist so einfach. Ich entwickle schon seit ein paar Jahren Webapplikation im Java und .NET Umfeld und wenn ich nun nach nur 6 Kapiteln in diesem Buch mal einen Strich machen darf: Es ist so einfach! In der Java und .NET Welt muss man derart viele Handstände machen, um vergleichsweise triviale Dinge zu lösen - in Ruby ist das oft nen Einzeiler!

Der Ruby Erfinder hat mal gesagt: "I wanna be a YES-guy!" - Mit Ruby on Rails hat er mindestens das wohl erreicht!

Next:

Get Started

Story Points, Real Days und Tasks - Wie schätzt man Aufwand nach SCRUM

Eine interessante Frage, die ich kürzlich gestellt bekommen habe:

"Wird die Aufwandschätzung für eine User Story ganz normal in Stunden geschätzt und mit dem Faktor 1,33 Faktor für "real days" multipliziert oder ist der Faktor je nach Team unterschiedlich?"

In den agilen Teams, in den ich bisher gearbeitet habe, gingen wir von Story Points aus. Warum? Story Points (SP) beziffern die "Groesse" (Size). Sie haben keinen zeitlichen Aspekt. Wenn man User Stories mit SP's schätzt, kann man sie nebeneinander stellen und vergleichen:

Story A ist doppelt so "viel" wie Story "B". Story "C" ist 5 man so "viel" wie Story A.

Das ist sehr abstrakt und das ist gut so! Wichtig ist auf jeden Fall, dass die Story Points Scale endlich ist: z.B. 1-5, oder 10-100, etc. Sie sollte eine Progression ausdrücken, also nicht linear sein.

Reals Days ist eine andere Möglichkeit, User Stories zu schätzen.

Während des Sprint Planning Meeting 2, wenn das Team die Arbeit aufteilt, analsyisert und annimmt, werden die User Story in Tasks runtergebrochen und mit h versehen. Wenn man dann alle Stunden aller Team Members aufsummiert bekommt man eine geschätzten Aufwand für den kommenden Sprint. Legt man neben dran die Summe der verfügbaren Arbzeisstunden, kann man ungefähr erkennen, was dring liegt und was nicht.

• Beispiel: Sprint à 2 Wochen (10 Arbeitstage), Teamsize 3:
• Total verfügbare Arbeitszeit: 252 h (8.4h/Tag x 10 Tage x 3)
• Real Days: 180 h (6h/Tag x 10 x 3)
• Summe der Aufwandschätzung von n Task vom Team im Sprint Planning Meeting 2: 200h

In diesem Beispiel sind 20h zu viel im Sprint Backlog - es sollte etwas entfernt und ein Puffer eingeplant werden. Erfahrungsgemäss hat das Team beim Herunterbrechen der Task Dinge vergessen, die dann bei der täglichen Arbeit auffallen.

Jedes Teammitglied fügt solche Tasks während des Springs mit verbleibender Zeit (remaining time) in h ein. Der Scrum Master legt beim Daily Scrum jeweils das Sprint Burndown Chart auf und bespricht die Situation mit dem Team. Hier wird erkenntlich, ob die remaining time mit den noch verfügbaren Stunden übereinstimmt.

Das Sprint Burndown Chart ist vielleicht mal einen extra Post gut, mal sehen ...