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

Neue Produktideen austesten, ohne den Überblick zu verlieren – Lean Startup-Workshop mit Lukas Fittl (Spark59) am 8. April

Lean Startup ist das neue Buzzword – aber was bedeutet es wirklich? Wie kann man neuartige Produktentwicklung am effektivsten durchführen?

In einem Workshop am 8. April in Wiesbaden wird von Lukas Fittl eine praktische Umsetzung von Lean Startup erklärt – der Lean Stack, wie in folgenden Artikeln beschrieben: Teil 1Teil 2 & Teil 3.

Der Inhalt des Workshops

Lean Stack ist ein Ansatz der sich an existierenden Kan-Ban/SCRUM Konzepten orientiert, und das Konzept der A3 Reports aus dem Toyota Production System aufgreift um neue Produktideen zu dokumentieren und Resultate mit dem Team zu teilen.

leanstack

Im Workshop bearbeitet werden Themen wie das Build-Measure-Learn Konzept, die Definition von User Hypothesen (vs User Stories) und wie man den richtigen Rahmen für neue Produktideen setzen kann.

Ausserdem behandelt wird die Frage “Wann soll ich neue Funktionalität wirklich implementieren?”, und wie man qualitiative Interview und Beobachtungs-Techniken anwenden kann um unnötige Features und Entwicklungszeit zu vermeiden.

Aus diesem Workshop nimmt man mit:

  • Was Lean Startup für den klassischen Kan-Ban/SCRUM Ansatz bedeutet
  • Wie kontinuierliche Produktinnovation ermöglicht werden kann
  • Wie man im Team gemeinsam neue Produktideen und Hypothesen bearbeitet
  • Wie qualititative und quantitative Daten neue Produkt Ideen beeinflussen
  • Wie Vision, Business Modell und wirtschaftliche Ziele zusammenspielen

Der Workshopleiter: Lukas Fittl

Lukas Fittl von Spark59

Lukas Fittl von Spark59

Lukas Fittl arbeitet seit 2006 an seinen Startup Unternehmen – gründete unter anderem das Blogging Netzwerk Soup.io, und arbeitet mit Ash Maurya (Autor von Running Lean) gemeinsam an Spark59 und USERcycle.

Er hat zum Thema Lean Startup bereits in vielen Städten Europa’s referiert, unter anderem als Gastvortragender an der London Business School und als Keynote Speaker bei der Smidig Konferenz in Oslo.

Die Teilnehmer

Dieser 4-stündige Workshop ist praktisch orientiert, und richtet sich an Unternehmer, Produkt Manager und deren Team Mitglieder.

Es wird erwartet das die Teilnehmer aktiv an einem Produkt arbeiten und ihre eigenen Fragestellungen daraus mitbringen.

Austragungsort

Der Workshop findet statt in den Büroräumen von //SEIBERT/MEDIA GmbH in der Kirchgasse 6, 65185 Wiesbaden.

Anmeldung

Die Anmeldung ist ab sofort über diese Eventbrite-Seite möglich.

——–
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

Ist das Daily Standup für Teammitglieder zwingend?

Daily StandupVon Zeit zu Zeit erhalte ich Anfragen von Lesern, zu denen ich natürlich sehr gerne auch Rückmeldung gebe. Im aktuellen Fall handelt es ich um eine Frage, die uns vor längerer Zeit auch einmal bewegt hat: „Ist das Daily Standup für Teammitglieder zwingend?“
Gerne führe ich meine Gedanken hierzu aus, freue mich aber auch über Ergänzungen anderer Leser über die Kommentarfunktion.

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:

Foto: tomnatt

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

Hyperproduktive Teams mit Scrum: „From Good to Great“

Wie können gute Teams mit Hilfe von Scrum zu großartigen Teams werden? Damit beschäftigt sich Scrum Co-Founder Jeff Sutherland schon seit vielen Jahren. Vor einiger Zeit hat er hierzu in seinem Blog geschrieben.

Jeff Sutherland macht allen motivierten Teams Hoffung, dieses Ziel erreichen zu können. Nach dem aktuellen Forschungsstand soll jedes Team in der Lage sein, hyperproduktiv zusammenzuarbeiten, auch wenn das Unternehmen, in dem das Team arbeitet, nicht die optimalen Bedingungen bietet.

Auf welche Punkte sollten Teams unbedingt achten, wenn sie hyperproduktiv zusammenarbeiten möchten?

  • Alle Teammitglieder müssen in Scrum geschult sein.
  • Der Backlog muss READY seine, bevor er in einen Sprint übernommen wird.
  • Das Software-Inkrement muss am Ende jedes Sprints DONE sein.
  • Immer wenn nur eine Person eine Aufgabe erledigt werden kann, sollte sofort mit Pair Programming gearbeitet werden.
  • Volle Fokussierung – kein Multitasking.
  • Das Team nutzt ein physisches Scrum Board / Taskboard.
  • Kurze Sprints, häufig von nur einer Woche.
  • Der Burndown erfolgt auf Story Point-Ebene (nicht Tasks oder Stunden)
  • Alles (inklusive Support) wird durch den Product Owner priorisiert.
  • Die höchstpriorisierten Hindernisse müssen aus dem Weg geräumt werden.
  • Die Führung des Teams erfolgt nach dem „Servant leadership“–Gedanken.

Eine Verdopplung der Produktivität ist laut einer Untersuchung bereits dann möglich, wenn darauf geachtet wird, dass alle Arbeiten am Ende des Sprints auch wirklich DONE sind. Die Fehlerquote konnte bei den betrachteten Scrum-Teams damit um ganze 40 Prozent reduziert werden. Wenn die Teams konsequent daran arbeiten, Hindernisse aus dem Weg zu räumen und ihre Arbeiten wirklich DONE abzuschließen, können sie leicht ihre Produktivität drastisch erhöhen. Leider tun dies nur geschätzte 50 Prozent der Scrum-Teams auf der Welt.

Eine weitere Verdopplung der Performance des Teams kann erreicht werden, wenn der Backlog einen hohen Grad von READY erreicht. Dies wirkt sich direkt auf die Effizienz in der Story-Umsetzung aus. Wenn Teams es schaffen, ihre Arbeiten jeweils entsprechend der Definition of DONE abzuschließen und auch einen sauberen Backlog pflegen, der hochgradig READY ist, können sie den Untersuchungsergebnissen nach durchaus mit der vierfachen Produktivität eines Durchschnittsteams erreichen.

Ein weiteres Level der Produktivität kann erreicht werden, wenn es sich um selbstorganisierende Teams handelt, die an der Maximierung ihrer (nachhaltigen) Team Velocity arbeiten und gemeinsame Ziele verfolgen. Dies erfordert flache Organisationsstrukturen und enge Zusammenarbeit.

Auch wenn es einfach klingt, ist es mit Sicherheit herausfordernd in der Umsetzung. Auch hier zeigt sich, dass eine gute Anwendung von agiler Softwareentwicklung viel Disziplin erfordert. Angesicht der starken Produktivitätsverbesserungen, die möglich sind, lohnt es sich denke ich dennoch, sich weiter in diese Richtung zu entwickeln. Dabei hilft diese Präsentation von Jeff Sutherland:
A Practical Roadmap to Great Scrum: A Systematic Guide to Hyperproductivity (PDF)

Foto: drewgstephens

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

%d Bloggern gefällt das: