inside-scrum

Der nächste Schritt - Personas

2009-10-27T20:38:00.000+01:00

Während mir schon recht lang klar war, wie wir in so einem Fall vorgehen werden, versuchte ich meinen Schulfreund nach und nach in die Materie einzuführen. Im nachhinein hat sich das als sehr nützlich erwiesen. Er kommt aus der Medizintechnik und hatte bislang kaum Berührungspunkte mit Software-Entwicklung, erst recht nicht für Internetanwendungen. Wir näherten uns also Schrittweise meiner Vorstellung, wie das Projekt abgewickelt werden soll.

Mein erster Schritt sollte es sein, Personas zu erarbeiten. Für mich ein unerlässliches Arbeitsmittel über den gesamten Zeitraum der Entwicklung habe ich ihm dieses Arbeitsmittel clever verkauft. Quasi als Anbieter der Software habe ich nicht vorgeben, dass wir mit Personas arbeiten, dass wir damit arbeiten, warum bla bla bla...

Mir war es wichtig, auch ein bischen reiner Selbstschutz, dass mein Schulfreund eine Vorstellung hat, wer an die Software verwenden wird, warum er dies tut und was für Aufgaben eine Person über die Software erledigen würde. Bis hierher hatte ich oft das Gefühl, dass wir recht visionär unterwegs waren. Mein Ziel war es, die Dinge mal auf den Boden zu holen. Wir haben gemeinsam den Blickwinkel stark verändert, von der Sicht des Produktherstellers mit starkem Vertriebsinteresse hin zur Sicht der Benutzer.

Wir entwickelten also Personas.

Bis hierher wurde Emails ausgetauscht. Über kurz oder lang verlor sowohl er als auch ich den Überblick. Kurzerhand habe ich alles auf Google Documents verschoben, unser erstes Arbeitsmittel mit Unterstützung verteilten Arbeitens.

In 3 Tagen lauffähige Software entwickeln - geht das, wie funktioniert das?

2009-10-22T18:25:00.003+02:00

Beim letzten Scrum Breakfast Zürich konnte ich der agilen Community ein interessantes Projekt vorstellen.

3-2-1 Live! Rapid Development.

Namics hat im August 2009 gemeinsam mit der Adhoco GmbH, Winterthur ein Projekt der besonderen Art abwickelt. Ein interdisziplinäres Team, dass sich nicht kannte und so noch nie zusammengearbeitet, hat sich das ambitionierte Ziel gesteckt, lauffähige Software in 3 Tagen zu realisieren, wobei zu Beginn nur ein Idee im Raum stand!

Das Team, bestehend aus dem CEO/Adhoco als Product Owner, 1 Entwicker/Adhoco, 2 Entwicklern/Namics, einem ScrumMaster/Namics und einer UI Designerin/Meyer-Hayoz Design Engineering, führe in der gegebenen Zeit Interviews durch, erarbeite Personas und User Stories, entwarf UI Prototypen, Wireframes und realisierte letztendlich ein Web Applikation, die für das iPhone optimiert wurde.

Im Vortrag wurden fünf Fragen beantwortet:

Wie kommt man von einer Idee zur Vision?
Wie sammelt man benutzerorientierte Anforderungen?
Wie stellt man den ersten Release zusammen?
Wie geht man bei der Umsetzung vor?
Wie geht man erfolgreich live?

... und natürlich wurde das Ergebnis gezeigt. Eine spannende Diskussion folgte auf den Fuss.

Klingt spannend? Dann studieren Sie die Unterlagen zum Vortrag ...

NAM-3-2-1-Live-RapidDevelopment-20091006-v1-1.pdf

Pay Per Use

2009-10-19T21:28:00.003+02:00

Im letzten Beitrag habe ich die derzeitigen Marktgegebenheiten erläutert und das Geschäftsmodell kurz angerissen. An dieser Stelle sei erwähnt, dass neben der Software eine komplett neue Hardware entwickelt wird, ein digitales Endoscop - EOSCOPE. Wie in der Medizintechnik so üblich wurde die Idee mit vielen Patenten geschützt und über Partner und eigenen Mitteln finanziert. Ich nenn' das mal StartUp.

Quasi mit leeren Taschen stand mein Schulfreund dann vor mir und fragte mich:

Was kostet dass, wenn man so eine Anwendung baut?

Bis zu diesem Zeitpunkt war ich meiner Wahrnehmung nach nicht als Software Entwickler angesprochen, sondern eher als guter Zuhörer, als Partei zum challangen der Idee und Vision, als Berater - wie auch immer. Es war recht abstrakt, wenig greifbar und hatte irgend wie auch nichts mit mir zu tun. Als er danach fragte, ob ich ihm helfen könnte und wie ich mir eine Bezahlung vorstellte, änderte sich alles.

Wie einen Schalter, den man umlegt - ich wusste wie es geht, wie man vorgeht, welche Schritte man macht, in welcher Reihenfolge, wie es funktionieren wird und wann es nicht funktioniert. Ich hatte für jede Frage eine Antwort, ausser was es kostet und wie lange ich brauchen werde.

Mein Schulfreund, leicht irritiert, meinte, dass kann doch nicht so viel Arbeit sei, er stelle sich das recht einfach vor. Mein Gedanke war, und ich erinnere mich recht gut daran: Kein fixer Scope und keine fixe Zeitvorgaben - Aufwandschätzung unmöglich.

Wie im Vaakuum kam ich mir vor, als ich meinem Schulfreund versuchte zu erklären, dass Software Entwicklung nicht auf ein paar netten Gesprächen basieren kann. Man müsse schon etwas mehr in der Hand haben. Ausserdem kann das schnell recht teuer werden, den Standartsoftware kommt wohl nicht in Frage ;-)

Nach einer Weile und etwas mehr Verständnis für meine Situation kam er mit einem recht attraktiven Model. Letztendlich ist die Investitionssumme für die Software nicht wichtig. Wichtig ist, dass sie ein integraler Bestandteil der Pay Per Use Philosophie ist das man auch über Beteiligungen regeln kann. Pssst .....

Viel mehr möchte ich hierzu nicht erörtern -nur soviel: Wir haben ein Agreement gefunden. Eine Dimension des magischen Dreieck ist damit fixiert, oder relativiert: Budget.

Bleiben Scope und Time.

Ein neues Projekt - ProjekDE

2009-10-02T08:39:00.002+02:00

Ein guter Schulfreund arbeitet schon seit Jahren an einer Idee, die die Medizintechnik revolutionieren soll, ein Markt, in dem ich mich bisher nur begrenzt auskannte. Hin und wieder trafen wir uns eher im privaten Umfeld, tranken ein paar Bier, sprachen von alten Zeit und mehr und mehr kam von seiner Seite Fragen zu meinem Beruf, was ich genau mache und ob ich mir vorstellen könnte, etwas für ihn zu entwickeln.

Im Herbst 2008 habe mich erstmalig genauer mit seiner Idee auseinandergesetzt. Warum soll es gehen?

Er hat mir an recht einfachen Beispiel erklärt, wohin die Reise geht - sagen wir mal das Business Konzept hatte ich begriffen, vorerst. Soweit ich das heute noch nachvollziehen kann, war sein Wunsch eine Anwendung im Internet zu haben, bei der man sich Anwendungscodes freischalten kann. Was das bedeutet und wozu man das braucht werde ich versuchen zum Besten zu geben.

Heute ist es in der Medizintechnik so, dass Geräte inventarisiert werden. Ein Krankenhaus kauft diverse Geräte, die für den Betrieb erforderlich sind. Da diese Geräte recht teuer sind, kann man mit entsprechend langer Lebzeit rechnen. Wie skaliert das Geschäft für die Gerätehersteller? Gar nicht. Man hat dennoch einen Weg gefunden, das Geschäft mit den Krankenhäusern aufrecht zu erhalten, denn die Menge der Krankhäuser ist endlich und schrumpft. Eines der Wundermittel sind sogenannte "Disposables", Wegwerfprodukte, die stehen. Andererseits gibt es auch Austauschkompononten die bei den teuren Gerätschaften zum Einsatz kommen. Zusammenfassend kann man feststellen, dass einerseits Krankenhäuser über die Motivation des Substanzerhalts selten neue Geräte anschaffen, die die sie bereits besitzen recht teuer Instand halten(müssen) und währenddessen viel Geld für Disposables ausgeben - andererseits verschafft diese Situation den Herstellern ein recht angenehmes Dasein. Krankenhäuser sind heute vielerorts in fester Hand von Herstellern. In Amerika geht man soger soweit, dass der Hersteller dem Krankenhaus nicht nur Gerätschaften, sondern ganze OP-Säle vermietet, sogar mit Personal - wenn gewünscht.

Als mein Schulfreund mir diese Geschichte erzählt hatte, war ich der Meinung ich hätte alles Verstanden - alles klar! Und was bauen wir nun genau? Er hat mit folgender Metapher seine Vison vorgestellt.

"Du kennst doch Prepaid Handies?"

Ja klar, und?

"Und Leasing-Modell bei Autos ist Dir auch bekannt?"

Im Kern stützt sich die Idee auf die Annahme, dass Krankenhäuser nicht länger teure Geräte kaufen, diese Inventarisieren und damit Kapital langfristig binden. Der Budget-Druck in den Krankenhäusern ist gross und wird steigen. Daher werden Krankenhäuser ein Interesse haben Investitionskosten zu reduzieren, wenn nicht gar abzuschaffen. Wie wäre es also, wenn man ein Gerät ähnlich einem Prepaid-Handy leihen könnte und nur für die Anwendung selbst zahlt? Und wie wäre es, wenn man zusätzlich das gesamte Serviceportfolio des Herstellers beanspruchen könnten, z.B. Rückgabe, Umtausch, Garantie, Services, etc. - ohne aber ein Grundbetrag zu bezahlen? Spielt man ein bischen mit dieser Idee wir schnell das Mischkonzept von Prepaid, quasi abzahlen auf Raten mit anschliessendem Übergang in Besitz, und Leasing klar - Pay Per Use!

Meine Aufgabe sollte es sein, eine Internetanwendung zu entwickeln, die den Geschäftsprozess für Pay Per Use unterstützt.

ProjectDE

2009-09-29T10:43:00.004+02:00

Hallo agile Gemeinde,

es ist ein bischen ruhig geworden auf meinem Blog, hm. Aus guten Grund.

Ich arbeite gerade neben meinem eigentlichen Job bei Namics mit einem Freund an dessen Internet-Idee: ProjectDE. Irgendwann muss ich mal was darüber schreiben, ich weiss. Kommt noch, ganz sicher.

Heute möchte ich nur kurz einen Vorgeschmack geben, was da so geht.Darf ich vorstellen, der Product Owner:

Hi Johnny,

Wollte dir noch sagen, dass ich noch nie erlebt habe, dass jemand ein Projekt so professionel, kreativ und weitsichtig lebt, wie du.

Du hast was großes geschaffen - kannst stolz sein!

Gruesse, Marc

Von meinem iPhone gesendet

Rapid Development Vortrag im Zug Zürich-Landquart

2009-05-29T19:03:00.005+02:00

Zusammen mit David Nydegger, mein Arbeitskollege bei namics, haben wir an der Orbit 2009 einen Vortrag zum Thema "Rapid Development" gehalten. Die Vortrag war nicht gratis - 130 CHF Eintritt pro Person waren fällig. Immerhin hatten sich trotzdem 19 Teilnehmer eingefunden.

Als David und ich uns an diesem Tag auf den Weg machten, wurden wir von vielen namics Mitarbeitern gefragt, ob wir denn nicht noch ein paar Freikarten hätten - sie würden den Vortrag auch gern sehen. Nun, wir hatten leider keine. Also versprachen wir, den Vortrag intern nochmals zu halten.

Da bislang kein Termin gefunden werden konnte, sind David und ich kurzhand auf den Zug ausgewichen, denn namics reist am kommenden Donnerstag den 04. Juni nach Davos - namics camp09. Also nutzen wir die Zugfahrt und machen unseren Vortrag mobil ...

Wer unseren Vortag "Rapid Development" an der Orbit09 verpasst haben sollte und gern mit dem Zug durch die Schweiz reist ist hiermit eingeladen teilzunehmen.

Der Zug fährt ab 11.37 ab Zürich HB. Der Vortrag beginnt um 11.45. Besammlung vorher auf Gleis 8.

Rolle vs. Persona - Warum sind Personas wichtig?

2009-05-15T14:50:00.000+02:00

Es gibt unterschiedliche Möglichkeiten Anforderung für eine Software zu erheben. Bei agilen Projekten wählt man häufig einen User Centered Ansatz und beschreibt Anforderungen aus Benutzersicht - so genannte User Stories. Soll man Benutzer mit Rollen verallgemeinern und zusammenfassen?

Geschäftsmodelle im Internet funktionieren, wenn man den Nerv der Benutzer trifft und dessen Erwartung erfüllt. Ein Internetauftritt, eine Anwendung oder ein spezielles Angebot - es soll eine ganz bestimmte Zielgruppe angesprochen werden. Kennt man die Zielgruppe, weiss wie man sie anspricht oder was gar abschreckende Wirkung hat - kann man das Angebot entsprechend ausrichten.

Am Beispiel einer Kampagne der PostFinance möchte ich zeigen, dass es durchaus wichtig ist, sich mit den realen Benutzern und deren Erwartungen auseinander zu setzen.

Zahle CHF 50 an 24-9779-8

Um nicht die gesamte Kampagne zu erzählen würde ich die Ausgangslage als User Story so formulieren:

Ein Kunde möchte mit seinem Mobiltelefon per SMS Überweisungen tätigen können.

Ein Kunde. Ein Kunde ist in diesem Fall eine Aggregation, eine Rolle in die der Benutzer schlüft. Jungendliche, Berufstätige, Schüler, Studenten - das könnten alles Kunden sein. Mit dieser Verfeinerung hat man die Rolle bereits etwas geschäft. Man kann noch ein Schritt weitergehen und Personas konzipieren, die einer realen Person entsprechen.

Angenommen Andreas ist Kunde der PostFinance. Er ist Mitte dreissig, Handelsreisender, keine Familie, sportlicher Typ.
Andreas wird es sicher begrüssen, wenn er irgendwo auf der Welt von unterwegs per SMS Überweisungen tätigen kann. Er hat praktisch keine Zeit für Hausbesuche bei seiner Bank und Internetzugang gibts auch nur beschränkt. Würde man Andreas zu SMS Überweisungen befragen, würde er sicher begeistert sein - ein Exciter, ein WOW Feature.

Nimmt man hingegen Peter, kann das ganz anders aussehen.
Peter ist IT-Sicherheitsbeauftragter, 44 Jahre alt, Familie mit 2 Kindern, ebenfalls sportlicher Typ. Würde man Peter zu SMS Überweisungen befragen, hätte er sicher etwas gegen ein solches Feature, denn er weiss, dass SMS in Klartext verschickt werden und ein gewisses Risiko der Manipulation besteht. Ein absolutes No Go! Er würde das Online-Banking Angebot nicht nutzen, wenn man dieses Feature anbietet.

Das Beispiel zeigt fiktiv, wie man auf ganz unterschiedliche Empfindungen trifft, von WOW bis hin zur abschreckenden Wirkung. Es ist also wichtig, dass man sich ein Bild vom realen Benutzer macht. Darüber hinaus ist ebenso wichtig, dass man sich neben den Befürwortern auch Personas konzipiert, die das Angabot nicht gut finden oder es gar versuchen zu sabotieren.

Lean Agile Scrum Conference in Zürich am 4.Juni 09

2009-05-13T13:05:00.000+02:00

Nach dem ScrumDay München 2009 gibt es nun am 04.Juni die "Lean Agile Scrum Conference" in Zürich, bei der ebenfalls Ken Schwaber anwesend ist und referiert - und das gleich mehrfach.

Das eintägige Programm der Lean Agile Scrum Conference am 04. Juni 09 in Zürich sieht gleichermassen wertvolle Vorträge vom Fachbeitrag bis hin zu Erfahrungsberichten zu den Themen Lean, Agile und Scrum vor.

Ken Schwaber beginnt mit der Keynote "Done and undone" und tritt am Mittag nochmals mit dem Vortrag "State of Scrum" vors Mikrofon. Anschliessend hat man die Möglichkeit am Ken Schwaber Seminar "ScrumBut Workshop" teilzunehmen (# Teilnehmer begrenzt).

Von der Software-Entwicklung bei der Zahnärztekasse AG über Projekte mit einer Agile-Wasserfall-Mischform bis hin zu Management-Praxis Tracks in Grossunternehmen - es ist sicher für jeden Teilnehmer etwas dabei.

Veranstaltungsinformationen:

4. Juni 2009
Von 8:00 bis 17:30 Uhr
ETH Zürich, Gloriastrasse 35, 8006 Zürich
http://www.swissict.ch/vomhypezurpraxis

3-2-1 Live - Rapid Development à la carte

2009-04-30T16:10:00.004+02:00

seeflu.com - eine Webapplikation bauen in weniger als 48h Dank Rapid Development.

Wie seeflu.com vormacht, kann man innerhalb von 48h von einer Idee zur lauffähigen Applikation kommen. Ich möchte kurz erläutern, wie das geht ...

Zu Beginn gab es eine einfache Idee. Dem Vater des Gedanken folgten recht schnell ein paar fixe Köpfe die meinten, da müssen wir was machen und ich mach' mit.
So fanden sich 4 Personen unterschiedlicher Kompetenzen:

ein Konzepter und Designer
ein Experte für Online-Kommunikation
zwei Entwickler

Schnell wurde die Idee manifestiert und ein Mission Statement erarbeitet. Hilfestellung dafür waren folgende Fragen:

Was wollen wir machen?
Für wen wollen wir das machen?
Warum wollen wir das machen?

Nach kleinen Diskussionen und viel Brainstorming wurde folgendes Mission Statement definiert:

"Covering everything there is to know about swine flu"

Davon ausgehend liess sich die Menge der möglichen Domains einschränken und so wurde schlussendlich seeflu.com reserviert.

Das Team hat den Funktionsumfang umrissen - Brainstorming. Dabei wurden gute und wichtige Funktionen entwickelt. Angesichts der kurzen Zeit wurde der Umfang für den ersten Release extrem heruntergefahren.

Kurzerhand wurde eine Informationsarchitektur entwickelt, ein Logo kreiert und ein einfaches Design entworfen. Die beiden Entwickler haben dies umgesetzt und ...

... nach 48h ist die Applikation heute live gegangen! seeflu.com

Scrum Day 2009 mit Ken Schwaber in München

2009-04-23T22:45:00.000+02:00

Ken Schwaber macht auf seiner Scrum Tour durch Europa auch in München halt - SCRUMDAY 2009.

Am 06. Mai 2009 findet in München ein eintägiger SCRUMDAY statt. Eingeleitet wird der interessante Tag mit der Keynote "Scrum, but ..." von Ken Schwaber, Mitbegründer von Scrum. Das Tagesprogramm sieht weiter Vorträge in parallelen Slots a 1h vor - Erfahrungsberichte, etwa der Allianz Deutschland AG, ImmobilienScout24 und AutosScout24, werden ebenso angeboten wie fachliche Vorträge rund um das Thema Scrum. Zwischen den Vorträgen wird Freiraum für Fragen, Antworten und spannenden Diskussionen geboten.

Vor dem Scrum Day 2009 in München kann man am 04. und 05. Mai den Certified ScrumMaster Kurs direkt mit Ken Schwaber belegen, sicher spannend.

Sie haben Interesse an agilem Projektvorgehen oder haben bereits nach Scrum gearbeitet und haben viele, viele Fragen? Dann empfehle ich beim Scrum Day 2009 in München vobeizuschauen:

Veranstaltungsort:
NH München Dornach - München
Einsteinring 20
85609 Aschheim-Dornach
Telefon: +49 89 / 940096 0
Fax: +49 89 / 940096 100
Internet: http://www.scrum-day.de

Wann sollte man NICHT agil arbeiten?

2009-03-30T10:27:00.002+02:00

Immer wieder stellt sich bei einen neuen Projekt die Frage, wie man vorgehen soll/möchte. Scrum und agil um jeden Preis - ich habe viel Lehrgeld bezahlt :), Heute würde ich mich intensiver mit dem Projekt-Ökosystem auseinandersetzen, bevor ich agil arbeiten möchte.

Kelly Waters fasst das auf seinem Blog so zusammen: "... 3 reasons why I wouldn't do agile software development:

1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.

2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.

3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.

In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors! " Kelly Waters

Die Punkte 1 und 3 finden fast immer positive Zustimmung, Punkt 2 allerdings ist bei meinen Projekten oft das Zünglein an der Waage ...

namics ist an der Orbit mit dem Thema: Rapid Development

2009-02-26T07:54:00.003+01:00

Rapid Development - Wie Sie mit agiler Softwarentwicklung Ihr Webprojekt schnell zum Erfolg bringen können.

Erfolgreiche Start-Up Firmen im Web-Umfeld haben schlicht keine andere Wahl: Mit begrenzten Ressourcen einen frühen Time-to-Market zu erreichen, ist für sie der kritische Erfolgsfaktor, um mit einer neuen Webapplikation im harten Wettbewerb bestehen zu können. Dabei nutzen Start-Ups oft Methoden und Prozesse aus der agilen Softwareentwicklung. Diese können auch Sie für Ihr Webprojekt nutzen.

Jean-Pierre König und David Nydegger zeigen Ihnen mit der Präsentation "Rapid Development", wie Sie selber eine Idee schnell in eine laufende Webapplikation umsetzen können, ohne sich in endlosen Konzeptions- und Spezifikationszyklen zu verlieren. Anhand eines konkreten Fallbeispiels erfahren Sie,

wie man von einer Idee zu einer Vision kommt
wie man effizient benutzerzentrierte Anforderungen sammelt und bewertet
wie man bestimmen kann, was für Funktionen und Inhalte im Release enthalten sein sollen
wie man während der Umsetzung stets Herr des Prozesses bleibt
und wie man erfolgreich live geht.

Die Präsentation "Rapid Development" hält sowohl für ein technisches als auch für ein businessorientiertes Publikum interessante Erfahrungen und Beispiele aus der Praxis bereit.

Jean-Pierre König ist Senior Software Engineer bei namics und beschäftigt sich seit längerem mit agiler Softwareentwicklung. David Nydegger ist Consultant bei namics und konnte vorher Erfahrungen in mehreren Start-Ups im Internetumfeld sammeln. Bei namics treibt er das Thema Rapid Development aktiv voran.

Orbit:
Messezentrum Zürich
12. - 15. Mai 2009

Scrum Breakfast in Zürich, im März 09

2009-02-18T16:10:00.002+01:00

Am 04. März 2009 findet erneut ein Scrum Breakfast in Zürich statt. Thema:

"Agile Methoden und Krisenmanagement in der Informationstechnologie"

Veranstalter:
SwissICT Fachgruppe Lean, Agile & Scrum

Daten:
Mittwoch, 4. März 2009
8:00 bis 10:00 Uhr, Vortrag 8:35 bis ca. 9:00 Uhr
namics ag, Konradstrasse 12, 8005 Zürich

Die Veranstaltung ist bereits ausgebucht, aber Teilnahme via Webinar ist möglich.

Scrum Breakfast in Zürich, im Februar 09

2009-02-03T15:21:00.003+01:00

Am 04. Februar 2009 findet erneut ein Scrum Breakfast statt. Thema:

"Teambuilding" fürr agile Teams - OHNE etwas von "Teamdynamiken" verstehen zu wollen

Veranstalter:
SwissICT Fachgruppe Lean, Agile & Scrum

Daten:
Mittwoch, 4. Februar 2009
ab 08:00 Uhr
namics ag, Konradstrasse 12, 8005 Zürich

Details und Anmeldung

Wie würde ich agil meinen Eltern erklären?

2009-02-03T09:13:00.003+01:00

Ich begebe mich an einem schönen Samstag morgen ins Autohaus mit der Absicht, einen Wagen zu kaufen. Im Verkaufsraum werden mir verschiedene Modelle gezeigt, der Verkäufer ist nett und nimmt sich viel Zeit. Jene vergeht und ich weiss, hier gefällt mir kein Wagen. Bei der Konkurrenz ist das ähnlich, da war ich bereits. Irgendwie sind das alles Standartprodukte, das möchte ich nicht.

Ich habe eine Vision von meinem Wagen und wenn ich mich umsehe, gibt es den nicht. Also bau' ich mir ihn selbst. Hinter dem Verkaufsraum, in der Entwicklung, Konzeption und Produktion werden sich meine Träume erfüllen!

Auf der Suche nach einem kompetenten Partner werde ich schnell fündig. Mir steht nun ein Team von Designern, Konstrukteuren, Modellbauern, Ingenieuren, Sattler, Qualitätsbeauftragten, Entwicklungsleitern und vielen anderen zur Verfügung. Alles Profies, versteht sich.

Ich treffe das Team zum ersten Mal, ich freu mich schon, denn sicher werden sie meine Vision vom perfekten Auto mögen. Ich bring den Elevator-Pitch hinter mich und ... wie ich vermutet hatte, MEIN Team ist begeistert! Es schauen ca. 20 Augen auf mich: Wo fangen wir an?

Nun, ich bin ein passionierter Autofahrer, weiss was ich möchte und wie mein Wagen in etwa aussehen soll. Wie man vorgeht weiss ich nicht. Ich habe keine Ahnung, also spiel' ich den Ball zurück und frage: Wie würden Sie vorgehen?

Wenig überrascht (ich hatte es ja erwartet) breitet sich die geballte Kompetenz der Anwesenden vor mir aus - he, die Jungs wissen, wie sie es geht. Also lehne ich mich zurück und verschaffe mir ein Überblick.

Jetzt hab' auch ich einen Plan, sehr gut! Ich treff' mich nun regelmässig mit meinem Team und sie zeigen mir den Fortschritt. Ich kann dann jeweils meine Meinung dazu geben und auch Veränderugen vornehmen lassen, z.B. beim Heck. Da bin ich mir sicher, dass es einige Designänderungen geben wird. Ich weiss nämlich noch nicht recht, wie es aussehen soll ...

In der Zwischenzeit ist ein Jahr vergangen und das Team hat hart gearbeitet, wir haben uns regelmässig getroffen und ich konnte bereits nach einem Monat ein Knetmodell in den Händen halten. Heute, nach 12 Monaten steige ich zum ersten mal in dem fahrbaren Prototyp. Ich freu' mich.

Wie machen die das? Nach 12 Monaten weiss ich immer noch nix darüber, wie man ein Auto baut, brauch ich auch nicht, denn mein Team weiss das. Ich vertaue dem Team, bekomme früh Feedback zu meinen Wünschen, weiss immer genau, wie lange man für die Umsetzung brauchen wird. Das Team berät' mich sogar.

Prototyping

2008-11-20T20:02:00.002+01:00

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!

2008-10-02T18:30:00.006+02:00

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?

2008-09-26T12:47:00.005+02:00

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,

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

69er - Projektende

2008-09-23T19:27:00.004+02:00

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

2008-09-10T14:30:00.001+02:00

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?

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

Uhhpf! Nicht gut ...

Was können wir besser machen?

Niemand arbeitet allein auf dem Projekt (auf täglicher Basis). Wir arbeiten nur, wenn mindestens 2 Teammitglieder arbeiten, bessere Resourcenplanung ausserhalb des Teams.
Reviews schneller(früher) machen, Arbeit (früher) abschliessen
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

2008-09-09T10:09:00.006+02:00

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

2008-09-01T21:51:00.000+02:00

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

2008-09-01T21:25:00.001+02:00

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

2008-08-18T18:34:00.001+02:00

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

2008-08-15T19:05:00.003+02:00

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