Tools4AgileTeams 2013 – aktueller Stand der Konferenz-Planung

Am 7. November 2013 findet die zweite Ausgabe der Konferenz Tools4AgileTeams in Wiesbaden statt. Es geht um einen intensiven Austausch der Teilnehmer rund um die Anwendung von Tools in agilen Software-Entwicklungsteams. Bis zum Start der Konferenz bleibt noch etwas Zeit, dennoch sind die Vorbereitungen der Konferenz schon in vollem Gange. So wurde bereits der Fachbeirat bestätigt, der Call for Sessions gestartet und eine neue Location gefunden. Ein kompakter Überblick über den aktuellen Stand der Vorbereitungen:

Fachbeirat steht, Call for Sessions gestartet

Der für die erste Konferenz im Vorjahr etablierte Fachbeirat mit Paul Herwarth von Bittenfeld, Jan Segers, Joachim Seibert und Joern Bock bleibt in dieser Form bestehen. Er begutachtet die eingereichten Vortragskonzepte der Speaker, gibt Rückmeldungen zu den Einreichungen und trifft unter allen vorgeschlagenen Themen die Auswahl. Genauere Infos zu den Mitgliedern des Fachbeirats und ihren Referenzen finden Sie auf der Website zur Konferenz.

Für den Vortragsteil der Tools4AgileTeams sind wie im letzten Jahr acht bis zehn Fachvorträge vorgesehen. Interessierte Speaker können ihre Themen dem Fachbeirat jetzt vorschlagen.

Besonders erwünscht sind hier Erfahrungsberichte über den Einsatz digitaler und analoger Tools in Projekten. Auch Vorträge, die beleuchten, unter welchen Rahmenbedingungen der Einsatz von Software-Anwendungen besonders wertvoll oder besonders hinderlich sein kann, sind sehr interessant. Als Anregung bietet sich ein Blick auf das Konferenzprogramm des Vorjahres an.

Also: Wenn Sie Einblicke in Herausforderungen, Problemlösungen und Best Practices Ihrer agilen Projektpraxis bieten und Ihre Erfahrungen im Rahmen eines Fachvortrags teilen möchten, reichen Sie Ihr Thema jetzt über die Konferenzwebsite ein. Deadline ist der 1. Juli 2013. Nach einer initialen Sichtung Anfang Juli meldet sich der Fachbeirat bei Ihnen und gibt Ihnen ein erstes Feedback.

Die Location in Wiesbaden steht fest

Murnau-Filmtheater_Nachtaufnahme_pink_950

Austragungsort der Tools4AgileTeams 2013 ist das Murnau Filmtheater in Wiesbaden.

Dort werden wir das großzügige Foyer, den flexiblen Multifunktionsbereich, einen Konferenzraum sowie den Kinosaal für die Konferenz in Anspruch nehmen können.

Neben der flexiblen Raum-Nutzungsmöglichkeit und der Chance, dieses Jahr noch mehr Teilnehmer als im ausverkauften Vorjahr aufnehmen zu können, hat uns vor allem die zentrale Lage direkt am Wiesbadener Hauptbahnhof überzeugt.

Alle Informationen rund um die Konferenz gibt es auf der Website unter www.tools4agileteams.com.

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

About these ads

Weihnachtspäckchenkonvoi goes Agile – agiles Vorgehen in einem sozialen Projekt

Beim Dezembertreffen der Agile Usergroup durften wir bei einem Vortrag von Sebastian Friedsam und Marco Tommasone einiges über das soziale Projekt Weihnachtspäckchenkonvoi und deren Organisation erfahren.

Beim Weihnachtspäckchenkonvoi werden jedes Jahr Tausende Pakete mit Weihnachtsgeschenken (u.a. Spielsachen) für Kinder in Rumänien, Ukraine und Moldawien gesammelt und in einem Konvoi in diese Länder transportiert. Die Organisation der Aktion mit Unterstützung von vielen Freiwilligen ist jedes Jahr eine Herausforderung, die diese in ihrer Freizeit auf sich nehmen.

Im Vortrag stellten Sebastian und Marco vor, was der Weihnachtspäckchenkonvoi ist, was die derzeitigen Herausforderungen sind und wo möglicherweise ein agiles Vorgehen hilfreich sein könnte. Dies wurde im Anschluss noch umfangreich von der Teilnehmern diskutiert. Der Vortrag von Sebastian und Marco ist in einer ersten Version als 3-Teiler bei YouTube zu finden.

Weitere Informationen:

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

Produktmanagement Lesetipps: Scrum an den Boss verkaufen, Make-or-Buy, ROTI, Tage der Entscheidungen

glassesEine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um die Bewerbung von Scrum beim Vorgesetzten, Make-or-Buy-or-Partner-Entscheidungen, Feedback für Meetings mittels ROTI und um “Tage der Entscheidungen”. Viel Spaß beim Lesen!

  • Schon häufiger habe ich es erlebt, dass Mitarbeiter die Einführung von Scrum in ihrem Unternehmen vorantreiben wollten und sich überlegt haben, wie Sie der Führungsebene die Vorteile vermitteln können. Robert Karlsson hat in dem Artikel “Key Arguments to Sell Scrum to Your Boss” einige Empfehlungen zusammengetragen, wie vorgegangen werden kann.
  • Building Your Own Product – Isn’t Always the Best Strategy“, diesen Reminder gibt uns das Blog onproductmanagement. Es sollte in Betracht gezogen werden, dass der Kauf einer bestehenden Lösung oder auch eine Partnerschaft der bessere Weg sein könnten.
  • Im Blog von //SEIBERT/MEDIA wird ein Verfahren vorgestellt, mit dem schnell Feedback zu Besprechungen und Workshops eingeholt werden kann: ROTI: Schnelles Feedback bei jeder Gelegenheit. Es wird auch gleich eine Druckvorlage mitgeliefert, mit dem die kurze Abfrage bei den Teilnehmern durchgeführt werden kann.
  • 3 Fragen sollten sich Unternehmen und Organisationen regelmäßig stellen, empfehlen Förster & Kreuz in ihrem aktuellen Artikel “Tage der Entscheidungen“: 1. Wo liegen die größten Chancen, auf die wir uns konzentrieren sollten? 2. Welche Fähigkeiten brauchen wir, um von diesen Chancen profitieren zu können? 3. Womit vergeuden wir heute Zeit und wofür sollten wir diese besser verwenden? Sie selbst möchten sich diese Frage fortan vier Mal pro Jahr stellen.

Foto: 0xMatheus

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

Tools4AgileTeams – weitere Vorträge der Konferenz bekannt gegeben

Am 8. November werde ich gemeinsam mit //SEIBERT/MEDIA das erste Mal die Ausrichtung einer größeren Konferenz vornehmen. Bei der Tools4AgileTeams, über die ich hier schon berichtet habe, wird sich aller um den Einsatz von Tools bei agilen Softwareentwicklungsteams drehen. Wir werden darüber sprechen, wann Tooleinsatz sinnvoll und wann Spielerei ist, welche Softwarelösungen bestehen und ähnliches.

Wir konnten zahlreiche renommierte Sponsoren gewinnen. Zudem haben wir eine ganze Reihe von spannenden Vorträgen im Konferenzprogramm zu bieten. Die aktuelle Liste der Vorträge schaut folgendermaßen aus:

See you on the other side – Scrum-Meetings mit verteilten Teams“ von Dr. Bernd Krehoff (Boris Gloger Consulting): Scrum-Meetings mit geografisch verteilten Teams sind eine echte Herausforderung. Meistern kann sie nur, wer die Distanz als echte Hürde begreift und die Meetings anders gestaltet. Tools können helfen, aber noch viel wichtiger ist die Wahl des richtigen Formats. Wie mache ich ein Sprint Planning mit einem Team, das in drei Ländern sitzt? Kann eine Retro dann überhaupt funktionieren? Und was ist mit Schätzen? Wir bieten: Erfahrung aus diversen Projekten sowie praktisches Know-How.
  Hör zu! Effektives Feedback verbessert die Software“ von Sven Peters (Atlassian)Früh Feedback von den Benutzern deiner Software zu bekommen, ist extrem wichtig für Qualität und Akzeptanz deiner Applikation. Hör zu, was deine Kunden, Tester und Stakeholder über neue Features zu sagen haben. Dies hat direkten Einfluss darauf, ob du das nächste Killer-Feature auslieferst oder einen Flop landest. Lass deine Kunden entscheiden, welche Ideen ein Hit werden und welche wieder aus der Software rausfliegen sollten.Finde heraus, wie Atlassian JIRA einsetzt, um effektiv Feedback einzusammeln und diese Informationen dann wiederum in den Entwicklungsprozess einfließen lässt. Lerne, wie wir unsere cloudbasierte Software nutzen, um Features bei einigen Kunden schon mal zu testen, bevor die breite Masse diese erhalten.
Evaluation von Project Collaboration Software Tools für die Anwendung im agilen Projektmanagement” von Holger Bock (Pentamino)Bei der Zusammenarbeit agiler Projektteams müssen über verschiedene Zeitzonen hinweg Dokumente bearbeitet, Informationen und der Projektfortschritt allen Beteiligten transparent gemacht werden. Einen Marktüberblick über die zahlreichen SW-Tools zu verschaffen, ist den meisten Unternehmen aus Zeitgründen unmöglich. Deshalb wurde ein Vergleich von ca. 20 Tools erstellt, um die Entscheidung für eine geeignete SW dem Management zu erleichtern. Die Ergebnisse werden in diesem Vortrag präsentiert.
Lebende Veränderung – eine wahre Geschichte eines agilen Unternehmens“ von Egor Sviridenko und Olga Ikhelis (Target Process): Christian (25) hat seine eigene Firma gegründet, mit dem Ziel das beste Produkt in seinem Marktsegment zu schaffen. Als das Unternehmen die verschiedenen Phasen seiner Entwicklung durchläuft, von den ersten Gehversuchen, durch seine Wegfindung, und bis zur Etablierung auf dem Markt und Reifung, muss Christian und seine Teams mit vielen Herausforderungen umgehen. Das Unternehmen wächst kontinuierlich, und der Markt verändert sich auch ständig. Auf diesem Weg müssen die internen Prozesse mehrmals angepasst oder auch völlig verändert werden. Was Christian dabei lernt, ist dass die Reise das Ziel ist, und die konstante Veränderung der Schlüssel zum Erfolg….Eine wahre Geschichte über das Leben eines Unternehmens. Ihres Unternehmens?
Das leidige Thema – Papier oder Software?“ von Jan SegersWer Scrum kennt hat mit diesem Thema oftmals bereits Erfahrungen gemacht. Welches Medium soll ich in meiner Firma einsetzen? Macht es Sinn möglichst viel auf Papier zu bannen oder sollte ich mich doch eher auf moderne Software verlassen? Oftmals werden diese Fragen nur subjektiv beantwortet. Dieser Vortrag analysiert beide Medien und erklärt objektiv, wann es Sinn macht auf welches Medium zu setzen anhand des Scrum Taskboards.
6 Jahre Erfahrungen mit Scrum-Tools – eine Retrospektive“ von Michael KlossScrum ist momentan sicherlich eine der bekanntesten agilen Methoden und daher existieren diverse Tools, die einem helfen sollen, Scrum als Prozess zu leben.
Der Vortrag ist eine Retrospektive aus den letzten 6 Jahren speziell auf den Fokus Scrum-Tools gerichtet. Es geht dabei sowohl um verteilte Teams als auch OnSite Projekte und wie das Tooling dort eine Rolle spielt, auch in Bezug auf andere Tools für Requirements, Management oder Testing.
Scrum Rollen sauber einhalten“ von Axel Jung (AOE Media)Scrum wird dann erfolgreich, wenn die Prozesse und Regeln auch eingehalten werden. Nur wenn jeder in seiner Rolle bleibt, fällt man nicht in die alten Strukturen zurück. Das Tool Kunagi hat uns dabei unterstützt den Scrum Prozess nach dem Idealbild zu leben und über Jahre hinweg nicht aufzuweichen. Die verschiedenen Rollen haben ihre fest definierten Grenzen und die User dürfen nur Aktionen ausführen die ihren Rollen entsprechen.Am Beispiel eines Telekommunikations Unternehmen zeigen wir die Einführung von Scrum mittels Kunagi und werden das Tool genauer vorstellen.
JimFlow – Die Evolution von Kanban bei Jimdo“ von Michael Lehr und Nadja Macht (Jimdo)Kanban wird seit Oktober 2010 bei Jimdo eingesetzt, um die Kommunikation zwischen den Teams zu verbessern, die Geschwindigkeit zu erhöhen und mehr Transparenz im gesamten Unternehmen zu schaffen. Auf diesem Wege ist Kanban ein wichtiger Bestandteil unserer Kultur geworden.Durch den Einsatz in nahezu allen Unternehmensbereichen und den Bedarf, die größer werdende Kluft zwischen digitalem Issue Tracking und analogen Kanban Boards zu schließen, haben wir JimFlow entwickelt.

Die Anmeldung ist weiterhin über die Konferenz-Website möglich.

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

Agiles Vorgehen zu Hause anwenden

Taskboard at homeWer die Vorzüge eines agilen Vorgehens im Berufsleben kennen und schätzen gelernt hat, möchte mitunter auch zu Hause nicht darauf verzichten. Viele Aufgaben und zu wenig Zeit, um alle abzuarbeiten, ist für viele Agilisten nicht nur im beruflichen, sondern auch im privaten Umfeld eine Herausforderung. Also heißt es, bewusst zu entscheiden, was “ausgeliefert” wird und was vorerst nicht umgesetzt wird.

Besonders häufig findet ein einfaches Kanban-Board Anwendung, das dabei hilft, den vollen Überblick über die anliegenden Aufgaben und den Stand der Bearbeitung zu behalten. Es wird dann von “Personal Kanban” gesprochen. In einem priorisierten Backlog wird festgehalten, welche Arbeiten in welcher Reihenfolge anfallen. In regelmäßigen Standups wird gemeinsam besprochen, was als nächstes angegangen wird. Etwa nach dem gemeinsamen Abendessen. Ein WiP-Limit begrenzt die Anzahl der parallel bearbeiteten Items. Teilweise wird das WiP-Limit am Wochentag ausgerichtet, da z.B. am Wochenende mehr Zeit für die Erledigung privater Aufgaben zur Verfügung steht als unter der Woche.
Damit eine Aufgabe tatsächlich als abgeschlossen gilt, sollte sie entsprechend einer formulierten Definition of Done abgeschlossen sein.
Abweichend von einer solchen Einteilung des Boards in “Backlog”, “Doing” und “Done” wird teils auch mit einem Board, das nach den Wochentagen eingeteilt ist, gearbeitet.

Ausgangspunkt für viele Personal Kanban-Anwender ist eine Situation, in der sie durch besonders viele Aufgaben überwältigt werden. Dies kann z.B. durch eine anstehende Hochzeit, einen Hausbau, Umzug oder ähnliches bedingt sein. Genau unter solchen Umständen ist es besonders wertvoll, sich die Zeit zu nehmen, um einen vollständigen Überblick der noch ausstehenden Arbeiten zu erhalten. Ein persönliches Kanban-Board aufzusetzen und initial zu befüllen ist mit weniger als einer Stunde Zeiteinsatz locker machbar. Ausprobieren lohnt. Durch regelmäßiges Reflektieren über den Prozess können nach und nach Optimierungen vorgenommen und so ein passendes persönliches Set gefunden werden.

Vereinzelt wird auch vom Einsatz von Scrum in der Familie gelesen, hier ist allerdings bereits die Rolleneinteilung in ScrumMaster und Product Owner unter Umständen eine kleine Herausforderung. Aber warum nicht mal selbst probieren?

Erfahrungsberichte zur Agile-Anwendung im privaten Umfeld:

Foto: orcmid

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

Produktmanagement Lesetipps: Gründen ohne technischen Co-Founder, Design Thinking, Reflective Thinking, Peer Reviews

Eine Ladung Informationen für Produktmanager gefällig? Wir haben Euch wieder eine Reihe von Lesetipps zusammengestellt. Diesmal geht es um’s Gründen ohne technischen Co-Founder, um den Ansatz “Design Thinking”, etwas Zeit zum Reflektieren, sowie die Kraft von Peer Reviews. Viel Spaß beim Lesen!

  • Why you should stop looking for a technical co-founder – at least for now von Andreas Kwiatkowski kann all denjenigen Nicht-Techies Mut machen, die denken, ohne das Erlernen einer Programmiersprache oder einen technisch versierten Co-Founder ließe sich die eigene Idee nicht realisieren. Die ersten Artikel auf seinem Blog Kwiat.com sind sehr vielversprechend und machen ihn zu einem Lesetipp für alle Internet-Produktmanager.
  • Ahmet Emre Acar stellt bei Gründerszene in seinem Artikel “Die Welt des Design-Thinking“ die Grundlagen des Design Thinking-Ansatzes dar. Dieser Innovationsansatz stellt in den Vordergrund, Dinge mit dem Menschen im Fokus neu zu erschaffen.
  • Don’t be Too Busy to Do Some Reflective Thinking - Wer sich täglich einem Information Overload aussetzt, sollte von Zeit zu Zeit ganz bewusst zurücktreten und sich die Zeit für etwas Reflektion nehmen. Marty Zwilling gibt uns ein paar Tipps, wie wir dabei vorgehen können, ohne auf der anderen Seite in ein “over-thinking” zu verfallen.
  • Sebastian Schneider betont in seinem Beitrag zu “Peer Reviews” die Bedeutung einer frühen Feedbackschleife durch die direkten Kollegen, die sehr kostengünstig ist und eine zeitnahe Qualitätssicherung ermöglicht, die spätere teure Korrekturen meidet.

Foto: 0xMatheus

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

Was kennzeichnet ein gutes Product Backlog?

Deep WatersDas Product Backlog enthält alle Arbeiten, die für die Erstellung eines erfolgreichen Produkts erforderlich sind. Es hat einen erheblichen Einfluss auf die Team-Produktivität, ob mit einem guten oder einem schlechten Product Backlog gearbeitet wird. Daher sollte sich gerade der Product Owner auch Gedanken über die Qualität des Backlogs machen. An welchen Kriterien können sich Product Owner und Team orientieren, um die Güte ihres Backlogs einschätzen zu können?

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 FacebookTwitter, E-Mail (oben rechts) oderRSS-Feed.

Englische Version des Artikels

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.

Follow

Bekomme jeden neuen Artikel in deinen Posteingang.

Schließe dich 915 Followern an

%d Bloggern gefällt das: