Tools4AgileTeams 2015 – neue Location und neuer Themen-Schwerpunkt

tools4agileteamsLiebe Agilisten, im Herbst geht unsere Konferenz Tools4AgileTeams in die nächste Runde: Am 17. und 18. September 2015 findet in Wiesbaden die vierte Ausgabe der T4AT statt. Wie schon im vergangenen Jahr wird es einen Konferenztag mit Vorträgen und Workshops und ein separates Open Space geben.

Neue Location: CSC Akademie Wiesbaden

Für die diesjährige Konferenz können wir durch eine Zusammenarbeit mit der CSC Akademie auf deren Räumlichkeiten in Wiesbaden zurückgreifen (Abraham-Lincoln-Park 1). Wie immer waren die folgenden Faktoren für die Auswahl ausschlaggebend: gute Erreichbarkeit (fünf Taxi-Minuten vom Hauptbahnhof entfernt), moderne Technik, ausreichend Platz für mehrere parallele Slots und das ganze Drumherum. Wir sind sicher, dass unsere Location auch diesmal alle Anforderungen erfüllen wird.

Schwerpunkt Zusammenarbeit

Der inhaltliche Schwerpunkt der vierten Tools4AgileTeams soll auf dem Thema Zusammenarbeit liegen. Für den Vortragstag sind drei Tracks vorgesehen, die sich auf die verschiedenen Ausprägungen von Zusammenarbeit fokussieren werden: im Team, mit dem Management und anderen Teams, mit Kunden.

Call for Sessions bis zum 15. Mai

Für diese Tracks können interessierte Speaker jetzt ihre Themenvorschläge einreichen. Klassischer Vortrag, interaktive Session, Mini-Workshop, Pecha Kucha – in Sachen Format habt Ihr freie Hand und könnt selbst bestimmen, in welcher Form Ihr Eure Inhalte vermitteln möchten. Auch für andere Formatvorschläge sind wir offen. Wenn Ihr Euer Thema mit einem interessierten Publikum aus Agilisten teilen möchtet, stellt es dem Fachbeirat kompakt vor. Hier haben wir ein bequemes Einreichungsformular vorbereitet: http://www.tools4agileteams.com/display/2015/Call+for+Sessions (Einreichungsschluss ist der 15. Mai.)

Wir sind gespannt auf Eure Vorschläge!

Wir freuen uns jetzt schon auf die Tools4AgileTeams 2015 und werden Euch in Kürze weitere Infos zu den konkreten Inhalten und natürlich zur Anmeldung an die Hand geben! Habt Ihr Fragen oder Anregungen zur Konferenz? Dann sprecht mich gerne direkt an, ich stehe Euch zu allen Fragen rund um die T4AT zur Verfügung!

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz in Wiesbaden

Entwicklung einer Teamvision

Kürzlich habe ich für ein Software-Entwicklungsteam einen Workshop für die Erstellung einer gemeinsamen Teamvision durchgeführt. Wir wollten das Bild der Idealvorstellung der Teamsituation von allen Team-Mitgliedern abgleichen und in eine gemeinsam formulierte Vision überführen. Der Workshop war mit einer Stunde angesetzt und damit sehr kompakt. Das Team hatte schon länger zusammengearbeitet und bestand aus 5 Personen. So konnte in der kurzen Zeit ein gutes Ergebnis erzielt werden.

Der Ablauf des Workshops

  1. Begrüßung
  2. Frage: Was erwartet ihr von dem Termin heute? (Blitzlicht)
  3. Geplantes Vorgehen vorstellen
  4. Frage: Wie stellt ihr euch die optimale Arbeitssituation (Zusammenarbeit, Projekte,…) im Team vor?
  5. Vorstellung der Punkte durch die Teilnehmer
  6. Clustering und Überschriften zu den vorgestellten Punkten
  7. Überschriften gewichtet/bepunktet und damit priorisiert, Aufreihung und Ordnung
  8. individuelle Formulierungsansätze
  9. gemeinsame „Vergesellschaftung“ und Übertragung in eine Formulierung

Begrüßung und Erwartungsabfrage, Vorstellung des Vorgehens

Nach ein paar einleitenden Worten von mir haben wir in einer kurzen Blitzlicht-Runde (jeder Teilnehmer antwortet rundum in 2-3 Sätzen) die Erwartungen an den Termin abgestimmt. Dann habe ich das konkrete geplante Vorgehen vorgestellt. Auch habe ich kurz vorgestellt, was eine Teamvision, die wir als Ergebnis erhalten wollte, erfüllen sollte:

  • Sie spricht alle Beteiligten an
  • Sie beschreibt die gewünschte Situation in Gegenwarts-Form
  • Sie ist kurz und prägnant

Frage: Wie stellt ihr euch die optimale Arbeitssituation (Zusammenarbeit, Projekte,…) im Team vor?, Vorstellung der Punkte

IMG_4219 Jedes Teammitglied sollte sich einige Minuten lang in Ruhe überlegen, wie es sich die perfekte Arbeitssituation vorstellt. Jeder Aspekt sollte auf ein eigenes Post-it geschrieben werden.

Dann haben wir uns zusammen vor einer Wand versammelt und die Teammember haben nach und nach ihre Punkte vorgestellt. Bei der Vorstellung wurde auch direkt ein grobes Clustering vorgenommen, ähnliche Punkte wurden also nahe zueinander gehängt, während unterschiedliche Themen voneinander entfernter aufgehängt werden.

Clustering und Finden von Überschriften zu den vorgestellten Punkten

Das grobe Vorab-Clustering wurde dann nach Vorstellung aller Punkte noch einmal zusammen besprochen und die einzelnen Cluster haben jeweils einen eigenen Namen bekommen.

Überschriften gewichtet/bepunktet und damit priorisiert, Aufreihung und Ordnung

IMG_4223

Die Teammember konnten dann eine vorgegebene Zahl von Punkten auf die einzelnen Cluster verteilen und damit ihre Gewichtung für das entsprechende Thema zum Ausdruck bringen.

Das ganze haben wir dann noch einmal nach Gewichtung geordnet und aufgereiht. Wie auf dem Bild auf der linken Seite ersichtlich haben wir jeweils die Überschrift mit den Punkten links aufgehängt, die Post-its, aus denen sich die Überschrift ergeben hatte, rechts daneben.

Individuelle Formulierungsansätze

Gedanklich befüllt mit den bisher besprochenen Wünschen und Vorstellungen der Teammember nahmen sich jetzt alle Teammember noch einmal in Ruhe Zeit, eine individuelle Formulierung der Teamvision vorzunehmen. Nach rund 10 Minuten konnten alle Teammitglieder eine Formulierung der gewünschten Situation in einer Ist-Beschreibung in 3-4 Sätzen vorweisen.

Gemeinsame „Vergesellschaftung“ und Übertragung in eine Formulierung

Jedes Teammitglied stellte die eigene Formulierung vor. Relativ schnell fand das Team eine Formulierung, die es als Ausgangsbasis für die gemeinsame Version der Teamvision nehmen wollte. Es wurden noch verschiedene Umstellungen und Ergänzungen vorgenommen, bis eine kompakte Formulierung in zwei Sätzen, mit der alle Teammitglieder zufrieden waren, gefunden war.

Die Formulierung haben wir dann in einer schöneren Form noch einmal aufbereitet und im Teamraum aufgehängt. Wichtiger als das formulierte Ergebnis selbst war dabei das im Laufe des Workshops gefundenen gemeinsamen Bildes davon, was dem Team wichtig ist.

——–
TIPPS UND TRICKS ZUM PRODUKTMANAGEMENT VON INTERNETANWENDUNGEN
Immer auf dem aktuellen Stand bleiben: Neue Artikel gibt es über FacebookTwitter, E-Mail (oben rechts) oder den RSS-Feed.

VERANSTALTUNGSHINWEIS: Tools4AgileTeams Konferenz am 7. November 2013 in Wiesbaden

Gründertraining in Aachen – Workshops zur Existenzgründung

Vom 04. – 07. Oktober 2011 findet das bereits 23. Gründertraining in Aachen statt. 2007 habe ich selbst am 15. Gründertraining teilgenommen. Die Veranstaltung war sehr professionell organisiert und hat viele interessante Informationen und Eindrücke in kurzer Zeit geboten. Wer sich mit einer Unternehmensgründung beschäftigt, sollte daher darüber nachdenken, diese Chance wahrzunehmen. Das Gründerzentrum der RWTH Aachen beschreibt seine Veranstaltung folgendermaßen:

Das Gründertraining bietet exklusive Informationen zur Unternehmensgründung in Workshops mit 15 Referenten aus Wissenschaft und Praxis inkl. umfangreichem Material zu allen Gründungsthemen (Kunde und Wettbewerb, Marktforschung, Personal, Finanzierung, Recht, Fördermöglichkeiten, etc.). Mit Mitarbeitern des Gründerzentrums werden Geschäftsideen diskutiert und bearbeitet. Darüber hinaus wird die Möglichkeit geboten, den eigenen Gründungserfolg bei einer interaktiven Gründungsimulation zu testen, Geschäftsideen mit Business Angels und GründerInnen zu diskutieren und das eigene Netzwerk zu erweitern.

Für die Teilnahme am Gründertraining ist eine vorherige Anmeldung notwendig. Anmeldeschluss ist der 16. September 2011.
Alle relevanten Informationen zur Bewerbung sind unter www.gruenderzentrum.rwth-aachen.de abrufbar.

Einen kleinen Einblick in die Gründungssimulation verschafft dieser Artikel von Till von Sonntagmorgen, der ebenfalls 2007 am Gründertraining teilnahm.

Wie wir mit Stattys Haftfolien effiziente Workshops gestalten

„Stattys – Geniale Methode für Workshops etc.“ titelte Stefan Hagen seinen neuesten Blogposts. Darin beschreibt er, wie mit elektrostatischen Folien Meetings und Workshops sehr effizient gestaltet werden können. Er weist dabei auch darauf hin, dass wir bei //SEIBERT/MEDIA mit Stattys-Folien arbeiten, was wir in der Tat sehr intensiv machen. Aufmerksam wurden wir auf Stattys durch unseren Kollegen und Freund Gerrit Eicker gemacht. Seit den ersten Erfahrungen damit haben sie einen festen Platz in unseren Moderationskoffern.

Wir nutzen sie häufig in Workshops und verwenden sie um Gedanken zu erfassen, zu strukturieren, zu priorisieren und ähnliches.

Anwendungsbeispiel

Wie kann die Nutzung solcher Folien konkret ausschauen? Ein Beispiel von einem Workshop, wie er regelmäßig in ähnlicher Form bei uns abläuft.
Wir möchten gemeinsam besprechen, welche Aufgaben wir als nächstes für die Entwicklung eines Neuprodukts angehen möchten. Im ersten Schritt sammeln wir in einem Brainstorming die möglichen Aufgaben. Wir schreiben dabei jeweils eine Idee auf einen Zettel und hängen diese Zettel an eine große freie Wand. Wenn die Brainstorming-Phase abgeschlossen ist, präsentieren wir nacheinander unsere Beiträge. Dabei beginnen wir auch mit dem „Clustern“ der Ideen. Das bedeutet, dass wir ähnliche oder gleiche Beiträge zu Gruppen verdichten, in dem wir die Zettel aneinander legen. Anschließend nehmen wir eine Priorisierung vor. Dazu verschieben wir die Zettel und Cluster so, dass die unserer Meinung nach wichtigsten Aufgaben nach oben rutschen, die unwichtigeren nach unten.

Meine Einschätzung

Während ich mit der Bezeichnung von Stattys als Methode nicht einverstanden bin, sondern es vielmehr als ein Werkzeug zur Unterstützung der Anwendung von Methoden wie Brainstorming betrachte, stimme ich der folgenden Einschätzung von Stefan Hagen zu:

Stattys gehören in den Methoden-Koffer eines Projektleiters.

Stattys versus Post-its

In den Kommentaren zu Stefans Artikel kam auch die Frage auf, ob nicht Post-its gleichermaßen gut nutzbar sind. Erst kürzlich hatten wir in einem Meeting wieder beides im Einsatz, Stattys und Post-its. Es zeigt sich, dass bei obiger Verwendung, die mit einem mehrmaligen Umkleben und auch übereinander hängen einhergeht, Post-its nicht wirklich mithalten können. Sie lassen sich z.B. bei Diskussionen über die Priorisierung nicht einfach x-fach hin und her schieben, ohne sichtbar an Klebkraft zu verlieren. Bei 40-50 Zetteln in einer Session kann es nervig werden, wenn immer wieder welche herunterfallen. Dies passiert insbesondere auf sehr rauen Untergründen, wie Raufasertapete. Stattys lassen sich auch davon nicht beeindrucken, sondern einfach verschieben.

Stattys und elektronische Systeme

Wir setzen bei unserer Arbeit sehr intensiv auf unser Confluence-Wiki und unser Aufgaben-Management-System JIRA. Daher bleibt die Dokumentation der Workshops in einem der Systeme nicht aus. So sind die Ergebnisse leicht Personen zugänglich zu machen, die nicht am Workshop teilgenommen haben.

Fazit

Stattys gehören für uns mittlerweile einfach dazu und unterstützen uns, Workshops unter Einbeziehung aller Teilnehmer durchzuführen. Es wird dadurch sehr ergebnisorientiert und fokussiert zusammen gearbeitet.

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.

Das Product Backlog Board

Diese Woche habe ich mit meinem Team einmal über das Product Backlog Board nach Empfehlung von Roman Pichler gesprochen. Das Product Backlog Board ist eine Visualisierung des Product Backlogs und der wichtigsten Constraints (= Nebenbedingungen/Auflagen) im Teamraum, so dass sich jederzeit jedes Teammitglied und auch die Stakeholder darüber informieren können.
Wir haben seit einiger Zeit eine Grundversion eines Backlog Boards im Büro gehabt, nach einer Schulung von Roman in München wurden mir jedoch noch einige Punkte deutlich, die ich mit dem Team abgestimmt habe.

Der Aufbau eines Backlog Boards

Den grundlegenden Aufbau eines Backlog Boards erklärt Roman in seinem Artikel „The Product Backlog Board„. Die folgende Darstellung zeigt ein reduziertes Product Backlog Board, an dem wir uns bei unserem Board orientiert haben:

product-backlog-board

Das Product Backlog Board

Die zentralen Bereiche des Product Backlog Boards sind die Story Area und die Constraint Area.

Die Story Area

In der Story Area wird der Product Backlog der aktuell in Arbeit befindlichen Version vorgehalten. Es handelt sich dabei nicht zwangsläufig um sauber ausformulierte Userstories, auch Fehlermeldungen können dort vorgehalten werden.
Von den Stories sind dort drei verschiedene Granularitäten vorzufinden: Stories, Epics und Themes.

Fein zerteilte Stories, die fertig für eine Umsetzung sind, befinden sich oben im „ready items“-Bereich. Die feine Zergliederung und Fertigstellung von Stories werden dabei auf diejenigen fokussiert, die im nächsten Sprint für eine Umsetzung vorgesehen werden.

Im unteren Teil der Story Area befinden sich Themes und Epics. Die Themes dienen der ganz groben Unterteilung des Backlogs nach Themenbereichen. Die Epics stellen eine grobe Formulierung von Features dar, die erst dann feiner formuliert und ausgearbeitet werden, wenn die Umsetzung nahe rückt.
Im Bereich der „ready items“ ist eine Priorisierung durch den Product Owner Pflicht, während im Bereich der Themes & Epics nach Roman eine Priorisierung nicht unbedingt erforderlich ist.

Die Constraint Area

In der Constraint Area werden die grundlegenden Anforderungen an das User Interface sowie operative Eigenschaften der Software festgehalten.
Das Produkt- und User Interface-Design kann in Form von Screens/Wireframes/Skribbles mit Anmerkungen zu den wichtigsten Vorgaben Vereinbarungen dargestellt werden.
Die operativen Eigenschaften können durch „Constraint Cards“ abgebildet werden, wobei pro Karte eine bestimmte operative Eigenschaft festgehalten wird. Das kann u.a. die Browser, für die optimiert werden soll, die Performance oder die Skalierbarkeit eines Softwareprodukts betreffen.
Die Constraints sollten mit der Definition of Done verknüpft werden, damit deren Einhaltung zum Bestandteil der Abnahme von jeder einzelnen Userstory wird. Das lässt sich gut am Beispiel der Browseroptimierung verdeutlichen. Wird diese in die Definition of Done aufgenommen, ist bei der Abnahme einer Story auch eine entsprechende Prüfung in den verschiedenen Browsern vorzunehmen. Ist die Erfüllung dieses Constraints nicht gegeben, gilt die Story somit nicht als „Done“.

[Anmerkung: Roman weist in seinem Beitrag über das Product Backlog Board noch eine „Model Area“ aus. Diese wurde im Rahmen der Schulung nicht behandelt und eignet sich auch für eine spätere Ergänzung.]

Regelmäßige Backlog-Pflege

Die regelmäßige Pflege des Product Backlogs und des Boards erfolgt in Form von Backlog Grooming Workshops oder Sessions. Das Team (inkl. Product Owner) nimmt dabei gemeinsam eine Aktualisierung des Backlogs vor, bespricht Stories, zerteilt sie, fügt neue hinzu und beschätzt sie. Für Teams mit 2-wöchigen Sprints schlägt Roman vor, wöchentlich 2 Stunden mit Backlog Grooming Workshops zu verbringen.
Wir hatten bisher weniger Zeit mit dem Grooming verbracht und haben die Workshops auch nicht zu einem festen Termin durchgeführt. Dies werden wir in Zukunft tun. Der Beitrag des Teams zur Erstellung und Pflege des Backlogs wird damit deutlich höher, wodurch auch sichergestellt wird, dass alle relevanten Aspekte einer Story besprochen werden.
In dem Workshop kann das Backlog Board auch direkt aktualisiert werden.

Mit diesem Setting werden wir in den nächsten Wochen erst einmal Erfahrungen sammeln. „Inspect and Adapt“. Die Reise mit Scrum bleibt spannend.

Weitere Artikel zur Product Backlog-Pflege:

Dir hat dieser Beitrag gefallen? Ich freue mich über einen Kommentar. Du kannst auch meinen RSS-Feed abonnieren oder mir auf Twitter folgen: @pherwarth.
%d Bloggern gefällt das: