Gemeinsam mit Benjamin Reitzammer, Reto Kiefer und Joachim Seibert von der Agile Usergroup Rhein-Main haben wir in den letzten Wochen die Rahmenbedingungen abgestimmt und laden nun am 21.4.2012 zum 1. Agile Open Space Rhein-Main nach Wiesbaden in die Räumlichkeiten von //SEIBERT/MEDIA ein.

Was ist ein Open Space?

Um es auf den Punkt zu bringen: Wir bieten den Rahmen, Ihr sorgt für die Inhalte.

Bei einem Open Space gibt es keine vorab festgelegte Agenda. Jeder Teilnehmer bekommt die Möglichkeit, eigene Sessions zu seinen Wunschthemen einzubringen. Dies können vorbereitete Sessions sein, die eher den Charakter eines Kurz-Workshops haben, z.B. auch Dojos oder Katas. Aber auch Diskussionsrunden, bei denen der “Session-Host” nur das Thema einbringt und die Moderation der Session übernimmt, die Inhalte aber von allen Teilnehmern gemeinsam erarbeitet werden, sind üblich. Es gibt keine Verpflichtung, selbst Themen einzubringen, es kann sich auch einfach Sessions von anderen Personen angeschlossen werden.

Wir erhoffen uns ein breites Themenspektrum über Scrum, Lean, Kanban, XP, Agile, … in den unterschiedlichsten Ausprägungen.

Nicht zu kurz kommen soll dabei auch der lockere Austausch zwischen den Teilnehmern, etwa beim Mittagessen, so dass wir uns untereinander noch besser kennen- und voneinander lernen.

Anmeldung

Die Anmeldung zu diesem Event erfolgt über XING. Es wird bei Anmeldung eine Kostenbeteiligung in Höhe von 29 Euro für Verpflegung, Materialien und Organisation berechnet.

Hier geht es zur Eventseite bei XING.

Foto: von logicalrealist

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Durch die aktive Beteiligung der Zuhörer entwickelte sich der Vortrag zu einem eineinhalb-stündigen Dialog. Vielen Dank an alle, die dabei waren und auch an Kurt Jäger von andrena für die Ausrichtung und Moderation.

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

• Lohnt sich die Einführung von agilen Vorgehensweisen?
• Wie führe ich agile Vorgehensweisen im Unternehmen ein?
• Welche Voraussetzungen für einen Erfolg bestehen?
• Soll ich besser auf Scrum oder auf Kanban setzen?
• Welche Fallstricke und welche Herausforderungen gibt es zu überwinden?
• Wie kann ich Scrum und Kanban in nicht-Programmierprojekten einsetzen?
• Wie werden wir zum agilen Unternehmen?

Datum und Zeit: 10. Januar 2012 um 18:30 Uhr

Ort: Saalbau Gallus, Frankfurt

Referent: Paul Herwarth von Bittenfeld

Moderation: Kurt Jäger (andrena objects ag)

Die Anmeldung erfolgt über die Website von andrena

Die besten Wünsche für ein paar schöne, geruhsame, erholsame, fröhliche, familiäre und besinnliche Weihnachtsfeiertage. Das Jahr neigt sich dem Ende und die etwas ruhigere Zeit eignet sich hervorragend, über die letzten Monate zu reflektieren und Pläne für die Zukunft zu schmieden. Eine lohnenswerte Aktivität mit einem hohen ROI, den wir als Product Owner und Produktmanager zu maximieren gewohnt sind.

Vielen Dank an alle treuen Leser, die in den vergangenen Jahren mit Tweets, Likes, Shares, Anregungen, Fragen, Weiterempfehlungen oder auf andere Weise dazu beigetragen haben, dass sich dieses Blog weiterentwickelt und mir großen Spaß bereitet.

Foto: von jcoterhals

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Eine Orientierung bieten die DEEP-Eigenschaften, die ein gutes Product Backlog aufweisen sollte. DEEP ist dabei ein Kürzel für:

• Detailed appropriately
• Emergent
• Estimated
• Prioritised

Betrachten wir uns diese Eigenschaften eines guten Product Backlogs einmal genauer.

Detailed appropriately

Die Grundregel hierbei heißt: Je näher ein Backlog Item an die Umsetzung heranrückt, desto granularer sollte es sein.
Dadurch gibt es im Product Backlog verschiedene Größen von User Stories:

• Items, die im nächsten Sprint umgesetzt werden sollen, werden in detaillierter Form vorgehalten, etwa als kleine Stories.
• Für die darauf folgenden Sprints angedachte Idems können mittelmäßig detailliert in Form von großen User Stories vorgehalten werden.
• Noch weiter von einer Umsetzung entfernte Odems können in Form von groben Epics festgehalten werden.
• Es wird auch deutlich, dass ein optimaler Product Backlog keinesfalls so ausschaut, dass alle Anforderungen bis ins kleinste Detail ausformuliert sind.

Emergent

Ein Product Backlog ist nie in Stein gemeißelt. Es ist lebendig und wird ständig gemeinsam von Product Owner und Team und Unterstützung der Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von Backlog Grooming-Workshops, aber z.B. auch im Rahmen des Review-Meetings wird über das Backlog und mögliche Anpassungsbedarfe gesprochen.

Estimated

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, wie etwa das Planning Poker oder das Estimation Game. Im Rahmen von Schätzmeetings oder Backlog Grooming-Sessions kann sichergestellt werden, dass eine Beschätzung für alle Backlog-Einträge vorliegt. Für Backlog-Einträge, die noch weiter von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised

Die geplanten Aufgaben sollten stets priorisiert sein. Die Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben Orientierung, worauf Product Owner und Team achten sollten. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein. Ein Product Backlog Board kann hierbei eine gute Hilfe sein.

Foto: von tassoman

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

Ungewollt wurde den kostenfreien Nutzern eine Funktion freigeschaltet, die eigentlich nur für kostenpflichtige Nutzer vorgesehen ist: sie konnten mehrere Administratoren gleichzeitig hinterlegen.

Die Ankündigung der Behebung dieses Fehlers erfolgt durch den UserVoice Community Manager Evan Hamilton auf diese Weise:

„Hey there,

The other day we discovered that we screwed up, and you benefited from it. You basically got the „Bank Error in Your Favor“ card from the Monopoly board game.

Free UserVoice accounts are only supposed to be allowed to have a single Admin…to add additional Admins, you must upgrade your account. Due to a bug, this wasn’t the case: you, and a number of other accounts, were able to add as many Admins to your Free plan as you wanted. Oh dear.

Obviously, we need to rectify this; we can’t make any money unless we have limits on our accounts. However, this was our error and we do feel badly about that. Here’s what we’re going to do:

We’ll give you a little over 60 days (what with holiday schedules and all) to upgrade your account before we reactivate the restrictions. For more info on our plans, see http://uservoice.com/plans. To change your plan, follow these steps: https://feedback.uservoice.com/knowledgebase/articles/40223. That means you have until about February 13th to make any adjustments.
We’re going to give you 50% off any UserVoice plan for a year, since this was our issue. Just use this code: freebug (How to redeem: https://feedback.uservoice.com/knowledgebase/articles/40216)
I’m extremely sorry you had to be inconvenienced by this (Though I’m glad you were undercharged, not overcharged!) and I’d be happy to answer any questions you might have. Thanks for your understanding!

-Evan Hamilton
Community Manager, UserVoice“

Diese Dinge macht Evan in diesem Fall meines Erachtens besonders gut, um aus dem Fehler eine Chance für eine höhere Kundenbindung und mehr Umsatz zu ziehen:

• Der offene Umgang mit dem Fehler führt zu einer großen Sympathie und schafft Vertrauen.
• Es ist ein Anlass für UserVoice, mal wieder alle kostenfreien Nutzer zu kontaktieren. Aus eigener Erfahrung kann ich sagen, dass das kurzzeitig zu einer deutlichen Zunahme der Aktivität der Nutzer führt.
• Die kostenfreien Nutzer erhalten den Vorteil für weitere 60 Tage, so dass auch andere kostenfreien Nutzer den ungeplanten Vorteil temporär nutzen und somit ein Premium-Feature ausprobieren können.
• Evan leitet direkt in einen Verkaufsprozess über. Durch das besondere Angebot eines 50%-Discounts wird es besonders interessant, ein Upgrade durchzuführen.

Foto: von Donna Grayson
——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oderRSS-Feed.

Was ist ein Daily Standup?

Um alle Leser abzuholen, möchte ich noch einmal vorstellen, worum es sich bei Daily Standups eigentlich handelt. Daily Standups sind tägliche Kurzbesprechungen des Projektteams und einer der Grundbestandteile agiler Softwareentwicklung. In Scrum wird hierfür die Bezeichnung „daily scrum“ verwendet. Es ist ein fest verankertes Element in Scrum. Aber auch in Teams, die mit Kanban arbeiten, werden tägliche Standup-Meetings häufig eingesetzt.

Als Grundregel kann angesehen werden, dass dieses Meeting maximal 15 Minuten dauern sollte. Jeden Tag, zur selben Uhrzeit am gleichen Ort. In dieser Zeit beantworten alle Teilnehmer die folgenden Fragen:

• Was wurde seit dem letzten Standup-Meeting gemacht?
• Was wird bis zum nächsten Standup-Meeting erledigt?
• Gibt es Hindernisse, Herausforderungen oder Optimierungsbedarfe, die angegangen werden sollten?

Optimalerweise findet dies an einem Taskboard statt, wie in obigem Bild dargestellt, damit alle auch direkt sehen können, von welcher Aufgabe der Kollege gerade spricht. Gemeinsam wird dann dieses Taskboard auch im Standup-Meeting aktualisiert, etwa erledigte Aufgaben verschoben.

Ist ein Teilnahmezwang für Daily Standups sinnvoll?

In der weniger agilen Praxis werden die Standup-Meetings häufig in Frage gestellt. So sind sowohl bei den Projektteams selbst als auch beim Management der Sinn und Nutzen nicht selten umstritten.

Zunächst einmal ist es meines Erachtens sinnvoll, den täglichen Einsatzbesprechungen eine ernsthafte Chance zu geben. Hat das Team also noch gar keine Erfahrung damit gemacht, wäre es ein guter Schritt, diese für einen längeren Zeitraum, zum Beispiel für 4 oder 6 Wochen oder bei Scrum-Teams für 2-3 Sprints einfach einmal auszuprobieren. Einen Zwang würde ich für nachteilig halten, da hier ganz klar mit Gegenwehr gerechnet werden muss. Vielmehr sollte das Team gemeinsam einen solchen Test-Zeitraum beschließen. Wenn dann negative, schlecht begründete Kritik auftaucht, kann derjenige darauf verwiesen werden, dass sich gemeinsam für eine Testphase entschieden wurde, die erst einmal abgewartet werden sollte. Wenn ernsthafte Verbesserungsvorschläge vorgetragen werden kann geschaut werden, dass diese möglichst schon frühzeitig mit in die Standups eingebracht werden.

Wir haben die Erfahrung gemacht, dass Standup-Meetings von Teammitgliedern insbesondere in den folgenden Fällen kritisiert werden:

• Die Meetings ziehen sich ewig hin und kommen nicht auf den Punkt. Dann sollte darauf geachtet werden, dass die Timebox eingehalten wird und Themen, die nur einen kleinen Teil der Gruppe betreffen erst im Anschluss an das Daily Standup besprochen werden.
• Es wird gar nicht zusammen gearbeitet. Wenn jeder eh an seiner eigenen Baustelle arbeitet, dann erscheint der gegenseitige Austausch natürlich überflüssig. In diesen Fällen steht das Team vor einer größeren Herausforderung und sollte sich eventuell einmal damit beschäftigen, wie Teamwork in der agilen Softwareentwicklung verstanden und angewendet wird.
• Es fehlt eine Moderation. Bei Scrum-Teams macht dies häufig der Scrum-Master, die Moderation kann aber auch abwechselnd von Teammitgliedern übernommen werden. Es sollte aber immer klar sein, wer gerade Moderator ist und dieser sollte z.B. darauf achten, dass die Redeanteile möglichst ausgeglichen sind. Nur wenn auch alle zu Wort kommen, macht es für sie auch Sinn, sich an dem Meeting zu beteiligen.
• Es fehlt eine feste Zeit und ein fester Ort. Wenn die Meetings nicht allen Teammitgliedern in Fleisch und Blut übergehen und einen festen Platz im Kalender aller Teammitglieder haben, geht unnötig viel Zeit dafür verloren zu klären, warum Kollege A und Kollegin B gerade noch nicht anwesend sind. Manche Teams arbeiten auch mit „Strafen“, falls jemand unentschuldigt fehlt oder zu spät kommt. Dies können z.B. 10 Cent für das Team-Sparschwein sein, die dann nach etwas sammeln in einen Kuchen für das Team investiert werden.
• Probleme werden nicht angegangen. Wenn immer wieder die gleichen Herausforderungen auftreten oder ein Kollege im Standup jeden Tag das gleiche erzählt, da er offensichtlich ein Problem mit einer Aufgabe hat, sollten beim Team die Alarmglocken angehen und für eine dauerhafte Lösung gesorgt werden. Standup-Meetings sind eine gute Möglichkeit, kontinuierliche Verbesserungsprozesse anzustoßen.

Nach dem wir nun ein paar Jahre Erfahrung mit Daily Standups haben, kann ich mir kaum noch vorstellen, wie ein Team, dass sehr eng zusammen arbeitet, ohne diese kurzen Einsatzbesprechungen effektiv und effizient zusammen arbeiten kann.

Weitere Informationen zu Daily Standups:

• Daily Standup-Meeting: Einsatzbesprechungen für effektive Teamarbeit
• Die Scrum-Meetings und ihre Bedeutung
• It’s Not Just Standing Up: Patterns for Daily Standup Meetings
• A new kind of standup

Foto: tomnatt

——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oderRSS-Feed.

Die Bedeutung guter Backlog-Pflege

Mike Cohn betont zunächst noch einmal die Bedeutung der Pflege des Backlogs. Er konnte in der Praxis zahlreiche Teams beobachten und die richtig guten Teams zeichneten sich alle dadurch aus, dass sie rund 10% ihrer Zeit in die Pflege des Product Backlogs stecken und diesen aktiv pflegen.
Das Stichwort lautet hier Backlog Grooming und kann zum Beispiel in Form von Workshops mit dem ganzen Team erfolgen.
Mike Cohn betont, dass es für Entscheidungen in der Backlog Priorisierung immer eine solide Grundlage geben sollte, wie etwa die Ergebnisse von Umfragen, aus Statistiken oder ähnliches. Statistisch signifikant braucht es für ihn nicht zu sein, aber z.B. das Feedback von 20-30 Anwendern im Rahmen einer Umfrage kann schon viel aussagen.
Nun aber zu den vier Maßnahmen, die er im folgenden vorstellt.

Kano-Analyse

Bei der Kano-Analyse wird eine Befragung von Anwendern durchgeführt, durch die eine Klassifizierung von Funktionalitäten in verschiedene Kategorien möglich ist:

• Basisfaktoren: Basisfaktoren werden von den Anwendern als selbstverständlich vorausgesetzt. Werden sie erfüllt, entsteht keine Zufriedenheit, bei Nichterfüllung entsteht jedoch Unzufriedenheit.
• Leistungsfaktoren: Diese wirken linear und ein mehr von dieser Funktionalität führt zu mehr Zufriedenheit der Anwender.
• Begeisterungsfaktoren: Begeisterungsfaktoren werden vom Anwender so nicht erwartet, sie überraschen ihn positiv. Als Beispiel nennt Mike Cohn einen Dosenhalter im Auto, den seine Frau spitze fand, der 1993 noch keineswegs selbstverständlich war. So etwas kann sogar das „Zünglein an der Waage“ für eine Kaufentscheidung sein.

Manchmal ist es gerechtfertigt, darüber Schätzungen abzugeben, in welche Kategorie eine Funktionalität fällt. Noch sinnvoller ist meist jedoch die Befragung einer kleinen Gruppe von Anwendern, etwa 20-30 Stück.
Als Tipp für die Einplanung in das Produkt schlägt er vor, dass alle Basisfaktoren integriert werden, da sonst mit Unzufriedenheit gerechnet werden muss. Darüber hinaus sollten einige lineare Funktionalitäten und wenigstens ein paar Begeisterungsfaktoren eingeplant werden.

Weitere Informationsquellen für das Kano-Modell:

• Einführung zum Kano-Modell bei Wikipedia
• Das Kano-Modell verstehen
• Kano model of customer satisfaction

Theme-Screening

Das Vorgehen beim Theme-Screening erfolgt mit den folgenden Schritten:

1. Identifiziere als erstes die Faktoren, die für die Priorisierung als Kriterien für das nächste Release herangezogen werden sollen. Zum Beispiel die Bedeutung für die bestehenden Anwender oder die Generierung von Umsatz. Diese Kriterien werden als Reihen in eine Tabelle eingetragen. Es sollten etwa 5-9 Kriterien sein.
2. Nach der Festlegung der Priorisierungskriterien wird ein „baseline theme“ gewählt. Eine Story oder ein Theme, die im weiteren Vergleich als Basis für die relative Bewertung genutzt wird. Dafür eignen sich solche, die wahrscheinlich in das nächste Release aufgenommen werden und das allen Teammitgliedern vertraut und verständlich ist. Es sollte aber nicht das wichtigste Theme sein, da in diesem Fall alle weiteren Themes im Verhältnis schlechter abschneiden würden. Das gilt also analog zu Referenz-Stories beim relativen Beschätzen des Product Backlogs, wo meist eine mittelgroße oder eine eher kleinere Story als Vergleich genutzt wird.
3. Alle Themes oder Stories, die zur Auswahl stehen, werden nun im Vergleich zum „baseline theme“ nach allen Kriterien bewertet. Für die schlechter abschneidenden Themes wird jeweils ein – eingetragen, für die besser abschneidenden ein + und für die gleich zu bewertenden Themes.

Mike Cohn stellt auf seiner Website sogar ein kleines Tool zum Theme-Screening bereit, das auch schnell das Vorgehen beim Theme-Screening verdeutlicht.

Weitere Informationsquellen für das Theme-Screening:

• Prioritisation Techniques – Part Two
• Theme Screening

Theme-Scoring

Theme-Scoring ist dem Theme-Screening sehr ähnlich. Auch hier geht es darum, verschiedene Themes gegeneinander abzuwägen. Als erstes werden auch hier die verschiedenen Kriterien zusammengestellt, nach denen die Bewertung erfolgen soll. Dann ist eine Bewertung der Kriterien erforderlich. Dafür erhalten sie einen Prozentwert, der sich zu 100% aufsummiert.

Als nächstes werden wieder alle Themes nebeneinander gestellt. Dann wird die Erfüllung der Kriterien für alle Themes bewertet auf einer Skala von 1-5, wobei 1 für eine schlechte Erfüllung des Kriteriums und 5 für eine gute Erfüllung des Kriteriums steht. Dabei ist es hilfreich, als erstes für alle Kriterien ein Basis-Theme festzulegen, dass eine Bewertung von 3 erhält. Somit lassen sich die anderen Themes leichter im Verhältnis zum jeweiligen Basis-Theme bewerten.

Mike Cohn stellt auf seiner Website auch ein kleines Tool zum Theme-Scoring bereit.

relative Gewichtung

Die relative Gewichtung („relative weighting“) ist ein Priorisierungsansatz, bei dem sowohl die positive Auswirkung der Präsenz eines Features als auch die negative Auswirkung der Abwesenheit eines Features in die Beurteilung einbezogen wird. Für jede Funktionalität wird eine bewertung von 0 (gering) bis 9 (hoch) vorgenommen.

Die Themes werden dabei in die Reihen einer Tabelle eingetragen. Dann wird jeweils eine Bewertung für den Nutzen der Funktion bei Bestehen und der Strafe bei Abwesenheit hinterlegt. Zusätzlich wird noch ein Wert für den geschätzten Aufwand, etwa in Story Points oder auch einem Euro-Betrag, hinterlegt. Es werden also in diesem Fall die Kosten einer Funktionalität explizit mit berücksichtigt.
Es wird dann geschaut, welchen Anteil am Gesamtnutzen und welchen Anteil an den Gesamtkosten eine bestimmte Funktionalität hat. Diese beiden Werte werden durcheinander geteilt und es ergibt sich eine Priorisierungskennzahl.

Das als zweites in diesem Fall aufgeführte Feature bringt zwar einen geringeren Nutzen, ist aber ein ganzes Stück günstiger. Dadurch ist der Return on Investment (ROI) von letzterem größer.

Auf der Website Mike Cohn gibt es auch zur relativen Gewichtung ein kleines Tool.

Links zum Vortrag von Mike Cohn

Der Vortrag von Mike Cohn
Folien von Mike Cohn (PDF)

An dieser Stelle möchte ich auch noch auf eine Excel-Vorlage für die Product Backlog Priorisierung von Michael Romer hinweisen.

Foto: peterstev
——–
Immer auf dem aktuellen Stand bleiben? Neue Artikel gibt es über Facebook, Twitter, E-Mail (oben rechts) oder RSS-Feed.

Englische Version des Artikels